送信メールが550エラーコードで跳ね返されていませんか?受信者から、メッセージが受信トレイではなく迷惑メールフォルダーに入ると言われていませんか?には明確な理由があります。2024年2月、GoogleとYahooはメール認証を任意ではなくし、必須要件としました。メールに依存する企業にとって、この変更を無視すれば到達性が損なわれ、収益にも打撃が及びます。

要点:

• GoogleとYahooは、一括送信者に対しSPFとDKIMによる送信メールの認証と、DMARCレコードの公開を義務付けています。
• 1日5,000通の一括送信者しきい値には、プライマリドメイン全体の合計トラフィックが含まれます。
• Google Postmaster Toolsの迷惑メール報告率は0.1%未満に維持すべきです。0.3%に達すると、受信側ゲートウェイで自動的に到達性へのペナルティが発生します。
• マーケティングメールや購読メールはRFC 8058のワンクリック配信停止ヘッダーに対応する必要があります。
• p=noneでの開始は基本的な準拠を満たしますが、ドメインなりすましを防ぎ長期的なドメイン評価を構築するには、p=quarantineまたはp=rejectへの移行が重要です。

何が変わり、なぜか：Gmail/Yahooの送信者ルール

なぜこのルールが存在するのでしょうか?根本原因はメールの初期設計にあります。Simple Mail Transfer Protocol(SMTP)は1982年にRFC 821で標準化されましたが、送信者の身元を検証する仕組みを備えていませんでした。どのメールサーバーでも任意のメールアドレスからのメールを装って送信でき、受信側ゲートウェイはそれを受け入れていました。つまり、誰でも表示ヘッダーのドメイン名を容易に偽装できたのです。

セキュリティエンジニアは長年にわたり、この構造的欠陥にパッチを当ててきました。2000年代半ばにSPFが登場し、送信IPアドレスを公開DNSリストと照合して検証するようになりました。続いてDKIMが公開鍵暗号方式を用いて登場し、送信者が送信ヘッダーに署名できるようになりました。2012年には大手企業がDMARCを公表し、SPFとDKIMのチェックを連携させ、ドメイン所有者が強制ポリシーを設定できるようにしました。

長年、受信箱プロバイダーはこれらの標準を任意として扱っていました。SPFとDKIMを設定したドメインは加点対象となり、未設定でもIPアドレスがクリーンであれば通常は受信トレイに届きました。

それが2024年2月に終わりを迎えました。Googleのメール送信者ガイドラインに示されているとおり、受信箱プロバイダーは認証を「あれば良い」推奨事項から必須のアクセス要件へと転換したのです。

プロバイダーは未認証メールを一括遮断するのではなく、段階的に執行を導入しました。2024年初めには接続速度の遅延と、未認証ストリームに対する一時的な4xx遅延コードの返却を開始しました。その後の数か月で、厳格な5xx拒否コードと自動的な迷惑メール振り分けへとエスカレートしました。Microsoftも大量送信者向けに同じ標準でゲートウェイフィルターを迅速に整合させ、その後、2025年にOutlook.comでも一括送信者に対し同等のSPF、DKIM、DMARC要件を執行すると発表しました。これは、これらのルールがGoogleとYahooのポリシーにとどまらず、業界全体の基準になりつつあることを示しています。

Gmailガイドラインにおける一括送信者の定義

Googleは一括送信者を、24時間の間に個人Gmailアカウ宛てに約5,000通以上のメールを送信するドメインと定義しており、Yahooも同様の基準を適用しています。しかし、この数字だけに注目するのはよくある誤りです。

第一に、送信量はIPアドレスやサーバーホスト名ごとではなく、ルートドメイン全体で計算されます。マーケティングプラットフォームがニュースレター3,500通を送信し、同じドメインのアプリケーションサーバーがパスワードリセットや請求書の受領通知2,000通を送信していれば、しきい値を超えています。

第二に、このルールはマーケティングメールだけでなく、すべての送信メールに適用されます。システム通知、顧客向け受領メール、日常のビジネスメールもすべて日次上限にカウントされます。1日に3,000通前後を送信するドメインは、すでに上限を超えているものとして完全な認証を設定すべきです。

メール送信者の中核要件

GoogleとYahooの一括送信者要件を満たすには、メールインフラが6つの技術的チェックを通過する必要があります:

1. すべての送信メールストリームに対して有効なSPFレコードとDKIM鍵ペアを設定する。
2. ドメインのDNSに有効なDMARC TXTレコードを公開する。
3. 表示される「From:」ヘッダーのドメインが、SPFまたはDKIMで認証されたドメインと一致することを確認する。
4. Google Postmaster Toolsでのユーザーの迷惑メール報告率を0.1%未満に保ち、0.3%に到達させない。
5. すべてのマーケティングメールとニュースレターにネイティブのワンクリック配信停止ヘッダーを含める。
6. 送信サーバーのIPが一致するA/AAAAレコードと有効な逆引きDNS(PTR)レコードを保有する。

準拠しない場合に起こること

認証チェックに失敗すると、受信側メールサーバーでドメイン評価が損なわれます。通常、次の3段階で進行します:

1. 受信サーバーが4xx遅延コードを返す。メールキューが蓄積し、配信が数時間遅れます。
2. メッセージはゲートウェイを通過しますが、受信トレイではなく迷惑メールフォルダーに振り分けられます。
3. メールサーバーが接続を完全に切断し、5xxハードバウンスエラーを返します。

各要件への対応方法：ステップバイステップ

1. SPFを設定し、10ルックアップ制限に注意する

ドメインルートにDNS TXTレコードを追加し、許可するすべてのIPアドレスとサードパーティメールベンダーを記載します。10回のDNSルックアップ制限に注意してください。SPFのRFCは、外部DNSクエリ(include、a、mx、redirect)を最大10回までに制限しています。超過するとSPF PermErrorが発生し、受信側サーバーは認証失敗として扱います。定期的にレコードを監査し、古いベンダーのincludeを削除して制限内に収めましょう。

2. すべての送信チャネルでDKIM署名を設定する

DKIMは送信メールヘッダーに暗号署名を行うもので、ドメインの代理でメールを送信するすべてのプラットフォームで有効化する必要があります。メールサービスポータルで2048ビットのDKIM鍵ペアを生成し、公開鍵をCNAMEまたはTXTレコードとしてDNSに公開します。DNSが反映されたら、管理コンソールで署名を有効化し、テストメールの生ヘッダーを確認してDKIM-Signatureヘッダーが存在しパスしていることを検証します。

3. DMARCレコードを公開する

GmailとYahooが義務付けるベースラインのDMARC要件を満たすには、_dmarc.yourdomain.comにDMARC TXTレコードを公開します。初回設定では、監視ポリシー(p=none)から始め、メール配信にリスクをかけずにレポートデータを収集すべきです。本番適用前に、公開のDMARCレコードチェッカーでDNSエントリをテストし、構文エラーを確認しましょう。

4. RFC 8058ワンクリック配信停止ヘッダーを追加する

メール末尾の単純なHTML配信停止リンクは、マーケティングメールには不十分です。送信ストリームに2つの生メールヘッダーを挿入する必要があります:

List-Unsubscribe:
List-Unsubscribe-Post: List-Unsubscribe=One-Click

GmailやYahooなどのクライアントがこれらのヘッダーを解析すると、受信箱UIの送信者名の横に目立つ「配信停止」ボタンが表示されます。クリックするとサーバーに自動化されたPOSTリクエストが送られ、ブラウザウィンドウを開かずに即座に購読者が解除されます。

5. 正引きおよび逆引きDNSを検証する

受信サーバーは、送信IPアドレスがDNSのドメインと一致するかを確認します。IPはPTRレコードによって有効なホスト名に解決される必要があり、そのホスト名が標準のDNS Aレコードで同じIPに逆解決される必要があります。専用メールサーバーやクラウドインスタンスの運用者は、プロバイダーのコンソールで逆引きDNS設定を編集するか、サポートチケットでIPをメールサーバーの完全修飾ドメイン名(FQDN)にマッピングしてもらえます。

6. Postmaster ToolsとDMARCレポートで指標を追跡する

Google Postmaster Toolsのアカウントを設定し、DNS TXTレコードでドメイン所有権を確認します。このダッシュボードでは、ドメイン評価、迷惑メール報告率、認証成功率を直接把握できます。報告率を0.1%未満に保ちましょう。0.3%に達すると、SPFとDKIMの状態にかかわらずGoogleはメールを迷惑メールフォルダーに振り分けます。すべての受信プロバイダーにわたる認証失敗を監視し不正な送信IPを検出するには、自動化されたDMARCレポートを設定してください。

準拠を超えて：ルールを活用した到達性の向上

p=noneポリシーのみでは、ドメインはなりすましから保護されません。p=noneポリシーは受信サーバーに認証データを記録させますが、攻撃者がフィッシング攻撃でドメインを偽装するのを防ぐことはできません。

正当なメールストリームがすべてSPFとDKIMのアライメントを通過することを確認したら、DMARCポリシーをp=quarantineまたはp=rejectに強化します。p=quarantineは未認証メールを迷惑メールに直接振り分け、p=rejectは受信ゲートウェイで偽のメッセージを破棄します。

DMARCの強制運用に到達した後は、Brand Indicators for Message Identification(BIMI)を公開できます。BIMIは受信箱内のメッセージの横に検証済みブランドロゴを表示し、ブランドの視認性と信頼を高めます。

一括送信者要件に関するよくある質問

GoogleとYahooにおける一括送信者のしきい値とは?

GoogleとYahooは、1日約5,000通以上を個人アカウント宛てに送信するドメインを一括送信者と定義しています。送信量は、すべての送信サービスを合算してプライマリドメイン全体で計算されます。

これらのルールはトランザクションメールにも適用されますか?

はい。パスワードリセット、注文更新、システムアラートなどのトランザクションメールもSPF、DKIM、DMARC、DNSのチェックを通過する必要があります。ただし、トランザクションメールにはワンクリック配信停止ヘッダーは不要です。

p=noneのDMARCポリシーで準拠できますか?

はい。p=noneはGoogleとYahooのベースライン要件を満たします。ただし、なりすましをブロックせずトラフィックを監視するだけなので、p=quarantineまたはp=rejectへの移行が推奨されます。

要件を満たさない場合、メールはどうなりますか?

メールプロバイダーは4xxエラーコードでSMTP接続を絞り、メールを迷惑メールフォルダーに直接振り分け、または5xxハードバウンスでメールを完全に拒否します。

迷惑メール報告率が高かった場合、回復にはどれくらいかかりますか?

リストの衛生を改善し報告率が0.1%未満に戻れば、クリーンな送信を7〜14日続けることで、Google Postmaster Toolsがドメイン評価を再構築するのが一般的です。

SPFレコードが10ルックアップ制限を超えているかを確認するには?

SPF TXTレコードを調べ、DNSルックアップをトリガーするすべてのメカニズムを数えます。メインレコードとネストされたレコード全体でのDNSクエリ合計が10を超えると、SPFレコードはPermErrorで失敗します。

出典:FinTechZoom