DMARCをquarantineに変更したらSPFエラー？よくある原因とDNS設定の落とし穴を解説

メールの到達性をあげるため、DMARCポリシーを p=none から p=quarantine や p=reject へ変更した直後、想定外にメールがエラーになり、「なぜぇ～」と、頭を抱えた経験はございませんか？

• Gmailでバウンスが発生した
• エラーログにSPFエラーと記載されている
• SPFチェックツールで確認すると『Pass』になるのにメールが届かない

メール配信システムの運用担当者であれば、DMARCポリシー引き上げと同時に何かが起きるかもしれないと心の中で構えるこの手のトラブル。

実はこの問題、「DMARCの設定変更そのもの」が直接的な原因ではなく、背後に隠れている「DNSレコードの構成ミス」が表面化したケースが非常に多いのです。

今回は、実際のトラブルシューティング事例をもとに、なぜMxToolboxなどで「SPF Pass」の判定が出ているのにGoogleなどで拒否されてしまうのか。

DMARC変更時に陥りやすいDNS設定の落とし穴、そして最も多い根本原因について分かりやすく説明していきます。

DMARCポリシー引き上げ後に発生するバウンス祭り

今回のケースはDMARCポリシー引き上げ時に比較的起きやすい典型的なトラブルのケースです。

メール配信を管理するシステム担当者が、セキュリティ強化とGoogleなどの送信者ガイドラインを遵守するため、 p=none で運用していたDMARCポリシーを p=quarantine に引き上げました。

変更作業自体は1行のTXTレコードを修正するだけなので瞬殺です。

ただ、数時間後、Gmail宛てのメールが配信エラーとなって戻ってくる事態に陥りました。Google側の受信サーバーから返ってきたエラーメッセージを確認すると、次のような内容が記録されていました。

550-5.7.26 This message does not have authentication information or fails to pass authentication checks... does not designate permitted sender hosts.

このエラーメッセージは、

「SPF認証に失敗したため、送信元ホストが許可されていないと判断しメールを拒否した」

という状態を示しています。

システム担当者は慌ててウェブ上の「SPFチェックツール」にドメインを入力してテストを行うのですが、ツールの判定は緑色で「Pass（成功）」。

ツール上では問題ないのに、実際のメールはSPFエラーで弾かれている..。なぜ!? 🙄

要注意です。DMARC変更が「エラー発生の直接的な原因」とは限らない

ここで大前提を確認しておきます。それは、「DMARCの設定を変更したこと自体が、SPFの仕組みを直接壊すことは通常あり得ない」という点です。

DMARCの役割とSPF・DKIMの関係

DMARCは、あくまで「SPF」と「DKIM」という2つの送信ドメイン認証の結果を評価し、認証に失敗したメールをどう処理するかを定めたポリシー（指示書）に過ぎません。

つまり、「DMARCをquarantineにしたらSPFエラーになった」という事象は、「DMARCがSPFを壊した」のではなく

「もともとSPFの設定に致命的な不備があり、DMARCを厳格化したことでその不備が “エラー “として顕在化した」

と考えるのが正しい考え方なのです。では、なぜ「SPF Pass」となるのか..。

なぜチェックツールでは「SPF Pass」になるのか？

もともとSPFに不備があったにもかかわらず、MxToolboxなどのチェックツールで「Pass」と表示されてしまうのは、テスト環境と本番環境で「参照している送信元IPアドレス」が異なるためです。

チェックツールは、仮のIPアドレス（テストを実行しているPCや自社のWebサーバーなど）を送信元として判定を行うことがあります。

しかし、受信BOX側が実際にチェックするのは、本番でメールを送った「実際の配信サーバーのIPアドレス」です。

ツール上の送信元と、本番の送信元が違っていれば、「ツールではPass、実際のメールはFail」という矛盾が起きてしまいます。

そのため、ツールの結果だけを鵜呑みにせず、バウンスメールのログ（Received-SPF: や client-ip=）を見て、「実際の送信元IP」で正しく認証されるかを直接検証することが重要です。

見落とされやすい根本原因｜CNAMEとTXTレコードの競合

IPアドレスの確認を行い、「設定したSPFレコードの中には確かに送信元IPが含まれている」と確認できた場合、次に疑うことは、DNSレコードの競合です。

【DNSの基本ルール】CNAMEと他レコードは共存できない

DNSの厳格な仕様（RFC）として、「同一のホスト名（ドメイン・サブドメイン）に対して、CNAMEレコードとその他のレコード（TXT、MX、Aなど）を同時に設定してはならない」というルールが存在します。

たとえば、メール配信用に mail.primoposto.co.jp というサブドメインを作成し、以下のような設定をしたとします。

• mail.primoposto.co.jp CNAME mailservice.com
• mail.primoposto.co.jp TXT "v=spf1 include:mailservice.com ~all"

一見すると、指定されたサービスへ向けるCNAMEと、SPF宣言のためのTXTレコードが存在し、問題ないように見えます。しかし、これはDNSの仕様上ではNGとなります。

これがSPFエラーを引き起こす仕組み

SPF認証は、受信側のサーバーが送信元ドメインのDNSサーバーにある「TXTレコード」を問い合わせることで実行されます。

しかし、問い合わせたドメイン名にCNAMEレコードが存在する場合、多くのDNSサーバーは

「ここは別名のCNAME（Canonical Name）だから、転送先の情報を見に行こう」

と判断し、本来そこにあるはずのTXTレコードを無視してしまったり、正しく情報を返さなかったりします。

結果として、Googleなどの受信側サーバーはSPFを宣言するTXTレコードを取得できず、

• SPFレコードが存在しない
• 送信元ホストが指定されていない

などと判断し、エラーを返すことになります。これが does not designate permitted sender hosts の正体です。

有料のメール配信サービス利用時に起こりやすい理由

この CNAME と TXT の競合問題は、

• SendGrid
• Amazon SES
• Cloudflare Email

などの外部のメール配信サービス（ESP：Email Service Provider）を利用している環境で起きます。

ESPを利用する際、ドメイン評価を管理しやすくするために専用のサブドメイン（例：em.primoposto.co.jp）を切って配信することが推奨されます。

その初期設定のマニュアルには「サブドメインにCNAMEを設定してください」と指示されることがよくあります。

ESP設定でのありがちなミス例
em.primoposto.co.jp CNAME provider.example-esp.com

担当者はマニュアル通りにCNAMEを設定します。そして後日、「SPFも設定しなければ」と思い立ち、同じサブドメインに対してSPF用のTXTレコードを追加してしまうのです。

これで意図しない競合の完成です。

p=none のうちはエラーが表面化せず見逃されていても、DMARCを quarantine にした途端に一斉にブロックされ、トラブルが発覚します。

DMARC導入・変更時に確認すべき重要な4つのポイント

このようなトラブルを未然に防ぐため、DMARCのポリシーを変更する前、またはメールの到達率に異常を感じた際は、いくつかの重要な設定項目を全体的に見直す必要があります。

SPFの正しい設定と重複の排除

まずは、バウンスログに記録された client-ip が、実送信IPとして自社のSPFレコード内に正しく含まれているかを確認します。

外部の配信サービスを include: で指定している場合、その記述に誤りがないかも重要です。手入力なのでミスが無いか、必ず疑ってください。

特に注意すべきは、同一ドメインに対してSPF用のTXTレコードが複数存在していないかという点です。SPFの記述は必ず1つのレコード内にまとめる必要があります。

DKIMレコードの正確な公開

SPFと並んで、公開鍵のDNSレコード（セレクタ名 ._domainkey）が正しく設定されているかどうかも確認しましょう。

設定が漏れているケースのほか、レコードのコピペ時に不要なスペースが混入し、フォーマットが崩れることで認証に失敗するケースも多いため、目視での慎重なチェックが求められます。

DNS構成の競合チェックと浸透待ち

最も重要なポイントが、DNS構成におけるレコードの競合チェックです。

前述の通り、同一のホスト名に対してCNAMEレコードとTXTレコード（SPF）が重複して登録されていないか、またはMXレコードとCNAMEが混在していないか確認ください。

また、DNSの変更を行った直後は、TTL（キャッシュの有効期限）が経過して全世界のDNSサーバーに新しい情報が浸透するまで、一定の待機時間が必要であることも考慮する必要があります。

DMARCポリシーの段階的な移行

運用面においては、いきなりポリシーを p=reject に設定することは絶対に避けてください。

最初は p=none（監視）の状態で数週間レポートを監視し、正当なメールが誤ってFailと判定されていないかを確認します。

問題がないと判断できた段階で p=quarantine へ引き上げ、さらに様子を見るといった、段階的なアプローチを取ることが安全な到達性改善の鉄則です。

最後に

今回の事例から学べる教訓は、

「DMARC変更が直接の原因に見えても、実際は土台となるDNS設計のミスであった」

ということです。メール到達率の問題に対処する際は、変更を加えた箇所だけを局所的に見るのではなく、SPF、DKIM、そしてそれらを支える関連DNSレコード全体を俯瞰して確認することが非常に重要です。

DMARCポリシーを変更した直後にSPFエラーが発生した際は、

1. 簡易的なチェックツールの結果を鵜呑みにせず「実送信IPでのSPF確認」を行うこと
2. 同じサブドメイン内で「CNAMEとTXTが競合していないか」をチェックすること
3. ESP推奨DNS設定を誤って解釈していないかを見直すこと

が早期解決への近道となります。

中でも、「サブドメインに対するCNAMEとSPF（TXT）の重複」は、現場の実務担当者が意外とハマりやすい落とし穴です。

DMARCポリシーの変更前後は、必ず自社のDNS構成全体を再点検し、安全で確実なメール配信環境を維持しましょう。

DMARCの本格的な運用・監視に向けて

このような設定の壁を乗り越え、自社のドメイン評価とブランドを守るためには、SPF・DKIMに加え、DMARCを正しく設定し、最終的に「p=reject（拒否）」の運用を目指すことが最適解です。

自分のメールアドレスから迷惑メールが届くという現象は、多くの場合、アカウントの乗っ取りではなく、メール配信における弱点を突いた「なりすまし」に起因します。

しかし、DMARCの運用には高度なXMLファイルの分析能力が必要となり、手動での管理は現実的ではありません。

PowerDMARCのような解析ツールを活用してメール送信状況を可視化し、継続的に監視することこそが、最短ルートでなりすましを排除し、メール到達率を最大化するための鍵となります。

プリモポストは2025年12月より PowerDMARC の正規代理店としての提供を開始しました。

メールなりすまし対策やDMARC運用は、一度設定すれば終わりではなく、 送信環境の変化や新たな攻撃手法に応じて継続的な見直しが必要となります。

そのため、取扱い開始にあたり先着100事業者さまを対象に、1年間特別価格でPowerDMARCを提供しています。 これは価格訴求を目的としたものではなく、 DMARC運用の可視化と定着を支援するための導入支援施策です。

「自社ドメインが現在どのように使われているのか把握したい」 「DMARCを設定したが、次の一手に迷っている」 といった場合には、現状確認からでもご相談ください。