DMARC fail の原因と切り分け｜6 パターン
目次
この記事でわかること
- DMARC が fail する典型的な 6 パターン
- Authentication-Results ヘッダの読み方
- 自社で切り分けるための実践フロー
DMARC fail とは何が起きているのか
DMARC レポート(rua)で dkim=fail spf=fail の行を見つけたとき、原因が分かりにくいという声をよく聞きます。DMARC は SPF/DKIM の検証結果に Header From とのドメイン一致(アライメント) を重ねた多段判定で、fail の原因は一通りではありません。中小企業で実際に頻発する 6 パターンに整理し、判別方法と対処を示します。
原因1: SPF レコードに送信元 IP が含まれていない
新しいメール配信ツールを導入した直後によくあるパターンです。SendGrid / Mailchimp / Resend などを追加したのに、自社の SPF レコードに include: 宣言を足し忘れている状態です。
判別方法は単純で、Authentication-Results ヘッダの spf= を確認します。
Authentication-Results: mx.example.jp;
spf=fail (sender IP is 168.245.0.1) [email protected];
dkim=none;
dmarc=fail (p=quarantine sp=quarantine dis=quarantine) header.from=example.co.jp
spf=fail で、かつ送信元 IP が見覚えのある配信ツールのものなら、SPF 設定漏れが濃厚です。各ツールが指定する include: を v=spf1 レコードに追記してください。SPF の整理方法はSPF レコードの flatteningも参考にしてください。
原因2: SPF が Permerror(構文エラー・lookup 上限超過)
spf=permerror は構文エラーまたは DNS lookup が 10 回を超えた状態です。RFC 7208 で include: などを再帰的に展開する DNS lookup は最大 10 回と決まっています。Microsoft 365 と Google Workspace と配信ツールを 3 つ並べた瞬間に超えるケースが珍しくありません。
判別は以下のような行で行います。
spf=permerror (too many DNS lookups) [email protected]
対処は SPF flattening(IP 直書きへの変換)か、メール送信ベンダーの集約です。?all のままだと「中立」として fail 扱いされる受信側もあるので、最終形は ~all または -all で締めます。
原因3: DKIM 署名が改ざん検知される
DKIM は本文と特定のヘッダーに対する電子署名なので、メーリングリストや一部の中継サーバーが Subject に [ML] を付けるなど、署名対象を 1 文字でも書き換えると署名が壊れます。
判別は dkim=fail (body hash did not verify) のようなメッセージが出ているかどうか。メーリングリストや MS Exchange の社内ループ転送で頻発します。
対処としては、
- 配信元の DKIM 署名範囲を見直す(ヘッダー署名項目を絞る)
- メーリングリスト側で ARC 署名を有効化する。ARC の概要はARC とは何かで扱っています
- 受け側に転送の事情を共有して、ホワイトリスト対応を依頼する
原因4: SPF/DKIM は pass、でもアラインメント不一致
これが中小企業で一番分かりにくいパターンです。SPF も DKIM も pass なのに DMARC は fail になります。
spf=pass smtp.mailfrom=bounces.sendgrid.net;
dkim=pass header.d=sendgrid.net;
dmarc=fail header.from=example.co.jp
SPF は SendGrid のドメインで通っており、DKIM 署名も SendGrid ドメインで付与されている。ところが Header From は自社ドメインなので、Header From と SPF/DKIM のドメインが一致しない = アラインメント fail で DMARC fail です。
対処は配信ツール側で「カスタムドメイン認証」「送信ドメイン認証」を有効にし、d=example.co.jp で署名するように切り替えます。詳しくはDMARC アライメントの解説を参照してください。
原因5: サブドメインの DMARC 設定漏れ
marketing.example.co.jp のようなサブドメインから送るとルートの DMARC が継承されますが、sp= タグを明示していないとサブドメイン用に SPF/DKIM を整備していない状態だと丸ごと fail します。
_dmarc.marketing.example.co.jp を別途設定するか、ルートに sp=none を一時明示してレポートを 2〜4 週間取るところから始めます。タグはDMARC レコードのタグ早見表を参照してください。
原因6: DNS 反映待ち・キャッシュ問題
レコードを直したのに改善しないとき、TTL の見落としが多いです。TTL が 86400 秒のまま変更すると、24 時間以上古いレコードがキャッシュされます。変更の数日前に TTL を 300 秒程度に下げてから本変更を行うのが定石です。
Authentication-Results ヘッダの読み方
切り分けの起点はメールヘッダーの Authentication-Results 行です。Gmail なら「メッセージのソースを表示」、Outlook なら「メッセージ オプション」から見られます。
確認すべき項目は次の 4 点です。
spf=の値(pass/fail/permerror/temperror/none)とsmtp.mailfromdkim=の値とheader.d(署名ドメイン)dmarc=の値とheader.from- アラインメントが取れているか(SPF の mailfrom と DKIM の d= が、いずれも header.from と組織ドメインで一致しているか)
DMARC レポートの読み方そのものはDMARC レポートの読み方で別途解説しています。
切り分けの実践フロー
- rua レポートで
dispositionとdkim/spfの組み合わせを集計 - 怪しい送信元 IP のメールを 1 通受信し Authentication-Results を確認
dig +short TXT example.co.jpで SPF を確認し lookup 数を検算- DKIM 公開鍵
default._domainkey.example.co.jpの存在を確認 - 該当する原因パターンを特定し、DNS を修正
- 修正後、最低 48 時間レポートを再観測
慌てて p=reject を p=none に戻すと集めたレポートの傾向が読めなくなります。DNS だけ直してポリシーは据え置きが基本です。
DMARC レポート解析ツールで原因切り分けを楽にする
p=none でレポートが届き始めたら、生 XML を手で読み続けるのは現実的ではありません。可視化ツールに任せると fail の集中箇所が一目で分かります。主要 7 製品の比較は DMARC レポート解析ツール おすすめ 7 選 を参照。今すぐ自社の SPF / DKIM / DMARC レコードの中身を日本語で読み解きたい場合は、無料の SPF / DKIM / DMARC 設定確認ツール もご利用ください。
自社の状況を確認してみませんか
設定状況がわからない方は、無料のドメイン診断で現状をチェックできます。 DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。 判断に迷う場合はお問い合わせからご相談ください。専門家がわかりやすくサポートいたします。