送信ドメイン認証とは？SPF・DKIM・DMARCの違いと確認方法

独自ドメインからメールを送る企業では、受信側が送信元の許可や電子署名、Fromドメインとの整合性を確認できるよう、送信ドメイン認証を整備する必要があります。特に複数のメール配信サービスやCRM、SaaS通知を使っている場合は、SPF・DKIM・DMARCを個別に設定するだけでなく、どのシステムがどのドメインを使って送信しているかを把握する必要があります。

この記事では、送信ドメイン認証とは何か、SPF・DKIM・DMARCは何を確認する仕組みなのかを整理したうえで、送信元の棚卸しから設定、テスト送信、認証結果の確認、DMARC集約レポート（aggregate reports）による継続確認までを順に解説します。

送信ドメイン認証とは？

送信ドメイン認証とは、送信元ホストの許可、電子署名、Fromドメインとの整合性などを受信側が確認するための仕組みです。 なりすましメールやフィッシングでは、受信者が画面上で見るFromアドレスが偽装されることがあります。送信側がDNSなどに認証情報を公開し、受信側がその情報と実際のメールを照合することで、不正なドメイン利用を見分けやすくします。

代表的な仕組みが、SPF・DKIM・DMARCです。ただし、3つは同じ役割の代替手段ではありません。SPFは主に送信元ホストの許可、DKIMは電子署名、DMARCは受信者が見るFromドメインとSPFまたはDKIMで認証されたドメインの整合性を確認します。

ここで押さえておきたいのが、メールには複数の「From」に相当する情報がある点です。受信者が通常見るのはHeader From（RFC5322.From）ですが、SPFが主に確認するのはSMTPのMAIL FROM、いわゆるEnvelope Fromに使われるドメインです。両者は同じとは限りません。

1通のメールでは、送信元IPとMAIL FROMを使ったSPF、署名ドメインと署名対象データを使ったDKIMの検証を受信側が行い、その結果とFromドメインが整合しているかをDMARCで確認します。その後の配送や迷惑メール判定は、認証結果だけでなく受信側のほかの判定材料も含めて決まります。

SPF・DKIM・DMARCの違いと仕組み

SPF・DKIM・DMARCの違いは、何を認証するのかとFromドメインとの関係を見ると整理しやすくなります。

DMARCでは、SPFまたはDKIMの認証結果とFromドメインとのアライメント（ドメインの整合）を確認します。

SPF｜送信元ホストの送信許可を確認する

SPF（Sender Policy Framework）は、SMTPのMAIL FROMやHELOで使われるドメインについて、接続元の送信サーバーがそのドメインからメールを送ることを許可されているか確認する仕組みです。ドメイン側はDNSにSPFポリシーを公開し、受信側は送信元IPアドレスと照合します。詳しい仕様はRFC 7208で定義されています。

SPF認証に成功しても、「受信者が見ているFromアドレスが本物である」「メールを書いた本人が正しい」と証明されるわけではありません。また、メールが転送されると受信側から見える接続元IPが変わるため、転送方式によってSPF結果が影響を受けることがあります。

DKIM｜電子署名で署名ドメインとメールを検証する

DKIM（DomainKeys Identified Mail）は、送信側が秘密鍵でメールに電子署名を付け、受信側がDNSに公開された公開鍵を使って署名を検証する仕組みです。中核仕様はRFC 6376で定義されています。受信側は署名ドメインと、署名対象となったヘッダーや本文データが送信後に改変されていないかを確認できます。

ただし、DKIMの検証成功はメール作者本人の身元を証明するものではありません。また、DKIMの署名ドメインと受信者が見るFromドメインが同じであることも、DKIM単体では必須条件ではありません。この関係を確認するのがDMARCです。

DMARC｜認証結果とFromドメインの整合性を確認する

DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、SPFまたはDKIMの認証結果を使い、受信者が見るFromドメイン（Header From / Author Domain）と認証済みドメインが整合しているかを確認する仕組みです。この整合性をアライメントと呼びます。

DMARC認証に成功するには、SPFまたはDKIMの少なくとも一方で認証に成功し、その認証ドメインとFromドメインのアライメントが取れている必要があります。SPFとDKIMの両方で認証に成功することがDMARC認証成功の条件ではありません。

DMARCには、認証に失敗したメールを受信側がどう扱うかについてドメイン所有者の方針を示すポリシーと、認証状況を継続的に把握するためのレポート機能があります。現行の中核仕様はRFC 9989、集約レポートの仕様はRFC 9990で定義されています。

一方、実運用ではSPFとDKIMの両方を整備することが推奨され、主要メールサービスの大量送信者向け要件でも両方が求められる場合があります。DMARC認証に成功するための判定条件と、実運用で整備すべき認証方式は分けて考えることが重要です。

企業に送信ドメイン認証が求められる理由

送信ドメイン認証が必要な理由は、なりすまし対策だけではありません。自社ドメインを使った不正送信を受信側が見分ける材料になり、同時に、主要メールサービスが送信者へ求める基本要件にもなっています。

認証が整っていないと、正規メールであっても迷惑メール扱いや受信拒否につながる場合があります。特に大量送信では、SPF・DKIM・DMARCの組み合わせやアライメントまで要件化されています。

ただし、送信ドメイン認証に成功しただけで受信トレイへの到達が保証されるわけではありません。 認証は安定したメール配信の重要な前提条件の一つですが、送信者の評判、配信リストの品質、迷惑メール報告率、コンテンツ、受信側のポリシーなども影響します。認証以外の原因も含めて確認したい場合は、メールが届かない原因と到達率改善チェックリストやメールが迷惑メールに入る原因と対策も参考にしてください。

主要メールサービスの送信者要件

以下は2026年8月時点の主な要件です。サービスごとに対象や判定基準が異なるため、Gmailの送信量基準をYahooやYahoo! JAPANへそのまま当てはめることはできません。

Gmailの大量送信者には、認証以外にもTLS、DNS、迷惑メール報告率、配信停止などの要件があります。上の表は送信ドメイン認証に関係する部分だけを抜き出したものです。要件は更新されるため、公開・運用時は各社の公式情報を確認してください。

送信ドメイン認証を設定する手順

設定はSPFレコードを追加するところから始めるのではなく、自社ドメインを使ってメールを送るシステムを先に棚卸しするのが基本です。送信元を把握せずに認証を変更すると、正規のメールが認証に失敗したり、DMARCポリシーの影響を受けたりする可能性があります。

1．自社からメールを送っているシステムを洗い出す

Google WorkspaceやMicrosoft 365に加え、CRM、MA、メール配信システム、SMTPリレー、ECシステム、SaaS通知、OTPやトランザクションメールを送るアプリケーションなど、自社ドメインをFromに使用してメールを送るすべてのシステムやサービスを確認します。

各送信元について、最低限、以下の情報を整理します。同じFromドメインを使っていても、サービスごとにEnvelope FromやDKIMの署名ドメイン、送信元IPが異なる場合があります。

• 送信元のシステム／サービス
• Fromドメイン
• Envelope From／Return-Pathドメイン
• SPFの設定状況
• DKIMの設定状況
• DMARCの設定状況
• DNSを管理する担当部署・担当者
• 確認状況（未確認／設定中／確認済み）

2．SPFを設定する

利用中のメールサービスやMTAが案内する公式のSPF情報を確認し、DNSへ反映します。ここで重要なのは、新しいサービスごとに別のSPFレコードを追加しないことです。同じDNS名に複数のSPFレコードを公開すると、受信側が有効なポリシーを選べずエラーになります。

複数の送信サービスを使う場合は、既存のSPFレコードと送信元一覧を照合し、正規の送信元を一つのポリシーへ反映します。実際のinclude:値やIPアドレスはサービスごとに異なるため、必ず各サービスの公式設定値を使用してください。

3．DKIMを設定する

DKIMでは、送信システムやメール送信サーバー（MTA）側でメールへの署名を有効にし、対応する公開鍵をDNSに公開します。セレクタ、レコード名・種別、公開鍵、署名の有効化手順はサービスによって異なるため、利用サービスの公式手順に従います。

DNSにDKIMレコードが存在するだけでは設定完了とはいえません。 実際のメールにDKIM-Signatureが付いているか、想定したd=ドメインで署名され、受信側でdkim=passになっているかまで確認します。

4．DMARCを設定する

DMARCは、SPFまたはDKIMで認証に成功するだけでなく、その認証ドメインとFromドメインのアライメントが取れる送信設計を前提に設定します。あわせて、集約レポートを受け取る場合は、受信先と確認担当者を決めておきます。

最初に把握すべきなのは、正規のメール送信経路です。集約レポートや実送信結果を使って、未把握の送信元、認証失敗、アライメント不一致、転送やメーリングリストなどの影響を確認したうえで、自社ドメインの用途とリスクに応じてポリシーを判断します。

• Fromドメインを使う送信システムをすべて棚卸しできているか
• 各送信経路でSPF / DKIMの少なくとも一方で認証に成功し、その認証ドメインとFromドメインのアライメントが取れているか
• 集約レポートで正規・未把握・失敗中の送信経路を区別できているか
• 転送、メーリングリスト、サポートツールなど間接的な経路への影響を確認したか
• OTPやトランザクションメールなど、認証失敗時の業務影響を評価したか
• 監視、修正、必要時の切り戻しを担当する責任者が決まっているか

なお、旧DMARC仕様で使われていたpctタグは、現行RFC 9989では削除されています。現在のtタグはy / nのテスト用フラグで、割合を指定して段階的に適用する仕組みではありません。また、none、quarantine、rejectの順に変更することも、すべての企業に共通する必須手順ではありません。

EngageLab Emailでは、公式ドキュメント上、送信ドメイン設定でSPF・DKIM・DMARCの設定情報と認証状態を扱えます。具体的なDNS値はドメインや設定によって異なるため、利用時はEngageLab Emailの送信設定ドキュメントで現在の案内を確認してください。

EngageLab Emailのドメイン構成画面。SPF・DKIM・DMARCについて、必要なDNSレコードと既存レコードを照合し、設定状況を確認できます。

SPF・DKIM・DMARCが正しく設定できたか確認する方法

DNSにレコードが表示されていることと、実際のメールで認証に成功することは別です。設定後は、DNS公開確認 → 送信経路ごとのテスト送信 → 集約レポートによる継続確認の順で確認します。

DNSレコードを確認する

まず、SPF・DKIM・DMARCのレコードが公開DNSから取得できるか確認します。SPFは対象となるMAIL FROM / HELOドメイン、DKIMはサービスが指定するセレクタ配下、DMARCはまず_dmarc.<Author Domain>を確認します。

ただし、DNSでレコードが取得できても、その送信経路で正しいEnvelope Fromが使われること、DKIM署名が実行されること、DMARCのアライメントが成立することまでは確認できません。DNSのキャッシュやTTLによって変更の反映時点も異なるため、DNS確認だけで完了としないようにします。

また、Fromにサブドメインを使っている場合、サブドメイン直下の_dmarcレコードが見つからないだけで「DMARC未設定」とは断定できません。上位ドメインのポリシーが適用される場合があるため、最終的には実メールのDMARC結果も確認します。

テストメールの認証結果を確認する

送信元一覧にある各システムからテストメールを送り、受信側が生成したAuthentication-Resultsを確認します。同じFromドメインを使っていても、CRM、OTP、サポートツール、メール配信システムでは送信IPやEnvelope From、DKIM署名が異なる場合があるため、一通のテストメールだけで全送信元を代表させないことが重要です。

• SPF：spf=passに加え、smtp.mailfromなど受信側が評価したドメインが想定どおりか確認します。

• DKIM：dkim=passとheader.dを確認し、想定した署名ドメインかを確認します。

• DMARC：dmarc=passとheader.fromを確認し、SPFまたはDKIMで認証に成功したドメインの少なくとも一方がFromドメインとアライメントが取れているか確認します。

Authentication-Resultsは、ヘッダーに書かれているだけで常に信頼できるわけではありません。外部の送信者が任意の値を付けることもできるため、最終的な受信メールボックスの信頼できる受信システムが付与した結果、またはメールサービスの認証結果画面を確認します。

Gmailでは「メッセージのソースを表示」から詳細ヘッダーを確認でき、簡易表示では「送信元」「署名元」からSPF / DKIMのドメインを確認できます。Yahoo!メールでは「このメールの認証情報」からSPF・DKIM・DMARCの結果を確認できます。Yahoo!メールのこの機能は一通のメールを確認するための単発確認であり、DMARC集約レポートの送信機能とは別です。

DMARC集約レポートで継続的に確認する

テスト送信は「この送信経路の、この一通が正しく認証されたか」を深く確認する方法です。一方、DMARC集約レポートは、対応する受信側メールサービスが一定期間に観測したメールについて、送信元IP、件数、SPF / DKIM結果、アライメント、DMARCポリシーの適用結果などを集約して返す仕組みです。

集約レポートを見ることで、棚卸しに含まれていない送信元や、特定の送信経路だけで発生している認証失敗を継続的に見つけやすくなります。ただし、すべての受信側・すべてのメールを完全に可視化する仕組みではありません。たとえばYahoo! JAPANは、Yahoo!メールからDMARC集約レポートを送信していないと案内しています。

送信ドメイン認証で見落としやすい注意点

送信ドメイン認証では、DNSに値を登録しただけで終えると、送信経路ごとの設定漏れやアライメント不一致を見逃しやすくなります。特に次の5点を確認してください。

• 複数の送信サービスを棚卸しできていない：正規の送信元がSPFに含まれていなかったり、特定の経路だけDKIMが未設定だったりすると、送信経路ごとに認証失敗やアライメント不一致が発生します。Fromドメインだけでなく、Envelope From、DKIMのd=、送信サービス、DNS管理者まで確認します。

• SPFの既存構成を確認せず追加している：同じDNS名に複数のSPFレコードを作るとエラーになります。また、SPF評価中にDNS照会を発生させる要素の合計が10を超えるとpermerrorになります。既存レコードと全送信元を確認してから変更します。

• DKIMレコードはあるが実メールに正しく署名されていない：公開鍵がDNSにあっても、メールにDKIM-Signatureがなければ認証されません。実メールでd=、セレクタ、dkim=passを確認します。

• SPF / DKIMの認証に成功してもDMARCのアライメントが取れていない：SPFが別のReturn-Pathドメインで認証に成功し、DKIMも第三者ドメインで認証に成功している場合、Fromドメインとアライメントが取れていなければDMARC認証は失敗します。smtp.mailfrom、header.d、header.fromを並べて確認します。

• 正規の送信経路を確認する前に強いDMARCポリシーを適用する：未把握のSaaS、転送、メーリングリスト、サポートツールなどが正規に使われていると、業務メールまで影響を受ける可能性があります。集約レポートと送信元一覧で影響範囲を確認してから判断します。

設定前のチェック

• 独自ドメインを使う全送信元と用途を一覧にした
• Fromドメイン、Envelope From、DKIM署名ドメイン、DNS管理者を記録した
• 既存のSPF・DKIM・DMARCレコードを確認した
• 各サービスの現在の公式設定値と有効化手順を確認した
• DMARC集約レポートの確認担当者を決めた

設定後のチェック

• 公開DNSからSPF・DKIM・DMARCの情報を取得できる
• SPFは同じDNS名に一つで、正規の送信元を反映している
• 各送信経路のテストメールでSPF / DKIMの結果を確認した
• SPFまたはDKIMの認証ドメインとFromドメインのアライメントが取れ、DMARC認証に成功している
• 集約レポートで未把握・失敗・アライメント不一致の送信経路を継続確認している
• より厳しいDMARCポリシーを適用する前に、転送などの間接経路と業務影響を確認した

まとめ

送信ドメイン認証を整備するときは、SPF・DKIM・DMARCのレコードを個別に追加するのではなく、次の順で進めると確認漏れを減らせます。

• 1

  送信元を棚卸しする

  自社ドメインを使う全システムと、Fromドメイン、Envelope From、DKIM署名ドメイン、DNS管理者を整理します。
• 2

  SPFを確認・設定する

  既存レコードを確認し、正規の送信元を一つのSPFポリシーへ反映します。
• 3

  DKIMを確認・設定する

  DNSへの公開鍵登録と、送信システム側の署名有効化の両方を確認します。
• 4

  DMARCを検討・設定する

  SPFまたはDKIMの認証ドメインとFromドメインとのアライメント、正規の送信経路を確認し、ドメイン用途とリスクに応じてポリシーを判断します。
• 5

  テスト送信する

  送信経路ごとに実際のメールを送り、受信側で認証結果を確認します。
• 6

  Authentication-Resultsを確認する

  SPF・DKIM・DMARCの認証結果だけでなく、評価されたドメインとアライメントまで確認します。
• 7

  DMARC集約レポートで継続確認する

  未把握の送信元や認証失敗、アライメント不一致を継続的に確認し、設定や運用の見直しにつなげます。

送信ドメイン認証は、メール配信基盤を安定して運用するための重要な前提の一つです。EngageLab Emailでは送信ドメインのSPF・DKIM・DMARC設定を扱えるため、メール配信基盤の導入とあわせて認証設定を整理したい場合は、EngageLab Emailの機能も確認できます。

DMARCを整備した後に、対応メールサービスでブランドロゴを表示する仕組みまで検討する場合は、BIMIの仕組みと設定条件も参考にしてください。