SPFはpassなのにDMARCがfailするとき｜アライメントの確かめ方

DMARCのレポートや届いたメールのヘッダーに spf=pass と出ているのに dmarc=fail になることがあります。

設定が壊れているわけではありません。認証は成功しています。成功したドメインが差出人(From)のドメインと揃っていない、というのがこの状態です。DMARCではこれをアライメントと呼びます。

先に結論を書きます。

• SPFやDKIMが成功していてもそのドメインがFromと揃っていなければDMARCは失敗します
• 揃っているかは1通ごとに決まります。DNSの設定を見ても分かりません
• 揃える方法は2つあります。SPF側(Return-Pathを自分のドメインにする)とDKIM側(署名の d= を自分のドメインにする)で、どちらか片方で足ります
• 手元のメールのヘッダーをメールヘッダー解析に貼れば、From と Return-Path の関係を確認できます
• そもそもSPFもDKIMも設定していない場合は別の話になります

この記事は、届いたメールのヘッダーやDMARCのレポートを手元に持っていて、認証が通っているのにDMARCが失敗する理由を知りたい方に向けて書いています。SPFもDKIMもまだ設定していない場合は「DMARCが機能しない状態です」と出たときを読んでください。

用語をここで揃えます。すでにご存じの場合は読み飛ばしてください。

実際のヘッダーで何が起きているか

外部のメール配信サービスを使っている場合の例です。

Authentication-Results: mx.example.jp;
       spf=pass smtp.mailfrom=bounce@mail.haishin.example;
       dkim=pass header.d=haishin.example;
       dmarc=fail header.from=example.jp
From: support@example.jp
Return-Path: <bounce@mail.haishin.example>
DKIM-Signature: v=1; a=rsa-sha256; d=haishin.example; s=s1; ...

spf=pass も dkim=pass も出ています。それでも dmarc=fail になっています。

理由は3つのドメインを並べると分かります。

SPFもDKIMも配信サービス側のドメインで成功しています。差出人の example.jp とは別のドメインです。

RFC 9989 セクション4.4.1 は、DKIMについてこの扱いの理由を書いています。

There is currently no generally accepted mechanism by which a Domain Owner may assert a list of third-party DKIM Signing Domains that are authorized to sign on behalf of a given Author Domain. Therefore, DMARC requires that Identifier Alignment is applied to the DKIM-Authenticated Identifier because a message can bear a valid signature from any domain, even one used by a bad actor.

(あるAuthor Domainの代理として署名する権限を持つ第三者のDKIM署名ドメインの一覧をドメイン所有者が表明するための一般に受け入れられた仕組みは、現時点で存在しない。したがってDMARCは、DKIMで認証された識別子に対して識別子のアライメントを適用することを求める。なぜなら、悪意ある者が使うドメインを含め、どのドメインからでも有効な署名を持つメッセージを作れるからである)

どのドメインからでも有効な署名は作れます。だから署名があることだけでは、差出人を名乗ってよい根拠になりません。

SPF側で揃える

SPFが評価するのはReturn-Pathで、DMARCが見るのはFromです。この2つが同じドメインになれば、SPF側でアライメントが成立します。

外部のメール配信サービスを使うとReturn-Pathがサービス側のドメインになっていることがあります。バウンス(宛先不明などの通知)をサービス側で受け取る構成です。

利用しているサービスの設定画面や公式ドキュメントで、Return-Path(エンベロープの送信元、バウンスの受け取り先)を自分のドメインに変えられるかを確認してください。呼び名はサービスごとに違います。変更できる場合は、設定するとDNSにレコードを追加することになります。

なお、Return-Pathが空のメールもあります。バウンス通知そのものがこの形です。この場合、SPFはHELOで名乗られたドメインを見ます。そのドメインはFromと揃わないのが普通なので、SPF側のアライメントには使えません。

DKIM側で揃える

DKIMの署名が名乗るドメイン(d=)をFromと同じにすれば、DKIM側でアライメントが成立します。

ここで3つの条件を分けて考えてください。どれも別のことです。

配信サービスが自社のドメインで署名している場合、最初の2つは満たされますが3つ目が満たされません。

本サイトの診断は、次の13の事業者について、利用者のドメイン配下のセレクタで公開鍵を配っていることを実測で確認しています。エックスサーバー、ConoHa WING、Google Workspace、Microsoft 365、SendGrid、Mailchimp、Zendesk、Postmark、Mailgun、Brevo、iCloudメール(カスタムドメイン)、ベンチマークメール、メール配信基盤(maildeliver.jp)です。この一覧はnpm run verify:selectorsで再現できます。挙げていないサービスを使っている場合は、利用しているサービスの設定画面や公式ドキュメントで、自分のドメインで署名する設定があるかを確認してください。設定できる場合は、公開鍵をDNSに登録することになります。

メールに複数の署名が付くこともあります。DMARCに使えるのはFromと揃っている署名だけです。

relaxedとstrict、そして組織ドメインの決まり方

揃っているかの判定には2つのモードがあります。

aspf はSPF側、adkim はDKIM側の指定で、2つは独立しています。片方だけをstrictにすることもできます。どちらも既定はrelaxedです。

RFC 9989 セクション4.4 は、3つの例を挙げています。

同じ節には、実際の運用についてこう書かれています。

In practice, nearly all Domain Owners have found relaxed alignment sufficient to meet their needs.

(実際には、ほぼすべてのドメイン所有者がrelaxedのアライメントで必要を満たせると分かっている)

ここで注意が要ります。組織ドメインの求め方がRFC 9989で変わりました。 以前は Public Suffix List という外部の一覧を参照する形でしたが、いまはDNSを1ラベルずつ上へたどって判定します(RFC 9989 セクション4.10.2)。

このため、文字列の末尾が一致しているかどうかで組織ドメインを判定することはできません。どこまでが組織ドメインかはDNSの状態で決まります。

貼り付けて確かめる

メールヘッダー解析に届いたメールのヘッダーを貼るとFromとReturn-Pathを取り出して表示します。貼り付けた内容はブラウザの中だけで処理され、サーバーには送信されません。

このツールが答えられる範囲は3つに分かれます。

3つ目で判定していない理由は、組織ドメインの判定にDNSをたどる必要があるためです。このツールは貼り付けた内容を外部へ送らない作りなので、その問い合わせを行いません。

最終的な答えは Authentication-Results: の dmarc= にあります。受信側が実際に下した判定なので、これが確実です。ツールは、その理由を切り分けるために使ってください。

relaxedを選ぶときに知っておくこと

relaxedは組織ドメイン単位で揃っているとみなすため、同じ組織ドメインのサブドメインからも認証を通せます。RFC 9989 セクション11.8 は、この点に触れています。

攻撃者があなたの組織ドメインのサブドメインのDNSを操作できる状態になった場合、そのサブドメインでSPFレコードを公開し、Fromにあなたのドメインを書いたメールでDMARCを通せる、という筋道です。

サブドメインを外部のサービスへ委任している場合に関係します。サブドメインの扱いはサブドメインのDMARC設定で扱っています。

判定そのものが成立しない場合

RFC 9989 セクション4.4 は、判定の前提についても書いています。Fromヘッダーが壊れている場合、無い場合、複数ある場合には、アライメントの判定自体が成立しません。適用すべきDMARCレコードを確実に決められないためです。この扱いは仕様の範囲外とされています。

直す順序

1. ヘッダーを見て、SPF側とDKIM側のどちらが揃っていないかを確かめます
2. どちらか片方を揃えます。両方を同時に直す必要はありません
3. もう一度自分宛にメールを送り、dmarc=pass になることを確かめます

SPFとDKIMのどちらを選ぶかの判断はSPFだけでDKIMは不要かで扱っています。DNSに追加したレコードが反映されるまでには時間がかかることがあり、その場合はDNSの変更が反映されないときを読んでください。

ドメイン全体の設定はメール認証の診断で確認できます。