IP ウォームアップ（IP Warm-up）

概要

IP ウォームアップ（IP Warm-up） は、新しい IP アドレスからのメール送信量を段階的に増やし、メールボックスプロバイダーに対して送信者レピュテーションを構築する手法です。新規の IP アドレスには送信履歴がなく、レピュテーションが確立されていません。この状態で大量のメールを一度に送信すると、スパム送信者と同様の行動パターンと見なされ、受信サーバーにブロックされます。

IP ウォームアップは一般的に 2〜4 週間かけて行います。初日は数百通から開始し、毎日送信量を増やしながら、バウンス率やスパム報告率が許容範囲内に収まっていることを確認し、最終的な目標送信量に到達させます。

M3AAWG（Messaging, Malware and Mobile Anti-Abuse Working Group）は、IP ウォームアップを新規 IP からのメール配信におけるベストプラクティスとして推奨しています。SendGrid、Amazon SES、Mailgun などのメール配信サービスも、専用 IP を使い始める際に IP ウォームアップを行うよう案内しています。

仕組み

ウォームアップは送信量の段階的な増加とエンゲージメントの高い受信者の優先送信を組み合わせて、プロバイダーに正当な送信者であるシグナルを蓄積させます。

なぜウォームアップが必要なのか

メールボックスプロバイダー（Gmail、Microsoft、Yahoo 等）は、送信元 IP の過去の送信行動に基づいてレピュテーションを評価します。新規 IP には送信履歴がないため、プロバイダーは「未知の送信元」として慎重に扱います。

新規 IP からの大量送信は、以下のリスクを伴います。

1. 受信サーバーがレート制限を適用し、4xx エラー（一時的拒否）を大量に返す
2. 一部のメールが迷惑メールフォルダに振り分けられる
3. スパムトラップに当たると、DNSBL に登録される
4. 一度レピュテーションが低下すると、回復に数週間〜数か月かかる

ウォームアップは「この IP は正当な送信者が管理している」というシグナルをプロバイダーに徐々に蓄積させる作業です。

ウォームアップスケジュールの例

目標送信量が 1 日 10 万通の場合のウォームアップスケジュール例です。

日数	1 日あたりの送信量
1〜2 日目	500 通
3〜4 日目	1,000 通
5〜6 日目	2,500 通
7〜8 日目	5,000 通
9〜10 日目	10,000 通
11〜12 日目	25,000 通
13〜14 日目	50,000 通
15 日目以降	100,000 通

増加のペースは送信内容やプロバイダーの反応に応じて調整します。バウンス率が 2% を超えたり、スパム報告率が 0.1% を超えたりした場合は、送信量の増加を一時停止して原因を調査します。

ウォームアップ中の送信先選定

ウォームアップ期間中は、エンゲージメントの高い受信者を優先的に送信対象にします。過去 30〜90 日以内に開封やクリックの実績がある宛先を最初のバッチに含めます。

エンゲージメントの高い受信者に送信する理由は 2 つあります。1 つは、メールを開封・クリックする受信者はスパム報告を行う可能性が低く、スパム報告率を低く保てること。もう 1 つは、プロバイダーが「このメールは受信者に歓迎されている」と判断するシグナルになることです。

反対に、長期間アクティブでないアドレス、購入リスト、収集元が不明なアドレスをウォームアップの初期段階で使うのは避けます。これらのアドレスにはスパムトラップが含まれている可能性が高く、DNSBL への登録リスクがあります。

プロバイダー別の分散

送信先を Gmail、Microsoft（Outlook/Hotmail）、Yahoo、その他のプロバイダーに均等に分散させます。特定のプロバイダーに集中させると、そのプロバイダーのレート制限に抵触しやすくなります。

Gmail は特にウォームアップに敏感で、新規 IP からの大量送信に対して積極的にレート制限をかけます。Gmail 宛の送信量は控えめに設定し、他のプロバイダーよりも緩やかに増加させるのが安全です。

具体例

メール配信サービスの自動ウォームアップ機能や、自前 MTA でのレート制限設定でウォームアップを実施します。

SendGrid の自動ウォームアップ

SendGrid は「IP Warmup」機能を提供しており、有効にすると送信量を自動的に段階的に増加させます。超過分のメールは SendGrid の共有 IP プールから送信されます。自動ウォームアップは 41 日間のスケジュールで動作し、初日は 50 通、最終日には 1,638,400 通まで増加します。

Amazon SES での手動ウォームアップ

Amazon SES のサンドボックス環境から本番環境に移行した後、専用 IP を使い始める際に手動でウォームアップを行います。SES はサンドボックス解除時に送信制限を段階的に緩和しますが、専用 IP の場合はユーザーがウォームアップスケジュールを管理する必要があります。SES の「Dedicated IP pools」と「Adaptive warm-up」機能で自動化も可能です。

Postfix でのレート制限設定

自前の MTA でウォームアップを行う場合、Postfix でドメインごとの送信レートを制限できます。

# /etc/postfix/main.cf
smtp_destination_rate_delay = 2s
smtp_destination_concurrency_limit = 2
default_destination_rate_delay = 1s

smtp_destination_rate_delay は同一宛先ドメインへの連続送信間隔を制御します。ウォームアップの進行に合わせて値を段階的に緩和し、最終的には通常運用の値に戻します。

確認方法

ウォームアップ中は以下の指標を毎日モニタリングします。

バウンス率は送信ログで確認します。Postfix の場合、status=bounced のエントリーを集計します。

grep "status=bounced" /var/log/mail.log | wc -l

ソフトバウンス（4xx）の割合も確認します。ウォームアップ中はプロバイダーがレート制限を適用して 4xx を返すことがあり、これは正常な動作です。

grep "status=deferred" /var/log/mail.log | wc -l

Google Postmaster Tools で Gmail 宛のスパム報告率を確認します。0.1% 未満を維持し、0.3% を超えたら送信量の増加を停止します。

送信元 IP が DNSBL に登録されていないかは dig で定期的にチェックします。

dig +short 25.100.51.198.zen.spamhaus.org

dig +short 25.100.51.198.b.barracudacentral.org

NXDOMAIN であれば登録されていません。ウォームアップ中に DNSBL に登録された場合は、送信を即座に停止して原因を調査します。

外部の視点からも確認したい場合は、Labee Dev Toolbox の IP API を使うと、外部の視点から見た PTR レコードの設定状況を確認できます。

curl "https://labee.dev/api/ip?ip=198.51.100.25"

{
  "success": true,
  "data": {
    "ip": "198.51.100.25",
    "type": "IPv4",
    "isPrivate": false,
    "ptr": "mail.example.com"
  },
  "error": null,
  "meta": { "responseTime": 42 }
}

data.ptr が null の場合、PTR レコードが未設定です。ウォームアップを開始する前に、送信 IP の逆引き DNS を正しく設定しておくことが前提条件です。PTR レコードが設定されていない IP からのメール送信は、Gmail をはじめ多くのプロバイダーで拒否されます。

メール認証（SPF・DKIM・DMARC）の設定もウォームアップ開始前に完了させておく必要があります。

curl "https://labee.dev/api/mail-auth?domain=example.com"

{
  "success": true,
  "data": {
    "spf": {
      "record": "v=spf1 ip4:198.51.100.25 ~all",
      "exists": true
    },
    "dkim": {
      "record": "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3...",
      "exists": true,
      "selector": "default"
    },
    "dmarc": {
      "record": "v=DMARC1; p=none; rua=mailto:dmarc@example.com",
      "exists": true
    },
    "bimi": {
      "record": null,
      "exists": false
    }
  },
  "error": null,
  "meta": { "responseTime": 120 }
}

data.spf.exists、data.dkim.exists、data.dmarc.exists が全て true であることを確認します。ウォームアップ中は DMARC ポリシーを p=none に設定し、認証失敗のレポートを収集しながら問題を修正します。ウォームアップ完了後に p=quarantine、p=reject へ段階的に強化します。

よくある問題

ウォームアップの失敗は、省略による即時ブロック、リスト品質の問題、送信中断によるレピュテーション低下が主な原因です。

ウォームアップを省略して大量送信する

新規 IP でウォームアップを省略して初日から大量送信すると、高確率でプロバイダーにブロックされます。Gmail は新規 IP に対して 500 通/時間程度のレート制限をかけることがあります。ブロックされた IP のレピュテーション回復には数週間かかるため、最初からやり直す方がかえって遅くなります。

ウォームアップ中にバウンス率が急上昇する

ウォームアップの初期段階でバウンス率が 2% を超える場合、送信リストの品質に問題があります。リストに無効アドレスやスパムトラップが含まれている可能性があります。送信量の増加を停止し、リストのクリーニングを行ってから再開します。ダブルオプトインで取得したアドレスのみを使うのが安全です。

ウォームアップの途中で送信を中断する

ウォームアップ期間中に数日間送信を停止すると、構築したレピュテーションが低下します。プロバイダーは送信パターンの一貫性を評価しており、急な中断は不自然なパターンと判断されます。ウォームアップ期間中は毎日一定量のメールを送信し続けることが必要です。やむを得ず中断した場合は、中断前の送信量ではなく、数段階戻った量から再開します。

送信リストを一切セグメントしていない

ウォームアップの初期段階でランダムに選んだアドレスに送信すると、エンゲージメントの低い受信者やスパムトラップが含まれるリスクがあります。ウォームアップ中は必ずエンゲージメントの高い受信者（過去 30〜90 日以内の開封・クリック実績あり）を優先します。送信量が増えるに従って、徐々に対象を広げていきます。

SPF・DKIM・DMARC の設定が未完了のまま開始する

メール認証が設定されていない状態でウォームアップを開始すると、プロバイダーが認証 fail のシグナルを蓄積し、レピュテーションが構築されるどころか低下します。ウォームアップの前提条件として、新規 IP の PTR レコード設定、SPF レコードへの IP 追加、DKIM 署名の有効化、DMARC レコードの公開（p=none で開始）を完了させます。