メールのなりすまし対策として広く使われているDMARC認証。

SPFやDKIMの設定も済ませて、ポリシーも適切に定義したはずなのに、なぜかDMARC認証が失敗してしまう—そんな経験はありませんか？

DMARC認証が失敗する原因には、SPFレコードやDKIMレコードの設定ミス、DNSの反映遅延、メール送信元の誤りなど、さまざまな要因があります。しかし、これらの「わかりやすい」原因の陰に隠れて、意外と見落とされがちなのがアライメント（整合性）の失敗です。

たとえば、SPF認証が「Pass（成功）」になっていても、Return-Pathのドメイン（envelope-from）とFromヘッダーのドメインが一致していなければ、DMARC的にはSPFアライメントが「Fail（失敗）」と判定されます。

同様に、DKIM認証が「Pass」でも、署名されたドメイン（d=タグ）とFromヘッダーのドメインが一致していなければ、DKIMアライメントも「Fail」となります。つまり、SPF認証やDKIM認証が通っているだけでは不十分で、**Fromヘッダーとの整合性（アライメント）**が取れていないと、DMARC認証は失敗してしまうのです。

今回は、DMARC認証の中でも意外と見落とされがちな「アライメントの失敗」に焦点を当てて、仕組みとよくある注意点についてわかりやすく解説していきます。

ご相談はこちらからご相談はこちらから

 

アライメントとは

「アライメント（alignment）」とは、DMARC認証においては「整合性」や「一致性」を意味する技術用語として用いられています。

メールのFromアドレスは、見た目上の送信者情報であり、技術的には誰にでも自由に設定可能です。そのため、攻撃者は正規ドメインを設定して、信頼される送信者を装うことが可能になっています。

そのような、なりすまし（スプーフィング）を対策するために、DMARCではアライメントが必要になります。アライメントは、一般的に2種類あり、SPFアライメントとDKIMアライメントです。

SPF/DKIMアライメントの違い

SPFアライメントとDKIMアライメントは、どちらもメール送信者情報の整合性を確認する仕組みですが、SPF、DKIMにおいてアライメントの判定方法が異なります。

  • SPFアライメント
    • SPF認証に使われる Envelope From（Return-Path）のドメインと、Fromヘッダーのドメインが一致しているか。
    • 一致していれば「SPFアライメントがPass」、一致していなければ「SPFアライメントがFail」となる。
  • DKIMアライメント
    • DKIM署名の d= 値（署名ドメイン）と、Fromヘッダーのドメインが一致しているか。
    • 一致していれば「DKIMアライメントがPass」、一致していなければ「DKIMアライメントがFail」となる。

DMARCにおけるアライメント

DMARCでは、「SPFまたはDKIMにおいて認証とアライメントがPass」であれば、DMARC認証がPassとなります。

具体的には、最低でも以下の条件どちらかを満たす必要があります。

  • SPF認証成功 & SPFアライメント成功=DMARC認証成功
  • DKIM認証成功 & DKIMアライメント成功=DMARC認証成功

図1：DMARC認証成功の判定（” Pass/Fail”についてはPass、Failのどちらでも結果に影響はない）

DMARCアライメントモード

DMARCを設定したのにメールが拒否される場合によくある原因として、アライメントモードがあります。DMARCでは、アライメントを確認する際にセキュリティを強化したモードである、Strict（厳格）モードが存在します。意図せず設定されていた場合は、 Relaxed（緩やか）モードへの変更を行うことで、改善する場合があります。アライメントモードは2種類存在し、以下の通りです。

  • Relaxedモード
    • SPFまたはDKIMの認証結果のドメインが、Fromヘッダーのドメインと「同一組織内」なら成功となる。

例：DKIM署名が relaxed.example.com で、Fromヘッダーが example.com → 合格

  • Strictモード
    • SPFまたはDKIMの認証結果のドメインが、Fromヘッダーのドメインと「完全一致」していないと失敗となる。

例：DKIM署名が strict.example.com で、Fromヘッダーが example.com → 不合格

 

メールシステムの認証要件によるメール認証失敗

DMARCにおけるアライメントですが、メールシステムによってはより厳しいメール認証要件を設定している場合があります。例として、GoogleではSPF認証、DKIM認証をどちらもPassした状態で、SPFアライメント、DKIMアライメントのどちらか一方、アライメントをPassすることが求められています[1]。2025/10/31時点で 、Gmailアカウントに1日5000件以上を送信する送信者に対してこの条件を満たす必要があります。

そのため、メール認証を運用する際には、現在使用しているメールシステムのガイドラインなどにも注意する必要があります。

[1] 注1)Google Workspace 管理者 ヘルプ, 「メール送信者のガイドライン 」,   1日あたり 5,000 件以上のメールを送信する場合の要件,2025/10/31

図2：Googleが求めるメール認証要件（” Pass/Fail”についてはPass、Failのどちらでも結果に影響はない）

注1)Google Workspace 管理者 ヘルプ, 「メール送信者のガイドライン 」 1日あたり 5,000 件以上のメールを送信する場合の要件,2025/10/31

 

DMARC認証の失敗原因を特定するには

DMARCの認証状況を確認し、 アライメントの失敗などの、認証失敗原因を特定するためには、DMARCレポートを解析する必要があります。しかし、DMARCレポートはXML形式で大量に届くため、人力による確認や集計を行うことは困難とされています。

そこで、Proofpoint EFDでは、 DMARCレポートを効率的に処理し、アライメントの状態や送信元の認証状況（SPF/DKIM/DMARC）を直感的なダッシュボードで確認できます。また、ダッシュボード内の専門的な説明を読み取ることが困難な場合でも、解析結果や次のアクションへのアドバイスをアナリストが解析し、月1回レポートとして発行いたします。 さらに、STech Iではお客様にご安心いただけるよう、EFDレポートの内容や具体的な動作についてご報告させていただくご支援メニューをご用意しております。

 

まとめ

今回は、DMARC認証が失敗する原因のひとつとして、よく見落とされがちな「アライメント」について解説しました。

DMARCは、正しく運用することでなりすましメールから自社ドメインを守り、信頼性の基盤を築くことができます。一方で、設定が複雑なため、誤った設定によって正当なメールが拒否され、業務に支障をきたすリスクもあります。

Proofpoint EFDでは、DMARCレポートの可視化と詳細な解析を通じて、こうしたリスクの早期発見と対策を支援します。自社ドメインの効率化やメール認証の精度を高めたい場合は、Proofpoint EFDをぜひご活用されてはいかがでしょうか？
また、ご不明点やご相談などがございましたら、どうぞお気軽にお問い合わせください。担当者が丁寧にご案内させていただきます。

DMARCの詳細はこちらからDMARCの詳細はこちらから

この記事を書いた人

セキュリティ情報発信