【メール入門 第6回】送信ドメイン認証 後編 ― RFC 9989、DMARCレポート、転送とARC、BIMI、段階的な導入

メールサーバー
スポンサーリンク
スポンサーリンク

「DMARCをp=rejectにしたら、取引先のメーリングリストに流したメールが届かなくなりました」
「DMARCのレポートが毎日届くけど、XMLで読めません」

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

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

RFC 9989で変わったこと

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

項目RFC 7489（2015年、情報提供）RFC 9989（2026年5月、標準化過程）
文書1つの RFC本体（RFC 9989）、集計レポート（RFC 9990）、失敗レポート（RFC 9991）に分割。RFC 9091（PSD の DMARC）も統合
組織ドメインの決め方Public Suffix List（外部の一覧）DNS のツリーウォーク（_dmarc を上位へ最大8回問い合わせ、psd タグで判断）
pct0〜100% の割合だけ適用廃止。代わりに t=y
tなしt=y なら quarantine を none、reject を quarantine として扱う
np・psdなし（np は RFC 9091 の実験）正式なタグになった
rf・ri失敗レポートの形式、集計の間隔廃止
p必須推奨（無ければ none と同じ）

既存のレコードはおおむねそのまま動きます。ただし、段階的な導入に使っていた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通ごとの報告で個人情報を含むため、送らない受信側が多く、当てにしません。

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

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

自動転送では転送サーバーが自分のIPから送り直すためSPFはfailだが内容はそのままなのでDKIMがpassしDMARCもpass、メーリングリストでは件名に（ML）とフッターを追加するためSPFもDKIMもfailになりDMARCがfailしてrejectなら拒否されることと、回避策としてMLがFromをリストのアドレスに書き換えることを示す図
  • 転送：転送するサーバーは、元のエンベロープ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

対策誰が行うか仕組み限界
DKIM を必ず付ける送信ドメイン転送で壊れにくい DKIM で DMARC に合格させるメーリングリストの書き換えには効かない
SRS（Sender Rewriting Scheme）転送するサーバーエンベロープ From を SRS0=…=example.jp=user@fwd.example.com の形に書き換え、転送側のドメインで SPF を pass させるSPF は pass するがヘッダー From と一致しないので DMARC には効かない。バウンスは元の送信者へ戻せる
From の書き換えメーリングリストヘッダー From をリストのアドレスにする受信者から元の送信者が分かりにくくなる
ARC（RFC 8617、実験的）転送・メーリングリストのサーバー受け取った時点の認証結果を署名付きで残す（ARC-Authentication-Results・ARC-Message-Signature・ARC-Seal）受信側がその中継者を信頼するときだけ効く。Microsoft 365 は信頼する ARC の署名者を登録できる

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

BIMI

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

Gmailの受信箱でVMCならロゴと青いチェックマーク、CMCならロゴだけ、BIMIなしなら頭文字が表示されることと、受信側がdefault._bimi.example.jpのTXTからSVGのロゴと証明書を取得・検証して表示し、前提がDMARCのp=quarantineかp=rejectであることを示す図
  • 管理者は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側の要件もあります。

要件求める受信側・対象満たさないとき（Gmail の例）送信側で行うこと
TLS で送るGmail：すべての送信者421 4.7.29（制限）・550 5.7.29（拒否）送信 MTA で STARTTLS を有効にする（第8回）
送信 IP の逆引き（PTR）と正引きの一致Gmail・Yahoo：すべての送信者451 4.7.23・550 5.7.25IP の管理者（ISP・クラウド）に PTR を設定してもらう（第7回）
SPF か DKIM。大量送信は両方と DMARC・アラインメントGmail・Yahoo・Microsoft（1日5,000通超）550 5.7.26・5.7.27・5.7.30・5.7.40。Microsoft は 550 5.7.515第5回とこの記事
迷惑メールの報告率Gmail・Yahoo：0.3% 未満（Gmail は 0.1% 未満を保つ）配信の制限、迷惑メールフォルダーPostmaster Tools 等で監視（第7回）
ワンクリック登録解除（RFC 8058）Gmail・Yahoo：大量送信者の宣伝メール配信の制限List-Unsubscribe と List-Unsubscribe-Post を付け、DKIM の署名に含める。Yahoo は2日以内に処理（第7回）
RFC 5322 に沿った形式Gmail・Yahoo550 5.7.1 の各種From は1つ、Message-ID・Date を付ける（第3回）
転送・メーリングリストは ARCGmail—この記事の「SRS と ARC」

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

段階的な導入手順

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

DMARCの導入を①棚卸し、②SPF・DKIM、③p=none＋ruaでレポートを1か月以上集める、④quarantineはまずt=yで、⑤reject、⑥守りを保つの6段階で進め、新しいSaaSを入れるときは①に戻ることと、_dmarcのTXTの変化を示す図
; ③ 監視        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の形式の例（抜粋）です。

Authentication-Resultsのheader.i=@example.jp（DKIMの署名ドメイン）、smtp.mailfrom=bounce@mail.example.jp（エンベロープFrom）、header.from=example.jp（ヘッダーFrom）の3つを拾い、組織ドメインがどれもexample.jpなのでrelaxedならDKIMもSPFも一致してDMARC passになることを示す図
  • 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ヘッダーと合わせて、どのサーバーで何が付いたかをたどります。

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

症状よくある原因対処
SPF が permerrorinclude の入れ子で10回を超えた。SPF のレコードが2つある使っていない include を消し、1つにまとめる。IP への展開は変更に追従できないので慎重に
自社のサーバーなのに SPF が failNAT やクラウドの実際の送信 IP が未登録外へ出る IP を確かめて登録する
DKIM が fail（body hash did not verify）署名した後に本文が変わった（ゲートウェイの免責文の追加、メーリングリスト）署名は最後に外へ送るサーバーで行う
DKIM が fail（公開鍵が見つからない）セレクターの TXT・CNAME が無い、長い鍵の分割の誤りdig で公開鍵を確かめる（連載「DNS入門」第6回）
SPF・DKIM は pass なのに DMARC が failSaaS のドメインで pass しているだけ自社ドメインで DKIM 署名、MAIL FROM を自社のサブドメインに
転送した先でだけ届かない・迷惑メール扱い転送で SPF が fail、DKIM が無いDKIM を付ける。転送側は SRS・ARC

原因の多くは「送信元の棚卸し漏れ」と「アラインメントの不一致」です。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. メールの設計演習

コメント

タイトルとURLをコピーしました