DMARCレポートに認証失敗が出たときの、原因の切り分け方

ECサービスからお客さんへのメールが迷惑メールに入る、という話があった。送信元のドメインは自社のもので、設定もしてある。なのに届かない。

ヘッダーを確認すると、SPFはpassしていた。しかしDKIM署名が無く、DMARC認証が失敗していた。

「DKIMが無い」が原因に見えるが、実はもう一段ある。

どのサービスが署名するべきか

DKIMは「送信したメールサーバが署名する」のが原則だ。ところが、自社ドメインのメールをECサービス経由で送るケースでは、実際に送信するのはECサービスのバックエンドになる。

このケースでは、ECサービスがさらに外部のメール配信サービスを使っていた。店舗オーナーからは直接触れない場所に、送信の実体があった。

「DKIMの設定がおかしい」と思って自分のDNSを何度見ても、そこじゃない。

まず確認したのはSPFの連鎖だ。自分のSPFレコードに include: で外部のドメインを参照しているとき、そこからさらに参照が続くことがある。

AIにこう頼んだ：「このSPFレコードの include: を辿って、最終的にどのIPアドレスが許可されているか教えて」

辿っていくと、外部配信サービスのIPが何段か先の include: で許可されていた。ECサービスがそのサービスをSPFに組み込んでいたので、自分のSPFレコードに include: 一行書くだけで連鎖的に許可されていた、ということだ。

「SPFレコードを書いた覚えはないのにpassする」は、こういう連鎖が起きているとき出てくる。ちゃんと許可されているので問題ではない。

次に見たのがDKIM。自分のDNSには確かに設定していた。

ECサービスから指示されたとおり、セレクタ名を付けたDKIM用のレコードを、CNAMEで外部サービスのドメインに委任する形で入れてあった。公開鍵の実体は委任先（外部サービス側）に置かれていて、自分のDNSはそこを指しているだけ、という構成だ。

nslookupで公開鍵を追いかけると、一方のセレクタは公開鍵が確認できた。レコード自体は存在する。

しかし受信したメールのヘッダーに DKIM-Signature が一行もない。

公開鍵はある、でも実際に署名していない。これはDNS側の問題ではなく、送信する側（外部サービス）が署名処理を行っていないということだ。こっちからは手出しができない。

もう一つ確認したのが、Return-Pathだ。

ヘッダーFromは自社ドメインになっている。しかしReturn-Pathは外部配信サービスのドメインだった。

AIにこう頼んだ：「このReturn-PathとFromの組み合わせは、DMARCの観点で問題ある？」

DMARCは「ヘッダーFromのドメイン」と「SPFやDKIMのドメイン」が一致していないと通らない（これをアライメントという）。Return-Pathが外部サービスのドメインのままだと、SPFはpassしていてもDMARCでアライメントが取れない。

「SPFはpassしているのにDMARCが失敗する」の、ほぼ毎回の原因はここだ。

切り分けの順番はこうなる。

「設定してあるのに認証失敗」は、たいてい設定が存在する場所と実際に署名するサービスが別、というパターンだ。

ECサービスや外部サービスがバックエンドで送信している場合、こちらから署名処理を変えることはできない。

選択肢は2つある。

サービス提供者に問い合わせて、DKIM署名に対応してもらうか。それが難しければ、自社ドメインのDMARCポリシーを p=none（失敗しても受信は拒否しない）にしておく。少なくとも迷惑メール扱いにならない最低限は確保できる。

中途半端な状態は気持ち悪いが、外部サービスのバックエンドをこちらで制御できない以上、そこに落としどころを置くしかない。

このケースで一点補足しておく。

送信元をAサービスに委託しているとき、Return-Pathがそのサービスのドメインになるのは普通の動作だ。バウンスメール（配信失敗時の通知）をサービス側で処理するための仕組みなので、「なりすまし」ではない。

ドメインオーナーが意図的にそのサービスを使う設定をしており、SPFレコードにもそのサービスを含めている以上、認証の観点で問題はない。DKIMが無いことだけが残る課題で、それは「不正」ではなく「改善できていない」という話だ。

ここを混同すると、余計なところを触って状況を悪化させる。