「DMARC検証に合格せず、DMARCポリシーがReject（拒否）となっている」：その意味と修正方法

「DMARC検証に合格せず、DMARCポリシーがRejectに設定されている」エラーは、メールがDMARC認証に失敗し、受信サーバーが配信をブロックしたことを意味します。この問題は、SPFまたはDKIMが「差出人」ドメインとの整合性に失敗し、かつDMARCポリシーがp=rejectに設定されている場合に発生します。DMARCリジェクトエラーを修正するには、SPFレコードの修正、DKIM署名の有効化、厳密なドメイン整合性の確保を行い、メール配信可能性を回復し、なりすましを防止してください。

このDMARCエラーが実際に意味すること

受信サーバーがメールを処理する際、送信者が許可されているか確認するため複数のチェックを実行します。これらのチェックに失敗した場合、サーバーはドメインのDMARCレコードを参照し、次の対応手順を確認します。

「DMARC検証に合格しません」の解説

DMARCの失敗は、メールがDMARCの整合性チェックに失敗した際に発生します。SPFやDKIMを通過すれば十分だと考えるのは誤りです。DMARCでは、ユーザーに表示される「From」ヘッダーのドメインが、SPFおよび/またはDKIMで検証されたドメインと一致していることを要求します。技術的な署名が可視の送信者アドレスと一致しない場合、DMARCは失敗します。

「DMARCポリシーの拒否」が意味するもの

p=rejectタグは最も厳格なDMARCポリシーです。受信サーバーに対して「このメールが検証を通過しない場合、配信せず完全に破棄せよ」と指示します。

DMARC検証の仕組み（概要）

DMARCを通過するには、メールは次の条件を満たす必要があります：

1. 技術パス: SPF または DKIM が有効である必要があります。
2. 整合性: SPFまたはDKIMで使用されるドメインは、「差出人」アドレスのドメインと一致する必要があります。

アライメントは単純なパスよりも重要です。例えば、サブドメインからメールを送信しても、SPFレコードがウェブホストのドメインのみを許可している場合、ホストのSPFチェックは「パス」するかもしれませんが、ドメインが一致しないためDMARCは「失敗」します。

メールがDMARCに失敗し拒否される理由

1. 認証失敗

• SPF失敗または未承認送信元IP: SPFはドメインのVIPゲストリストのようなものと考えてください。CRMやメールマーケティングプラットフォームなど新しいツールを使い始めた際、そのリスト（SPFレコード）への追加を忘れると、受信サーバーは未登録のIPが侵入を試みていると認識し、ドアを閉ざしてしまいます。
• 欠落または破損したDKIM：DKIMは基本的にデジタルの蝋印のようなものです。サーバーがメールに「署名」していない場合、またはDNS設定に指定した「鍵」が古いか破損している場合、受信者はメールが実際にあなたから送信されたことを確認できません。印がないと、入場を許可されません。

2.アライメントの問題

• DKIMドメイン不一致：これは、提示された身分証明書の名義と本人が一致しない状況に似ています。メール送信元がyourdomain.comと表示されているのに、DKIM署名がrandom-service.comによって署名されている場合、DMARCは不審に思います。すべてが同一の基盤を指し示す必要があります。
• 転送によるSPF整合性の破綻：これは典型的な「中間者」問題です。メールが転送されると、「Return-Path」が転送元の情報に置き換わる場合が多く、これによりSPFが完全に破綻します。これは非常に一般的な現象であり、まさにDKIMが命綱となる理由です。DKIMはメールが転送されても付随し続ける一方、SPFは通常機能しなくなるからです。

ポリシー p=reject がこのエラーを重大なものにする理由

DMARCポリシーは、以下の順序で適用されます：

• p=none:監視モード。メールはブロックされません。
• p=quarantine:疑わしいメールは迷惑メールフォルダに振り分けられます。
• p=reject:ゼロトレランス。許可されていないメールは削除されます。

p=reject 状態では、誤りの余地は一切ありません。サードパーティ送信者が完全に設定されていない場合、正当なビジネス通信もフィッシング攻撃と同様に扱われ、ブロックされます。

隠された要因：サブドメインポリシー (sp=)

管理者にとって意外な点の一つは、DMARCがサブドメイン（例：marketing.yourdomain.com）をどのように扱うかです。デフォルトでは、メインドメインをp=rejectに設定すると、すべてのサブドメインがその「ブロック」コマンドを自動的に継承します。

サブドメインから送信する古いツールがまだ完全に設定されていない場合、即座に送信が停止されます。これを管理するには、DMARCレコードでspタグを使用できます：

• sp=none:メインドメインがp=reject設定であっても、サブドメインを「監視モード」に維持します。
• sp=reject:サーバーに対し、いかなるサブドメインからの不正なメールもブロックするよう明示的に指示します。

プロのアドバイス：サブドメインを使用しているすべてのサービスについて100%確信が持てない場合は、p=reject; sp=none; から始めて、サブブランドを監査している間もメインブランドを保護しましょう。

このエラーが発生する一般的な状況

Gmail と Google Workspace

Googleは最近、一括送信者に対する要件を強化しました。「GoogleのDMARCポリシーに準拠していないため、メッセージが拒否されました」というバウンスメッセージが表示される場合があります。

Microsoft 365 と Outlook

マイクロソフトは頻繁に「高度な脅威対策」を使用します。DMARCが失敗しポリシーが拒否された場合、Outlookサーバーはしばしば5.7.1 NDR（非配達レポート）を生成します。

サードパーティ製ツール

多くの企業は、CRMやHRプラットフォームの認証を忘れています。これらのツールは自社ドメインを「代行」してメールを送信するため、DMARC拒否の最も一般的な原因となっています。

「DMARC検証に合格しません」の修正方法

エラーを解決するには、次の手順に従ってください：

1. 送信元を特定する：まず最初に「差出人へ返送」のメモを確認しましょう。バウンスバックメッセージを見て、メールを送信しようとした具体的なIPアドレスやサービスを探します。これが通常、ゲートでブロックされた犯人を特定する決定的な証拠となります。
2. SPF認証の確認：SPFレコードはドメインの「承認済み送信者」リストと考えてください。利用中のサービスが実際に登録されていることを確認する必要があります。登録されていない場合は、DNSレコードにそのサービスの「include」ステートメントを追加し、受信サーバーが「このサービスがあなたを代表して送信することを許可されている」と認識できるようにする必要があります。
3. DKIM署名の問題を修正：サービスが実際に、自社ドメインを指すDKIMキーでメールに「署名」していることを確認する必要があります。デジタル署名が欠落しているか、全く別のドメインに属している場合、受信者はそれを偽造IDとして扱います。
4. ドメイン整合性の確保：すべての要素が一致している必要があります。「差出人」アドレスのドメインが、SPFおよびDKIMで使用されているドメインと同一であることを確認してください。メールの差出元がcompany.comと表示されているのに、SPFがrandom-app.netを認証している場合、DMARCの検証は成立しません。
5. DMARCレポートの確認：DMARC監視ツールを使用して「RUA」レポートを確認します。これにより、どのサービスが失敗しているのか、その理由が正確にわかります。
6. 再送信前のテスト:オンラインヘッダーアナライザーを使用してテストメールを送信し、「DMARC Pass」ステータスを確認してください。

一時的な対処法 vs. 適切な解決策

p=rejectを削除することが危険な理由

配信を「修正」するためにポリシーをp=noneに戻したくなるかもしれません。これによりバウンスは止まりますが、ドメインがハッカーによるなりすましの標的となるリスクが生じます。偽りの安心感を与えつつ、ブランド評判を危険に晒す結果となります。

より安全な復旧方法

セキュリティを弱める代わりに、監視ツールを使用して正常なトラフィックの異常を特定してください。また、「パーセンテージ」タグ（例: p=reject; pct=50）を使用して、送信元がすべて正しく調整されていることを確認しながら、ポリシーを段階的に適用することも可能です。

PowerDMARCがDMARCリジェクトエラーを防止する方法

単純な「拒否」ポリシーは鈍器のようなものですが、PowerDMARCは悪意のある行為者だけを確実に排除するための精密なツールを提供します。

1.完全な可視性とAI脅威インテリジェンス：XMLレポートを手動で読むのは、マトリックスコードを読もうとするようなものです。PowerDMARCのDMARCレポートアナライザーは、これらの複雑なファイルを人間が読めるダッシュボードに変換します。

2.AI駆動型脅威マッピング：当社のAI搭載脅威インテリジェンスは、不正なIPアドレスの地理的位置と評判を特定します。これにより、設定ミスのある内部ツールと悪意のあるなりすまし攻撃を区別することが可能になります。

3.簡易レコード管理（ホステッドサービス）：DMARC失敗の最も一般的な原因は「不整合」であり、SPFまたはDKIMレコードがドメインと一致しない状態を指します。PowerDMARCのホステッドサービス（ホステッドDMARCを含む）では、DNSプロバイダーにログインすることなく、ダッシュボードから直接これらのレコードを更新できます。

DMARCポリシー拒否エラーを回避するためのベストプラクティス

「拒否」ポリシーを維持するには、継続的なメンテナンスが必要です。正当なメールが自社のセキュリティ網に引っかからないようにするには、以下の業界ベストプラクティスに従ってください：

認証と整合性の衛生管理

• 新規送信者は常に認証を：マーケティング部門や人事部門が新しいメールツールを導入する前に、カスタムDKIMまたはSPF整合性をサポートしていることを確認してください。適切なDNS設定なしに、第三者が自社ドメインを「代行」して送信することを決して許可しないでください。
• 耐障害性にはDKIMを推奨：SPFはメール転送によって容易に破られます。DKIMは、メールが異なるサーバーを経由してもデジタル署名がメールヘッダーに付随し続けるため、はるかに堅牢です。

継続的監視と変更管理

• 定期的なDMARCレポートの確認：DMARCは、自社ドメインを使用してメールを送信している主体を詳細に記録したXMLレポートを生成します。少なくとも週1回はこれらのレポートを確認することで、不正ななりすましの試みや、突然準拠しなくなった正当なサービスを見逃さずに済みます。
• メールインフラ変更追跡：メールDNSレコードをコードのように扱ってください。SPF、DKIM、DMARCレコードへのあらゆる変更を記録します。サーバー移行やベンダー変更後に配信問題が発生した場合、特定の設定変更が「ポリシー拒否」エラーを引き起こしたことを迅速に特定し、ロールバックできます。

結論：拒絶があなたの可能性を台無しにさせないで

「DMARCポリシーによる拒否」エラーは、まるで自社の警備員が誤ってあなたをオフィスから締め出してしまうようなものです。確かに厄介ですが、そのロックが実際に機能している証拠でもあります。

解決策は鍵を捨ててp=noneに戻ることではなく、正しい鍵を携行していることを確認することです。SPFとDKIMがドメインと適切に連携していることを保証すれば、バウンスを止め、完全に自信を持ってメール送信を開始できます。レポートを注視し、本番運用前に新ツールの認証を完了させれば、正当なメールがデジタルごみ箱行きになる心配は永遠になくなります。

今すぐ専門家による15日間の無料トライアルを開始し、ドメインセキュリティをいかに簡素化できるかご確認ください。

よくあるご質問

なぜ私のメールはDMARCに失敗するがSPFには合格するのか？

これは通常、整合性の問題です。メールサーバードメインに対してはSPFが「合格」していますが、そのドメインが「差出人」アドレスのドメインと一致していません。

配信を修正するためにp=rejectを削除すべきですか？

いいえ。これはセキュリティを損なう「応急処置」です。代わりに、問題が発生しているサービスを特定し、SPF/DKIM設定で正しく認証してください。

DMARCの修正が効果を発揮するまでにはどのくらい時間がかかりますか？

DNSの変更が全世界に反映されるまでには24～48時間かかる場合がありますが、ほとんどの現代的なシステムでは1時間以内に変更が反映されます。

DMARCは内部メールや転送メールに影響しますか？

はい。転送はしばしばSPFを無効化します。そのため、転送されたメールがDMARC検証を通過し続けるためには、有効なDKIM署名を保持することが非常に重要です。

• について
• 最新記事

ユネス・タラダ

ドメインとメールセキュリティのエキスパートPowerDMARC

ユネスはPowerDMARCのオペレーションチームリーダーで、メール認証とセキュリティの専門知識を持つ。マイクロソフト認定のAzureアドミニストレーターアソシエイトであり、CompTIA A+やその他多くの資格を持っています。

最新記事 by Yunes Tarada(全て見る)

• NIST SP 800-81r3：電子メールのためのDNSセキュリティガイドライン - 2026年6月25日
• DKIMレコードの分割方法 - 2026年6月5日
• compauth=fail：Microsoft 複合認証の解説 - 2026年6月1日