DMARC（Domain-based Message Authentication, Reporting and Conformance）
概要
DMARC（Domain-based Message Authentication, Reporting and Conformance） は、SPF と DKIM の認証結果を組み合わせ、認証に失敗したメールをどう処理すべきかをドメイン所有者が宣言する仕組みです。仕様は RFC 7489（2015年）で定義されています。
SPF と DKIM はそれぞれ独立した認証を行いますが、どちらも「メールクライアントに表示されるヘッダー From のドメインがなりすましでないか」を直接検証しません。DMARC はこのギャップを埋め、ヘッダー From ドメインと SPF / DKIM の認証結果を照合（アライメント）することでなりすましメールを判定します。
2025 年 11 月以降、Google は大量送信者（1 日 5,000 通以上）に対して DMARC の設定を義務化し、非準拠メールは一時的または永続的に拒否される運用に移行しています。Yahoo も同様の方針を取っています。DMARC レコードがない、またはポリシーが p=none のままでは、正規メールが迷惑メールフォルダに振り分けられるリスクがあります。
仕組み
DMARC の検証フローは次の通りです。
- 受信サーバーが SPF（エンベロープ From のドメイン検証）と DKIM（
DKIM-Signatureのd=タグのドメイン検証）を実行する _dmarc.ドメインの TXT レコードからポリシーを取得する- SPF または DKIM のいずれかが pass し、かつアライメントが取れていれば DMARC pass
- fail の場合、ポリシー（
none/quarantine/reject）に従ってメールを処理する
アライメントとは
アライメントは、SPF / DKIM が検証したドメインと、ヘッダー From のドメインが一致するかを確認する処理です。アライメントには relaxed（デフォルト）と strict の 2 モードがあります。
relaxed モードでは組織ドメインレベルでの一致を許容します。例えばヘッダー From が @example.com で、DKIM の d= が mail.example.com であれば、どちらも example.com の配下なので pass します。strict モードでは完全一致が必要です。aspf=s または adkim=s で指定します。
ポリシー
p=none はポリシー適用なし。メールの処理に影響を与えず、レポートの受信だけを行います。DMARC 導入初期のモニタリングフェーズで使います。
p=quarantine は認証失敗メールを迷惑メールフォルダに振り分けます。p=reject は認証失敗メールを受信拒否します。段階的に none → quarantine → reject と移行するのが一般的な導入パターンです。
レポート
DMARC はドメイン所有者に認証結果のフィードバックを送ります。
rua= タグに指定したアドレスには、集計レポート（Aggregate Report）が XML 形式で届きます。通常 24 時間ごとで、送信元 IP、認証結果、件数の統計データが含まれます。自社の正規メールが pass しているか、不審な送信元がないかを把握するのに使います。
ruf= タグに指定したアドレスには、失敗レポート（Forensic Report）が届きます。ただし Gmail、Yahoo を含む主要プロバイダーの多くはプライバシー上の理由で ruf レポートを送信していません。現在は rua を軸にした運用が現実的です。
設定例
p=none から p=reject まで段階的にポリシーを強化する導入パターンと、サブドメイン向けの個別設定を示します。
モニタリングフェーズ（p=none）
DMARC 導入初期のモニタリング用レコードです。
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"rua で指定したアドレスに集計レポートが届き、自社の送信状況を把握できます。十分なデータが集まったら p=quarantine に移行します。
quarantine への移行
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=100"問題がないことを確認したら p=reject へ移行します。
reject への移行
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; pct=100"サブドメインへの個別ポリシー
サブドメインに個別のポリシーを適用するには sp= タグを使います。
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-reports@example.com"確認方法
DMARC レコードの内容は dig で確認できます。
dig TXT _dmarc.example.com;; ANSWER SECTION:
_dmarc.example.com. 3600 IN TXT "v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s"v=DMARC1 で始まる行が返れば、レコードが存在しています。p= タグでポリシー、rua= タグでレポート送信先を確認します。
外部の視点からも確認したい場合は、Labee Dev Toolbox の Mail Auth API を使うと、外部の視点から見た結果を取得できます。
curl "https://labee.dev/api/mail-auth?domain=example.com"{
"success": true,
"data": {
"spf": { "record": "v=spf1 include:_spf.google.com ~all", "exists": true },
"dkim": { "record": "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...", "exists": true, "selector": "default" },
"dmarc": {
"record": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com",
"exists": true
},
"bimi": { "record": null, "exists": false }
},
"error": null,
"meta": { "responseTime": 123 }
}data.dmarc.exists が true であれば外部から DMARC レコードが確認できる状態です。data.dmarc.record フィールドでポリシーの内容も確認できます。
よくある問題
DMARC 運用で頻出するのは、ポリシーの放置、レポート未設定、サブドメインの認証漏れです。
p=none のまま放置する
モニタリングフェーズで導入したまま強化しないパターンです。p=none はメール処理に影響しないため、なりすまし対策として機能しません。rua レポートを 2〜4 週間確認して正規送信元の pass が安定したら、p=quarantine に移行します。
rua の受信先を用意しない
rua= を設定しないと、認証失敗の状況を把握できません。集計レポートは XML 形式で届くため、DMARC Analyzer（dmarcian、Valimail など）のようなレポート解析サービスを使うと可読性が上がります。専用メールアドレスを用意して、定期的に確認する習慣を作ります。
pct= を低い値のまま使い続ける
pct=50 は「50% のメールにポリシーを適用する」という意味ですが、残り 50% には適用されません。部分適用はなりすましリスクを完全には排除しません。本番環境では pct=100（または省略、デフォルトが 100）で運用します。
サブドメインの送信元を見落とす
marketing.example.com や info.example.com などサブドメインから送信するサービスがある場合、p=reject 移行前にそれらもすべて SPF / DKIM を設定します。rua レポートでサブドメインの認証状況を確認してから移行します。
アライメントエラーを見落とす
SPF が pass でも、SPF が検証したドメイン（エンベロープ From）とヘッダー From が異なればアライメントエラーになります。SaaS のメール送信サービスを使う際にこのズレが起きやすく、サービス側の指示通りにカスタムドメインを設定する（または DKIM アライメントで代替する）必要があります。
他の認証方式との関係
SPF はエンベロープ From を検証しますが、ヘッダー From のなりすましは防げません。DKIM はメール本文とヘッダーへの署名で改ざんを検証しますが、署名ドメインとヘッダー From の一致は保証しません。DMARC がこの両方をヘッダー From との比較で統合し、受信側が取るべき行動を宣言します。
BIMI は DMARC ポリシーが p=quarantine 以上の場合に有効化できます。p=reject で運用している場合、VMC または CMC を取得することで Gmail や Yahoo Mail のメールに会社ロゴを表示できます。DMARC の強化は BIMI への前提条件です。