2. メール認証の3つの柱 — SPF・DKIM・DMARC
このセクションのポイント: メール認証には、SPF(送信サーバの正当性確認)、DKIM(メール改竄防止)、DMARC(SPF・DKIMを統合し、なりすましを検出・防止)の3つの技術があります。
SPF — 送信サーバの正当性を確認する
SPF(Sender Policy Framework)は、「このドメインからメールを送信してよいサーバはどれか」をDNSに登録する仕組みです。
SPFは、封筒の消印と同じ。どこから送られてきたのかが分かる。
例えるなら、封筒の切手に押された「消印」と同じです。
消印を見れば、いつ、どの郵便局で受け付けられたのかが分かります。
同様に、受信側メールサーバは、メールを送ってきた送信元サーバのIPアドレスを確認して、正当なメールサーバから送信されたのかを確認します。
ただし、SPFだけでは限界があります。
共用のメールサーバ環境では、他のテナントもSPF検証に合格してしまう場合があります。
これは、郵便局から多くの人が手紙を送ると、消印も同じになるのと同じです。
また、メールが転送されると、送信元IPアドレスが変わるためSPF検証に失敗します。
DKIM — メールの改竄を防止する
DKIM(DomainKeys Identified Mail)は、メールに電子署名を付与し、送信後にメールの内容が改竄されていないことを保証する仕組みです。
DKIMは、封筒の封蝋と同じ。改竄されていないことが分かる。
例えるなら、封筒に封蝋を施すようなものです。
封蝋が無傷であれば、中身が途中で書き換えられていないことがわかります。
受信側は、DNSに公開されている公開鍵を使って、署名の正当性を検証します。
DKIMは転送されても署名が維持されるため、SPFの弱点を補完します。
しかし、DKIM単体では、署名ドメインとメールのFromアドレスの一致を確認しないため、攻撃者が自身のドメインで署名しつつ、Fromアドレスを偽装することが可能です。
DMARC — SPFとDKIMを統合し、なりすましを防止する
DMARC(Domain-based Message Authentication, Reporting and Conformance)は、SPFとDKIMの検証結果を活用しつつ、さらにAlignmentチェック(認証済みドメインとFromアドレスの一致確認)を行うことで、なりすましメールを検出・防止します。
SPFとDKIMが「封筒の外側の確認」だとすれば、DMARCは「中身の手紙を確認して差出人が封筒の外側で書いてある差出人と一致しているかを照合する」プロセスに相当します。
封筒の外側を確認するだけでは不十分で、封筒の中の手紙に書いてある差出人と一致しているかの照合が必要なのと同じです。
DMARCメカニズムの全体像(詳細はDMARC仕様解説ページをご参照ください)
3. DMARCが果たす3つの役割
このセクションのポイント: DMARCは、①Alignmentチェック(Fromアドレス詐称検出)、②認証失敗時の処理指示、③レポートによる監視の3つの機能を提供します。
① DMARC Alignmentチェック
SPFやDKIMが合格していても、それだけでは「ヘッダーFromのドメイン」が正当かどうかはわかりません。
DMARCのAlignmentチェックは、SPFやDKIMで認証されたドメインと、メールの差出人として表示されるヘッダーFromのドメインが一致しているかを確認します。
それは、あたかも、封筒の中の手紙を取り出して確認するようなものです。
これにより、「SPFやDKIMは合格しているが、実は別のドメインの認証結果を利用していた」というなりすましを検出できます。
DMARCは、封筒と手紙を照合する。
Alignment一致(正当なメール)
ヘッダーFromのドメインと、認証されたドメインが一致しています。
DMARCは合格と判定します。
Alignment不一致(なりすましの疑い)
ヘッダーFromのドメインと、認証されたドメインが一致していません。
DMARCは不合格と判定します。
メールの場合は、EnvelopeのデータとBodyのデータは一連のデータとして流れるので、あまり気にしないかもしれません。
しかし、手紙の例で考えると、開封して手紙を取り出して読むことは、問題ないのか?と気になるところですよね。
ですから、DMARCは通信の秘密保持に違反するのではないかと、議論になってきました。
この件について、総務省が定めるDMARC導入に関する法的な留意点によると、DMARC等の送信ドメイン認証において取得される情報は「通信の経路情報(送信ドメイン)」に限定されるため、メールの本文や件名自体を含めない等の一定の条件を満たすことを前提として、電気通信事業法で保護される「通信の秘密」の侵害には当たらないと整理されています。
なお、この整理は無条件に成立するものではなく、利用者への事前の十分な説明(約款等による包括同意を含む)が前提となっている点にご留意ください。
② ドメイン所有者による処理指示(ポリシー)
DMARCでは、認証に失敗したメールをどう扱うかを、ドメイン所有者が受信側メールサーバに指示できます。
このポリシーは、DNSのTXTレコードとして公開されます。
p=none(モニタリング)
- 認証結果に関わらず、既存のメール処理を変更しません。
まずはレポートを収集し、現状を把握するためのフェーズです。
注意:p=noneは「安全」を意味しません。攻撃者にとって、p=noneのドメインは格好の標的です。
p=quarantine(隔離)
- 認証に失敗したメールを迷惑メールフォルダに振り分けるよう指示します。
p=reject(拒否)
- 認証に失敗したメールの受信自体を拒否するよう指示します。
最終的に目指すべきポリシーです。
DMARCの検査処理
この図で、注目して頂きたいのは、送信者側の指定してきたポリシーに従うも従わないも、受信者側次第という点です。
local_policyで、上書きして処理することも可能です。
p=noneは、受け取って欲しいという意味ではなく、何も指定しない、という意味です。
ですから、p=noneであっても、受信者側で、DKIMやSPFに不合格であるとか、DMARCのアライメントチェックに違反しているとから受信しない、という決定ができます。
実際、GmailやOutlook.comなど、B2C向けサービスにおいては、p=noneであっても、SPFやDKIMの不合格やアライメントの不一致でメールが届かないようになっています。
③ DMARCレポートによる監視
DMARCを設定すると、世界中の受信メールサーバから、自社ドメイン名義で受信されたメールの認証結果レポート(RUAレポート)が届きます。
これにより、以下のことがわかります。
- 正規メールの認証状況
- 自社が送信しているメールが、SPF・DKIM・DMARCに正しく合格しているか確認できます。
- なりすましメールの実態
- 自社ドメインを騙って送信されているメールの量、送信元IPアドレス、送信地域を把握できます。
- 設定不備の発見
- SPFやDKIMの設定に問題がある送信経路を特定できます。
レポートを受信し分析することは、セキュリティ監視として非常に重要です。
レポートの受信設定を省略することは、攻撃者に対して「この会社は監視していない」と知らせているのと同じです。
4. なぜ今、DMARCの導入が求められているのか
このセクションのポイント: 政府機関の要請、業界規格での位置づけ強化、大手メールサービスの送信者要件強化により、DMARCの導入は「推奨」から「必須」へと変わりつつあります。
政府機関からの要請
総務省や経済産業省をはじめとする各省庁が、なりすましメール対策としてDMARCの導入を強く推奨しています。
特に、フィッシング詐欺やビジネスメール詐欺(BEC)の被害増加を受け、組織のメールセキュリティ強化は国を挙げての課題となっています。
PCI DSS 4.0での位置づけ
クレジットカード情報を扱うECサイトや決済事業者に適用される国際的なセキュリティ基準「PCI DSS」のバージョン4.0では、要件5.4.1として「アンチフィッシングを目的とした自動化された仕組み」の導入が必須化されました(2025年3月31日発効)。
PCI Security Standards Council(PCI SSC)のガイダンスでは、この要件を満たす具体的な対策として、DMARC・SPF・DKIMの実装が推奨されています。
つまり、「DMARC」という名称そのものが基準本文で必須と明記されているわけではありませんが、事実上、これらの対策なしにアンチフィッシング要件を満たすことは困難であるため、決済に関わる事業者にとってDMARCの導入は実質的に不可避となっています。
Gmailの送信者ガイドライン
2024年2月より、Googleは1日5,000通以上のメールを送信する送信者に対し、SPF・DKIMの実装を必須としました。
DMARC自体は要件上「必須」ではありませんが、送信者に課される迷惑メール率0.3%以下という制限を満たすには、実質的にDMARCの導入が欠かせません。
これに対応していない送信者からのメールは、受信が拒否される可能性があります。
Googleだけでなく、Microsoft、Yahoo!など主要メールプロバイダも同様の方向性を打ち出しています。
詳細はGoogleの新しいメールセキュリティポリシーの解説ページをご参照ください。
なりすましメール被害の深刻化
近年、なりすましメールによるフィッシング詐欺、ビジネスメール詐欺(BEC)、ランサムウェア攻撃の被害が急増しています。
2025年には、国内の多くの企業でMicrosoft365のExchange Onlineが持つDirect Send機能が悪用される事例も多発しました。
こうした脅威に対抗するためにも、DMARCの導入は不可欠です。
5. DMARC未導入のリスク
このセクションのポイント: DMARC未導入は、攻撃者への「どうぞご自由に」というサインです。自社だけでなく、取引先やお客様にも被害が及びます。
- 自社ドメインがなりすましに悪用される
- DMARCが未導入のドメインは、攻撃者にとって最も利用しやすいターゲットです。
p=rejectが設定されたドメインを攻撃しても無駄なため、攻撃者はDMARC未導入やp=noneのドメインを優先的に狙います。
- メールの到達率が低下する
- Gmail、Microsoft365などの主要メールサービスは、DMARC対応を送信者に求めるようになっています。
未対応の場合、正規のメールでさえ迷惑メール扱いされたり、受信を拒否されるリスクが高まります。
- コンプライアンス違反
- PCI DSS 4.0をはじめとする業界規格や、政府のガイドラインへの非準拠となります。
取引先からのセキュリティ監査でも、DMARC未導入は指摘事項となり得ます。
- インシデント発生時の対応遅延
- DMARCレポートが無ければ、自社ドメインがなりすましに使われていることすら把握できません。
被害が発覚するのは、取引先やお客様からの連絡がきっかけとなることが多く、その時点では既に手遅れです。
- 取引先・お客様への被害拡大
- 自社ドメインを騙ったなりすましメールにより、取引先やお客様が金銭的被害を受けた場合、信頼関係の毀損は避けられません。
6. 導入のステップ
このセクションのポイント: DMARCの導入は段階的に進めるのが一般的ですが、弊社では最初からp=rejectでの導入をお勧めしています。
DMARC導入の基本ステップ:
- Step 1:現状確認
- 自社ドメインのSPF・DKIM・DMARCの設定状況を確認する
- Step 2:SPF・DKIMの整備
- 自社が利用する全てのメール送信経路でSPF・DKIMを正しく設定する
- Step 3:DMARC設定(p=reject推奨)
- DMARCレコードをDNSに追加し、RUAレポートの受信を開始する
- Step 4:継続的な監視と改善
- RUAレポートを分析し、設定の最適化と脅威の監視を継続する
一般的な段階的導入 vs 弊社推奨のアプローチ
一般的には、まずp=noneでモニタリングを開始し、段階的にp=quarantine、p=rejectへ移行する方法が紹介されています。
弊社では、まずp=noneでモニタリングを行い、正規の送信元メール配信プラットフォームの仕分けを終えます。
その後、SPFとDKIMの整備を終えた段階で、p=quarantineを経由せず、直接p=rejectへの変更をお勧めしています。
その理由は以下のとおりです。
- 問題の即時検知
-
p=rejectであれば、DMARCに合格できないメールは送信時に即座にエラーとなります。
p=quarantineでは迷惑メールフォルダに入るだけで、送信側が問題に気づけません。
- なりすましメールの迅速な減少
-
p=rejectに設定すると、2〜3週間程度でなりすましメールは全体の1%未満にまで減少します。
これは、攻撃者が「送っても無駄なドメイン」を攻撃対象から外すためです。
- 見逃した正規のメール配信プラットフォームに気づく
-
週に数通だけ送る正規のメール配信プラットフォームからの送信は、見つけ出す事が困難です。
p=rejectにすることで正規のメール配信プラットフォームをmaillogや利用している現場からの申請で炙り出すことができます。
また、p=rejectにすることで、なりすましメールが急速に減少するため、分析しやすくなり、このような少数のメールを送っているメール配信プラットフォームを見つけ出すこともできます。
ただし、この方法は、RUAレポートの分析(Step1)で洗い出しきれなかった、ごく低頻度の送信元を発見するための最終的な安全網です。
この方法に頼る前に、RUAレポート分析を十分に行い、既知の送信元を可能な限り洗い出しておくことが前提となります。
専門サービスの活用
DMARCの設定自体はDNSへのTXTレコード追加で行えますが、正しい運用には以下の対応が必要です。
- 全メール送信経路の洗い出し
- 自社ドメインでメールを送信している全てのシステム・サービスを特定する必要があります。
社内メール、マーケティングメール、SaaS経由の通知メールなど、漏れがあるとp=reject設定後にメールが届かなくなります。
- SPF・DKIMの適切な設定
- 各送信経路でSPF・DKIMを正しく設定し、DMARC Alignmentが合格するように調整する必要があります。
- RUAレポートの分析
- RUAレポートはXML形式で送信され、手動での確認は困難です。
商用のDMARCレポート分析サービスを利用することで、効率的な監視が可能になります。
弊社のMailDataサービスでは、これらの導入・運用を包括的にサポートしています。
FAQ
- Q1. DMARCとは何ですか?一言で教えてください。
- A. DMARCは、あなたの会社のメールアドレスが「なりすまし」に使われることを防ぐ仕組みです。
SPFとDKIMという2つの認証技術を組み合わせ、メールの差出人が本物かどうかを受信側で確認し、偽物であれば拒否するよう指示できます。
- Q2. SPFやDKIMだけではダメですか?
- A. SPFとDKIMだけでは、ヘッダーFromの詐称を防げません。
例えば、攻撃者が自分のサーバでSPFを合格させつつ、ヘッダーFromにあなたの会社のアドレスを表示することが可能です。
DMARCのAlignmentチェックにより、このような攻撃を検出できます。
- Q3. DMARCの導入にはどのくらい時間がかかりますか?
- A. 基本的なDNSへのレコード追加は即日可能です。
ただし、自社の全メール送信経路の洗い出しとSPF・DKIMの設定整備には、数日〜数週間かかることがあります。
弊社のサービスをご利用いただければ、効率的に導入を進められます。
- Q4. 小さな会社でもDMARCは必要ですか?
- A. はい、必要です。
攻撃者は企業規模を問わず、対策の甘いドメインを狙います。
むしろ、セキュリティ体制が手薄になりがちな中小企業は、格好のターゲットです。
また、取引先がDMARC対応を求めるケースも増えており、ビジネス上の要件ともなりつつあります。
- Q5. DMARCを設定したら、メールが届かなくなることはありませんか?
- A. SPF・DKIMが正しく設定されていれば、正規のメールが届かなくなることはありません。
逆に、p=rejectの設定は「このドメインは認証をきちんと行っている」という信頼の証となり、メールの到達率が向上する効果もあります。
事前に全メール送信経路を洗い出し、適切に設定することが重要です。
- Q6. RUAレポートには個人情報が含まれますか?
- A. いいえ、RUAレポートには個人情報は含まれません。
含まれるのは、送信元IPアドレス、メール通数、SPF・DKIM・DMARCの認証結果といった統計情報のみです。
安心してレポート受信を設定してください。
仕様を学ぶ