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