メールが拒否される理由や、迷惑メールに振り分けられる理由を探るために、認証、プロバイダーの応答、オーディエンスの質、配信停止の動作を確認します。
配信の成功と、受信トレイへの到達は別物です。受信サーバーはメッセージを受け付けたうえで、迷惑メールフォルダーに入れることがあります。キャンペーンのダッシュボードに「到達」と表示されていても、読み手がそのメールを目にしたことの証明にはなりません。
問題が起きたら、コピーを変えたりプロバイダーを乗り換えたりする前に、まず証拠を集めましょう。原因は、認証、レピュテーション、オーディエンス、あるいはメッセージそのものかもしれません。
拒否されたメッセージや配信が遅延したメッセージについては、実際のSMTP応答と拡張ステータスコードを確認します。一時的なエラーと恒久的な拒否では、対処の仕方が異なります。Google の送信者向けのよくある質問は両方について説明していますが、要件を満たさないメールがいまやすべて恒久的なエラーになる、とは書いていません。
メッセージが受け付けられているのに迷惑メールフォルダーに入る場合は、受信したメールのヘッダーにある認証結果、入手できればプロバイダーのレピュテーションデータ、そしてオーディエンスや送信量の最近の変化を確認します。いくつかのシード受信トレイは問題の診断に役立ちますが、リスト全体で受信トレイに届いているかを測れるわけではありません。
拡張ステータスコードは、RFC 3463 で定められた、ドットで区切られた3つの数字です。最初の数字はクラスを表します。4で始まるコードは一時的なエラーで、送信サーバーは後で再試行すべきです。5で始まるコードは恒久的なエラーなので、同じメッセージをそのまま再送しても解決しません。
2番目の数字は、問題の分野を絞り込みます。X.1.X のコードはアドレスに関するもので、5.1.1 は通常、メールボックスが存在しないことを意味します。そのアドレスは配信除外にしましょう。X.7.X のコードはセキュリティやポリシーに関するもので、認証やレピュテーションの問題はここに現れることが多くなります。
Gmail が返す応答の一覧は、Google のSMTPエラーのリファレンスに掲載されています。1つのコードが複数の異なる理由を表すことがあるので、コードだけでなく応答の全文を読みましょう。
Google Postmaster Tools では、Gmail があなたの送信ドメインをどう見ているかを確認できます。Google の要件で言及されている、ユーザーから報告された迷惑メール率もここで見られます。ドメインの所有権は、DNSレコードで確認します。Gmail がデータを表示するのは、そのドメインから Gmail ユーザー宛てに毎日十分な量のメールが送られるようになってからなので、小規模な送信者ではダッシュボードが空のままのこともあります。
Microsoft の Smart Network Data Services（SNDS）は、特定のIPアドレスから Outlook.com の個人向けメールボックスに届いたメールについて、迷惑メール報告率やスパムトラップへのヒットなどをレポートします。登録できるのは自分が管理しているIPアドレスなので、最も役立つのは専用の送信IPを使っている場合です。共有IPの場合は、送信プロバイダーに何を監視しているかを尋ねましょう。
どちらのツールも、個々のキャンペーンがどこに届いたかは教えてくれません。わかるのは日ごとの傾向です。問題が何回かの配信を通じて積み重なってきた場合には、まさにそれが必要になります。
SPFは、エンベロープのドメインについて送信インフラを許可します。DKIMは、ドメインの身元でメッセージに署名します。DMARCは、表示される From ドメインとのアライメントを確認し、ポリシーとレポートの仕組みを公開します。どれも、受信トレイへの到達を保証するものではありません。
送信プロバイダーから提供されたレコードを使い、実際に受信したメールで結果を確かめましょう。競合するSPFレコードを追加したり、DNSレコードがあるからといって、すべての送信経路がそれを正しく使っていると思い込んだりしないでください。インフラには、適切な逆引きDNSと安全な通信経路も必要です。
Brew では、ドメイン認証の手順に従って、求められたレコードを公開します。実際のキャンペーンやオートメーションで使われる差出人アドレスも確認しましょう。エージェントが複数のブランドを運用している場合は、特に重要です。
DMARCポリシーは、差出人アドレスのドメインの _dmarc ホストに置くTXTレコードです。まずは p=none から始めます。これは、認証に失敗したメールに対して特別な処理をしないよう受信側に求めるもので、受信側は引き続き rua のアドレスに集約レポートを送ります。
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"レポートには、あなたのドメインを名乗ってメールを送っているすべての送信元と、それぞれがアライメントの取れたSPFかDKIMに合格したかどうかが載っています。請求システムやヘルプデスクなど、忘れていたツールが見つかるはずです。失敗している送信元は、ひとつずつ修正するか削除しましょう。
正規のメールがすべて合格するようになったら、p=quarantine に移行します。これは、認証に失敗したメールを疑わしいものとして扱うよう受信側に求めるもので、通常は迷惑メールフォルダーに振り分けられます。
_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"最も厳しいポリシーである p=reject は、認証に失敗したメールの受け取りを拒否するよう受信側に求めます。移行するのは、quarantine でしばらく運用し、正規のメールが失敗しないことを確かめてからにしましょう。どの段階でも、レポートを読み続けてください。あなたのドメインで送信を始めた新しいツールは、まずそこに現れます。
例外は、mail.example.com のような送信専用のサブドメインです。ほかに何も送信しておらず、プロバイダーがSPFとDKIMを認証済みなら、最初から p=reject にできます。Brew は、自身が設定した専用のサブドメインには p=reject を、ほかのサービスも送信している可能性があるメインのドメインには p=none を推奨しています。
Google のメール送信者のガイドラインは、すべての送信者に求める要件と、個人の Gmail アカウント宛てに1日あたり約5,000通に達する送信者向けの、より厳しいルールを区別しています。Google は、迷惑メール率を0.1%未満に保ち、0.3%に達しないよう求めています。一括送信者向けの要件には、SPFとDKIM、DMARC、アライメント、そして対象となる購読メールでのワンクリック配信停止が含まれます。
送信量にかかわらず、すべての送信者に対する Google の要件には、次のものがあります。
一括送信者は、さらに次のことも行う必要があります。
p=none のポリシーも認めています。Google は、しきい値を適用する際、同じプライマリドメインからのメールをまとめて数えます。一度しきい値を超えたドメインは、その後も一括送信者として扱われます。数え方については、送信者向けのよくある質問で説明されています。
Yahoo のガイダンスも、認証、迷惑メール報告、配信停止を扱っています。Yahoo は一括送信者について同様の数値のしきい値を公表していないため、Gmail の数値をすべてのプロバイダーに当てはめるのではなく、Yahoo のよくある質問を確認してください。
Microsoft は2025年の発表で、個人向けのメールボックス（outlook.com、hotmail.com、live.com のアドレス）に1日5,000通を超えるメールを送るドメインに対し、SPFとDKIMへの合格とDMARCの公開を義務付けました。DMARCのポリシーは p=none でもかまいませんが、From ドメインがSPFかDKIMのどちらかとアライメントしている必要があります。
プロバイダーのガイダンスの確認日：2026年9月28日。新たな問題を診断するときは、リンク先のページを確認してください。
RFC 8058 に基づくワンクリック配信停止は、ヘッダーとHTTPSのPOSTによる仕組みです。フッターに見えるリンクを置くことも役に立ち、関連するルールでも求められていますが、配信設定ページだけでは、このプロトコルを実装したことにはなりません。
ワンクリック配信停止に対応したメッセージには、2つのヘッダーが含まれます。
List-Unsubscribe: <https://example.com/unsubscribe/opaque-token>, <mailto:unsubscribe@example.com?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-Click読み手が受信トレイで配信停止をクリックすると、メールボックスプロバイダーは、本文に List-Unsubscribe=One-Click を入れたPOSTリクエストを、そのHTTPSのURLに送ります。mailto: のアドレスは、ワンクリックに対応していないメールソフト向けの代替手段です。RFC 8058 は、両方のヘッダーを署名の対象に含む有効なDKIM署名も求めています。URLは受信者ごとに固有で、推測しにくいものにしましょう。セキュリティスキャナーは受信メール内のリンクにアクセスすることが多いため、そのURLへの単純なGETリクエストで誰かを配信停止にしてはいけません。
Brew は、マーケティング配信に List-Unsubscribe と List-Unsubscribe-Post ヘッダーを追加します。リンク先は、ワンクリックのPOSTを受け付ける、署名付きで受信者ごとに固有のHTTPSのURLです。
マーケティングメールの配信停止が、利用しているすべての経路で、その後のマーケティング配信を止めることを確認しましょう。コンタクトをインポートするときや、プラットフォームを移行するときも、配信除外の情報を引き継ぎます。必要不可欠なトランザクションメッセージは、目的も送信設定も分けておきましょう。
アドレスをどこから入手したのか、登録時に人々が何を期待していたのかを見直しましょう。無効なアドレスはプロバイダーの配信除外の仕組みで取り除き、迷惑メール報告が急増したら原因を調べます。トラッキング上で開封されていないというだけの理由で、同じ人に再送するのはやめましょう。
これさえ守れば必ず届く、というリストの鮮度も、画像とテキストの比率も、禁止ワードも存在しません。よく把握できていないリストに急に送信量を増やすほうが、「無料」という言葉を使うよりはるかに深刻な問題です。
エージェントがキャンペーンを送信する場合も、同じチェックが当てはまります。確認済みの事実、関連性の高いオーディエンス、誰かが目を通している返信先アドレスを使いましょう。特定した原因を修正し、規模を絞ったテスト送信を行い、プロバイダーの応答を確認してから、再び配信を広げてください。
