2026年にコールドメールをスパムから守るには、2つの別々の仕事をこなす必要があります。1つは、主要なメールボックスプロバイダーが今や強制している認証チェックを通過すること。もう1つは、そのプロバイダーが採点する送信者レピュテーションを保護することです。認証は一度きりの DNS 設定です — 専用の送信ドメイン上に SPF、DKIM、DMARC を置きます。レピュテーションは継続的です — 送信前にドメインをウォームアップし、受信箱ごとの1日あたりの量を低く保ち、スパム苦情率を 0.1% 未満に維持します。どちらか一方を省けば Gmail はあなたをスパムに振り分け、認証を完全に省けば Outlook は今やメッセージをその場で拒否します。

ルールは 2024年に任意ではなくなりました。Google と Yahoo は 2024年2月に、Gmail へ1日 5,000通を超えて送るすべての送信者に対して大量送信者の要件の適用を開始しました。Microsoft も Outlook、Hotmail、Live で続き、2025年5月から適用しています。3社とも今や同じ認証の土台を求めているため、以下の設定は主要な受信箱すべてを一度に満たします。

前提条件

DNS を自分で管理できる送信ドメイン。コールドメールを自社ブランドの主ドメイン（yourcompany.com）から送らないでください。 セカンダリドメイン（getyourcompany.com、tryyourcompany.co）を取得し、レピュテーションの問題が社内メールを汚染しないようにします。
DNS プロバイダー（Cloudflare、Namecheap、Route 53）へのアクセス。
これらのヘッダーと設定を扱える送信プラットフォーム。Smartlead と Instantly は認証設定と受信箱ごとのローテーションを担います。レコードを自分で設定するなら、素の SMTP リレーでも動きます。
モニタリング用の Google Postmaster Tools アカウントと Microsoft SNDS アカウント。どちらも無料です。

手順

専用の送信ドメインを登録し、その上に受信箱を作成します。 その MX レコードをプロバイダー（Google Workspace、Microsoft 365、または送信プラットフォームの受信箱）に向けます。量のスケールは、1つの受信箱により多くのメールを押し込むのではなく、受信箱とドメインを増やして行う計画にします — これが到達性に対する最大のレバーです。
SPF レコードを公開します。 あなたのために送信を許可されたすべてのサービスを列挙した TXT レコードを、ドメインのルートに追加します。Google Workspace の場合は v=spf1 include:_spf.google.com ~all。すべての送信者が列挙されていると確信できるまでは、-all ではなく ~all（softfail）を使います。大量送信者ルールでは SPF が存在し通過する必要があり、SPF レコードの欠落は即失格です。
DKIM を有効にし、鍵を公開します。 プロバイダーで DKIM をオンにし、公開鍵を <selector>._domainkey.yourdomain.com の TXT レコードとして公開します。2048ビットの鍵を使います。DKIM は転送を生き延びる信号なので、プロバイダーが最も重く見る認証信号です。
DMARC レコードを公開します。 _dmarc.yourdomain.com に TXT レコードを追加します。v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com。p=none は送信者ルールが求める最小値であり、かつ アラインメント していなければなりません — 表示される From ドメインが SPF または DKIM のドメインと一致する必要があります。まず p=none で2週間の集計レポートを集め、そのレポートが正当な送信者だけが通過していることを示したら、p=quarantine、最終的に p=reject へと強めます。
すべてのメッセージにワンクリック配信停止を追加します。 Gmail と Yahoo は大量メールに RFC 8058 のワンクリック配信停止を求めます。プラットフォームは両方のヘッダーを送る必要があります。List-Unsubscribe: <https://unsub.example.com/u/123>, <mailto:unsub@example.com> と List-Unsubscribe-Post: List-Unsubscribe=One-Click。結果として生じるオプトアウトは 2日以内 に処理します — この期限は要件の一部であり、礼儀ではありません。本文中に見える配信停止リンクではこれを満たせません。プロバイダーが確認するのはヘッダーです。
1通のコールドメッセージも送る前に、ドメインをウォームアップします。 真新しいドメインにはレピュテーションがなく、プロバイダーは未知のドメインからの突然の量をスパム信号として扱います。自動ウォームアップ（Smartlead、Instantly、専用のウォームアップツールがこれを行います）を最低でも3〜4週間走らせます。受信箱ごとに1日あたり約5〜10通から 25〜30通へと引き上げ、1日で量を約20〜30% を超えて増やさないでください。本番稼働後も軽いウォームアップを走らせ続けます。
定常状態の量に上限を設け、苦情率を監視します。 ウォームアップ後は、各受信箱を1日あたり約50通のコールド送信に抑えます — 現場のデータは、単一の受信箱でそれを超えると到達性が劣化することを一貫して示しています。効いてくる硬い上限はスパム苦情率です。Google のしきい値は 0.3% ですが、0.1% 未満に留めたいところです。0.3% では Gmail はあなたをフィルタし始めます。0.1 と 0.3 の差は安全余裕であって、目標ではありません。
プロバイダー側から、毎週監視します。 Google Postmaster Tools と Microsoft SNDS のスパム率とドメインレピュテーションのダッシュボードを確認します。これらはプロバイダーが見ているものを示し、それが唯一意味を持つ採点です。レピュテーションが下がったら、押し切るのではなく、すぐに量を削ります。

成功基準

Google Postmaster Tools がドメインレピュテーション「High」または「Medium」、スパム率 0.1% 未満を示す。
新規の Gmail、Yahoo、Outlook アドレスへのテスト送信が、プロモーションや迷惑メールではなくメイン受信箱に届く。
DMARC 集計レポートが、正当なメールの 100% が SPF または DKIM のアラインメントを通過していることを示す。
バウンスログに 550 5.7.515 の拒否が出ていない（このコードは、認証されていないメールを Microsoft が拒否しているものです）。

よくある落とし穴

「正当に見せる」ために主ドメインから送る。 1回のスパムトラップ命中や苦情の急増が、請求書やサポート返信も含め、会社全体が送っているドメインのレピュテーションを沈めかねません。

ガード: すべてのコールドアウトリーチをセカンダリドメインに隔離します。それらを使い捨てのインフラとして扱います。

ウォームアップを形式と見なし、速く上げすぎる。 2週間前のドメインから初日に 200通を送るのは、ブロックリストへの最速ルートであり、焼けたドメインはめったに回復しません — 交換することになります。

ガード: ランプは記憶ではなくツールで強制します。1日の増加に上限を設け、プラットフォームに抑えさせます。

苦情率ではなく量に最適化する。 受信箱ごとの上限を超えた送信は、いったんスパムフォルダに落ちれば商談を増やしません。あなたに付いて回る苦情を増やすだけです。

ガード: 量を伸ばすには受信箱とドメインを増やします。送信数より前に、苦情率を主要な健全性指標として追跡します。

DMARC を p=none にして、決して先へ進まない。 p=none は大量送信者のバーは越えますが、ドメインをなりすまし可能なまま残し、時間とともにレピュテーションを蝕みます。

ガード: 集計レポートで正当な送信者がすべて通過していると確認したら、1か月以内に p=quarantine または p=reject へ移行します。

エスカレーションのタイミング

きれいなウォームアップと正しい認証の後もレピュテーションが「Low」のままなら、問題はたいていリストの品質です — バウンスや苦情を起こすアドレスに送っています。送信を止め、リストを検証にかけ、ロールアカウントとキャッチオールを除いてから再開します。DNS レコードが検証を通った後も 550 5.7.515 の拒否が続くなら、アラインメントが壊れています。From ドメインが DKIM 署名ドメインと一致していません。次のバッチを送る前に、アラインメントを直します。

How to Keep Cold Email Out of Spam in 2026

前提条件

手順

成功基準

よくある落とし穴

エスカレーションのタイミング

関連