毎週見るパターンです。チームがリセラーから 40 ドメインにわたる 120 のインボックスを購入。2-3 週間ウォームアップ。キャンペーンをローンチ。返信ゼロ、不在通知すらなし。パニック。コピーを変更。それでも何もない。6 週間で、デリバラビリティが完全に沈む。インフラは廃棄され、最初からやり直し。

10 回中 9 回、問題はインフラであってコピーではありません。適切に認証されたインフラで送られる「悪い」コピーは届きます。壊れたインフラで送られる「良い」コピーは届きません。フレーミングと認証はスパムワードよりも 10 倍重要です。

認証の三角形: SPF、DKIM、DMARC

すべてのコールド送信ドメインは、整列して構成された 3 つの DNS レコードを必要とします。いずれか 1 つが欠けていたり誤って構成されていたりすると、デリバラビリティは崩壊します。

SPF（Sender Policy Framework）

SPF は受信メールサーバーに、あなたのドメインから送信を許可された IP がどれかを伝えます。標準的な Google Workspace SPF レコードは v=spf1 include:_spf.google.com ~all のようになります。重要なルール: SPF が通過するには、リターンアドレス（envelope-from）が送信者アドレスと一致する必要があります — これを SPF アライメント と呼びます。転送はアライメントを破壊し、コールドキャンペーンで異なる「reply-to」アドレスがしばしばデリバラビリティを沈めるのはこれが理由です。

DKIM（DomainKeys Identified Mail）

DKIM は暗号署名 — メッセージが実際に送信を主張するドメインから来たことを証明する切手です。Google Workspace は管理コンソール内で DKIM キーを生成します。それを TXT レコードとして DNS にコピーします。Microsoft 365 も同様に動作します。Gmail の自分宛にメールを送って「Show original」を実行することで通過を確認 — SPF、DKIM、DMARC がすべて PASS を表示するべきです。

DMARC（Domain-based Message Authentication）

DMARC は SPF または DKIM が失敗したときに受信側に何をするか伝えるポリシーです。3 つのポリシーは none、quarantine、reject。コールド送信のベストプラクティスは:

v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@yourdomain.com; sp=none

p=reject は SPF と DKIM が通過していればゴールドスタンダード。クリーンなインフラを強制 — 認証されていないものは何も通りません。rua=（集約レポート URI）を追加すると、誰があなたとして送信しようとしているかの日次レポートを受け取ります。rua= をスキップするのはよくある初心者のミス。それなしでは盲目飛行です。

よくあるセットアップの落とし穴: SPF と DKIM が通過確認される前の p=reject。認証が失敗すると、自分のメールも自分のプライマリインボックスに届きません。mail-tester.com にテストを送り、10/10 を確認し、Gmail の「Show original」で SPF/DKIM/DMARC がすべて PASS を表示することを検査してから DMARC を引き締めてください。

ドメインウォームアップ: 28 日、2 週間ではなく

新規ドメインは、実際のキャンペーンを実行する前に最低 28 日のウォームアップが必要です。2 週間では足りません。3 週間は限界的な結果のための最低ライン。4 週間で返信率が安定します。

ウォームアップツール — Warmup Inbox、Warmbox、Warmforge、Mailwarm、Folderly、Mailreach、Warmy — はドメイン評価を構築するために会話をシミュレートします。シーケンサーと統合するものを使用してください。ウォームアップ中、インボックスの健全性スコアはゼロから 80-100 に向けて上昇すべきです。新規ドメインで 3 週間後もスコアが 20 未満なら、上流で何かが壊れています — 通常、リセラーの IP ブロックや DNS の誤設定。

ウォームアップが実際に行うこと: ドメインに合法的で人間らしいメールトラフィックがあることを確立。それがしないこと: 悪いコピー、検証されていないリスト、スパムブロックリスト上のドメインレジストラを補償すること。

プロバイダごとのプレースメントテスト

各メールプロバイダは異なるデリバラビリティのシードを持ちます。Google のスパムフィルタは Microsoft 365 のものではありません。Mimecast、Barracuda、Proofpoint（エンタープライズアンチスパム）はそれぞれ異なる分類を行います。プレースメントテストを実行することで、サイレントなオーディエンスにキャンペーンを無駄にする前に、どのプロバイダがインボックスに入れ、どれが隔離するかが分かります。

使用するツール:

mail-tester.com — 基本的な健全性スコア、スパムワードチェック、認証検証
Folderly — 完全なプレースメントテストと継続的なデリバラビリティモニタリング
GlockApps — プロバイダ全体での詳細なインボックス・プレースメント
Emailguard / Mailreach / Warmy — 継続的なプレースメントモニタリング
Inbox Placement（Smartlead）— 最も安いクイックチェック

稼働前に新規インフラでプレースメントテストを実行し、その後 2 週間ごとに再テスト。デリバラビリティはドリフトします — 4 週目にインボックス入りするドメインが 8 週目に隔離されることがあります。早く捕捉し、返信が死ぬ前にローテーションしてください。

マルチ ESP、マルチレジストラのスタック

2026 年のゴールドスタンダード: 最低 2 つのドメインレジストラ、2 つの ESP（Google Workspace + Microsoft 365）。実際のスケールではそれぞれ 3 つ。理由はシンプル: 単一障害点はパイプライン全体を殺します。Google がグレーハットのリセラーを廃止したり、Microsoft がクォータを引き締めたりするとき、最初を修正している間に第 2 のスタックにローテーションします。

月 10 万通以上のメールを送るチームでこれが実際にどう見えるか:

バッチ 1: レジストラ A の 30 ドメイン、Google Workspace、シーケンサー 1 — 2 週間送信、その後クールダウン
バッチ 2: レジストラ B の 30 ドメイン、Microsoft 365、シーケンサー 2 — バッチ 1 が休んでいる間に送信
バッチ 3: ホットスワップ予備 — 事前ウォームアップ済み、いずれかのバッチが焼けたとき展開準備完了

ローテーションなしで 100 以上のインボックスを運用するエージェンシーが 6 週間ごとにデリバラビリティの崖を見るのはこれが理由です。彼らは一度に 1 つのスタックを焼いています。ローテーションは焼けを分散し、インフラの寿命を延ばします。

ドメインの命名: 文字、.com または .co、例外なし

エンタープライズターゲットのシステム管理者は、珍しい TLD と疑わしく見えるドメインを積極的にブロックします。送信ドメインは、システム管理者が一目で信頼する通常の会社ドメインのように見えるべきです。

使う: .com、.co、ローカルキャンペーン用の地域特化 TLD（.de、.nl、.fr、.uk）
避ける: .xyz、.online、.site、.tech、.info、.biz — すべてエンタープライズフィルタにフラグされる
避ける: 数字（company1.com）、ハイフン（get-company.com）— フィッシングパターン
優先: 文字のみのバリアント（trycompany.com、hqcompany.com、getcompany.com、usecompany.com、joincompany.com）

プライマリドメインはコールド送信に決して使うべきではありません — 評価リスクが高すぎます。別のインフラ上の購入したルックアライク・ドメインを使い、顧客対応のコミュニケーションのためにプライマリドメインをクリーンに保ってください。

ドメインごとに 2 インボックス、3 ではなく

数千のコールド送信セットアップからのデリバラビリティデータ: Google Workspace のドメインごとに 2 インボックスは 3 を上回ります。ドメインごとに多くのインボックスがあってもスループットは増えません — ドメイン焼けあたりのリスクが増えるだけです。15 ドメインそれぞれに 2 インボックス（30 メールボックス）は、10 ドメインそれぞれに 3 インボックス（30 メールボックス）をデリバラビリティで上回ります。

スパムワードとコピーの衛生

スパムワードリストは過大評価されています。フレーミングとインフラが 10 倍重要です。とは言え、「無料」、「保証」、「緊急」、「今すぐ行動」、または典型的なセールスっぽい言葉を意図的に詰め込まないでください。Mailmeteor のスパムチェッカーまたは Folderly のワードチェッカーを使ってクイックなサニティパスを行ってください。

個々の単語よりも重要なこと:

コールドメールを 50-60 ワード以下に保つ（Leadbird のコピーデータは一貫して短い方がよく届くことを示しています）
最初のタッチに HTML、CSS、トラッキングピクセルを含めない — プレーンテキストが勝ちます
例外的な理由がない限り、最初のメールにリンクなし
CTA は 3 つではなく 1 つ
パターン・フィンガープリンティングを避けるため、すべての行で Spintax または AI 生成のバリアント

クライアントのために構築するもの

典型的なデリバラビリティ・エンゲージメント:

既存のドメインフリート、認証レコード、ウォームアッププール、プレースメントを監査
ボリュームに合わせたマルチ ESP、マルチレジストラのアーキテクチャを設定
rua= レポートを伴う SPF、DKIM、p=reject DMARC を構成
ローテーションスケジュール（バッチ 1/2/3）とホットスワップ予備を構築
プレースメントテストのケイデンスを統合（2 週間ごと、自動アラート）
シーケンスと返信データと並んでデリバラビリティ指標を HubSpot に取り込み
システムを運用しドリフトを診断するためにチームをトレーニング

スケジュール: ドメインフリートのサイズとウォームアップの状態に応じて、契約から最初のクリーンな送信まで 4 〜 6 週間。ウォームアップ中は LinkedIn とコールドコール・キャンペーンを実行するため、パイプラインのために 1 か月待つ必要はありません。

コールドメール・インフラのプレイブック