SPF・DKIM・DMARCをわかりやすく解説

メール認証は、どのサーバーが送信を許可されていたか、メッセージに署名があるか、その認証結果が受信者に表示されるドメインと一致するかを判断する材料を受信側へ提供します。

SPF、DKIM、DMARCは互いに関係していますが、それぞれ異なる内容を確認します。

SPFは、メッセージを送信したサーバーが、そのメッセージのエンベロープ送信元ドメインに公開されたポリシーで許可されているかを確認します。この技術上の送信元は、通常、Return-Pathヘッダーで確認できます。

ドメインは、SPFポリシーをDNSのTXTレコードとして公開します。ポリシーでは、送信サーバーのIPアドレスを直接許可したり、そのドメインに代わって送信するサービスのレコードを参照したりできます。

SPFへの合格は重要ですが、それだけでは、受信者に表示されるFrom:アドレスのドメインと、SPFで認証されたドメインが一致することまでは証明できません。この関係はDMARCのアライメントで確認します。

SPFレコードは、送信サービスごとに別々に公開するのではなく、同じホスト名（同じDNS名）につき1つにまとめます。ルートドメインとサブドメインは別のホスト名なので、それぞれ個別のSPFレコードを持てます。

あるサービスから、次のレコードを公開するよう案内されたとします。

v=spf1 include:_spf.google.com ~all

別のサービスからは、次のように案内されるかもしれません。

v=spf1 include:mailservice.example ~all

この2つを同じホスト名の別々のSPFレコードとして公開してはいけません。両方の送信サービスを1つのポリシーへまとめます。

v=spf1 include:_spf.google.com include:mailservice.example ~all

SPFの評価には、DNSルックアップ回数の上限もあります。各includeの参照先でさらにDNSルックアップが発生する場合があるため、構文上は正しく見える長いポリシーでも評価に失敗することがあります。

同じホスト名のSPFレコードは1つにし、実際に使うサービスだけを含めてください。レコードに直接書かれたincludeの数だけでなく、その先に続く参照も確認することが大切です。

DKIMは、メッセージに暗号学的な署名を追加します。署名には、署名ドメインを示すd=とセレクタを示すs=が含まれ、受信側サーバーはそれらを使ってDNSから対応する公開鍵を取得します。

検証に成功すると、受信側は、対応する秘密鍵でメッセージが署名され、署名の対象部分が署名後に変更されていないことを確認できます。

ただし、DKIMに合格したからといって、メッセージに表示されるすべての内容が信頼できると証明されるわけではありません。DKIMの役割は、有効なドメイン署名を確認し、その署名が対象とする部分を保護することです。

DMARCは、SPFまたはDKIMに合格し、その認証ドメインが受信者に表示されるFrom:アドレスのドメインとアライメントしているかを評価します。アライメントの取れた仕組みは、SPFとDKIMのどちらか一方に合格すれば十分です。

SPFへの合格とSPFアライメントは、別々の確認項目です。

1. SPFは、通常Return-PathまたはSMTPのMAIL FROMに示されるエンベロープ送信元ドメインを確認します。
2. SPFアライメントは、そのドメインと表示上のFrom:ドメインを比較します。緩和アライメント（relaxed）では両者の組織ドメインが同じなら一致と見なされ、厳格アライメント（strict）ではドメインの完全一致が必要です。

たとえば、次のようなメッセージを考えます。

• 表示上のFrom:：[email protected]
• Return-Path:：[email protected]
• example.comのSPF：合格

SPFに合格し、ドメインのアライメントも取れているため、SPFによってDMARCの要件を満たせます。

一方、Return-Pathが[email protected]の場合、mailvendor.comのSPFには合格しても、example.comとのアライメントは取れません。このSPFの結果だけではDMARCの要件を満たせません。

DKIMにも同じ考え方があります。有効な署名ならDKIMの検証には合格しますが、DMARCでDKIMアライメントが成立するには、署名のd=ドメインと表示上のFromドメインが一致する必要があります。緩和アライメントでは両者の組織ドメインが同じなら一致と見なされ、厳格アライメントでは完全一致が必要です。

そのため、無関係なサービスのドメインによる有効なDKIM署名は、DKIMの検証に合格してもDMARCの要件を満たさない場合があります。DMARCに合格するには、アライメントの取れたSPFまたはDKIMのどちらか一方に合格すれば十分です。

SPFとDKIMのどちらもアライメントを伴って合格しなかった場合、受信側システムはドメインのDMARCレコードに公開されたポリシーを確認します。

• p=none：DMARCの結果を理由とする特別な強制処理を求めず、主に監視します。
• p=quarantine：不審なメールとして扱い、一般には迷惑メールへ振り分けるよう受信側へ求めます。
• p=reject：メールを拒否するよう受信側へ求めます。

これらは受信サービスに公開する処理の要請であり、すべての受信サービスが機械的に従う命令ではありません。特に、p=noneはメールを破棄するという意味ではありません。DMARCの結果だけを理由に隔離または拒否するよう求めない、という意味です。

_dmarc TXTレコードのrua項目にレポートの送信先アドレスを指定すると、GoogleやMicrosoftなどの受信サービスからDMARC集約レポートが届くことがあります。

この機械可読形式のレポートには、そのドメインから送られたと称するメールの送信元と、SPF、DKIM、アライメントの結果が集計されています。集約レポートを有効にしていれば、レポートが届くこと自体は通常の動作です。それだけで、ドメインが認証に失敗している、または攻撃を受けているという意味ではありません。

正規の送信サービスを把握し、見覚えのない送信元に気付き、監視からより厳格なポリシーへ移行する前に認証結果を確認するために利用できます。

MailLogicを設定するときは、ダッシュボードに表示される値をそのまま使用し、ドメイン設定の手順で確認してください。