海外向けにメールを一斉配信するとき、最初に決まるのは配信ツールではありません。受信側が公表している条件です。Google、Microsoft、Yahooはいずれも、送信ドメインの認証、迷惑メール率、配信停止の扱いについて要件を公開しています。SPFやDKIMは「届きやすくするための工夫」ではなく、受け取ってもらうための条件として書かれていて、満たさない送信は迷惑メール扱いか、受け取り拒否の対象になります。
3社の要件はよく似ています。似ているせいで取り違えやすいのが、しきい値の数え方と、満たさなかったときに返ってくるものの違いです。1日5,000通という同じ数字を、Googleは宛先がGmailのアカウントである通数で数え、Microsoftは同じ5322.Fromのドメインから個人向けサービスへ送った通数で数えます。Yahooは、参照したページに数値の基準がありません。
この記事は、各社が公開しているページの記載だけを使って、要件の差、通数の数え方、満たさなかったときの挙動、配信ツール側で必要になる作業を順に整理します。確認日は2026年10月21日です。扱うのは受信側の技術要件だけで、受信同意の取得や配信そのものの設計はメールマーケティングの全体像の側に置いています。
要件そのものは、3社でほとんど同じ
同じ6項目で並べると、違いは文言の細かさに集まります。SPFとDKIMについては、全送信者には「どちらか」、大量送信者には「両方」を求める形がGoogleとYahooで共通です。MicrosoftのNDRエラーの説明ページは全送信者と大量送信者を分けず、しきい値を超える送信者について、SPFとDKIMの両方がpassすること、DMARCレコードを公表すること、DMARCの検証に合格することを並べています。
DMARCのポリシーについては、Googleが「p=noneに設定してもよい」と明記し、Yahooは「少なくともp=none」と書いています。3社とも、最初からrejectまで上げることは求めていません。求めているのはポリシーの強さではなく、Fromのドメインと認証の整合です。GoogleはFrom:ヘッダーのドメインがSPFのドメインまたはDKIMのドメインと整合することを条件に挙げ、Microsoftは5322.Fromのドメインに対してSPFとDKIMの少なくとも一方が整合することを求めています。ここを外すと、SPFとDKIMを設定していてもDMARCは通りません。
Googleの要件は、1つのヘルプページに全送信者向けと大量送信者向けが並んで書かれています。社内で合意を取るときは、このページを見せたうえで「どちらの節に自社が該当するか」から話を始めたほうが早く進みます。認証を入れる作業はDNSの変更を伴うため、判断する人と作業する人が別になりがちです。
「1日5,000通」は、総数ではなく受信側ごとに数える
いちばん事故が起きやすいのがここです。Googleのページは「2024年2月1日から、Gmailのアカウントへ1日5,000通を超えるメールを送る送信者は、この節の要件を満たさなければならない」と書いています。数えるのはGmailのアカウント宛の通数で、配信全体の通数ではありません。
Microsoftの条件は単位が違います。NDRエラーの説明ページは、5322.Fromアドレスに同じドメインを使って、Microsoftの個人向けメールサービスへ5,000通以上を送る送信者について書いています。対象はOutlook.com、Hotmail、Live.com、MSNなどの個人向けサービスです。送信ドメイン単位で、その受信側だけを数える形になります。
Yahooは、参照したBest Practicesのページで「All Senders」と「Bulk Senders」を分けていますが、どこからがBulk Sendersなのかという数値を示していません。通数で判定できないため、海外向けに一斉配信をするなら、最初からBulk Sendersの要件を満たしておくほうが扱いが簡単です。
この図のように、合計では1万通でも、受信側ごとに分けると各社のしきい値には届かないことがあります。ただし、しきい値を下回っていても全送信者向けの要件は外れません。SPFまたはDKIM、正引きと逆引きのDNS、TLS、迷惑メール率は、通数に関係なく求められている条件です。「5,000通までは何もしなくてよい」という読み方は、どのページにも書かれていません。
満たさなかったときに返ってくるものは、同じではない
要件が似ている一方で、違反したときに観測される結果は各社で違います。Googleは認証について「これらの方法で認証されていないメッセージは、迷惑メール扱いになるか、5.7.26エラーで拒否されることがある」と書いています。Microsoftは認証の水準を満たさない送信ドメインに対して、拒否の応答そのものを公開しています。
| 受信側 | 公表されている結果 | 記載されている文言 |
|---|---|---|
| Google（Gmail） | 想定どおり配信されない、または迷惑メール扱い | 認証されていないメッセージは迷惑メール扱いか「5.7.26」エラーで拒否されることがある |
| Microsoft（個人向け） | 送信を拒否し、NDRを返す | 「550 5.7.515 Access denied, sending domain does not meet the required authentication level」 |
| Yahoo | 参照したページでは確認できず | 2024年2月から送信基準の適用が始まり、2024年前半にかけて段階的に展開すると記載 |
実務上の意味は、気づけるかどうかの差です。Microsoftの拒否はNDRとして送信側に返るため、配信ツールのレポートにエラーとして残ります。迷惑メールフォルダへ入る場合は、送信側のレポートでは「配信済み」として数えられます。開封率が落ちているのに配信エラーが増えていないときは、認証とドメインの整合を先に疑うほうが近道です。開封率を上げる前に、件名ではなく配送経路の側に原因があるかもしれません。
迷惑メール率は、送信側の集計では測れない
Googleは全送信者向けに「Postmaster Toolsで報告される迷惑メール率を0.3%未満に保つ」ことを挙げ、大量送信者向けには0.30%未満と書いています。さらに「0.10%未満に保ち、0.30%以上に達しないようにする」という水準も示しています。この数値はGoogle側のツールが報告する値で、配信ツールの画面に出る苦情率とは別の集計です。Yahooは全送信者と大量送信者の双方に0.3%未満を示しています。
0.10%は1万通に10通、0.30%は1万通に30通にあたります。配信のたびに数通の報告が出る規模であれば、一度の失敗で水準を超えます。測定の経路が受信側にしかないため、海外向けの配信を始めるなら、送信ドメインをPostmaster Toolsへ登録して値を見られる状態にしておくほうが安全です。登録していなければ、0.3%を超えたかどうかを自社で知る手段がありません。
全送信者に共通する条件は、認証だけではない
通数のしきい値とは別に、すべての送信者へ求められている条件があります。認証の話に目が行きがちですが、落ちるときはDNSや接続の側で落ちます。
| 条件 | Google（Gmail）の記載 | Yahooの記載 |
|---|---|---|
| 認証 | 送信ドメインにSPFまたはDKIMを設定する | 最低限SPFまたはDKIMを実装する |
| 正引き・逆引き | 有効な正引きと逆引き（PTR）が必要。送信IPはPTRのホスト名のIPと一致すること | 有効な正引きと逆引きが必要 |
| 接続 | 送信にTLS接続を使う | 参照したページでは確認できず |
| 形式 | RFC 5322（Internet Message Format）に従う | RFC 5321とRFC 5322に従う |
| 迷惑メール率 | Postmaster Toolsの報告値で0.3%未満 | 0.3%未満 |
| なりすまし | GmailのFrom:ヘッダーを装わない | 参照したページでは確認できず |
Googleはこれに加えて、運用の形についても書いています。「可能であれば、すべてのメッセージを同じIPアドレスから送る。複数のIPアドレスから送る必要がある場合は、メッセージの種類ごとに別のIPアドレスを使う」。そして「同じ種類のメッセージは、同じFrom:アドレスを使うべき」。お知らせと取引メールを同じ経路に混ぜると、片方の評価がもう片方に影響する前提になっている、ということです。
配信ツール側の作業は、ドメインの認証
受信側の条件は、配信ツールを契約しただけでは満たせません。Mailchimpのヘルプは、ドメインの検証と認証を別のものとして説明しています。検証は「そのアドレスにアクセスできることの確認」で、「検証だけでは配信に影響しない」と書かれています。配信のために必要なのは認証の側で、同社のヘルプは「DKIM用のCNAMEレコード2件とDMARC用のTXTレコード1件をDNSに追加する」と具体的な件数を示しています。
同じページには、GmailとYahooが「1日24時間のうちにGmailまたはYahooのアドレスへ5,000通を超えて送る送信者」に対して、独自の認証と公表されたDMARCレコードを求めることが書かれています。また、From:アドレスにGmailやYahooのような無料のメールサービスを使っている場合は、仕事やWebサイトで使っている独自ドメインのアドレスへ切り替えることを強く推奨しています。無料ドメインのままでは、認証を自社で整える余地がないためです。
ここで決めることは、配信ツールの選定とは別の作業です。ツールを替えてもDNSの設定は残り、ドメインを替えれば認証をやり直すことになります。メルマガ配信ツールの選び方を検討する段階で、どのドメインから送るのかを先に決めておくと、あとの作業が減ります。料金の数え方は海外ツールで癖が出るところで、連絡先の状態で請求が変わるMailchimpの請求の数え方も、契約前に見ておく価値があります。
ワンクリック解除は、ヘッダーの形まで決まっている
配信停止の要件は、文面の工夫ではなく技術仕様です。Googleは大量送信者に対し、マーケティングメールと購読メールがワンクリックでの解除に対応し、本文に分かりやすい解除リンクを含むことを求めています。実装については、送信するメッセージに次の2つのヘッダーを入れるよう書かれています。List-Unsubscribe-Post: List-Unsubscribe=One-Click と、HTTPSのURIを持つ List-Unsubscribe です。参照先としてRFC 2369とRFC 8058が挙げられています。
RFC 8058は、この仕組みを定めた標準です。文書は「List-Unsubscribeヘッダーフィールドにワンクリック機能を知らせる方法」を記述するとし、送信側はメッセージに List-Unsubscribe と List-Unsubscribe-Post を1つずつ置き、前者はHTTPSのURIを1つ含まなければならないとしています。目的は、受信側が追加のやり取りなしに背景で解除要求を処理し、それが送信側で完全に処理されると分かる状態を作ることです。解除ページで「本当に解除しますか」と確認を挟む作りは、この仕組みが想定しているものではありません。
処理の速さについては、Yahooが「2日以内に解除を反映する」と書いています。RFC 8058には処理期限の規定がありません。解除の反映が手作業や日次のバッチに依存している運用では、ここが満たせなくなります。解除要求の受け口を作るだけでなく、反映までの時間を測っておく必要があります。
この記事で確認できなかったこと
Microsoftの要件については、同社のTech Communityにある高頻度送信者向けの発表記事を自動取得できませんでした。そのため、適用の開始日、迷惑メールフォルダへの振り分けから拒否へ移る段取り、迷惑メール率や配信停止についての記載は、この記事では扱っていません。使ったのはNDRエラー「550 5.7.515」の説明ページだけです。
Yahooについては、Bulk Sendersの数値の定義を参照したページで確認できませんでした。GoogleのPostmaster Toolsに登録していない場合に迷惑メール率をどう把握するか、しきい値を一度超えた送信者がその後どう扱われるかも、参照した各ページに記載がありません。日本国内の受信事業者が独自に公表している条件、特定電子メール法に基づく同意取得と表示の義務も、この記事の範囲外です。
当サイトは、ここで挙げた受信側のサービスへ実際に大量配信して検証したわけではありません。書いたのは、各社が公開しているページとRFCに載っている範囲だけです。設定の作業そのものはDNSの変更を伴うため、実施の前に自社のドメイン管理者と確認してください。海外のツールを使うときに国内の制度と噛み合う論点は、海外ツールの利用料と消費税でも扱っています。ほかの記事は海外マーケティングに並べています。
この分野の実務を相談したい方へ
記事で扱っている内容は、当社が実務として支援している領域です。 自社で進めるか外部に任せるかの判断からご相談いただけます。
あわせて読みたい
Mailchimpの請求は連絡先の状態で決まる｜停止済みも数える Mailchimpの請求額を決めるのは名簿の総数ではなく、連絡先の状態です。購読済み・配信停止済み・未購読の3つが数えられ、アーカイブ済みは外れます。送信上限の倍率と、上限を超えたときの扱いまで公式ヘルプの記載で整理します。
メールマーケティングとは？見込み客・既存顧客を育成する方法 メールマーケティングの仕組みを、同意取得、配信設計、セグメント、コンテンツ、認証、計測、改善、配信停止まで実務順に解説します。
メルマガ配信ツールおすすめ比較｜中小企業向けサービスを目的別に紹介 メルマガ配信ツールを、同意管理、認証、作成、予約、自動化、分析、権限、料金、データ移行の公式情報から比較する方法を解説します。