第5回で、SPF・DKIM・DMARCの仕組みを見ました。仕組みが分かっても、実際に運用すると、転送やメーリングリストで認証が壊れる、レポートの読み方が分からない、どこまで厳しくしてよいか分からない、といった壁にぶつかります。

第6回（後編）では、2026年5月に標準化されたRFC 9989の変更点から始めて、DMARCを安全に強めていくための運用を扱います。

RFC 9989で変わったこと

DMARCは長く、情報提供のRFC 7489（2015年）で運用されてきました。2026年5月、標準化過程のRFC 9989になり、いくつかの点が変わりました。

既存のレコードはおおむねそのまま動きます。ただし、段階的な導入に使っていたpct=10などは新しい受信側では意味を持たないため、t=yに置き換えます。

また、次の2点が明記されました。

• メーリングリストに投稿する利用者がいるドメインは、p=rejectにすべきでない（SHOULD NOT）
• p=rejectならDKIM署名が必須（MUST）

DMARC集計レポートの読み方

ruaを設定すると、受信側（Gmail・Microsoft・Yahooなど）が1日ごとに、送信元IPごとの通数とSPF・DKIM・DMARCの結果を、XML（gzip・zipで圧縮、形式はRFC 9990）で送ってきます。本文や宛先は含みません。

<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">                       （抜粋）
  <report_metadata><org_name>Example Receiver</org_name>
    <date_range><begin>1790294400</begin><end>1790380799</end></date_range></report_metadata>
  <policy_published><domain>example.jp</domain><p>none</p></policy_published>
  <record>
    <row><source_ip>198.51.100.77</source_ip><count>412</count>
      <policy_evaluated><disposition>none</disposition><dkim>fail</dkim><spf>fail</spf></policy_evaluated></row>
    <identifiers><envelope_from>bounce.saas.example.net</envelope_from><header_from>example.jp</header_from></identifiers>
    <auth_results><spf><domain>bounce.saas.example.net</domain><result>pass</result></spf></auth_results>
  </record>
</feedback>

• policy_evaluatedはアラインメント込みのDMARC上の判定、auth_resultsはSPF・DKIMそのものの結果
• 上の例は、SaaSのSPFはpassだが自社ドメインと一致せずfail。つまり「SaaS側で自社ドメインのDKIMを設定すべき送信元」

見る順番は次のとおりです。

1. 通数の多い送信元IPから、自社の正規の送信元かを判定する
2. 正規なのにfailのものを直す
3. 知らない送信元はなりすまし

量が多いので、集計サービスやツールで可視化するのが現実的です。なおruf（失敗レポート、RFC 9991）は1通ごとの報告で個人情報を含むため、送らない受信側が多く、当てにしません。

転送とメーリングリストで起きること

送信ドメイン認証の最大の弱点は、転送とメーリングリストです。

• 転送：転送するサーバーは、元のエンベロープFromのまま自分のIPから送り直す。最終的な受信側から見ると、接続元のIPが元のドメインのSPFに無いためSPFはfail。内容が同じならDKIMは残るので、DKIMでDMARCに合格できる
• メーリングリスト：件名に[ML名]を付けたり、本文にフッターを加えたりするため、DKIMの署名も壊れる。両方とも一致しなくなると、投稿者のドメインがp=rejectなら配信メールが拒否され、購読者の自動退会まで起こる

このため多くのメーリングリストは、Fromをリストのアドレス（投稿者名 via ML名 <ml@lists.example.net>）に書き換えて回避しています。冒頭の「メーリングリストに流したメールが届かない」は、この問題です。

ポイント
IPが変わっても、中身が同じならDKIMがDMARCを支える。だからDKIMは必ず付ける。

SRSとARC

Gmailは送信者ガイドラインで、転送やメーリングリストの運営者にARCヘッダーを付けるよう求めています。一方、IETFでは2026年4月に、ARCを「Historic（歴史的）」に移す提案（draft-ietf-dmarc-arc-to-historic）が出され、転送の問題は策定中のDKIM2で扱う方向です。どちらも2026年9月時点で確定していません。

BIMI

DMARCを強制したことへの「ご褒美」もあります。BIMIは、DMARCを満たしたメールに、送信ドメインのロゴを受信箱で表示させる仕組みです。

• 管理者はdefault._bimi.example.jpのTXTに、SVGのロゴと証明書のURLを載せる
• 前提は、DMARCをp=quarantineかp=rejectで強制していること。p=noneでは表示されない
• 証明書は、商標登録されたロゴ向けのVMCと、12か月以上使ってきたロゴ向けのCMCがあり、認証局が発行する
• Gmailは、VMCなら青いチェックマーク付きで、2024年9月からはCMCでもロゴを表示する。Apple MailはVMCに対応し、Yahooは証明書が無くても条件しだいで表示する

仕様はRFCではなく、BIMI Groupが管理しています。

送信者ガイドラインとSMTP側の要件

Gmail・Yahoo・Microsoftは、送信者に守ってほしい要件（送信者ガイドライン）を公開しています。送信ドメイン認証だけでなく、SMTP側の要件もあります。

開始時期とDNS側の要件は、連載「DNS入門」第6回にまとめています。その後、Microsoftは2025年5月5日から、1日5,000通を超える送信ドメインで要件を満たさないメールを550 5.7.515で拒否し、Gmailは2025年11月から、不適合のメールの一時的・恒久的な拒否を段階的に強めています。社内システムの通知メールも対象になり得ます。

段階的な導入手順

では、DMARCをどう強めていくか。ポイントは、いきなりrejectにしないことです。

; ③ 監視        v=DMARC1; p=none; rua=mailto:dmarc-rua@example.jp
; ④ 試験        v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-rua@example.jp
; ④ 隔離        v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@example.jp
; ⑤ 拒否        v=DMARC1; p=reject; rua=mailto:dmarc-rua@example.jp

1. 棚卸し：自社ドメインでメールを送るものをすべて挙げる（メールサーバー、Microsoft 365・Google、SaaS、配信ツール、複合機・監視・vCenterなど）。送らないドメインとサブドメインも挙げる
2. SPFとDKIM：送信元ごとに、SPFに含めるか、自社ドメインでDKIM署名させる。10回の制限に注意（第5回）
3. p=none＋rua：集計レポートを最低1か月集め、正規なのにfailの送信元を直す
4. quarantine：まずt=yで影響を見てから外す（RFC 9989ではpctの代わり）。同じくらいの期間、レポートを比べる
5. reject：正規の送信元がすべて一致したら進める。DKIMを必須にし、メーリングリストに投稿する利用者への影響を確かめる
6. 守りを保つ：送らないドメインはv=spf1 -all、p=reject、Null MX（連載「DNS入門」第6回）で守る。新しいSaaSを入れるときは1に戻る

Authentication-Resultsの読み方

個々のメールの認証結果は、受信側が付けるAuthentication-Resultsヘッダーで確かめます。

Authentication-Results: mx.example.com;
       dkim=pass header.i=@example.jp header.s=s202609 header.b=Ktd8yQ0f;
       spf=pass (mx.example.com: domain of bounce@mail.example.jp designates 203.0.113.25 as permitted sender) smtp.mailfrom=bounce@mail.example.jp;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.jp

Authentication-Results: spf=pass (sender IP is 203.0.113.25) smtp.mailfrom=mail.example.jp;
 dkim=pass (signature was verified) header.d=example.jp; dmarc=pass action=none
 header.from=example.jp;compauth=pass reason=100

1つ目はGmailの形式、2つ目はMicrosoft 365の形式の例（抜粋）です。

• smtp.mailfromがエンベロープFrom、header.fromがヘッダーFrom、header.i・header.dがDKIMの署名ドメイン。3つのドメインを並べてアラインメントを見る
• dis=は受信側が実際に適用した扱い（NONE・QUARANTINE・REJECT）。Microsoftのcompauthは、DMARCの無いドメインも含めた総合判定で、reason=はその理由の番号
• 先頭の名前（mx.example.com）が自分の受信サーバーのものだけを信じる。送信者が偽の同名ヘッダーを入れられるため（RFC 8601）

ヘッダーの表示方法は第3回で扱いました。Receivedヘッダーと合わせて、どのサーバーで何が付いたかをたどります。

よくある不合格の原因と対処

原因の多くは「送信元の棚卸し漏れ」と「アラインメントの不一致」です。DMARCの集計レポートと、受信したメールのAuthentication-Resultsを突き合わせると、どの送信元のどの認証が失敗しているかを絞り込めます。

考えてみよう

1. 自社ドメインを名乗ってメールを送っているシステムやSaaSを、すべて挙げられますか。それぞれSPFとDKIMのどちらでDMARCに合格していますか。
2. 自社ドメインをp=rejectにしたとき、影響を受けるのはどんなメールですか。転送、メーリングリスト、登録漏れの送信元に分けて考えてみましょう。
3. 手元に届いたメールのAuthentication-Resultsから、エンベロープFrom・ヘッダーFrom・DKIMの署名ドメインの3つを答えてください。アラインメントは取れていますか。

ヒント：第5回のアラインメントの図、この記事のレポートの見る順番、転送とメーリングリストの図、Authentication-Resultsの読み方が手がかりです。レコードはdig _dmarc.example.jp TXT、PowerShellではResolve-DnsName _dmarc.example.jp -Type TXTで確かめられます（第9回）。

まとめ

• RFC 9989（2026年5月）でpctは廃止、代わりにt=y。p=rejectならDKIMは必須
• 集計レポートは通数の多い送信元から。正規なのにfailを直し、知らない送信元はなりすまし
• 転送はSPFを壊し、メーリングリストはDKIMも壊す。DKIMを必ず付け、SRS・ARC・Fromの書き換えを知っておく
• BIMIはDMARCを強制したドメインにロゴを表示する
• 導入は棚卸し → p=none → quarantine（t=y） → reject → 維持
• Authentication-Resultsで3つのドメインを並べてアラインメントを見る

次回は、送信ドメイン認証を満たしたうえで、迷惑メールと判定されずに届けるための対策と配信の作法を扱います。

連載「メール入門」全12回

1. メールが届くまで
2. SMTPのやり取り
3. メッセージの構造
4. ポートと暗号化・認証
5. 送信ドメイン認証 前編
6. 送信ドメイン認証 後編（この記事）
7. 迷惑メール対策と配信
8. MTAの運用
9. コマンドで調べる
10. クラウドと現代のメール
11. メールのトラブルシュート
12. メールの設計演習