email-deliverability-audit

メール配信到達性監査

返信率が低下していて原因がわからない場合は、まずここから始めてください。 ほとんどの場合、問題は配信到達性です。メールが受信トレイに届いていません。このスキルで問題の内容を特定できます。

チェック項目

レイヤー	内容	方法
DNS 認証	送信ドメインごとに SPF、DKIM、DMARC が設定されているか	dig コマンド
受信トレイの状態	ウォームアップ状況、レピュテーション、ブロック、接続失敗	Smartlead email-accounts API
送信量の状態	1日あたりの送信数の推移、容量の利用率	Smartlead analytics
受信トレイごとの送信数と返信率	振り返り期間中の送信数、返信数、返信率（%）	Smartlead campaign analytics
バウンス率	過去30日間の受信トレイごと、ドメインごとのバウンス率	Smartlead campaign analytics
迷惑メールフォルダーへの振り分け	Smartlead Smart Delivery による実際の受信トレイ対迷惑メールテスト	任意

1%ルール — そして判定の基準となる下限

健全なドメインは、200通送信後に1%以上の返信率を維持します。 十分なサンプルで1%を下回る場合、 何かが壊れています。その状態が続けば、ドメインは停止されます。

1%ルールはひとつの数値です。ここでドメインにフラグを立てる1%は、/inbox-lifecycle-managerでドメインを停止する基準と同じです。「フラグ」と「停止」を分けるのは、より緩やかな第2の基準ではなく、 下限です。下限に達していない場合、答えは「まだわからない」です。これは失敗ではなく、正当な判定結果です。

判定	判定に必要な下限
返信率	期間内に200件の送信
バウンス率	50件の送信
バウンスの内訳（どの分類か）	そのドメインについて30件の分類済みバウンス
停止の判断	ドメインの使用開始から30日。使用開始日が不明な場合は、使用期間が短いものとして扱う
配信テスト	テストごとに送信者100〜300件

14件の送信に対する「返信率0.00%」を失敗と報告したり、ウォームアップが終わっていない使用開始から3週間のドメインを不適切と判断したりすることで、健全なドメインが停止されてしまいます。

返信率（送信数200件以上）	判定
≥ 1.5%	十分に良好です。そのままにしてください。
1.0 - 1.5%	健全です。基準をクリアしています。
< 1.0%	消耗しています。/inbox-lifecycle-managerに引き継ぎます。ただし、送信数200件と使用開始から30日の下限も満たしている場合に限ります。
送信数150件以上で返信0件	明白な結果です。返信が完全に0件の場合は、低くても0ではない返信率より少ないサンプルで判定できます。

ドメインが基準を下回る場合に考えられる原因（監査では根本原因の候補を提示し、特定を試みます）：

• メールが迷惑メールフォルダーに届いている — 迷惑メール振り分けテストを実施する
• ドメインのレピュテーションが損なわれている — DMARC レポートとバウンスコードを確認する
• メール文面に問題がある — /spam-word-checkerを再実行し、対照フリートでの配信テストで確認する
• リストがコールド、またはICPに合っていない — バウンス率を確認する。3%を超える場合、問題はドメインではなくリストにあります
• 受信トレイのウォームアップが不十分 — ウォームアップ状況とドメインの使用期間を確認する

ドメインとメール文面を切り分けるテスト

配信率が低いだけでは、ドメインが消耗しているのか、メール文面に問題があるのかはわかりません。同じ文面を、正常な対照フリートから送信してください。

使用中のフリート	対照フリート	判定
< 100%	~100%	ドメイン側の問題です。 送信インフラが原因です。
< 100%	< 100%	メール文面です。 ドメインをひとつでも交換する前に、文面を書き直してください。
≥ 85%	≥ 85%	どちらでもありません。インフラは正常です。ターゲティングまたはオファーが原因です。
対照フリートをテストできない	—	メール文面が原因だと仮定します。修正のほうが低コストで、元に戻すこともできます。

使用する場面

• 週次で返信率が30%超低下した場合 → 完全な監査を実施する
• バウンス率が2%を超えて急増した場合 → 認証と迷惑メール振り分けをチェックする
• キャンペーンを拡大する前（インフラの準備が整っているか確認する）
• 定期的な衛生管理として毎月
• 自分で設定していないSmartleadアカウントを引き継ぐ場合

入力

• SMARTLEAD_API_KEY（環境変数）
• 任意：監査対象を指定する
  • --client-id=X（サブクライアント用）
  • --campaign-id=X（1つのキャンペーンの受信トレイのみを監査）
  • --domain=example.com（1つのドメインのみを監査）
  • --tag=active（activeタグが付いた受信トレイのみを監査）

手順

1. 受信トレイの一覧を取得する

npx tsx scripts/audit-inboxes.ts --all --out=/tmp/audit/inboxes.csv

受信トレイごとの出力：id、email、domain、warmup_status、reputation、max_warmup/day、sent_today、smtp_ok、imap_ok、is_blocked、tags。

2. ドメイン認証を確認する

npx tsx scripts/check-domain-auth.ts --from-csv=/tmp/audit/inboxes.csv --out=/tmp/audit/auth.csv

一意のドメインごとに、次を実行します。

dig TXT <domain> +short                             # SPF
dig TXT _dmarc.<domain> +short                      # DMARC

# DKIM has NO single selector. Present if ANY of these resolves:
dig TXT   google._domainkey.<domain>    +short      # Google / Gmail-backed — the common one
dig CNAME selector1._domainkey.<domain> +short      # Microsoft 365 — a CNAME, TXT returns nothing
dig CNAME selector2._domainkey.<domain> +short      # Microsoft 365, second key
dig TXT   default._domainkey.<domain>   +short      # generic fallback, frequently empty

⛔ default._domainkey だけを確認しないでください。 実際のフリートの多くでは空になっており、default だけを確認すると、すべてのドメインが「DKIM が見つからない」と報告されます。その結果、本当に問題があるドメインに「DNS を修正してください」と案内され、すでに存在するレコードを再公開するために 1 週間を無駄にすることになります。このスクリプトは 4 つすべてを試し、解決されたものを報告します。

出力：domain、spf_present、spf_strict、dkim_present、dmarc_present、dmarc_policy（none/quarantine/reject）。

3. キャンペーン／受信トレイごとの送信・返信・バウンスの指標を取得する

npx tsx scripts/audit-performance.ts --days=30 --out=/tmp/audit/performance.csv

アクティブなすべてのキャンペーンを確認し、過去 30 日間の受信トレイごとの分析データを取得します。出力列：inbox_id, email, domain, type, tags, sent, replies, bounces, reply_rate_pct, bounce_rate_pct, flag_low_reply, flag_high_bounce。

次の場合に自動でフラグが付きます：

• flag_low_reply = TRUE：送信数が 200 以上で、reply_rate_pct が 1.0 未満（1% ルール）
• flag_high_bounce = TRUE：送信数が 50 以上で、bounce_rate_pct が 3.0 を超える

4. （任意）Smart Delivery のスパム振り分けテストを実行する

npx tsx scripts/run-spam-test.ts --campaign-id=12345 --senders=100 --out=/tmp/audit/spam-test.json

Smartlead の Smart Delivery API を使用して、実際の受信トレイ振り分けテストを実行します：

• 利用可能なプロバイダープールのみを使用します：G Suite + Office365（provider_ids 20, 21）
• 100 個の送信元から、約 200 個のシードメールボックスに送信します
• 完了まで待機します（5～20 分）
• providerwise、spam-filter-details、dkim-details、spf-details、blacklist を取得します

出力には、受信トレイ、スパム、プロモーションのそれぞれに届いた割合が、送信元と受信側プロバイダー別に表示されます。これが実際の状況を示すデータです。

5. レポートをまとめる

3 つの CSV（inboxes.csv、auth.csv、performance.csv）に加え、実行した場合はスパムテストの JSON を読み、この形式に沿って手作業でレポートを作成します。生成スクリプトはありません。結果の取りまとめは判断が求められる作業であり、以下がレポートのテンプレートです：

# Deliverability Audit — 2026-04-17

## Summary

- 80 inboxes audited across 40 domains
- 3 inboxes blocked (4% of fleet)
- 5 domains missing DKIM
- 2 domains with DMARC policy=none (no enforcement)
- Fleet performance (last 30d):
    Sent:           42,384
    Replies:          523
    Overall reply rate: 1.23% (PASS — above 1% threshold)
    Bounces:           382
    Bounce rate:      0.90% (PASS — below 2%)
- 4 inboxes failed the 1% rule (sent ≥200, reply rate <1%)
- Spam placement (test run): 83% inbox / 14% spam / 3% tabs (ACCEPTABLE but not great)

## Critical issues (fix within 24h)

1. Domain trygrowth.co has no DMARC record. Add: v=DMARC1; p=none; rua=mailto:[email protected]
2. Inbox [email protected] blocked in warmup — likely flagged by warmup network. Rotate out of campaigns.
3. 12 inboxes have 0 daily sent today despite being in active campaigns. Check campaign schedule.
4. Inbox [email protected] failed the 1% rule: 347 sent, 1 reply (0.29% reply rate). Investigate:
   - Check spam placement for this inbox
   - Compare copy vs. a sibling inbox that's passing
   - Rotate inbox out if bad reputation is confirmed

## Warnings (fix within 1 week)

- 5 domains missing DKIM record at default._domainkey
- 3 inboxes reputation dropped "fair" → "bad"
- Spam filter trigger DKIM_INVALID firing 8% of the time — likely for a subset of domains

## Action items (prioritized)

1. [HIGH] Add missing DKIM records to: trygrowth.co, othergrow.co, ...
2. [HIGH] Rotate out blocked inboxes: [email protected], [email protected], ...
3. [MED] Tighten DMARC to p=quarantine on all domains after 2 weeks of p=none observation
4. [MED] Replace 3 bad-reputation inboxes (tag them "retired", provision new)
5. [LOW] Re-run spam placement test after fixing DKIM issues

6. アクション項目に対応する

アクション項目を適切なスキルに渡します：

• DKIM／SPF が見つからない → /zapmail-domain-setup-public で Zapmail 経由でドメインを再接続する
• ブロックされた受信トレイ → /smartlead-inbox-manager で「retired」タグを付け、予備の受信トレイに切り替える
• キャンペーンのスケジュールに関する問題 → Smartlead のキャンペーンスケジュール設定
• 問題のあるコピーにフラグが付いた → キャンペーンのコピーに対して /spam-word-checker を実行する

数値の解釈

バウンス率

• <1% — 優秀です。リストは健全です。
• 1-2% — コールドメールでは通常の範囲です。対応は不要です。
• 2-3% — 要注意です。リストの品質を確認してください。古いメールアドレスが含まれている可能性があります。
• >3% — 危険です。リストを検証（MillionVerifier）し、一時停止を検討してください。
• >5% — 直ちに停止してください。ドメインのレピュテーションを損なっています。

スパム振り分け

• 受信トレイ >90% — 良好です。送信を増やしましょう。
• 受信トレイ 85-90% — 健全です。ドメインを優良と判断するためにクリアすべき基準です。
• 受信トレイ 70-84% — 劣化しています。spam-filter-details を確認して、何が原因になっているかを調べてください。
• 受信トレイ <70% — 危険であり、厳格な基準です。このドメインをキャンペーンに追加しないでください。一時停止し、さらに送信する前に認証とコピーを修正してください。

100～300 個の送信元でテストしてください。サンプル数が少ないと、実行ごとに結果が 10 ポイント以上変動します。

DMARC ポリシー

• None — ドメイン運用開始から最初の 2 週間は許容されます。それ以降は、より厳格にしてください。
• Quarantine — 長期的に推奨されます。認証に失敗したメールはスパムに振り分けられます。
• Reject — 最も厳格です。すべての正規メールが認証を通過していることを確認する rua= レポートを 30 日以上問題なく確認した後にのみ使用してください。

ウォームアップ時の評価

• Smartlead は評価を 0～100 で報告します。数値が高いほど良好です。
• 98％以上 — 予備受信トレイを稼働中のキャンペーンに昇格させる前に必要です。
• 80～98％ — 送信しても問題ありませんが、この評価の段階では新しい予備受信トレイを昇格させないでください。
• 50～80％ — ウォームアップを続け、重要な送信には使用しないでください。
• 50％未満 — この受信トレイから送信しないでください。ウォームアップの相手が受信トレイでメールを確認できていません。

⚠️ ウォームアップがオフの場合、評価がゼロという意味ではなく、読み取り結果がないということです。 ウォームアップがオフの受信トレイからは何も報告されないため、評価できません。保留として扱ってください。つまり、稼働可能数に含めず、キャンペーンに紐付けず、人による確認対象として報告します。数値を表示させるために、ウォームアップを黙って再びオンにしないでください。測定しようとしているシグナルを書き換えることになります。

よくある根本原因

• SPF の設定が緩すぎる — v=spf1 +all は全員を許可リストに登録します。v=spf1 include:zapmail.com ~all などを使用してください。
• DKIM が未設定 — 新しいドメインで、セレクターが公開されていません。Zapmail はデフォルトで default._domainkey に公開します。
• DMARC のアライメント失敗 — From ドメインが SPF／DKIM のドメインと一致していません。通常、返信先の設定ミス、またはサードパーティーの送信者が原因です。
• ドメインあたりの受信トレイが多すぎる — Gmail は、受信トレイが 3～5 個を超えるドメインを不審と判断します。ドメインあたり 2 個に抑えてください。
• 若すぎる、または送信が少なすぎるドメインを評価している — 作成から 30 日未満、または送信数が 200 件未満の場合、数値からドメインの評判が損なわれているのか、運の悪い週だったのかを見分けられません。これは根本原因ではなく、証拠がない状態です。そして、健全なドメインが停止される最もよくある原因です。
• ウォームアップのペースが急すぎる — 1 週間で 1 日あたり 5 件から 40 件に増やすと、フラグが立ちます。2～4 週間かけて増やしてください。
• スパム送信に使われている共有送信 IP — Zapmail を含むほとんどのプロバイダーは共有プールを使用します。同じ IP を使う誰かがスパムを送信すると、影響を受けます。プールがローテーションされるのを待つ以外に、できることはあまりありません。

次にすること

フラグが 1 つでも立った場合： /deliverability-incident-response → フラグが立った項目（返信率の低さ、高いバウンス率、ブロックされた受信トレイなど）に応じたトリアージの判断ツリーを確認します。

ドメインの評判が損なわれていると確認された場合： /inbox-lifecycle-manager → 送信数不足を招くキャンセルを防ぐガードを適用したうえで、キャンセル、昇格、購入の判断を行います。

すべて問題ない場合： 次の月曜日に、もう一度実行してください。この監査は /cold-email-weekly-rhythm にある月曜日のタスクです。

または、待機してください： 修正を適用したばかりの場合は、7 日待ってから再監査してください。評価の変化が反映されるまでには時間がかかります。

関連スキル

• /smartlead-inbox-manager — アクション項目を実行します（ローテーション、タグの付け直し、ウォームアップ設定）
• /zapmail-domain-setup-public — ドメインプロバイダー側の DNS／認証の問題を修正します
• /spam-word-checker — スパムを誘発する表現がないか、文面を確認します
• /deliverability-test-public — SMTP、Gmail、Outlook 間の返信／バウンスを簡易比較します
• /inbox-lifecycle-manager — 判定に基づいて、キャンセル、予備受信トレイの昇格、購入計画を実行します

スクリプト

• scripts/audit-inboxes.ts — 受信トレイ一覧を取得して整形します
• scripts/check-domain-auth.ts — dig ベースで SPF／DKIM／DMARC を確認します
• scripts/audit-performance.ts — キャンペーン分析から受信トレイごとの送信数／返信数／バウンス数／各率を取得します（1％ルールを適用）
• scripts/run-spam-test.ts — Smart Delivery テストを作成し、ポーリングして結果を取得します

参考資料

• references/dns-records.md — SPF／DKIM／DMARC レコードのテンプレートと解釈ガイド