メールが迷惑メールに入るのを防ぐ修正順序

送信ボタンを押すと、サーバーから 250 OK が返されます。これで届いたと思うでしょう。しかし二週間後、重要な提案書が迷惑メールフォルダーに放置されていたことや、受信者がログインする前にゲートウェイフィルターによって通知なく削除されていたことが分かります。メールが迷惑メールに入るのを防ぐには、簡単そうな項目からではなく、正しい問題を正しい順番で修正する必要があります。

メールが迷惑メールに入るのを防ごうとする送信者の多くは、着手する場所を間違えています。件名を書き換え、テンプレートを作り直すことに何時間も費やし、表面的な変更で解決しようとします。その一方で、SPF レコードの PermError により、何か月も認証が失敗し続けていることがあります。入口の問題を最初に直さない限り、ほかの変更は役に立ちません。

2024 年二月以降、Google、Yahoo、Microsoft は厳しい技術要件を適用するようになりました。Google の一括送信者基準である一日約 5,000 通を一度でも超えると、その後も一括送信者として扱われる可能性があります。厳格な要件への準拠は、配信を維持するための重要な条件です。猶予期間は終わりました。

受信側がドメインをどのように評価するかについては、メール送信者のレピュテーションシグナルのガイドをご覧ください。この記事では、優先順位を付けた修正チェックリストを紹介します。上から順に進めてください。

迷惑メールを防ぐうえで修正順序が重要な理由

メールが迷惑メールに入るのを効率よく防ぐには、何より先に認証を修正する必要があります。受信側は接続レイヤーで認証を評価します。これは本文を読む前、苦情率を考慮する前、送信量を評価する前です。SPF、DKIM、DMARC のいずれかに問題があれば、最初の関門を通過できないため、この一覧の下位項目は意味を持ちません。

• 認証は入口です。
• アライメントは鍵が錠に合うかどうかです。
• バウンス率と苦情率は建物内での評判です。
• コンテンツは中に入ってから対処する例外的な問題です。

各修正が意味を持つのは、その上にある問題を解決した後です。

修正 1：SPF、DKIM、DMARC の認証

認証は、メールが迷惑メールに入るのを防ぐための必須の第一歩です。SPF、DKIM、DMARC の三つをすべて正しく組み合わせて設定する必要があります。これらがなければ、大手プロバイダーはメールを最初から不審なものとして扱う可能性があります。IP をウォームアップし、リストをきれいに保ち、完璧な本文を用意しても、入口でブロックされることがあります。

SPF (Sender Policy Framework)

SPF は、特定の IP アドレスにドメインからのメール送信を許可する DNS TXT レコードです。受信サーバーは DNS を確認し、接続元の IP が記載されているかを検証します。記載されていなければ SPF は失敗します。手順については、SPF レコード設定ガイドをご覧ください。

10 回というルックアップ上限の落とし穴。RFC 7208 では、一レコードあたりの SPF 評価が DNS ルックアップ 10 回までに厳しく制限されています。各 include:、a、mx、exists メカニズムがカウントされ、各 include 内のネストされたルックアップも含まれます。Google、Mailchimp、Zendesk、CRM を追加すれば、10 回を簡単に超えます。受信側は PermError を返し、SPF レコード全体を無効として扱います。構文が正しく見えても、すべてのメールで認証が失敗する可能性があります。

v=spf1 include:_spf.google.com include:sendgrid.net ~all

dig txt yourdomain.com +short でレコードを確認してください。使っていないサービスを削除し、include は必要最小限にします。

DKIM (DomainKeys Identified Mail)

DKIM はメールヘッダーに暗号署名を追加し、転送中にメッセージが改変されていないことを証明します。サーバーが秘密鍵でヘッダーに署名し、受信側は DNS にある公開鍵を使って検証します。

Google は最低 1024 ビットの鍵を必須とし、2048 ビットを強く推奨しています。旧式の 512 ビット鍵は安全でないと見なされ、拒否の原因になる可能性があります。今すぐ 2048 ビット RSA に切り替えてください。DNS プロバイダーが長い TXT 文字列を切り詰める場合は、レコード内で鍵を引用符付きの二つの文字列に分割します。

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC はポリシーレイヤーです。SPF または DKIM が失敗したときの処理を受信側に伝えます。p=none のままにするのは監視専用モードであり、なりすましを防ぐ効果はありません。p=quarantine（迷惑メールに振り分ける）に移行し、最終的には p=reject（受信を拒否する）に進めます。

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@yourdomain.com

rua タグは集計レポートを受信トレイに送ります。毎週確認してください。誰がドメインを使って送信しているか、どこで認証が失敗しているかを正確に把握できます。

修正 2：DMARC が失敗する見えにくい理由、アライメント

認証が正しく見えてもメールが迷惑メールに入り続ける場合、アライメントの設定ミスがよくある原因です。DMARC では、表示される "From" ヘッダーのドメインが、SPF または DKIM 認証に使うドメインと一致する必要があります。ESP 経由で送信すると、標準設定ではこれらのドメインが一致しないことが多く、SPF と DKIM が個別に成功しても DMARC は失敗する可能性があります。

例（標準的な ESP 設定）：
From ヘッダー：newsletter@yourcompany.com
Return-Path（SPF ドメイン）：bounce-mc.mailchimp.com
DKIM 署名：d=mailchimp.com

SPF は成功。DKIM も成功。どちらのドメインも yourcompany.com と一致しないため、DMARC は失敗。

修正方法：ESP の設定で Custom Domain Authentication を有効にします。これは "Whitelabeling" と呼ばれることもあります。これにより、ESP は Return-Path に自社ドメインのサブドメインを使うか、d=yourcompany.com で DKIM 署名を行います。アライメントが整えば、DMARC は成功します。認証はすでに動作していると思い込んでいた多くの送信者にとって、この変更だけでも迷惑メールへの振り分けを大きく減らせる可能性があります。

修正 3：リスト管理とハードバウンス 2% ルール

ハードバウンス（SMTP 5xx エラー）は、リストが古い、購入された、または収集されたものだと受信側に判断される要因になります。リスト品質が原因でメールが迷惑メールに入るのを防ぐには、ハードバウンスしたアドレスを直ちに抑止し、二度と送信しないでください。ハードバウンス率は 2% 未満に保ちます。5% に達すると、ESP がアカウントを停止する可能性があります。

6+ か月送信していないリストは、送信前に ZeroBounce や Bouncer などの検証ツールにかけてください。古いリストが今もきれいだとは考えないでください。無効になったアドレスは、メールが迷惑メールに入るのを防げない一般的な原因です。

修正 4：苦情率と 0.3% の境界線

迷惑メールへの振り分けを防ぐうえで、迷惑メール苦情率は特に危険な指標です。Google と Yahoo は 0.3% という厳しい基準を設けています。わずか 3 件の苦情が 1,000 通に占める割合です。この基準を超えるとブロックされる可能性があり、何か月もかけて積み上げたほぼすべての良いシグナルを上回ることがあります。

Yahoo の計算方法には、想像以上に注意が必要です。Yahoo は総送信数ではなく、受信トレイに届いたメール数を基準に苦情率を算出します。迷惑メールに入ったのが 900 通、総送信数が 1,000 通で、苦情を出した人が 1 人、受信トレイに届いたのが 100 通なら、苦情率は 1.0% です。問題に気付く前から、上限の三倍になっています。

一括送信者にはワンクリック購読解除が必須です。List-Unsubscribe-Post: List-Unsubscribe=One-Click ヘッダーを追加してください。一回で購読解除できなければ、利用者は代わりに迷惑メールとして報告しやすくなります。一件の苦情は、一件の購読解除より大きな損失になります。

Google Postmaster Tools で Gmail の実際の迷惑メール率を監視してください。Gmail がドメインをどう見ているかを確認できる公式情報です。問題が起きたときだけではなく、毎週確認します。

修正 5：送信量を平準化し、急増を避ける

送信量の急増は、アカウントが侵害されたように見えます。メールが迷惑メールに入るのを防ぐには、急増によって問題が迷惑メールへの振り分けだけでなく、完全なブロックに発展し得ることを理解してください。29 日間何も送らず、突然 50,000 通を一斉送信した日が 30 日目なら、Microsoft が 421 RP-001（レピュテーション制限）を返し、直ちに流量を制限する可能性があります。

新しい IP を使いますか。厳格なウォームアップ計画に従い、まず 50 通を 1 日目の量とし、次に 100 通を 2 日目の量として、その後は段階的に倍増させます。大規模なキャンペーンは 24 から 48 時間に分散してください。30 日を超えて送信を止めると IP レピュテーションが低下します。新しい IP と同様に扱い、最初から再びウォームアップします。一貫性自体が到達性のシグナルであり、不規則な送信は迷惑メールへの振り分けを防ぎにくくします。

修正 6：リンクとドメインのレピュテーション

認証が完璧でも、本文からブロックリスト掲載ドメインへリンクしていれば、メールはフィルタリングされる可能性があります。侵害されたドメインにリンクしている場合、認証を直しても解決しません。受信側はメッセージ内のすべての URL を Spamhaus DBL や SURBL などのブロックリストと照合します。一つの不良リンクで、それ以外は健全な送信全体が失敗することもあります。

bit.ly や tinyurl などの公開 URL 短縮サービスは使わないでください。マルウェアキャンペーンに悪用されることが多く、頻繁にブロックリストへ登録されます。追跡リンクには自社ドメインを使います。また、送信 IP にホスト名へ逆引きできる PTR レコードがあり、そのホスト名を正引きすると同じ IP に戻ることも確認してください（FCrDNS）。自前で構築したベアメタル VPS では、この設定が通知なく失敗し、明確なエラーコードがないまま配信を妨げることがあります。

修正 7：コンテンツは最初ではなく最後

2026 年において、いわゆる "迷惑メールのトリガー語" の多くは俗説です。現在の受信側はキーワード一覧ではなく、エンゲージメントシグナルで学習した ML モデルを使います。コンテンツだけで、迷惑メールへの振り分けを説明できることはほとんどありません。ここから始めても、実際の障害は上流にあるため問題を解消できません。"Buy Now" を "Get Started" に変えても、レピュテーションの問題は直りません。ただし、コンテンツの技術的な不備は今も重要です。画像が 100% でテキストのないメールはフィッシングのように見え、壊れた HTML はフィルターに検出されることがあります。テンプレートを適切に保ち、プレーンテキストの MIME 版を含めれば、この項目は完了です。

迷惑メールを防ぐために 3 つだけ実行するなら

三つの修正で、到達性問題のおよそ 80% を解決できます。どこから始めればよいか迷ったら、ここから着手してください。一覧のほかの項目をすべて合わせた場合と比べても、迷惑メールへの振り分け防止に大きく貢献します。

1. DMARC を p=quarantine または p=reject で適用する。正規の運用者であることを受信側へ示し、ブランドをなりすましから守ります。
2. 苦情率 0.1% の線を監視する。迷惑メール苦情率を 0.1% 未満に保ちます。0.2% に達したら、すべてのマーケティング送信を止め、次回の送信前に調査してください。
3. ハードバウンスを自動的に除外する。最初の失敗後もハードバウンス先をリストに残さないでください。ESP レベルで抑止を自動化します。

時間を無駄にする対策（効果のない俗説）

次の対策では、メールが迷惑メールに入るのを防げません。時間をかけるのはやめましょう。

• 件名に使う魔法の言葉。"Free" を "Complimentary" に変えても認証の問題は直りません。迷惑メールフィルターは ML を基盤にしています。
• "From" 名の変更。bob@company.com から sara@company.com に変えても、何もリセットされません。レピュテーションは company.com に残ります。
• きれいだと称するリストの購入。そのようなものはありません。購入リストには多数のスパムトラップが含まれます。購入リストへ一回キャンペーンを送るだけで、ドメインレピュテーションが長期的に損なわれる可能性があります。回復できる場合でも数か月かかる種類の損害です。

修正が機能していることを確認する方法

推測せず、測定してください。変更後は、ローカル DNS だけでなく、外部からも各修正を確認できることを検証します。

ステップ 1：Gmail でヘッダーを確認

Gmail アカウントに送信します。メールを開き、三点メニューをクリックして "メッセージのソースを表示" を選択します。次の項目を探してください。

SPF: PASS with IP [Your IP]
DKIM: PASS with domain [Your Domain]
DMARC: PASS

FAIL または SOFTFAIL が一つでもあれば、設定に問題があります。修正してから送信を再開してください。

ステップ 2：DNS を直接確認

# Check SPF (look for v=spf1)
dig txt yourdomain.com +short

# Check DMARC (look for p=quarantine or p=reject)
dig txt _dmarc.yourdomain.com +short

ステップ 3：シードテストを使用

GlockApps や Mail-Tester などのツールでは、シードリストへ送信し、実際のキャンペーンを始める前に、複数のプロバイダーで受信トレイと迷惑メールのどちらへ届くかを確認できます。大規模送信の前に毎回使用し、変更によって迷惑メールへの振り分けを実際に減らせるか検証してください。

インフラの問題（そして、より速い解決方法）

率直に言えば、SPF の修正、DKIM 鍵のローテーション、DMARC アライメントの適用、IP のウォームアップは継続的な作業です。一つのドメインなら管理できますが、五十社の顧客向けに五十個のドメインを扱うとなれば、まったく別の仕事です。

TrekMail はその運用負担を減らします。組み込みの SPF/DKIM/DMARC 設定ウィザードが、問題になる前に設定ミスを指摘します。すべてのドメインのレコードを一つのダッシュボードで管理できるため、DNS の設定ミスによる迷惑メールへの振り分けを防ぎやすくなり、TLS も自動的に適用されます。顧客や事業部門向けに複数ドメインの環境を運用している場合は、複数ドメインのメールホスティングガイドで実際の構成をご確認ください。

BYO SMTP の利点。多くのプロバイダーでは共有 IP プールを使う必要があります。同じプールの利用者が迷惑メールを送れば、自分も影響を受けます。TrekMail の BYO SMTP では、Amazon SES、SendGrid、Mailgun をアカウントへ直接接続できます。TrekMail の複数ドメインホスティングが持つコスト上の利点と、自分で管理する専用送信サービスの到達性を組み合わせられます。IP のレピュテーションが損なわれた場合は、API キーを交換します。メールボックスを移行する必要も、サポートチケットを作る必要もありません。約 60 秒で再開できます。

メールが迷惑メールに入るのを防ぐには、実際に効果のある項目から始める

メールが迷惑メールに入るのを長期的に防ぐ戦略は、修正順序そのものです。認証が最初、アライメントが二番目、バウンスと苦情の管理が三番目、コンテンツは最後です。迷惑メールフィルターと戦い続ける送信者は、多くの場合、この一覧を逆から進めています。DMARC ポリシーの不備や DKIM 署名の不一致で毎回の送信が失敗しているのに、テンプレートばかり調整しています。

認証レイヤーを正しく設定すれば、問題の大半は解決します。件名、送信時間、テンプレートデザインなど、ほかの最適化が意味を持つのは、最初の関門を安定して通過できるようになってからです。

TrekMail がインフラレイヤーを処理するため、深夜に DNS をデバッグする必要がなくなります。無料プランはずっと無料です。カードは不要で、試用期間のカウントダウンもなく、10 ドメインが含まれます。有料プランは月額 $3.50 の Starter からで、管理 SMTP、50 ドメイン、完全な DKIM/DMARC ウィザードが含まれます。プランを比較して無料で始める →