お客様のDMARC強化対応で「SPF/DKIM認証失敗」の調査依頼が来た話

本稿は、お客様から「貴社ドメインからSPF/DKIM認証が失敗しているメールがある」とご連絡をいただき、原因調査を行った際の知見を共有致します。

メールの仕組みって奥が深い。
内村でございます。
（知らないことを知れるのは楽しいですね）

お客様がDMARC（Domain-based Message Authentication, Reporting and Conformance）のポリシー強化を進められる中で、弊社ドメインに関連するSPF/DKIM認証失敗の報告を受けました。

結論として、原因は「弊社内でのメール転送」でした。なりすましでもシステムの不具合でもありません。
しかし、この結論に辿り着くまでの調査プロセスと、そこで得た知見は、同じような問い合わせを受けた方のお役に立つかと思い、記事にまとめました。

内容についての諸注意
お客様からのお問い合わせ内容
DMARCとは（おさらい）
いただいたデータの分析
調査の進め方
原因の特定
ARC（Authenticated Received Chain）とは
- ARC の課題と DMARC2 の動向
結論・皆さまに覚えておいていただきたいこと
参考情報
まとめ

内容についての諸注意

当記事は 2026年3月時点でお調べした内容を記載しています。
最新の情報に関しては各種公式サイト、RFC 等をご確認下さい。

当記事作成の際には十分注意しておりますが、内容に公式と相違がある場合は公式を優先とさせていただきます。

なお、お客様の特定に繋がる情報は記載していません。ドメイン名等は仮のものに置き換えております。

お客様からのお問い合わせ内容

お客様からいただいた内容を要約すると、以下の通りです。

弊社においてDMARC強化対応を推進しております。
事前調査の結果、貴社ドメインにてSPF/DKIM認証が失敗しているとの情報がございました。
貴社構築システムにて ~@example.jp を送信元アドレスとしてメール発信しているケースがあるかご確認ください。

併せて、SPF/DKIM認証が失敗したIPアドレスの一覧（DMARCレポートからの抜粋）をいただきました。

DMARCとは（おさらい）

DMARC について簡単におさらいします。

メール認証の3兄弟

メールの送信元の正当性を検証する技術として、以下の3つが広く利用されています。

技術	検証対象	概要
SPF (Sender Policy Framework)	エンベロープFrom	送信元IPアドレスが、ドメインのDNSに登録された許可リストに含まれるか
DKIM (DomainKeys Identified Mail)	メール本文・ヘッダ	メールに付与された電子署名が、ドメインのDNSに登録された公開鍵で検証できるか
DMARC	ヘッダFrom（見た目の差出人）	SPFまたはDKIMの認証結果が、ヘッダFromのドメインと「一致（アライメント）」するか

DMARCのポイントは「アライメント」です。
SPFやDKIMの技術的な認証がパスしていても、SPFの認証ドメイン（Return-Path）やDKIMの署名ドメイン（d=タグ）の少なくともいずれか一方が、ヘッダFrom（受信者が目にする差出人アドレス）のドメインと一致していなければ、DMARCとしては fail になります。

DMARC ポリシーの段階

DMARCポリシーは段階的に強化されます。

ポリシー	動作
`none`	認証失敗しても何もしない（レポートのみ収集）
`quarantine`	認証失敗したメールを迷惑メールフォルダに振り分け
`reject`	認証失敗したメールを拒否（受信しない）

お客様は none から quarantine または reject への強化を予定されており、その事前調査として「認証失敗しているメールの洗い出し」を行っていた、という背景です。

ポリシーを強化する前に洗い出しを行うのは、正当なメールが誤ってブロックされないようにするための重要なステップです。

その他当ブログ記事

DMARC については弊社技術ブログでも掲載しています。
ご参照ください。

blog.serverworks.co.jp

いただいたデータの分析

お客様からいただいた Excel 書類には、SPF/DKIM両方の認証が失敗した送信元IPアドレスの一覧が記載されていました。

確認したところ、以下の特徴がありました。

送信元IPアドレスが『全て Google のメールサーバー（ASN 15169）』
逆引きホスト名が全て *.google.com
DKIMドメイン・SPFドメインがいずれも弊社ドメイン（serverworks.co.jp）

この時点で、AWS上で構築したシステム（Amazon SES, Lambda 等）からの送信ではなく、「Google Workspace (Gmail) 経由の送信」であることが推定されました。

調査の進め方

ステップ1「開発資産（システム）の調査」

まず、弊社がお客様向けに構築・運用しているシステムのソースコードを調査しました。

Git リポジトリ内で、お客様ドメインを送信元としたメール送信処理が存在しないかを、以下のようなキーワードで検索しました。

# リポジトリ内でお客様ドメインを含むファイルを検索
grep -rn "example.jp" .

# メール送信関連のキーワード
grep -rn -E "(send.*mail|smtp|ses|from.*address)" .

結果は「該当なし」。
システムからお客様ドメインを送信元としたメール送信は行っていないことを確認しました。

ステップ2「Gmail エイリアス設定の調査」

IPアドレスが全てGoogleのメールサーバーであったため、次に「弊社メンバーが Gmail の『Send mail as（送信元アドレスの追加）』機能で、お客様ドメインのアドレスをエイリアスとして設定していないか」を調査しました。

この機能は、Gmail の「設定」→「アカウント」→「他のメールアドレスを追加」から設定できるもので、別ドメインのアドレスを差出人として利用できるようになります。

しかし、社内のコミュニケーション履歴を調査したところ、そのような設定を行った形跡は確認されませんでした。

ステップ3「社内有識者からの情報提供」

ここで社内のセキュリティスペシャリストから、重要な情報提供がありました。

おそらく「転送」が原因です。

セキュリティスペシャリストの分析によると、以下のシナリオが想定されるとのことでした。

お客様から弊社担当者にメールを送信
弊社担当者が Gmail で受信メールの転送設定を利用（またはメーリングリスト経由で転送）
転送時にエンベロープFrom（Return-Path）が弊社ドメインに差し替わる → SPFアライメントが不一致に
一方、ヘッダFrom（見た目の差出人）はお客様ドメインのまま残る
DMARCアライメントが不一致となり、認証失敗として記録される

なお、DKIMは本来「転送に強い」技術です。
メール本文やヘッダが転送前後で変わらなければ、署名検証はパスします。
しかし、メーリングリスト（ML）を経由する場合は、件名への特定文字列の付与やフッターの追加など、本文やヘッダに変更が加わることがあります。
この場合、メールが改ざんされたと判定され、DKIMもエラーとなります。

原因の特定

DMARCレポート（XML）の確認

お客様に追加データの提供をお願いし、DMARCレポートのXML（集約レポート）を確認しました。

確認のポイントは envelope_to フィールドです。

結果は、「envelope_to フィールドはレポート全体で記載なし」。
これは転送時の典型的な特徴です。

加えて、以下の記述を確認しました。

<policy_evaluated>
  <disposition>none</disposition>
  <dkim>fail</dkim>
  <spf>fail</spf>
  <reason>
    <type>local_policy</type>
    <comment>arc=pass</comment>
  </reason>
</policy_evaluated>

arc=pass
これが決め手です。

Google Workspace グループ（メーリングリスト）の特定

弊社内を確認したところ、お客様とのメールやり取りで使用している Google Workspace のグループ（メーリングリスト）が存在し、お客様からのメールがこのグループ経由で社内メンバーに転送されていることが判明しました。

これが、DMARCレポートに記録された「SPF/DKIM認証失敗」の原因でした。

メールヘッダーによる最終確認

転送先メンバーの受信メールヘッダーを確認したところ、以下が確認できました。

ARC-Authentication-Results にて dkim=pass、spf=pass、dmarc=pass （Google が最初に受信した時点）
ARC-Seal にて cv=pass（ARC検証が正常）

Google Workspace がメールを最初に受信した時点では全ての認証が pass しており、グループ（メーリングリスト）による再配信時にエンベロープが差し替わったことで、DMARCアライメント上は fail と記録されたものの、ARC で救済されている状態でした。

ARC（Authenticated Received Chain）とは

ここで登場した ARC について補足します。

ARC は RFC 8617 で定義された技術で、メールが転送やメーリングリストを経由する際に、「元の認証結果を連鎖的に保存する」仕組みです。

通常、メールが転送されると SPF/DKIM の認証が壊れます。
しかし、ARC に対応したメールサーバー（Google を含む主要プロバイダ）は、転送前の認証結果を ARC ヘッダーとして保存し、受信側はその ARC ヘッダーを検証することで「元々は正当なメールだった」と判断できます。

【転送前】
  SPF=pass, DKIM=pass, DMARC=pass
    ↓ ARC ヘッダーとして保存
【転送後（グループ再配信）】
  SPF=fail（エンベロープFromが変わったため）
  DKIM=fail（件名やフッターの変更で署名が無効化された場合）
  DMARC=fail（アライメント不一致）
  arc=pass（転送前の認証結果が正当と確認）

つまり、DMARCレポート上は「fail」と記録されますが、実際のメール配送においては ARC により正しく配送されます。

ARC の課題と DMARC2 の動向

ARC は転送メールの救済に有効な技術ですが、構造的な課題も指摘されています。

ARC はメールサーバーが受信時点で検証した結果をヘッダーに追加し、以降の転送先に「私が検証したから大丈夫」と伝える仕組みです。
しかし、もしARC を付加したメールサーバー自体が悪意のあるものであった場合、なりすましが見逃される可能性があります。

この課題を踏まえ、現在 DMARC bis と呼ばれる DMARC2 の仕様検討が進められており、ARC の扱いを含め仕様が変わる予定です。
今後の動向にも注目しておく必要があります。

結論・皆さまに覚えておいていただきたいこと

結論

今回の認証失敗は、弊社内の Google Workspace グループ（メーリングリスト）によるメール転送が原因でした。

弊社システムからお客様ドメインを詐称したメール送信は行っていない
Gmail の「Send mail as」エイリアス設定も行っていない
転送時の ARC 判定は pass であり、実際のメール配送に影響はない

同じような問い合わせを受けた方へ

DMARC強化の潮流を受けて、同様のお問い合わせが増えると予想されます。
以下のポイントを覚えておくと、調査がスムーズです。

まずIPアドレスを確認する
- 送信元IPが Google (ASN 15169) や Microsoft (ASN 8075) のメールサーバーであれば、自社システム（Amazon SES 等）からの送信ではなく、メールクライアント起因です
envelope_to の有無を確認する
- DMARCレポート（集約レポート）に envelope_to が無い場合、転送が原因である可能性が高いです
arc=pass を確認する
- DMARCレポートの <reason> に arc=pass があれば、転送による認証失敗は ARC で救済されており、実害はありません
転送やメーリングリストでは必ず発生する
- これはメールの仕組み上、正常な動作です
- DMARCレポートに fail として記録されること自体は避けられませんが、ARC 対応サーバー間であれば配送に問題は生じません

金融業界における背景

2022年以降、金融庁はフィッシング対策の一環として金融機関へのDMARC対応を要請しています。
2025年以降はその要請がさらに強まり、金融庁自身もDMARCポリシーを reject まで引き上げました。
監督下の金融機関に対しても同様の対応が求められており、対応を加速させる金融機関が増えています。

今後、金融機関のお客様を持つ企業では、同様の問い合わせが増える可能性があります。
本記事がその際の一助となれば幸いです。

参考情報

まとめ

「SPF/DKIM認証が失敗している」と言われると、一瞬ドキッとします。
（事実。私は初動、冷静さを欠けておりました。ごめんなさい。）

しかし冷静にデータを分析すれば、多くのケースではメール転送やメーリングリストによる正常な動作です。
IPアドレス、envelope_to、arc=pass の3点を確認すれば、迅速に原因を特定できます。

将来お困りの誰かのためになれますと幸いです。