キャンペーンを9 AMに送信し、正午の時点で開封率は1.8%でした。内容や件名も影響しますが、メールが受信トレイへ届かなかった可能性があります。誰かが読む前にバウンス、拒否、迷惑メールへの振り分けが起きていました。
メール送信者のレピュテーションはこの結果に関係しますが、単独で決めるものではありません。受信事業者は内容、認証、送信行動を複数のシグナルで評価します。ここで扱う四つは実務的な枠組みであり、共通の評価式でも、結果を確実に制御する方法でもありません。
メール送信者レピュテーションとは
メール送信者レピュテーションとは、Gmail、Yahoo、Microsoftなどが送信ドメインとIPへ関連付ける評価です。あらゆる事業者を横断してダッシュボードで確認できる単一の数値ではなく、継続的に変わる複数のシグナルです。迷惑メールの苦情率、認証のアラインメント、送信量の履歴、インフラの健全性は四つの測定領域です。事業者のしきい値を外れると、フィルタリングや拒否が増える可能性がありますが、影響は一律ではありません。
2024年二月以降、GoogleとYahooは各社の定義に該当する送信者やメールに、より厳しい要件を適用しています。認証エラーが恒久的な5xx拒否につながることはありますが、すべての失敗が迷惑メールへの配置ではなく拒否を起こすわけではありません。完全な応答と該当ポリシーを確認してください。
シグナル1: 苦情率と0.3%の境界
迷惑メールの苦情率は、送信者評価における重要なシグナルです。受信者が"迷惑メールを報告"を選ぶと、積み上げた肯定的なシグナルより強く作用する場合があります。不適切なリスト区分が何か月もの良好な受信トレイ配置を損なうこともありますが、送信量、宛先、その他の要因も結果に影響します。
GoogleとYahooが公表している水準には次が含まれます。
- 目標: 0.1%未満
- 危険領域: 0.1%-0.3%
- ポリシー違反: 0.3%以上
0.3%では一部の緩和措置を利用できなくなり、5xxエラーが生じる可能性があります。ただし、猶予や警告なしに必ず拒否されるわけではありません。事業者の最新ポリシーと実際の送信データを確認してください。
Yahooの受信トレイ分母
Yahooは、送信総数ではなく受信トレイへ届いたメールを基準に苦情率を計算または表示する場合があります。方法、対象範囲、分母は現在の資料で確認してください。すべての事業者に共通する式ではありません。
1,000通を送信し、900通はすでにフィルタリングされて迷惑メールへ、100通は受信トレイへ入ります。一人が苦情を送信します。この例でYahooは1/100 = 1.0%と計算し、0.1%とはなりません。
受信トレイへ届くメールが減ると分母が小さくなり、計算上の苦情率がさらに上がる可能性があります。Yahooは2025年後半にSender Hubの"Insights"ダッシュボードを発表しました。毎週の確認に使う前に、提供状況、定義、画面を確認してください。
ワンクリックでの配信停止による保護
配信停止リンクが見つけにくいと、ユーザーは代わりに迷惑メールとして報告する場合があります。大量送信者向け規則が適用される購読型のプロモーションメールについて、RFC 8058は次のヘッダーを定めています。
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://yourdomain.com/unsubscribe?id=...>GoogleとYahooは、対象となる大量送信者のプロモーションメールにワンクリックでの配信停止を求めています。Googleの一日5,000通という基準は個人用Gmailアカウント宛てであり、すべての事業者やメール種別に自動適用されるわけではありません。
シグナル2: 認証のアラインメント（SPF、DKIM、DMARC）
認証のアラインメントも送信者評価の要素です。SPF、DKIM、DMARCは実際の送信経路に合わせて構成しますが、すべてが同じドメインを使う必要はありません。整合したSPFまたはDKIMの少なくとも一方が成功すればDMARCは合格します。レコードが存在するだけではアラインメントも配信も保証されません。
DNSレコードを一から用意する場合は、独自ドメインメール設定の完全ガイドで各レコードを確認できます。最低限の認証基盤については、ビジネスメールのセキュリティ設定を参照してください。
SPF: 10回のルックアップ上限
一回の評価中にDNS検索を発生させる仕組みが10回の上限を超えると、SPFは失敗する可能性があります。正規のサービスでもincludeを重ねすぎるとPermErrorになります。主レコードに見えるinclude数だけでなく、検索を起こす仕組みと入れ子を含む全体を数えてください。
# Check your SPF record and count includes
dig txt yourdomain.com +short一つのレコードにinclude:sendgrid.net include:zendesk.com include:mailchimp.com include:salesforce.comがあれば、入れ子も含めて実際の検索数を計算します。上限に近い可能性はありますが、目に見えるincludeの数だけでは判断できません。
DKIM: 鍵長と方式を確認する
GoogleはDKIM鍵の要件と推奨事項を公表しています。RSAを使う特定の状況では1024-bitが最低要件となり、2048-bitが推奨される場合があります。512-bitのRSA鍵は現代の用途に適しません。対応する方式と事業者の最新要件も確認してください。
# Verify your DKIM key (replace 'selector' with your actual selector)
dig txt selector._domainkey.yourdomain.com +shortDMARC: 存在だけでなくアラインメント
表示される"From"ヘッダーのドメインは、SPFで使うReturn-Pathドメインまたは検証に成功したDKIMのd=ドメインと整合する必要があります。p=noneのDMARCレコードでも公開要件を満たしレポートを収集できますが、失敗メールの隔離や拒否を受信側へ要求しません。
# Check your DMARC policy
dig txt _dmarc.yourdomain.com +shortp=quarantineを共通の最低値とする規則も、p=rejectだけを"最高基準"とする考え方もありません。Microsoftの550 5.7.515は、とくに大量送信で認証またはポリシーに関連する場合があります。完全な応答を読み、SPFだけの問題や迷惑メールへの振り分けと決めつけないでください。
シグナル3: 送信量の履歴
送信量の履歴は、Googleの大量送信者区分を通じて評価へ影響する可能性があります。ブラックフライデーの一度のキャンペーンでもしきい値を超えると、厳しい要件が継続して適用されることがあります。この扱いはGoogleのポリシーであり、すべての事業者に同じ規則がある証拠ではありません。
基準は、個人用Gmailアカウント（@gmail.com、@googlemail.com）へ一日およそ5,000通です。
大量送信者に分類されると、次の要件が適用される場合があります。
- 対象となるプロモーションメールでのワンクリック配信停止
- 最新ポリシーに基づく、より厳しいDMARC要件
- 認証エラーによる影響の増大
送信量が一日50通へ戻っても、分類が解除されるとは限りません。新しいドメインから急に大量送信せず、同意、運用能力、事業者の応答を見ながら段階的に増やします。
シグナル4: インフラの健全性
インフラは、問題が起こるまで見過ごされやすい評価要素です。新しい送信IPの段階的な増加と、送信IPのFCrDNSは有用な確認項目です。内容、受信者、ポリシーも引き続き重要です。
IPのウォームアップ
自分にとって新しいIPでも、公開上の履歴が少ない場合と過去の履歴がある場合があります。Microsoftは新しい送信IPを制限することがあります。急に5,000通を送ると、ログに次の応答が現れる可能性があります。
421 RP-001 Client host rejected - reputationこれは送信サーバーへ後で再試行するよう求める一時的な応答です。シグナルを無視して再試行し続けると制限が悪化する場合はありますが、必ず恒久ブロックへ変わるわけではありません。一日50-100通から始め、2-4週間かけて増やす方法は調整が必要な一例であり、成功を保証しません。
FCrDNS（正引き確認済み逆引きDNS）
送信IPには送信ホスト名を返すPTRレコードがあり、そのホスト名が同じIPへ正引きされる構成が望まれます。フィルターはFCrDNSを一つのシグナルとして確認することがあります。欠如するとリスクが増しますが、大半のゲートウェイですぐにブロックされるとは限りません。
# Check PTR record for your sending IP
dig -x <your-sending-ip> +short結果は、同じIPへ正引きできるホスト名であるべきです。一致しない場合は、権限のある担当者が修正し、他の項目とともにDNSの反映を確認してください。
送信者レピュテーションを診断するDNS監査
監視ツールを確認する前に、権限のある資産に対する読み取り専用の問い合わせでDNSを調べます。四つのコマンドは、外部から見えるSPF、DMARCポリシー、DKIMレコード、逆引きDNSを示しますが、評価のすべてを説明せず、配信も保証しません。
# 1. SPF - count includes, verify -all or ~all terminator
dig txt yourdomain.com +short
# 2. DMARC - check policy level (p=none/quarantine/reject)
dig txt _dmarc.yourdomain.com +short
# 3. DKIM - verify key exists and bit length
dig txt selector._domainkey.yourdomain.com +short
# 4. FCrDNS - PTR must resolve to a hostname
dig -x <your-sending-ip> +short設定を変更する前に結果を状況と併せて評価し、修正後は必ず検証してください。
送信者レピュテーションを毎週監視する
ブロックを待たず、三つの情報源で週次の基準を確認できます。Google Postmaster Toolsは利用可能な迷惑メール率や遵守状況、Microsoft SNDSは一部のIPシグナル、Spamhausは関連する掲載情報を提供します。アクセス条件、対象範囲、画面は変わる可能性があります。
| ツール | 確認できる情報 | 運用上の目標 |
|---|---|---|
| Google Postmaster Tools | 迷惑メール率、遵守状況、利用可能な認証結果 | 迷惑メール率 < 0.1% |
| Microsoft SNDS | IPの状態（Green/Yellow/Red）、スパムトラップの可能性 | 良好な状態で既知のトラップ接触がないこと。ただし配信は保証されない |
| Spamhaus Lookup | SBL/ZENリストへの掲載状況 | 確認対象となるリストに掲載されていないこと |
Google Postmaster Toolsの変更: Googleは2025年九月にDomain ReputationとIP Reputationのダッシュボードを廃止しました。現在の画面ではCompliance Statusや迷惑メール率が重視される場合があります。"No Data"は、Gmail宛ての日次送信量が~200通未満、対象データの不足、その他の理由でも生じ得ます。何も届いていない証拠ではありません。
ブロックリストの影響はすべて同じではありません。
- レベル1（深刻な影響の可能性）: Spamhaus SBL/ZENは多くの受信者に大きく影響することがありますが、業界全体でほぼ100%拒否されるとは限りません
- レベル2（一部環境で問題）: SpamCop、Barracudaは一部の受信者に影響する可能性があります
- レベル3（評価が必要なシグナル）: UCEPROTECT Level 3はネットブロック全体を掲載します。無視または対応する前に、実際の受信者が利用しているか確認します
Spamhausへの掲載が見つかった場合は、対象のIPまたはドメインであることを確認し、原因を修正して公式手順に従ってから送信を再開します。
48時間のレピュテーション低下に対する手順
開封率が急落し、バウンスログに5xxエラーが表示されています。開封データだけでは信頼できませんが、拒否と併せれば調査すべき状況です。以下の五段階は調整可能な運用枠組みであり、所定時間内の回復を保証するものではありません。
- 問題のあるマーケティング送信を停止します。 パスワードリセット、請求書、領収書など、必要かつ期待されるトランザクションメールだけを継続します。エンゲージメントを人為的に作るために送信しないでください。
- 変数を切り分けます。 SPFへ新しい
include:を追加した、ESPを切り替えたなど、直近の変更は有用な仮説ですが、自動的に原因とはなりません。時刻、ログ、構成を比較します。 - DMARC集約レポートを確認します。 不明な送信元が見つかることはありますが、レポートは不完全で、それだけでは不正利用を証明しません。シャドーIT、代理店、承認済み送信者を確認します。
- リストを分割して見直します。 直近に送った区分を特定します。90日間開封しなかった人を全員削除せず、エンゲージメントを人為的に水増ししないでください。同意、信頼できる活動、苦情、確認済みの無効性を使います。
- ブロックリストを確認します。 SpamhausとMX ToolboxでIPとドメインを調べます。実際に掲載されていれば、送信量を増やす前に原因を修正し、正規の解除手順に従います。
共有ホスティングがレピュテーションを損なう可能性
cPanel、GoDaddy、一般的な共有ホスティングでは、数百の送信者と送信IPを共有する場合があります。他の利用者による不正なキャンペーンが共有評価を損なうことがあります。すべてのプールで必ず起こるわけではなく、事業者への連絡、リレーの変更、適切なインフラへの移行といった対応が可能です。
複数ドメインのメールを管理するチームでも、ドメインが増えるだけで損害が生じるわけではありません。送信経路や共有インフラの管理が不適切な場合にリスクが高まります。
| 共有ホスティング | TrekMail | |
|---|---|---|
| IPの管理 | 他の送信者とプールを共有 | プランと構成に応じた送信インフラの選択肢 |
| 評価低下への対応 | 事業者の対応または移行が必要な場合がある | ダッシュボードで対応するSMTP認証情報を変更できる場合がある |
| 認証設定 | 手動設定と検証が必要な場合が多い | 提供状況に応じて一部のエラーを示すSPF、DKIM、DMARCウィザード |
| 回復時間 | 数日から数週間以上と幅がある | 認証情報の変更だけではなく、ドメイン、事業者、認証、履歴に左右される |
TrekMailはIMAPホスティングおよびストレージとSMTP送信を分離します。プランが対応していれば、BYO SMTPでAmazon SES、SendGrid、Mailgunをリレーとして接続できます。事業者に問題がある場合、SMTP認証情報の変更でメールボックス移行を避けられる可能性がありますが、ドメインレピュテーションは初期化されず、数分で受信トレイへ戻る保証もありません。メール履歴の維持は、選択した構成、保存、手順に依存します。
案内されているプランは無料からで、無料枠にBYO SMTPが含まれ、Starterプランは月額$3.50で最大50ドメインのマネージドSMTP付きとされています。現在の料金表で、提供状況、上限、条件、"無料"の意味を確認してください。
結論
メール送信者レピュテーションはドメインの信用スコアではなく、四つのシグナルだけで決まりません。苦情率を0.1%未満に保ち、認証を整合させ、該当する送信量の規則を守り、インフラを確認します。内容、同意、受信者の期待も重要です。
配信問題には技術的な原因が多い一方、内容も影響します。例として、11回検索するSPFレコード、更新されていない512-bitのDKIM鍵、3 AMに共有IPで迷惑メールを送る別利用者があります。
データで確認できた問題を修正し、定期的に監視し、異常が起きたら手順に従ってください。
不適切な共有プールを避けたい場合は、現在の無料プランが提供され、カード不要であれば、TrekMailを無料で試すことができます。
