メールドメインのレピュテーション: 診断と回復

送信ボタンを押すと、サーバーは250 OKと応答します。二週間後、メールが受信トレイへ届いていなかったことが分かります。迷惑メールフォルダーに入っていたか、ゲートウェイのポリシーによっては受信者がログインする前に削除された可能性があります。件名や本文も結果に影響します。別の可能性として、メールドメインのレピュテーションが関係し、その評価は何週間も前から低下していた場合があります。

GoogleとYahooが2024年二月に一部の適用を強化して以降、各社が定義する送信者区分には該当する基準への対応が必要です。しきい値を超えると表示機会が減る可能性はありますが、すべての送信者が一律に遮断されるわけではありません。このガイドでは、評価が下がる原因、診断に役立つエラーコード、段階的な回復方法を解説します。まずDNSの基礎が必要なら、独自ドメインでメールを設定する方法から始めてください。

メールドメインのレピュテーションとは

メールドメインのレピュテーションとは、Google、Microsoft、Yahooなどの受信事業者が、送信メールの長期的な挙動を基にドメインへ関連付ける信頼シグナルです。苦情率、認証エラー、不適切なリスト管理などが評価に影響します。事業者を横断する単一のスコアはありません。悪化後は健全な送信を積み重ねる期間が必要ですが、回復の可否や期間は事業者と原因により異なります。

重要なのは、評価が自然に元へ戻るとは限らない点です。長年良好な履歴を築いたドメインなら、時折のミスに耐えることもあります。苦情や認証エラーが続いたドメインは回復に長い時間を要する場合がありますが、あらかじめ永久的な評価が決まるわけではありません。

受信事業者は組織ドメイン単位で一部のシグナルを集約することがあります。サブドメインは確実な防壁ではありません。marketing.example.comがブロックリストに載れば、ceo@example.comからのメールも影響を受ける可能性があります。集約の程度は事業者ごとに異なるため、実データで確認してください。

到達した最大区分と継続的な分類

Googleがドメインを大量送信者として分類する基準は、個人用Gmailアカウントへ一日およそ5,000通を送る場合です。この分類は継続的に扱われ、送信量を減らしても解除されるとは限りません。該当者にはワンクリックでの配信停止ヘッダーやDMARCの公開などの要件が引き続き適用されます。ただし、すべての事業者が同じしきい値を使うわけではなく、DMARCを常にp=quarantineまたはp=rejectにする必要があるという意味でもありません。

Gmail宛ての日次送信量が~100通未満なら、Postmaster Toolsに"No Data"と表示されることがあります。テスト用アドレスへの送信やバウンス率の分析は参考になりますが、小さなサンプルですべての宛先を代表することはできません。

レピュテーション低下につながる4つの主な原因

評価が急落したときは、苦情率、認証の不整合、SPFのルックアップ上限、恒久的なバウンスという四つの領域を調べます。原因はこれだけではなく、内容、同意、受信側の基準も影響します。該当する層を切り分ければ、見当違いの対策に時間を費やさずに済みます。

1. 苦情率0.3%のしきい値

ユーザーによる迷惑メール報告は、GoogleとYahooにとって重要なシグナルです。0.3%、つまり3件の苦情につき1,000通は、各社の指針でリスクの高いしきい値とされ、迷惑メールへの振り分けや拒否につながる可能性があります。ただし、どこでも直ちに同じブロックが発生するわけではありません。Googleは0.1%未満を維持し、0.3%に近づかないよう推奨しています。

Yahooは、送信総数ではなく受信トレイに届いたメールを分母とする独自の計算方法を案内する場合があります。定義や分母は変わり得るため、共通の計算式と決めつけず、最新資料を確認してください。

例: 1,000通を送信し、900通が自動的に迷惑メールへ振り分けられ、100通が受信トレイに入ります。そのうち1人が苦情を送信します。
計算: 苦情1件 ÷ 受信トレイ到達100通 = 苦情率1.0%。
結果: この例では上限の3×となり、フィルタリングがさらに強まる可能性があります。

開封率の低下は一つの手掛かりですが、開封データはプライバシー機能の影響を受け、不完全です。十分なデータがあればGoogle Postmaster Toolsに"Low"や"Bad"と表示されることがありますが、画面や対象範囲は変わる可能性があります。

2. 認証の不整合とスプーフィングのシグナル

SPFとDKIMが成功しても、表示されるFromドメインと整合していない場合があります。このとき、もう一方の整合した認証方式が成功しなければDMARCは失敗します。DMARCの失敗はスプーフィングのように見え、評価を損なうことがありますが、他のシグナルと併せて判断されます。

たとえばMailchimpやSendGridなどのESPを使うと、SPFのエンベロープ送信者がmail.sendgrid.netを指し、Fromヘッダーはyourcompany.comとなる場合があります。IPが承認されているためSPFは成功しますが、ドメインが一致しないのでSPFによるDMARCアラインメントは失敗します。整合したDKIM署名が成功すれば、DMARCはそちらで合格できます。

Microsoftは、大量送信者向けの認証またはポリシー要件に関連して550 5.7.515を返すことがあります。完全な応答を読まずに、内容やReturn-Pathだけの問題とは断定できません。ESPで独自ドメイン認証を設定します。この機能は"Whitelabeling"と呼ばれる場合もあります。SPFとDKIMの両方についてアラインメントを確認してください。

3. SPFの10ルックアップ上限（RFC 7208）

SPFへ無制限に送信元を追加することはできません。RFC 7208 §4.6.4は、SPF評価中にDNS検索を発生させる仕組みに10回の上限を定めています。Google、Outlook、Zendesk、Mailchimp、CRMを含めると、上限に近づくことがあります。入れ子のinclude:も追加の検索を消費する場合があります。

対象となる検索が11回に達すると、受信側の評価はPermErrorを返す可能性があります。その検査ではSPFレコードが有効な結果を提供できません。宛先やDNS経路によって結果が異なることはありますが、ログを確認せずに緩いパーサーと厳しいパーサーの差だと一律に説明することはできません。

4. Microsoftにおける不明な受信者へのバウンス

Microsoftは恒久的なバウンスと、アドレスを推測するnamespace miningに似た挙動を監視しています。2-3%を超えるバウンス率は運用上のリスク例であり、即時ブロックを必ず発生させる公式しきい値ではありません。550 5.7.1やスロットリングの421 RP-001などが返る場合がありますが、完全な応答で意味を確かめてください。

迷惑メール苦情率が0%でも、恒久的に無効なアドレス、認証、ポリシーによる問題は起こり得ます。"User Unknown"と、認証やポリシーに関する恒久的応答を区別し、Microsoftの宛先へ連絡する前に同意と有効性を確認してください。

事業者別の診断情報

レピュテーション問題を解決するには、どの事業者がフィルタリングまたは拒否しているかを把握します。事業者ごとに重視するシグナルや提供する診断ツールが異なります。現在の提供状況、利用条件、資料を確認してください。

診断手順: 障害を切り分ける

推測だけに頼らず、適切な環境で承認された技術検査を行い、受信したメッセージのヘッダーを確認します。組み合わせることで、インフラ、認証、送信行動の問題を切り分けやすくなりますが、一つのサンプルだけで完全に診断できるわけではありません。

ターミナルによるインフラ検査

送信量を増やす前に認証構成を確認します。以下の三つは一般的な障害点を調べる例です。対象ドメインの承認を得て環境に合わせて使い、ここにあるコマンドをそのまま実行しないでください。

# Check SPF - count the includes, verify it ends in ~all or -all
dig txt yourdomain.com +short

# Check DMARC - p= should be quarantine or reject for live domains
dig txt _dmarc.yourdomain.com +short

# Check FCrDNS (Forward-Confirmed Reverse DNS)
# Step 1: Get the hostname from your sending IP
dig -x 1.2.3.4 +short
# Expected output: mail.yourdomain.com.

# Step 2: Verify the hostname resolves back to the same IP
dig mail.yourdomain.com +short
# Expected output: 1.2.3.4

FCrDNSの検査に失敗し、IPとホスト名が一致しない場合、一部の受信者は否定的なシグナルとして扱う可能性があります。GmailやYahooが必ず拒否するわけではありませんが、送信量を増やす前に修正してDNSの反映を確認してください。

ヘッダーの調査

自分で管理するGmailアカウントへ、承認されたテストメールを送ります。メールを開き、三点メニューから"メッセージのソースを表示"を選び、Authentication-Resultsヘッダーを探します。この結果はその経路と受信者に限られ、今後の配信を保証しません。

否定的なシグナル、アラインメント失敗:

spf=pass smtp.mailfrom=sendgrid.net
dkim=pass header.d=sendgrid.net
dmarc=fail (p=reject) header.from=yourcompany.com

SPFとDKIMは成功していますが、どちらのドメインもyourcompany.comと整合していないためDMARCは失敗します。このサンプルは前述の認証不整合を示し、否定的なシグナルに影響する可能性があります。

肯定的なシグナル、整合済み:

spf=pass smtp.mailfrom=em.yourcompany.com
dkim=pass header.d=yourcompany.com
dmarc=pass

回復手順

Google Postmaster Toolsで"Bad"と表示されている場合、健全で計画的な送信を2-4週間続けるという期間は運用上の目安であり、保証ではありません。原因、送信量、宛先によって回復は異なります。効果を測れるよう段階的に進めます。

フェーズ1: リストの見直し

無効な受信者への送信を続けると回復を妨げます。90日間に開封やクリックがないという理由だけで一律に削除しないでください。開封データは信頼性が低く、同意、サービス上の必要性、保存義務が存在する場合もあります。恒久的な無効が確認されたアドレスは抑止し、同じ宛先から"User Unknown"が二度返った後も送る処理になっていれば修正します。

フェーズ2: 技術的な修正

すべての正規送信元を承認して棚卸しした後、p=noneからp=quarantineへの段階的な移行を検討します。DMARCポリシーは一部の不正利用を抑えますが、あらゆるスプーフィングを防ぐものでも、レピュテーションを必ず改善するものでもありません。1024-bitのDKIM鍵を使用している場合は、現在の対応状況を確認し、2048-bitまたは利用可能な方式へ安全にローテーションしてDNSを更新します。必須DNSレコードのガイドにTrekMailドメインの形式が記載されていますが、現在の構成も検証してください。

フェーズ3: 段階的に管理するウォームアップ

過去30日間に送信者との実際の関係が確認できる受信者から再開し、人工的なエンゲージメントは作らないでください。次の数値は一例です。

• 1日目: 50通
• 2日目: 100通
• 3日目: 200通
• 4日目: 400通

利用できるデータを毎日確認します。シグナルが悪化した場合に48時間休止し、前日の量から再開する方法は例であり、共通の規則ではありません。事業者のポリシーと観測結果に合わせて調整してください。

インフラの健全性: 見えにくい問題

明確なエラーを出さずに影響するインフラ要素が二つあります。認証レコードが正しくても、TLSの設定と共有IPプールの品質は確認が必要です。ただし、原因がこの二つだけとは限りません。

TLSの利用

主要事業者は、利用できる場合に保護されたSMTP転送を期待しますが、ポリシー、状況、対応バージョンは異なります。必要かつ互換性がある場合はTLS 1.2以上を設定し、平文接続がすべて自動的に拒否されるとは決めつけないでください。TrekMailではTLSが標準で有効と説明されていますが、現在の動作とプランを確認してください。

共有IPを使う他の送信者

低価格の共有ホスティングやESPの無料プランでは、多くの送信者が同じIPを使う場合があります。他の利用者の不正行為によりプールがSpamhaus SBLへ掲載されると、ドメインに既知の問題がなくてもメールが影響を受ける可能性があります。

月間100k通を超えても、専用IPが必ず有利とは限りません。安定した送信量、運用能力、監視が必要です。それ以下では、事業者のプール管理を評価するか、外部SMTPを検討します。TrekMailのBYO SMTPオプションでは、プランと提供状況に応じてAmazon SES、SendGrid、Mailgunを接続できます。事業者を自分で選んでも、IPを直接管理できることや良好な評価は保証されません。

TrekMailの位置付け

メールドメインのレピュテーションは、マーケティング上の変数ではなく、技術と運用の制約です。正確なDNS設定、責任ある宛先管理、適切に管理された送信インフラが必要です。

複数ドメインを管理すると複雑さが増します。マルチドメインメールホスティングのガイドでは、完全な分離を保証することなく、相互影響のリスクを抑える構成を説明しています。認証全体については、メールセキュリティの基礎ガイドでDMARCポリシーとDKIM鍵のローテーションを詳しく解説しています。

TrekMailは、定額ストレージ、IMAPメールボックス、catch-allルーティング、サーバー側移行などの受信メール機能を、ユーザー単位ではない料金体系で提供すると説明しています。送信にはプランと上限に応じて外部SMTP事業者を接続できます。SPF、DKIM、DMARCの設定ウィザードはオンボーディング時に利用できると案内されていますが、送信前に現在の提供状況、構成、最終結果を確認してください。

プランは月額$3.50からと案内されています。クレジットカードが必要な14日間の無料トライアル、またはカード不要で継続無料と説明されるNanoプランがあり、10ドメインと5 GBを含むとされています。現在の価格、適用条件、機能、上限はtrekmail.net/pricingで確認してください。

まとめ

確認すべき原因には、0.3%を超える苦情率、ESPの設定によるDMARCアラインメントエラー、SPFの10ルックアップ上限超過、Microsoft宛ての恒久的なバウンスがあります。原因はこの四つだけではなく、それぞれ個別のデータと診断が必要です。

評価がすでに低下しているなら、リストを見直し、技術面を修正してから、送信量を段階的に増やします。二週間から四週間という期間は目安にすぎず、固定の所要時間や近道はありません。

承認された手段でDNSを確認してください。問題が見つかったら、次のキャンペーンを送る前に修正して結果を検証します。