Gmailの「250 2.0.0 OK DMARC:Quarantine」とは？｜受け付けられたのに届かない理由と確認手順

2026.11.05

株式会社プリモポスト取締役

日吉浩之メール到達エバンジェリスト

メール配信サービスを運営する方から、Gmail や Google Workspace 宛ての一部の宛先だけ、SMTPの応答が次のようになる。ほかの宛先はいつもどおり 250 2.0.0 OK だけが返ってくる。

250 2.0.0 OK DMARC:Quarantine

「SMTPでは受け付けたうえで、受信箱ではなく隔離しているという理解でよいか。なぜ一部の宛先だけなのか」という内容です。

送信ログを見ている方なら、250 で始まる行は「成功」として流してしまいがちです。ですが、この応答は「届いた」という意味ではありません。

今回は、この応答の意味と、一部の宛先だけに出る理由、そして送信側が何を確認すればよいかを整理していきたいと思います。

この応答が意味すること

「受け付けた」と「受信箱に入った」は別

SMTPの 250 は、受信サーバーがメッセージを受け取ったことを示すだけです。受け取ったあと、受信箱に入れるか、迷惑メールフォルダに入れるかは、受信側がその後で決めます。

DMARC:Quarantine の部分は、そのメールがDMARCの検証に失敗し、差出人（Fromヘッダー）のドメインが p=quarantine を公開しているため、受信側がquarantine（隔離）として扱った、という意味だと考えられます。

Googleは、DMARCの設定方法の解説の中で、p=quarantine のときに受信サーバーが取る動作を「メールを迷惑メールとしてマークし、受信者の迷惑メールフォルダに送る」と説明しています（Google Workspace ヘルプ：DMARCを設定する）。

Gmailの個人アカウントであれば、多くの場合は迷惑メールフォルダに入ると考えてよいでしょう。

ポリシーごとの応答の違い

同じDMARCの失敗でも、差出人ドメインのポリシーによってGmailの応答は変わります。

差出人ドメインのポリシー	Gmailの応答（例）	メールの行き先
p=none	`250 2.0.0 OK`	通常どおり判定（DMARCの失敗だけでは隔離しない）
p=quarantine	`250 2.0.0 OK DMARC:Quarantine`	受け付けたうえで、迷惑メールフォルダなどへ
p=reject	`550 5.7.26 Unauthenticated email from ... is not accepted due to domain's DMARC policy.`	受信拒否（バウンス）
p=reject（DNSの一時的な失敗）	`451 4.7.26 ... temporary DNS failures prevent authentication.`	一時エラー。再送される

550 5.7.26 と 451 4.7.26 は、Googleが公開しているSMTPエラーの一覧に載っています（Gmail の SMTP エラーとコード）。一方、250 ... DMARC:Quarantine はエラーではないためか、2026年11月4日時点でこの一覧には載っていません。

つまり、DMARC:Quarantine は「拒否はしないが、正規のメールとしては扱っていない」という、送信側にとって最も気づきにくい結果です。

バウンスにならないので、配信システムの成功件数にそのまま数えられてしまいます。

「一部の宛先だけ」に出るのはなぜか

質問者がいちばん引っかかっていたのは、同じ送信なのに一部の宛先だけにこの応答が出ることでした。公式されている情報と合わせて整理します。

（１）送信経路によって、DKIMやSPFの合否が違う

同じFromドメインでも、配信システム、社内のメールサーバー、外部のフォームツールなど、複数の経路から送っていることはよくあります。

そのうち1つの経路だけ、DKIM署名がFromのドメインと一致していない、SPFに含まれていない、といった状態だと、その経路から送ったメールだけがDMARCに失敗します。

（２）転送やゲートウェイを通ると、認証が壊れる

Google Workspaceを使っている企業の中には、手前にセキュリティゲートウェイを置いていたり、別のアドレスから転送していたりするところがあります。

中継の途中でSPFが通らなくなったり、本文やヘッダーの書き換えでDKIM署名が壊れたりすると、その宛先だけDMARCに失敗します。B2Bの宛先で偏って出る場合は、まずここを疑います。

（３）pct で一部だけに適用している

差出人ドメインのDMARCレコードに pct=50 のような値が入っていると、失敗したメールの一部だけにquarantineが適用されます。

ただし、2026年5月に発行されたDMARCの新しい仕様（RFC 9989）では pct は削除されました（RFC 9989の解説記事）。

（４）受信側は、公開されたポリシーどおりに動くとは限らない

Googleのトラブルシューティングのページにも「組織は、DMARCに合格したメッセージであっても隔離や拒否を選ぶことができる」とあります（DMARCの問題をトラブルシューティングする）。

Google Workspaceの宛先では、管理者の設定によって、迷惑メールフォルダではなく管理者の隔離に回ることもあるようです。

見落としやすい点：quarantineは「止める」設定ではない

当社の過去の記事でも書いたとおり、quarantineは受信側への「お願い」であり、確実に止める設定ではありません（DMARCをquarantineに設定していても、なりすましメールが受信箱に届く理由）。

今回の応答は、その逆の立場から見た話です。自社の正規のメールが、quarantineの対象として扱われている可能性がある、ということです。

メール配信を管理している皆さまが今やること：チェックリスト

DMARC:Quarantine が出たら、上から順に確認してください。

送信ログから、該当する配信を抜き出す。宛先、送信元IP、時刻、Fromドメインを一覧にする
```
grep "DMARC:Quarantine" /var/log/maillog
```
Fromドメインの DMARC レコードを確認する。p=quarantine か、pct が入っていないか
```
dig +short TXT _dmarc.example.jp
```
自分のGmailアドレスに同じ経路で送り、ヘッダーを見る。Gmailで「メッセージのソースを表示」を開き、Authentication-Results の spf=、dkim=、dmarc= を確認する。DMARCに失敗していれば、dmarc=fail (p=QUARANTINE ...) のように表示される
DMARCの集約レポートで、該当する送信元IPのSPFとDKIMの結果を確認する。どちらがFromドメインと一致していないかがわかる
DKIMの署名ドメイン（d=）をFromドメインにそろえる。ESPの共有ドメインで署名されている経路は、独自ドメインの署名に切り替える
転送やゲートウェイが原因なら、DKIMで合格する状態を優先する。転送でSPFが崩れるのは避けにくいが、DKIMは本文を書き換えなければ残りやすい
配信システムを運用しているなら、DMARC:Quarantine を「成功」とは別に集計する。顧客ドメインごとに件数を出しておくと、設定ミスにすぐ気づける