SPF、DKIM、DMARC：その概要と重要性
by
最終更新日: 読書時間 9 分
主なポイント
- SPF、DKIM、DMARCはそれぞれ異なる目的を果たしますが、ドメインをなりすましやフィッシングから完全に保護するには、これら3つすべてが必要です。
- SPFは送信サーバーを認証し、DKIMはメッセージを暗号的に署名し、DMARCはポリシーを適用しレポートを提供します。
- DMARCは、受信トレイに失敗したメッセージの処理方法を指示し、レポートを通じて可視性を提供する唯一のプロトコルです。
- Google、Yahoo、Microsoft、Appleはいずれも、一括送信者に対してSPF、DKIM、DMARCを必須としています。これらに準拠しない場合、スパム扱いまたは拒否されます。
- これら3つはすべて、ドメインの設定においてDNS TXTレコードとして公開されます。
- メール認証を行わない場合、ドメインはなりすましの危険に晒され、配信率が低下し、コンプライアンス違反を引き起こす可能性があります。
SPF、DKIM、DMARCは、3つの電子メール認証プロトコルであり、連携して電子メールの正当性を検証し、ブランドのなりすましから保護し、メッセージが検証に失敗した際の対応を制御します。
今日、これはこれまで以上に重要です。Google、Yahoo、Apple、そして現在ではMicrosoftも、大量送信者に対してSPF、DKIM、DMARCを必須としています。2025年5月5日以降、Microsoftは 非準拠メールを拒否しています を拒否しています。メール認証はもはや任意の対策ではありません。
このガイドでは、SPF、DKIM、DMARCの仕組み、これら3つすべてが必要な理由、そして正しい実装方法について解説します。
SPF、DKIM、DMARCとは何ですか？
SPF (Sender Policy Framework)
SPF（Sender Policy Framework）は、ドメイン所有者が、自身のドメインに代わってメールを送信することを許可された承認済みメールサーバーのリストを定義できるようにするメール検証プロトコルです。
これをドメインのゲストリストと考えてください。リストにないサーバーからのメールは、受信メールサーバーが異常を検知します。これにより メールのなりすましを軽減し を軽減し、特定のドメインを使用してメールを送信できるのは許可されたサーバーのみであることを保証します。
ただし、SPF単体には限界がある。メールの内容を検証せず、チェックに失敗した場合に受信サーバーがどう対応すべきかを指示しない。
そこでDKIMとDMARCが登場する。
おすすめ記事： DMARCとDKIMの比較｜どちらが適しているのか、その理由とは？
DKIM
DKIM（DomainKeys Identified Mail）は、送信メールにデジタル署名を追加することでメッセージの真正性と完全性を保証する電子メール認証方式です。
SPFは送信を許可された者を確認する一方、DKIMはメッセージが送信者のサーバーを離れた後に改変されていないことを確認します。
DKIMは信頼の基盤を提供し、メールのなりすましを防止し、メッセージの完全性を保証します。しかしSPFと同様に、DKIMレコードだけでは検証に失敗した際に受信サーバーが取るべき行動を指示できません。そのためにはDMARCが必要です。
PowerDMARCで電子メール認証を簡素化！他のソリューションとは異なり、PowerDMARCは以下の機能を提供します：
クレジットカードは不要です。 |
DMARC
DMARC（ドメインベースのメッセージ認証、報告、準拠）は、ドメイン所有者が自身のドメインから送信された未認証メールの処理方法をメール受信者に指示することを可能にします。
SPFとDKIMの両方の機能を組み合わせ、さらにどちらのプロトコルも単独では提供しない2つの重要な機能を追加します：ポリシーの強制とレポート機能です。
これは、受信トレイに失敗したメールメッセージの処理方法を指示し、レポートを通じて可視性を提供する唯一のプロトコルです。
SPF vs. DKIM vs. DMARC：主な違い
これら3つのプロトコルはすべて、 電子メール認証において役割を果たしますが、それぞれが異なる要素を扱います。以下に並列比較を示します。
| 特徴 | SPF | DKIM | DMARC |
|---|---|---|---|
| 目的 | ドメインのメール送信を許可するサーバーを指定します | 電子メールの完全性と送信者の真正性をデジタル署名を用いて検証する | 認証ポリシーを適用し、レポートを提供します |
| 仕組み | 送信元IPをDNS内の許可済み送信者リストと照合する | 非対称暗号を用いて送信メールを秘密鍵で署名する；受信者はDNS内の公開鍵で検証する | SPFまたはDKIMが通過し、差出人ドメインと一致していることを確認します。ポリシーに違反したメールに対してポリシーを適用します。 |
| DNSレコードの種類 | TXTレコード | TXTレコード（公開鍵） | TXTレコード |
| チェック項目 | Return-Path ドメインおよび送信サーバーのIPアドレス | DKIM署名ヘッダー | 送信元アドレスのSPFおよび/またはDKIMとの整合性 |
| ポリシーの実施 | いいえ | いいえ | はい（なし、隔離、拒否） |
| 報告 | いいえ | いいえ | はい（集計レポートおよびフォレンジックレポート） |
| 単独でなりすましを防止する？ | 部分的に | 部分的に | はい、SPFおよびDKIMと組み合わせた場合 |
詳細はこちらの動画をご覧ください：
SPF、DKIM、DMARCの連携方法
SPF、DKIM、DMARCはそれぞれ異なる目的を果たし、ドメインをなりすまし、フィッシング、偽装から完全に保護するにはこれら3つすべてが必要です。メールが受信トレイに届く際の認証フローは以下の通りです：
- SPFチェック: 受信サーバーは送信元IPを確認し、ドメインのSPFレコードに記載された許可された送信元リストと照合します。リストに該当するIPの場合、SPFは通過します。
- DKIMチェック: 受信サーバーはメールのDKIM-Signatureヘッダーを確認し、送信者のDNSから公開鍵を取得します。署名が有効でメッセージが改変されていない場合、DKIMは通過します。
- DMARCの評価: DMARCは、これらのプロトコル（SPFまたはDKIM）のいずれかが通過したかどうか、およびその検証で使用されたドメインが差出人アドレスのドメインと一致するかどうかを確認します。一致が確認された場合、メールは通常通り配信されます。一致しない場合、DMARCはドメイン所有者が設定したポリシー（none、quarantine、またはreject）を適用します。
- レポート機能: 結果にかかわらず、DMARCは認証結果、送信元、およびあらゆるなりすまし試行の詳細を記載したレポートをドメイン所有者に送信します。
DMARCがなければ、偽装メールはSPFを通過する可能性があり（攻撃者が異なるReturn-Pathドメインを使用する場合）、またはDKIMを回避する可能性があります（メッセージが署名されていない場合）。DMARCは、認証結果と表示される差出人アドレスの一致を要求することで、これらの隙間を塞ぎます。
おすすめ記事: DMARCが失敗する理由とは？ よくある原因と解決策
SPF、DKIM、DMARCの設定方法
3つのプロトコルすべてを設定するのは技術的に聞こえるかもしれませんが、どこに何を設定すればよいか分かれば手順は単純です。SPF、DKIM、DMARCを実装するには、ドメインのDNSプロバイダーの設定画面へのアクセス権が必要です。
ステップ1: SPFの設定
SPFレコードは、ドメインのDNSにTXTレコードとして公開されます。SPFレコードは、受信サーバーに対して、どのIPアドレスおよびメールサーバーが、そのドメインに代わってメールを送信する権限を持つかを通知します。
SPFレコードを作成するには：
- ドメイン向けにメールを送信するすべてのサーバーとサービスを特定してください（メールサーバー、マーケティングプラットフォーム、CRMツールなど）。
- DNSに DNSにTXTレコードを作成してください 承認済み送信元を指定して作成してください。
- レコードを公開し、SPFチェックを通過することを確認するためにテストします。
SPFレコードは次のような形式です：
v=spf1 include:_spf.google.com include:sendgrid.net -all
この例は、GoogleとSendGridが当該ドメイン宛てにメールを送信することを許可し、受信者に対して他のすべての送信元からのメールを拒否するよう指示します。
ステップ2: DKIMの設定
DKIMでは、送信元のDNSに公開鍵を公開し、送信メールのデジタル署名を検証する必要があります。
DKIMを設定する DKIMを設定するには:
- メールサービスプロバイダーまたはメールサーバーを通じて、DKIM鍵ペア（公開鍵と秘密鍵）を生成してください。
- ドメインのDNSに公開鍵をTXTレコードとして追加してください。
- メールサーバーまたはプロバイダーを設定し、送信メッセージに秘密鍵で署名するようにしてください。
- メールを送信し、ヘッダーを確認してDKIM署名が存在し有効であることをテストしてください。
ステップ3: DMARCの設定
DMARCレコードは、ドメインのDNSにTXTレコードとして保存されます。DMARCを設定するには、SPFおよびDKIMチェックに失敗したメールを受信サーバーがどのように処理するかを指示するポリシーを定義する必要があります。
DMARCレコードを作成するには DMARCレコードを作成するには:
- ポリシーとして p=none で開始し、配信率に影響を与えずにメールトラフィックを監視します。
- 認証結果に関する集計レポートを受け取れるよう、レポート用アドレスを追加してください。
- DNSにDMARCレコードを公開してください。
- レポートを定期的に確認し、正当なメールが確実に通過していることを確認できたら、 p=quarantine に設定し、最終的には p=rejectに設定してください。
基本的なDMARCレコードは次のようになります：
v=DMARC1; p=none; rua=mailto:[email protected];
ステップ4: 設定の確認
メールヘッダーを確認することで、メールがSPF、DKIM、DMARCのチェックを通過したかどうかを確認できます。テストメールを送信し、Authentication-Resultsヘッダーを検査して、3つのプロトコルすべてが通過していることを確認してください。
PowerDMARCの無料ツールでさらに簡単になります。 DMARC Generator、 SPFジェネレーター、および DKIMジェネレーター でワンクリックでレコードを作成でき、プラットフォームのレポートダッシュボードで認証ステータスを完全に可視化できます。
SPF、DKIM、DMARCを導入しない場合、何が起こるのか？
メール認証を省略することは、問題が積み重なるまでは無害に見えるかもしれません。ドメインを無防備に放置した場合のリスクは以下の通りです。
送信者の評判が損なわれている
電子メール認証を実施しない場合、フィッシング攻撃への脆弱性が高まることで、ブランド評判が損なわれる可能性があります。
攻撃者があなたのドメインを偽装し、顧客やパートナー、従業員に詐欺メールを送信した場合、築き上げた信頼は急速に失われます。たとえ攻撃の責任があなたになくとも、受信者はフィッシング攻撃をあなたのブランドと結びつけて認識します。
メール配信率の低下
メール認証がない場合、正当なメールがスパムとしてマークされる可能性があり、その結果、メールの配信率が低下します。
多くのメールサービスプロバイダーでは、メールを正常に配信するためにDKIMとDMARCの設定が必須となっています。メールが常にスパムフォルダに振り分けられると、開封率が低下し、マーケティング効果が損なわれるだけでなく、重要な取引メールが宛先に届かない可能性があります。
財務上の損失と顧客の信頼問題
メール認証を実施しない場合、攻撃者があなたのドメインをなりすます可能性があり、結果として金銭的損失や顧客の信頼問題につながる恐れがあります。
ビジネスメール詐欺（BEC）攻撃では、攻撃者が役員やベンダーを装い、不正な送金、認証情報の窃取、法的責任の発生につながる可能性があります。
視認性の喪失
メール認証を使用しない場合、メールのパフォーマンスやセキュリティに関する可視性が失われ、ドメインの不正使用を特定することが困難になります。
DMARCレポートがなければ、誰があなたの名でメールを送信しているのか、あなたの 正当なメールが が正しく認証されているか、攻撃者が積極的にドメインをなりすましているかを知る方法はありません。
SPF、DKIM、およびDMARCのベストプラクティス
記録を公開するのは始まりに過ぎません。SPF、DKIM、DMARCを最大限に活用するには、以下のベストプラクティスに従い、長期的にメール認証を強固に保ちましょう。
DMARCをp=noneから開始し、段階的に進める
DMARCを初めて導入する際は、 p=none から始めることを推奨します。これによりメールトラフィックを監視し、正当な送信元をすべて特定できます。
すべてが適切に認証されていると確信したら、 p=quarantine 次に p=reject に設定して完全な保護を実現してください。
SPFレコードを最新の状態に保ってください
メールサービス（新しいマーケティングプラットフォーム、CRM、ヘルプデスクツールなど）を追加または削除するたびに、変更を反映させるためSPFレコードを更新してください。
古いSPFレコードは、正当なメールが認証に失敗する原因となる可能性があります。
DKIMキーを定期的にローテーションしてください
DKIMキーを定期的にローテーションすることで、キー侵害のリスクを低減できます。ほとんどのセキュリティ専門家は、少なくとも年に1回または2回のキーローテーションを推奨しています。
プラットフォームを活用して管理を簡素化する
複数のドメインや送信元をまたいでSPF、DKIM、DMARCを管理することは、すぐに複雑になりがちです。
PowerDMARCのようなプラットフォームは、ホスト型レコード管理、人間が読めるレポート、リアルタイムアラートを単一のダッシュボードに統合するため、手動でのDNS編集なしに認証態勢を常に把握できます。
PowerDMARCでドメインを確実に保護
信頼できるメールセキュリティパートナーとして、すべての組織にSPF、DKIM、DMARCの導入をお勧めします。これらのプロトコルは現代のメール保護の基盤であり、サイバー脅威に先手を打ち、送信するすべてのメッセージで信頼を維持するのに役立ちます。
長年にわたり組織のメールインフラ保護を支援してきた経験に基づき、PowerDMARCのチームは段階的な導入アプローチを推奨します。
監視から始め、データを分析し、設定に自信が持てるようになったら、段階的に厳格なポリシーを適用していく。
監視、レポート作成、継続的な最適化を容易にするため、PowerDMARCはSPF、DKIM、DMARCの管理を一つのプラットフォームに統合します。リアルタイム可視性、ガイド付きポリシー適用、自動化されたインサイトにより、プロセスの手動作業を大幅に削減し、チームが安全で信頼性の高いメール認証設定を維持することを支援します。
無料の15日間トライアルを開始 ドメイン保護を強化しましょう。
よくある質問 (FAQ)
1. SPF、DKIM、DMARCの違いは何ですか？
SPFはメールが許可されたIPアドレスから送信されたことを確認し、DKIMはデジタル署名を用いてメール内容が改ざんされていないことを保証し、DMARCはSPFとDKIMの両方を基盤としてポリシーの適用とレポート機能を提供します。SPFをメール送信者のアドレス確認、DKIMをメッセージの完全性検証、DMARCを検証失敗時の対応を決定する総合的なセキュリティポリシーと捉えてください。
2. 自分のドメインにはSPFとDKIMの両方が必要ですか？
SPFやDKIMは個別に実装可能ですが、両方を併用することで保護が大幅に強化されます。SPFはメール転送時に機能しない場合があり、DKIMだけでは送信インフラを検証できません。最大限のセキュリティとDMARC準拠を実現するには、SPFとDKIMを実装した上で、ポリシー適用とレポート機能のためにDMARCを追加してください。
3. SPF、DKIM、DMARCレコードが正常に機能しているかどうかを確認するにはどうすればよいですか？
DNSルックアップツールを使用してレコードの存在を確認し、テストメールを送信してドメイン認証結果のヘッダーをチェックし、DMARCレポートを分析して失敗箇所を特定し、PowerDMARCの無料ツールなどのオンライン検証ツールを活用してください。DMARCレポートによる定期的な監視が、継続的な保護を確保する最も包括的な方法です。
4. SPF、DKIM、またはDMARCは、受信者にとってメールの見え方に影響しますか？
いいえ。これらのプロトコルはバックグラウンドで動作し、メールの外観、内容、レイアウトを変更することはありません。受信者はSPF、DKIM、DMARCの結果を直接目にすることはありません。ただし、適切に認証されたメールはスパムとしてマークされる可能性が低くなり、受信トレイへの到達率と全体的な信頼性が向上します。
5. SPF、DKIM、DMARCレコードはどのくらいの頻度で確認または更新すべきですか？
メール送信サービスを追加または削除する際、および定期メンテナンスの一環として、レコードを確認する必要があります。新しいツールやベンダーが導入される際には、SPFレコードの更新が頻繁に必要となります。セキュリティのため、DKIMキーは定期的にローテーションすべきです。問題を早期に検出しポリシー適用を導くため、DMARCレポートは継続的に確認する必要があります。
ドメインとメールセキュリティのエキスパートPowerDMARC
AhonaはPowerDMARCのマーケティングマネージャーで、サイバーセキュリティのトピックについて5年以上の執筆経験があり、ドメインと電子メールのセキュリティを専門としている。ジャーナリズムとコミュニケーションの卒業後学位を取得し、2019年からセキュリティ分野でキャリアを固めている。
最新記事 by Ahona Rudra(全て見る)
- Outlookメール暗号化はHIPAA準拠か？ 2026年完全ガイド - 2026年3月5日
- 見返りを求めるソーシャルエンジニアリング攻撃：その仕組みと防御法 - 2026年3月3日
- 5つのエンタープライズ向けベンダーリスク管理ソリューション：2026年TPRMプラットフォーム比較 - 2026年3月3日
