メール到達率とDNS

メールのドメインレピュテーション: 評価悪化の原因と対策

著者:Alexey Bulygin
IPやホスティング先を変更しても送信者について回るメールのドメインレピュテーションを示す図

メールが迷惑メールに振り分けられます。ホスティング事業者を変えても、やはり迷惑メール扱いになります。新しい専用IPを用意しても変わりません。サーバーを一から構築し直しても同じです。

最初にはっきり説明されにくい点があります。問題はサーバーではなく、ドメイン名にあるかもしれません。

メールのドメインレピュテーションに関する指標は、送信元のインフラだけでなくルートドメイン、つまりcompany.comにもひも付きます。ホストを変更し、IPを入れ替え、別のプロバイダーへ移行しても、ドメイン側の評価は残る可能性があります。問題がサーバーではなくドメイン名に関連する場合があるためです。住所を変えただけでは、名前にひも付く評価まで自動的に消えるとは限りません。

DNS設定、メールボックス構成、認証の基本といった基盤をまだ整えている段階なら、小規模企業向けビジネスメールのガイドで一通り確認できます。この記事では、ドメインの評価悪化という特定の障害パターンに焦点を当てます。その原因、判断材料となるエラーコード、予防に役立つ構成を解説します。

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

メールのドメインレピュテーションとは、Google、Yahoo、Microsoftなどのメールボックス事業者が送信ドメインに対して形成する信頼評価です。迷惑メールの苦情率、認証の合格率、エンゲージメントの傾向、送信量の履歴などから判断されます。IPレピュテーションとは異なり、ドメインレピュテーションはドメイン名に結び付いており、プロバイダーやサーバーを替えただけで簡単に初期化できるものではありません。

2025年から2026年にかけて、主要事業者ではドメイン単位の評価がIPレピュテーションと並ぶ重要な判断材料になっています。IPアドレスは変更できるため、GoogleやYahooは比較的安定した識別子であるドメインのシグナルも追跡しています。実際の重み付けは事業者やメッセージの種類によって異なります。

この点は、ドメインレピュテーションに特有の問題を生みます。クリーンなIP、適切なPTRレコード、低いバウンス率など、サーバー側を正しく整えても、ドメインの履歴が受理や分類に影響する可能性があります。ドメインレピュテーションは診断上の重要な要素ですが、結果を決める唯一の条件ではありません。

「評価が悪化した」状態を示す診断上の兆候

ドメインレピュテーションの悪化は、さまざまな拒否や分類のパターンとして現れることがあります。受理後に迷惑メールへ移動する、ゲートウェイで550エラーにより拒否される、プロモーションに分類される、新しいIPでもブロックされる、といった兆候です。本文、認証、IP、受信側ポリシーも原因になり得るため、単独の症状だけで断定せずに調査します。

症状技術的なシグネチャ診断
メールが標準で迷惑メールに入る250 OK、受理後に迷惑メールへ分類レピュテーション低下の可能性。受理は受信トレイへの配信を保証せず、本文など他の要因も影響する。
ゲートウェイでポリシー拒否550 5.7.1または550 5.7.515(Microsoft)DMARC、受信側ポリシー、レピュテーションなどを確認する。完全なエラー応答が判断に必要。
トランザクションメールがプロモーションに入る請求書やリセット通知がGmailのプロモーションに入る混在したトラフィックや本文が分類に影響した可能性がある。ドメインのブロックを証明するものではない。
新しいIPですぐにブロック新規の専用IPが初日からブロックされるドメイン側のシグナルが疑われるが、IPの履歴、設定、認証、本文も確認が必要。

最後の行は有力な切り分け材料ですが、決定的なテストではありません。新しいIPには十分な良い履歴がなく、割り当て前の評価や制限が存在する場合もあります。ドメインを割り当てた直後から拒否されるなら、ドメイン、IP、DNS、認証、本文、受信側ポリシーをまとめて確認してください。ドメイン側の問題は、インフラの交換だけでは解消しない場合があります。

ドメインの評価を損なう四つの運用上の原因

高度なフィルターがドメインを拒否する理由は、迷惑メールらしい単語だけではありません。送信行動やインフラのパターンも見ています。以下の四つの原因を理解することが、ドメインレピュテーションへの長期的な悪影響を防ぐ第一歩です。

1. サブドメインのレピュテーション集約

「リスクの高いキャンペーンをpromo.example.comから送れば、example.comは無傷でいられる」という誤解がよくあります。

十分な分離策とはいえません。Googleは組織ドメイン単位でもレピュテーションを集約します。promo.example.comで苦情率が高くなれば、そのシグナルがexample.comの評価にも影響する可能性があります。サブドメインは一定のシグナル分離には役立ちますが、ドメインレピュテーションを守る防火壁ではありません。

2. 大量送信者のしきい値と継続的な要件

2024年の二月以降、GoogleとYahooは「大量送信者」に、より厳格な遵守要件を適用しています。Googleは一日およそ5,000通以上を個人向けGmailアドレスへ送るドメインを基準として示していますが、Yahooの定義は同一ではありません。最新の基準を事業者ごとに確認してください。

注意すべき点は、一度しきい値を超えた後の扱いです。たとえばブラックフライデーに大量配信を行い、その後の送信量が一日50通へ戻っても、大量送信者向けの基準が引き続き適用されることがあります。DMARC、ワンクリックでの配信停止、厳格なリスト衛生を継続して満たせる運用にしておくべきです。

3. 苦情率0.3%という上限

GoogleとYahooは、迷惑メールの苦情率に厳しい基準を設けています。

  • しきい値: 0.3%(3件の苦情につき1,000通)
  • 確認場所: Google Postmaster Tools。Gmailが把握しているドメインレピュテーションを確認できる公式の画面です
  • 回復期間: しきい値を下回った後も、おおむね30日から60日にわたり良好な送信を続ける必要がある場合があります

多くの運用担当者は、問題が表面化するまで上限に近づいていることに気付きません。障害が起きてからではなく、平常時にGoogle Postmaster Toolsを設定しておきましょう。

4. 共有IPにおける他テナントの影響

cPanelや低価格のウェブメールプランなど、一般的な共有ホスティングでは、数百のテナントと同じIPからメールを送る場合があります。いずれかのテナントがフィッシングを行えば、そのIPがSpamhaus SBLに掲載される可能性があります。これは技術的にはIPレピュテーションの問題ですが、問題のある共有IPとの関連が繰り返されれば、時間とともにドメイン側の評価にも悪影響が及ぶことがあります。同じプールで問題が続くと、IPとドメインのレピュテーションを明確に切り分けにくくなります。

予防策: クリーンなドメイン構成

良好なドメインレピュテーションを維持するには、適切な認証、別のルートドメインによるトラフィック分離、検証済みのネットワーク構成という三つの層を連携させます。一定規模で送信するなら、いずれかを省略せず、自社の環境と受信事業者の要件に合わせて検証してください。

レイヤー1: SPF、DKIM、DMARCによる認証

認証は送信元の確認に欠かせません。設定がなければ、受信側は誰がメッセージを送ったかを検証しにくくなり、信頼の判断にも不利です。

  • SPF: ドメインのために送信できるIPを承認します。DNSルックアップ10回の上限に注意してください。Google Workspace、Mailchimp、Zendeskなど多数のベンダーをincludeするとPermErrorになり、SPFの評価が成立しない場合があります。
  • DKIM: 各メッセージに暗号学的な署名を付けます。利用先が対応する2048ビット鍵を使用してください。
  • DMARC: SPFまたはDKIMの整合した認証結果を使い、失敗したメッセージに対する受信側のポリシーを示します。まずp=noneで監視し、結果を確認してからp=quarantineまたはp=rejectへ進めます。
# Example DMARC record - replace with your reporting address
_dmarc.company.com  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@company.com; pct=100"

Microsoftの550 5.7.515拒否では、DMARCの未設定や認証、ポリシー上の問題が関連することがあります。また、2024年に導入されたGoogleとYahooの大量送信者向け要件にもDMARCが含まれます。このエラーコードが表示されたら、まずDMARCポリシーと実際の認証結果、アラインメントを確認してください。

レイヤー2: 別のルートドメインによる分離

コールドアウトリーチや大量のマーケティングメールを、主要な企業ドメインから送ることは避け、用途に応じて完全に別のルートドメインを検討します。

主要ドメイン: company.com。CEOの連絡、請求書、カスタマーサポートに使い、マーケティングには使わない。
マーケティング: trycompany.com。ニュースレターや製品アップデートに使う。
アウトリーチ: getcompany.com。コールドメールのシーケンスに使う。

getcompany.comがスパムトラップに接触して評価を損ねた場合でも、company.comを分けておけばCEOから投資家へのメールに同じシグナルが直接及ぶリスクを抑えられます。ただし、異なるルートドメインの利用も完全な隔離や配信を保証するものではありません。数十社の顧客にこの構成を展開する代理店は、マルチドメインメールホスティングのガイドで大規模なプロビジョニング方法を確認できます。

レイヤー3: ネットワーク衛生とFCrDNS

送信IPには、ホスト名を返す有効なPTRレコード(逆引きDNS)が必要です。そのホスト名が同じIPへ正引きできる状態を、正引き確認済み逆引きDNS(FCrDNS)と呼びます。

# Verify FCrDNS on your sending IP
dig -x YOUR_IP_ADDRESS       # Should return your hostname
dig +short YOUR_HOSTNAME     # Should return the same IP

結果が一致しない場合、GmailやMicrosoftで否定的なシグナルとして扱われ、拒否につながる可能性があります。新しいIPのウォームアップ前に修正し、DNSの反映後に正引きと逆引きを再確認してください。

レイヤー4: ウォームアップと休止による変化

メールのドメインレピュテーションは固定ではありません。継続的で良好な送信がない期間には、事業者ごとにシグナルが弱まることがあります。

  • 新規ドメイン: 初日は20通程度から始め、反応やエラーを確認しながら2日から3日ごとに倍増する例があります。最初の30日間はコールドアウトリーチを避ける慎重な計画を検討してください。適切な増加幅は宛先、内容、事業者により異なります。
  • 休止中のドメイン: 30日を超えて送信を停止すると履歴シグナルが弱まる場合があります。完全にリセットされると決めつけず、再開時は新規ドメインに近い慎重なペースで再評価してください。

TrekMailのドメインウォームアップルールには、マネージドSMTPアカウント向けの増加スケジュールが記載されています。利用時は現在のプランと最新要件も確認してください。

すでに評価が悪化している場合の初動

開封率が5%未満、ハードバウンスの増加、問題が確認されていないIPでも550拒否が発生する場合は、ドメインレピュテーションを含む原因を調査します。開封率は測定に限界があり、これらの兆候だけで原因は確定しません。切り分けながら順序立てて回復策を進めると、各変更の効果を確認しやすくなります。

  1. 問題のあるプロモーション送信を一時停止します。 パスワードリセットや領収書など、受信者が必要としているトランザクションメールに絞ります。原因と改善を確認しながら、それ以外の配信は慎重に再開します。
  2. Google Postmaster Toolsを確認します。 Gmailが観測しているドメイン評価を確認できる公式の情報源です。「Bad」と表示される場合、4週間から8週間程度以上を要する可能性も見込み、関係者に不確実性を含めた予定を共有します。
  3. 反応のない連絡先を整理します。 90日間メールを開いていない相手を機械的に削除するのではなく、同意、取引上の必要性、保存義務、直近の行動を確認し、不要または無効な宛先への送信を止めます。エンゲージメントを人為的に作る行為は避け、実際に希望する受信者との健全な配信を積み重ねます。
  4. 移行は最終手段です。 Spamhaus DBLに掲載されている場合は、掲載理由と正式な解除手順を確認します。回復不能と早合点せず、是正と解除申請を試み、それでも利用継続が現実的でない場合に新しいドメインへの移行を検討します。クリーンな出発点の技術設定は、独自ドメインメールの設定ガイドで確認できます。

TrekMailで実装できる基本構成

中小企業や代理店がドメインレピュテーションを損ねる一因は、低価格インフラ上で異なるトラフィックを混在させることです。CEOの連絡とニュースレターの一斉送信が同じ経路を共有すると、一度の高リスクなキャンペーンがドメイン全体の評価に影響する可能性があります。

TrekMailでは、用途を分離する構成を計画できます。

従来の方法TrekMailでの方法
CEOのメールとニュースレターがサーバーを共有企業メールを管理されたIPプールで運用
共有ホスティングでIPを共有する相手が不明大量送信には持ち込みSMTP(SES、SendGrid、Mailgun)を利用
あらゆる用途に一つのドメインを使用マルチドメインのプロビジョニングで用途ごとにトラフィックを分離
DNSを手動設定し、ミスが発生しやすい追加する各ドメインでSPF、DKIM、DMARC設定ウィザードを利用

中小企業は、TrekMailで企業メール(team@company.com)を認証設定とともに管理されたIP上で運用できます。大量送信には、Amazon SES、SendGrid、Mailgunなどの持ち込みSMTPを利用できる構成があります。CEOのメールとマーケティング送信を別の経路に分けることで、目的ごとに適したインフラを選べます。利用可能な機能と制限は現在のプランで確認してください。

代理店は、一つのダッシュボードから100件以上の顧客ドメインを管理する構成を検討できます。顧客ごとの企業用受信トレイと、マーケティング用の別リレーを分ければ、キャンペーンの問題が主要ドメインへ波及するリスクを抑えられます。アカウントをまたぐ構成方法は、顧客メール管理ガイドで解説しています。実際の上限と提供機能は契約前に確認してください。

メールのドメインレピュテーション問題は、個別の小技より構成の見直しが重要な領域です。認証、ドメイン分離、健全なインフラという三つを、一定量の送信を始める前に整えてください。

TrekMailのStarterプランは月額$3.50からと案内されています。マネージドSMTP、SPF、DKIM、DMARCの設定、マルチドメイン対応など、実際の提供内容は最新の料金ページで確認してください。14日間のトライアルの有効化にはクレジットカードが必要とされています。カードなしで始めたい場合、Nanoプランは10ドメインと持ち込みSMTPを$0で提供すると案内されていますが、現在の条件と上限を申込時に確認してください。

ドメインレピュテーションが良好になった後は、継続的な監視と適切な運用で維持します。そのためにも、最初に無理のない構成を整えることが重要です。

この記事を共有

投稿 共有 共有

TrekMail の運用と保護に必要な技術を使用します。確認すると、Cookie ポリシーに記載された限定的な分析と広告測定も許可されます。

TrekMail にサインイン

ダッシュボード、メールボックス、DNS にアクセスできます。

または

12 文字 パスワードが一致

または

再設定メールを送信しました

このメールアドレスのアカウントが存在する場合、パスワード再設定の手順をお送りしました。

続行すると、TrekMail の 利用規約 および プライバシーポリシーに同意したものとみなされます.