DMARC 認証失敗の原因切り分け｜5 つの典型
目次
この記事でわかること
- DMARC が pass / fail と判定される基本ロジック
- fail を引き起こす 5 つの典型パターンと見分け方
- 自社で迷わず切り分けるための実践フロー
DMARC fail を「どこで詰まったか」で見る
DMARC レポート（rua）に dmarc=fail の行を見つけたとき、原因の特定で立ち止まる相談をよく受けます。DMARC は SPF または DKIM のいずれかが pass し、かつ Header From とのドメインが揃って（alignment）はじめて pass と判定されます。逆に言えば、fail は次の 3 段階のどこかで詰まっているだけです。
- SPF / DKIM 自体の認証
- Header From との alignment
- ポリシー継承（subdomain / 転送経路）
この記事では実務で頻発する 5 つの典型パターンに絞って切り分け方を整理します。より深い解説や個別原因の詳細は DMARC fail の原因と切り分け｜6 パターン も合わせて参照してください。
典型 1: SPF のみ pass、DKIM 未署名で alignment 不一致
メール配信サービス（SendGrid、Mailchimp、Resend など）の初期設定でよくあるパターンです。SPF は配信ベンダー側のバウンスドメインで通過しているのに、DKIM 署名が d=sendgrid.net のままで、Header From が自社ドメインだと alignment が外れて fail します。
判別は Authentication-Results の dkim= 行で header.d がどこになっているかを見ます。d= が配信会社ドメインなら、配信ツール側で「送信ドメイン認証」「カスタムドメイン認証」を有効化し、d= を自社ドメインに切り替えます。SPF / DKIM / DMARC の関係を整理し直したい場合は SPF・DKIM・DMARC の違い に基礎をまとめています。
典型 2: メーリングリスト / 自動転送で DKIM 署名が破壊される
社内 ML や Google Groups、Outlook の自動転送を経由すると、Subject に [ML] などを付加した瞬間に DKIM の本文ハッシュが壊れて fail します。SPF は中継サーバの IP に書き換わるためこれも fail。結果として DMARC fail が量産されます。
このパターンの判別は rua レポートの「送信元 IP がメールサーバや ML 配信会社のもの」かどうかで切り分けます。対処は中継側で ARC 署名を有効化するか、List-Id ヘッダで除外設定を行うのが定石です。rua の見方に不慣れな場合は DMARC レポートの読み方 と 集計レポートの読み解き方 が出発点になります。
典型 3: サブドメインから送信して subdomain policy 不適合
info@marketing.example.co.jp のように普段使わないサブドメインから送信したとき、_dmarc.marketing.example.co.jp を別途切っていないと、ルートドメインの sp= が適用されます。sp=reject を明示しているとサブドメイン送信が一律 reject、何も書いていないと p= が継承されます。
判別は rua の policy_evaluated セクションで disposition=reject かつ header.from=marketing.example.co.jp のように出ます。対処はサブドメイン用の DMARC レコードを p=none で発行し、運用状況を 2〜4 週間レポートで観測してから締めていく流れです。詳細は サブドメイン用 DMARC（sp= タグ） を参照してください。
典型 4: ML 配信会社の Return-Path 不一致
SendGrid や Mailchimp、Resend のような ML 配信会社では、Return-Path（envelope from）が配信会社のバウンスドメインに書き換わります。SPF は通っても、Header From のドメインと一致しないため SPF alignment は不成立。DKIM 側で d= を自社ドメインに切り替えていないと、DMARC fail になります。
判別は rua の auth_results.spf で domain がベンダー側ドメインになっているかどうかです。対処は配信会社の管理画面で「Sender Authentication」「Domain Authentication」を完了させ、mail._domainkey などの DKIM 公開鍵を自社 DNS に登録すること。設定後 24〜48 時間レポートを観測して fail が消えたかを確認します。
典型 5: DKIM 鍵の typo や TTL 反映待ち
公開鍵の TXT レコードを 1 文字でも間違える、改行コードが入り込む、TTL が長すぎて旧鍵がキャッシュされ続けるなど、DNS 起因の fail も少なくありません。dig +short TXT selector._domainkey.example.co.jp で実際に返ってくる文字列を確認します。DKIM 単体の検証方法は DKIM の検証方法 にまとめています。
DNS 変更直前に TTL を 300 秒程度に下げておくのが定石です。変更後 1〜2 時間で旧キャッシュが切れます。
切り分けの実践フロー（5 ステップ）
- rua の集計から fail が集中している送信元 IP / Header From を特定
- 該当ドメインからのメールを 1 通受信し、Authentication-Results を全文確認
- SPF / DKIM のどちらが pass し、
mailfrom/header.dが何かをメモ - Header From と組織ドメインが一致するかで alignment を判定
- 上記 5 典型のどれに該当するかを決め打ちし、DNS または配信ツール側を修正
レポートそのものが届かないケースは別物なので、原因の系統を混同しないでください。届かない場合は DMARC レポートが届かない を参照。rua と ruf の役割の違いを再確認したい場合は rua と ruf の比較 を併読してください。
よくある質問
Q. fail が出たら p=reject を p=none に戻すべき？
戻すと集めたレポートの傾向が読めなくなります。DNS だけ直してポリシーは据え置きが基本です。
Q. Gmail だけ fail で他は通る場合は？
Gmail はレポート頻度と判定が厳しめです。他社で pass していても Gmail の Authentication-Results を必ず一次情報として確認してください。
Q. 全部 pass のはずなのに fail が出る場合は？
典型 1（alignment 不一致）か典型 4（Return-Path 不一致）の可能性が高いです。header.d と mailfrom のドメインを実物で確認します。
まとめ
- DMARC fail は SPF / DKIM のどちらか pass + alignment 成立で初めて回避できる
- 中小企業で頻発するのは alignment 不一致と転送破壊
- 切り分けは Authentication-Results の 4 項目（SPF / DKIM / DMARC / header.from）から始める
まずは現状を把握しましょう
自社のドメインがどのような状態にあるか、無料の ドメイン診断 でチェックできます。 設定状況がわからない方は お問い合わせ からお気軽にご相談ください。 専門家がわかりやすくサポートいたします。