Labee Dev Toolbox
技術ノートガイド用語解説
無料で試す
  1. ホーム
  2. / 用語解説
  3. / DMARC 合否判定（DMARC pass / fail）
メール認証

DMARC 合否判定（DMARC pass / fail）

2026年2月3日 更新

概要

DMARC 合否判定（DMARC pass / fail） は、受信サーバーが SPF または DKIM の認証結果とアライメントの両方を評価し、メールが DMARC ポリシーに適合するかを判定するプロセスです。仕様は RFC 7489（2015年）の Section 4.2 で定義されています。

判定ルールは明快です。SPF が pass かつ SPF アライメントが pass、または DKIM が pass かつ DKIM アライメントが pass のいずれか一方を満たせば DMARC pass になります。両方とも満たさなければ DMARC fail です。DMARC fail になったメールには、ドメイン所有者が p= タグで宣言したポリシー（none、quarantine、reject）が適用されます。

この「認証 + アライメント」の二段構えが DMARC の核心です。SPF や DKIM が pass していても、ヘッダー From ドメインとの一致（アライメント）が取れていなければ DMARC は fail します。逆に、SPF が fail していても DKIM アライメントが成立していれば DMARC は pass します。

仕組み

DMARC の合否は「認証（SPF / DKIM が pass しているか）」と「アライメント（ヘッダー From ドメインと一致するか）」の二段階で評価されます。

判定フロー

受信サーバーが DMARC の合否を判定する流れは次の通りです。

  1. ヘッダー From（RFC5322.From）のドメインを取得する
  2. _dmarc.ドメイン の TXT レコードから DMARC ポリシーを取得する
  3. SPF 認証を実行し、pass した場合は SPF アライメントを評価する
  4. DKIM 認証を実行し、pass した場合は DKIM アライメントを評価する
  5. ステップ 3 または 4 のいずれかで「認証 pass + アライメント pass」が成立すれば DMARC pass
  6. どちらも成立しなければ DMARC fail となり、p= タグのポリシーに従ってメールを処理する

SPF と DKIM は並列に評価されます。片方が fail しても、もう片方が pass + aligned であれば DMARC 全体は pass です。

認証とアライメントの関係

認証（Authentication）とアライメント（Alignment）は別の評価です。

SPF 認証は、エンベロープ From のドメインの SPF レコードに送信元 IP が含まれているかを検証します。SPF アライメントは、SPF が検証したドメイン（エンベロープ From）とヘッダー From のドメインが一致するかを確認します。

DKIM 認証は、DKIM-Signature ヘッダーの署名が有効かを検証します。DKIM アライメントは、署名の d= タグのドメインとヘッダー From のドメインが一致するかを確認します。

認証が pass していてもアライメントが fail すれば、その経路は DMARC の判定に寄与しません。

判定パターン

具体的な判定パターンを示します。ヘッダー From が @example.com の場合を想定します。

SPF 認証SPF アライメントDKIM 認証DKIM アライメントDMARC 結果
passpasspasspasspass
passpassfail-pass
fail-passpasspass
passfailpasspasspass
passfailfail-fail
fail-passfailfail
fail-fail-fail

4 行目のケースは、SaaS のメール配信サービスでよく発生します。SPF はサービス側のドメインで pass しますが、ヘッダー From とのアライメントが取れません。カスタムドメインの DKIM 署名が pass + aligned であれば、DMARC は pass します。

DMARC fail 後の処理

DMARC fail になったメールは、ポリシーに従って処理されます。

p=none の場合、メールは通常通り配送されます。ポリシーが適用されないため、受信者はメールを受け取れます。ただし rua レポートには fail として記録されます。

p=quarantine の場合、受信サーバーはメールを迷惑メールフォルダに振り分けます。Gmail は Spam フォルダ、Outlook は Junk フォルダに移動します。

p=reject の場合、受信サーバーはメールを拒否します。SMTP レベルでの拒否（5xx レスポンス）か受信後の破棄かはプロバイダーの実装に依存しますが、受信者には届きません。

pct= タグが設定されている場合、指定された割合の fail メールにのみポリシーが適用されます。pct=50 なら 50% の fail メールにポリシーを適用し、残り 50% は p=none と同様に扱います。

具体例

自社サーバーからの直接送信、SaaS 経由の送信、認証未設定の送信の 3 パターンで DMARC の判定結果がどう変わるかを示します。

DMARC pass になるケース

自社サーバーから直接送信し、SPF と DKIM の両方が正しく設定されている場合です。

ヘッダー From: info@example.com
エンベロープ From: info@example.com
送信元 IP: 203.0.113.10（SPF レコードに記載済み）
DKIM 署名: d=example.com; s=selector1

→ SPF 認証: pass（エンベロープ From のドメインの SPF レコードに IP が含まれる）
→ SPF アライメント: pass（エンベロープ From と ヘッダー From が同一ドメイン）
→ DMARC: pass

SPF の経路だけで DMARC pass が成立しています。DKIM も pass していれば冗長性が確保されますが、DMARC の合否判定には片方で十分です。

DKIM アライメントのみで pass するケース

SendGrid 経由で送信し、カスタムドメインの DKIM 署名を設定している場合です。

ヘッダー From: news@example.com
エンベロープ From: bounce@em1234.sendgrid.net
DKIM 署名 1: d=example.com; s=s1（カスタムドメイン署名）
DKIM 署名 2: d=sendgrid.net; s=smtpapi（SendGrid 署名）

→ SPF 認証: pass（sendgrid.net の SPF レコードに IP が含まれる）
→ SPF アライメント: fail（sendgrid.net ≠ example.com）
→ DKIM 認証（署名 1）: pass
→ DKIM アライメント（署名 1）: pass（d=example.com = ヘッダー From のドメイン）
→ DMARC: pass

SPF は pass していますが、エンベロープ From のドメインがヘッダー From と一致しないためアライメントが fail します。DKIM 署名 1 がカスタムドメインで pass + aligned のため、DMARC は pass です。署名 2 の d=sendgrid.net はアライメントに失敗しますが、署名 1 が通過しているので影響しません。

DMARC fail になるケース

SPF の設定はあるものの、DKIM が未設定で、エンベロープ From のドメインがヘッダー From と異なる場合です。

ヘッダー From: contact@example.com
エンベロープ From: bounce@mailservice.net
DKIM 署名: なし

→ SPF 認証: pass（mailservice.net の SPF レコードに IP が含まれる）
→ SPF アライメント: fail（mailservice.net ≠ example.com）
→ DKIM 認証: fail（署名なし）
→ DMARC: fail

SPF は pass していますが、アライメントが取れません。DKIM も未設定のため、DMARC pass の条件を満たす経路がありません。

確認方法

DMARC の合否判定結果を確認する方法は、メールヘッダーの Authentication-Results を読むのが最も直接的です。

受信したメールのソースを表示すると、Authentication-Results ヘッダーに DMARC の判定結果が記録されています。

Authentication-Results: mx.google.com;
    dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com;
    spf=pass (google.com: domain of bounce@example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounce@example.com;
    dkim=pass header.d=example.com header.s=selector1

dmarc=pass が DMARC の最終判定です。p=REJECT はドメインのポリシー、dis=NONE は実際に適用された処置（disposition）を示しています。pass の場合はポリシーが適用されないため NONE になります。

DMARC fail の場合は次のように表示されます。

Authentication-Results: mx.google.com;
    dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) header.from=example.com;
    spf=pass smtp.mailfrom=other-domain.com;
    dkim=fail

dmarc=fail で dis=QUARANTINE は、ポリシーに従い迷惑メールフォルダに振り分けられたことを示します。

ドメイン全体の DMARC pass 率を把握するには、rua で受信する集計レポート（Aggregate Report）を確認します。XML 内の <policy_evaluated> セクションに送信元 IP ごとの判定結果が記録されています。

<record>
  <row>
    <source_ip>203.0.113.10</source_ip>
    <count>1500</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
</record>

<policy_evaluated> の <dkim> と <spf> はアライメント込みの結果です。両方が pass であれば DMARC pass、両方が fail であれば DMARC fail です。<auth_results> セクションの結果と混同しないよう注意します。<auth_results> は純粋な認証結果（アライメントを含まない）です。

外部からドメインの DMARC レコードの設定状態を確認したい場合は、dig で TXT レコードを引きます。

dig TXT _dmarc.example.com
;; ANSWER SECTION:
_dmarc.example.com.	3600	IN	TXT	"v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s"

外部の視点からも確認したい場合は、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 でポリシーの内容を確認できます。ただし、この API は DNS レコードの存在確認であり、個々のメールの DMARC 合否判定を行うものではありません。

よくある問題

DMARC の合否判定で混乱が生じやすいのは、SPF や DKIM が pass しているにもかかわらずアライメント不一致で DMARC fail となるケースです。

SPF pass なのに DMARC fail になる

最も混乱が多いケースです。SPF 認証が pass していても、SPF アライメントが fail していれば DMARC には寄与しません。

典型的な原因は、SaaS のメール送信サービスがエンベロープ From にサービス側のドメイン（bounces.sendgrid.net など）を使っていることです。SPF は sendgrid.net の SPF レコードで pass しますが、ヘッダー From が @example.com のため、組織ドメインが異なりアライメントが fail します。

対処法は 2 通りあります。1 つ目は、送信サービスのカスタムドメイン設定でエンベロープ From を bounce.example.com のように自社ドメイン配下にする方法です。relaxed モードであれば組織ドメインが一致して SPF アライメントが pass します。2 つ目は、カスタムドメインで DKIM 署名を設定し、DKIM アライメントで DMARC pass を確保する方法です。

DKIM pass なのに DMARC fail になる

DKIM 認証が pass していても、d= タグのドメインがヘッダー From のドメインと一致しなければ DKIM アライメントは fail します。

Amazon SES を導入直後にカスタムドメインの DKIM を設定していない場合、d=amazonses.com で署名されます。ヘッダー From が @example.com であれば組織ドメインが異なり、DKIM アライメントは fail です。SES のカスタムドメイン DKIM（Easy DKIM）を設定して d=example.com で署名されるようにします。

転送メールで DMARC fail になる

メーリングリストや大学のメール転送を経由すると、DMARC fail が発生しやすくなります。転送時にエンベロープ From が転送サーバーのドメインに書き換わるため SPF アライメントが fail し、転送先がメール本文やヘッダーを改変（Subject にプレフィックスを追加するなど）すると DKIM 署名が壊れて DKIM も fail します。

ARC（Authenticated Received Chain、RFC 8617）は、転送チェーンの各段階で認証結果を記録する仕組みで、転送によるDMARC fail を緩和する目的で策定されています。Gmail は ARC の評価をサポートしていますが、すべてのプロバイダーが対応しているわけではありません。転送メールの DMARC fail は rua レポートで検出し、影響範囲を把握します。

rua レポートの読み間違い

DMARC 集計レポートの XML には、<auth_results> と <policy_evaluated> の 2 箇所に認証結果が記載されます。

<auth_results> は SPF と DKIM の純粋な認証結果です。SPF が pass でも、アライメントが fail していれば <policy_evaluated> の <spf> は fail になります。DMARC の合否判定は <policy_evaluated> の値で行います。

<auth_results> だけを見て「SPF pass なのに DMARC fail になった」と誤認するケースがあります。レポートを分析する際は、<policy_evaluated> セクションを参照します。dmarcian や Valimail などのレポート解析サービスを使うと、この区別が視覚的に分かりやすくなります。

p=none で DMARC fail を放置する

p=none は DMARC fail になってもメール配送に影響しないため、fail が発生していても気づきにくい状態です。rua レポートを定期的に確認して fail の送信元を特定し、正規の送信経路であれば SPF / DKIM の設定を修正します。

fail を放置したまま p=quarantine や p=reject に移行すると、正規メールが迷惑メールフォルダ行きまたは拒否されます。ポリシー強化前に、すべての正規送信経路で DMARC pass が安定していることを rua レポートで確認します。

実際のドメインで確認してみる

登録不要、無料です。ドメイン名を入れるだけで外部からの見え方を確認できます。

無料で試す

関連用語

メール認証

DMARC（Domain-based Message Authentication, Reporting and Conformance）

SPF と DKIM の認証結果を統合し、なりすましメールの処理方針をドメイン所有者が宣言する仕組み。Google・Yahoo が大量送信者に義務化。

メール認証

DMARC ポリシー

DMARC 認証に失敗したメールを none・quarantine・reject で処理する宣言。Google は大量送信者に p=quarantine 以上を要求。

メール認証

識別子アライメント（Identifier Alignment）

DMARC が SPF・DKIM の認証ドメインとヘッダー From を照合して、なりすましを検出する仕組み。DMARC pass の必須条件。

メール認証

SPF アライメント（SPF Alignment）

DMARC が SPF の認証ドメイン（エンベロープ From）とヘッダー From のドメインを照合する仕組み。不一致は DMARC 失敗の主要原因。

メール認証

DKIM アライメント（DKIM Alignment）

DMARC が DKIM 署名の d= ドメインとヘッダー From ドメインを照合する仕組み。第三者署名ではアライメントが不一致になる。

コンテンツ 技術ノート ガイド 用語解説
ツール ツール一覧 API Reference
Labee 日本語トップ Labee LLC
© 2026 Labee LLC . All rights reserved.
ホーム ブログ ガイド 用語集