実在する企業になりすまして、ID・パスワードなどの重要な情報を騙し取ったり、金銭を振り込ませたりする「なりすましメール」の被害が後を絶ちません。
こうしたなりすましメールへの対策として有効なのが、送信ドメイン認証です。送信ドメイン認証は、メールが正規の送信元から送られていることを確認し、なりすましや改ざんを検知する役割を担っています。
近年は、GmailやOutlook、iCloudなどの主要なメールサービスで送信者ガイドラインの要件が強化されており、適切に認証されていないメールは、迷惑メールとして扱われたり、受信拒否されたりするリスクが高まっています。そのため、メールを安定して届けるためにも、送信ドメイン認証への対応は重要です。
本記事では、送信ドメイン認証の代表的な技術であるSPF・DKIM・DMARCの役割や仕組み、違いをわかりやすく解説するとともに、導入・運用時のポイントについても紹介します。
目次
送信ドメイン認証(SPF・DKIM・DMARC)とは
送信ドメイン認証は、メールが正規の送信元から送られていることを確認する技術です。設定することで、第三者によるなりすましを検知しやすくなります。
SPF・DKIM・DMARCはそれぞれ役割が異なり、SPF・DKIMは単独でも導入できますが、十分な効果を得るためには組み合わせて運用することが推奨されます。まずは、それぞれの役割と仕組みについて見ていきましょう。
SPFの役割と仕組み
SPF(Sender Policy Framework)は、メールの送信元サーバーが、そのドメインを送信元としたメール送信を許可されていることを確認する仕組みです。
SPFでは、以下のような流れで認証が行われます。
- 送信側:そのドメインを送信元としてメールを送信するサーバーの情報を、SPFレコードとしてDNSに登録する
- 送信側:メールを送信する
- 受信側:送信元ドメイン(エンベロープFromドメイン)のSPFレコードを参照する
- 受信側:受信したメールの送信元サーバーのIPアドレスと、SPFレコードの内容を照合する
- 受信側:照合結果にもとづいて、送信元の正当性を判定する

SPFの概要や設定方法については、以下の記事で詳しく解説しています。
DKIMの役割と仕組み
DKIM(DomainKeys Identified Mail)は、メールに電子署名を付与し、配送途中で内容が改ざんされていないことを確認する仕組みです。
DKIMでは、以下のような流れで認証が行われます。
- 送信側:DKIMに使用する秘密鍵を送信メールサーバーに登録する
- 送信側:対応する公開鍵を、送信ドメインのDNSサーバーに登録する
- 送信側:メール送信時に、秘密鍵で電子署名を生成し、メールヘッダに付与する
- 受信側:DNSから公開鍵を取得して電子署名を検証し、メールが改ざんされていないことを確認する

DKIMの概要や設定方法については、以下の記事で詳しく解説しています。
DMARCの役割と仕組み
DMARC(Domain-based Message Authentication, Reporting, and Conformance)は、SPF・DKIMの認証結果と、メールの差出人(ヘッダFrom)のドメインとの整合性(アライメント)を確認し、なりすましメールへの対策を行うための仕組みです。
DMARCでは、以下のような流れで認証が行われます。
- メール送信:送信者がメールを送信する
- DMARCレコードの確認:受信サーバーはメールを受け取ると、ヘッダFromのドメインのDMARCレコードを確認する
- 認証の実施:SPFまたはDKIMの認証結果と、認証に利用されたドメインとヘッダFromのドメインの整合性(アライメント)を確認する
- ポリシー適用:DMARC認証に失敗した場合、DMARCレコードに設定されたポリシー(none/quarantine/reject)に基づいてメールを処理する
- レポート送信:受信サーバーは、認証結果をDMARCレポートとしてドメイン所有者に送信する(※DMARCレポートが送信されない場合もある)

DMARCの概要については、以下の記事で詳しく解説しています。
SPF・DKIM・DMARCの違い
SPF・DKIM・DMARCは、それぞれ異なる方法でメールの正当性を確認する仕組みです。主な役割や検証対象、課題の違いを以下の表にまとめました。
| 項目 | SPF | DKIM | DMARC |
|---|---|---|---|
| 主な役割 | 送信元サーバーの正当性を確認する | メールが配送途中で改ざんされていないかを検証する | 差出人の偽装が行われていないかを検証し、なりすましメールの扱い方を決める |
| 検証の対象 | 送信元サーバーのIPアドレス | メールに付与された電子署名と、その署名に対応する本文やヘッダ | SPF・DKIMの認証ドメインと、ヘッダFromドメインの整合性 |
| 主な課題 | ヘッダFromドメインとの整合性は確認できない/転送により失敗する場合がある | ヘッダFromドメインとの整合性は確認できない | SPFまたはDKIMの設定が前提となる |
SPFやDKIMだけでは、受信者に表示される差出人(ヘッダFrom)のなりすましを検知できません。そのため、SPF・DKIMに加え、認証に利用されたドメインとヘッダFromドメインとの整合性を確認するDMARCを組み合わせて利用することが推奨されています。
なぜSPF・DKIM・DMARCが必要なのか
SPF・DKIM・DMARCは、なりすましメール対策だけでなく、メールを安定して届けるためにも重要な技術です。フィッシングメールの増加に伴い、受信側のメールサービスプロバイダは送信ドメイン認証を重視するようになっており、適切に設定されていない場合、メールが迷惑メールとして扱われたり、受信拒否されたりする可能性があります。
ここでは、SPF・DKIM・DMARCが必要とされる背景について解説します。
なりすましメールを防ぐため
SPF・DKIM・DMARCの最も重要な役割の一つが、なりすましメールの防止です。
企業のドメインが第三者によって悪用されると、フィッシングメールなどの送信に利用され、企業の信用低下やブランドイメージの毀損につながるおそれがあります。
SPF・DKIM・DMARCを適切に設定することで、自社ドメインを悪用したなりすましメールを検知しやすくなり、被害の防止につながります。
送信者ガイドラインで対応が求められているため
なりすましメールの増加を受け、主要なメールサービスプロバイダは送信者ガイドラインの要件を強化しています。
例えば、Googleは2024年2月から、Gmail宛に1日5,000通以上のメールを送信する送信者に対して、SPFまたはDKIMの設定に加え、DMARCの設定を必須としています。また、MicrosoftとAppleも送信者に対し、SPF・DKIM・DMARCによる認証を求めています。
こうしたガイドラインに対応していない場合、メールが迷惑メールフォルダに振り分けられたり、受信拒否されたりする可能性があります。そのため、メールを送信する企業にとって、SPF・DKIM・DMARCの設定は実質的な必須要件となっています。
各メールサービスプロバイダの送信者ガイドラインの要件については、以下の記事で詳しく解説しています。
メール到達率を向上させるため
SPF・DKIM・DMARCは、メール到達率の向上にも寄与します。
受信側のメールサービスプロバイダは、送信ドメイン認証の結果を迷惑メール判定の材料の一つとして利用しています。そのため、SPF・DKIM・DMARCが適切に設定されているメールは信頼性が高いと判断されやすく、迷惑メールフォルダへの振り分けや受信拒否のリスクを低減できます。
ただし、送信ドメイン認証だけでメールの到達が保証されるわけではありません。送信元IPアドレスやドメインのレピュテーション、メール本文の内容、受信者の反応なども到達率に影響するため、これらの要素も含めた総合的な対策が重要です。
SPF・DKIM・DMARCの導入・運用のポイント
SPF・DKIM・DMARCは、単に設定するだけでなく、適切な手順で導入し、継続的に運用することが重要です。特にDMARCは、ポリシーの設定を誤ると正規のメールまで届かなくなる可能性があります。
ここでは、SPF・DKIM・DMARCを導入・運用する際に押さえておきたいポイントを紹介します。
SPF・DKIMだけで終わらせない
SPFやDKIMは、それぞれ送信元サーバーの正当性やメールの改ざん有無を確認するための重要な仕組みですが、前述したようにこれらだけでは差出人(ヘッダFrom)のなりすましを防ぐことはできません。
なりすましメール対策としての効果を高めるためには、SPF・DKIMに加えてDMARCも導入し、認証に利用されたドメインとヘッダFromドメインとの整合性を検証することが重要です。
DMARCポリシーは段階的に引き上げる
DMARCポリシーとは、認証に失敗したメールをどのように扱うかを指定するもので、「none(監視のみ)」「quarantine(隔離)」「reject(拒否)」の3段階があります。
DMARCを導入する場合は、まずは監視のみを行う「none」から始めます。なぜなら、自社のメール配信状況を十分に把握できていない状態で、いきなり「quarantine」や「reject」を適用すると、正規のメールまで迷惑メールとして扱われたり、受信拒否されたりする可能性があるためです。
まずはポリシーを「none」に設定し、正規のメールが適切に認証されているかを確認しましょう。問題がないことを確認できたら、ポリシーを段階的に強化することが推奨されます。
DMARCポリシー強化の進め方については、以下の記事で詳しく解説しています。
認証結果を定期的に確認する
SPF・DKIM・DMARCは、一度設定しても、その後の送信環境の変化によって認証に失敗するようになる可能性があります。例えば、新しいメール配信サービスを導入した場合や、DNS設定を変更した場合などには注意が必要です。
そのため、認証結果を定期的に確認し、問題が発生していないかを監視することが重要です。特にDMARCレポートを活用すると、自社ドメインを利用して送信されているメールの認証結果や、認証に失敗しているメールの送信元を把握できます。
ただし、DMARCレポートは、各メールサービスプロバイダから個別にXML形式で送られてくるため、そのままでは内容を把握しづらく、手作業で集計するのは現実的ではありません。
ベアメールの「迷惑メールスコアリング」では、複雑なDMARCレポートを自動で集計し、グラフや表でわかりやすく可視化する「DMARC分析機能」を提供しています。SPF・DKIM・アライメントの認証状況を簡単に把握できるほか、送信元IPアドレスや認証結果などの条件でフィルタリングすることも可能です。

SPF・DKIM・DMARCを適切に運用し、安定したメール配信環境を整備したい方におすすめです。詳細については、以下の資料をご確認ください。

まとめ
本記事では、SPF・DKIM・DMARCの役割や仕組み、違い、導入・運用のポイントについて解説しました。
SPF・DKIM・DMARCは、それぞれ異なる役割を持ちます。なりすましメール対策やメール到達率向上のためには、SPF・DKIMだけでなくDMARCもあわせて導入し、継続的に認証結果を確認しながら運用することが重要です。
まずは自社の設定状況を確認し、未対応の認証方式がある場合は段階的に導入を進めていきましょう。
記事を探す
- 2026年06月
- 2026年05月
- 2026年04月
- 2026年03月
- 2026年01月
- 2025年12月
- 2025年11月
- 2025年10月
- 2025年09月
- 2025年08月
- 2025年07月
- 2025年06月
- 2025年05月
- 2025年04月
- 2025年03月
- 2025年02月
- 2025年01月
- 2024年12月
- 2024年11月
- 2024年10月
- 2024年09月
- 2024年08月
- 2024年07月
- 2024年06月
- 2024年05月
- 2024年03月
- 2024年02月
- 2024年01月
- 2023年12月
- 2023年11月
- 2023年10月
- 2023年09月
- 2023年06月
- 2023年05月
- 2023年01月
- 2022年12月
- 2022年11月
- 2022年10月
- 2022年09月
- 2022年08月
- 2022年07月
- 2022年06月
- 2022年05月
- 2022年04月
- 2022年03月
- 2022年01月
- 2021年12月
- 2021年11月
- 2021年10月
- 2021年09月
- 2021年08月
- 2021年07月
- 2021年06月
- 2021年05月
- 2021年04月
- 2021年03月
- 2021年02月
- 2021年01月
- 2020年12月
- 2020年11月
- 2020年09月
- 2020年08月
- 2020年06月
- 2020年05月
- 2020年04月
- 2020年02月
- 2020年01月
- 2019年12月
- 2019年11月
- 2019年10月
- 2019年09月
- 2019年08月
- 2019年07月
- 2019年06月
- 2019年05月
- 2019年02月
タグ一覧
- 用語解説 (66)
- HowToガイド (56)
- トラブルシューティング (34)
- メール到達率 (29)
- DMARC (21)
- SMTP (18)
- プロに学ぶ (14)
- Techブログ (13)
- メルマガ (13)
- 迷惑メール/スパム (13)
- DNS設定 (12)
- SPF (12)
- メールサーバー (12)
- メールリレー (11)
- DKIM (10)
- ツール・サービス比較 (9)
- BIMI (8)
- Gmail (8)
- IPレピュテーション (6)
- Postfix (6)
- メールエラー/バウンス (6)
- メールヘッダ (6)
- メール開封率 (6)
- ブラックリスト (3)
- メール配信サービス (3)
- API (2)
- ARC (2)
- Exchange Online (2)
- Outlook (2)
- RFC (2)
- iCloud (1)
- メールマーケティング (1)
- 調査 (1)
