2026 年のメール到達率 — 標準仕様、ウォームアップ、フィードバックループ。

§1 · 定義

メール到達率とは何か。

到達率とは、送信したメッセージが受信者のメインの受信箱に届く比率のことであり、配信（受信側メールサーバーが受け入れた）や送信（送信パイプラインに渡した）とは区別されます。メッセージが正常に送信され、受信側メールサーバーに配信されたうえで迷惑メールフォルダに入った場合、配信は成功でも到達は失敗です。重要視される指標 — 開封率、クリック率、コンバージョン — は配信ではなく到達率に依存します。

メールボックスプロバイダー — Gmail、Outlook、Yahoo、Apple iCloud Mail、Proton、主要な地域プロバイダー — はいずれも、受信するすべてのメッセージに対して多段階のスコアリングパイプラインを実行します。各段階はプロバイダー間でほぼ共通しており、重み付けが異なるだけです。

1. 接続時チェック。逆引き DNS、HELO/EHLO の整合性、TLS サポート、RBL（Spamhaus、SpamCop など）への IP 掲載状況。
2. 認証チェック。SPF の合否（RFC 7208）、DKIM 署名の検証（RFC 6376）、DMARC アライメント（RFC 7489）。最も寛容な下流スコアリングを得るには 3 つすべてがクリーンに合格する必要があります。
3. コンテンツスコアリング。スパムキーワードの密度、リンクのレピュテーション、画像とテキストの比率、From 名と From アドレスの一致性。
4. レピュテーション参照。プロバイダーが内部で保持する送信 IP および From ドメインの履歴 — 過去のバウンス率、苦情率、過去配信時のエンゲージメント。
5. エンゲージメントシグナル。受信者本人（または同コホート内の受信者）が過去に類似メッセージを開封・クリックしたか。直近のエンゲージメントは単一指標として最も強力なポジティブシグナルです。
6. 最終振り分け。受信トレイ、プロモーションタブ（Gmail）、迷惑メールフォルダ、または拒否。この結果がレピュテーションに再びフィードバックされます。

以下の 5 セクションは、ステージ 2（認証）とステージ 4（レピュテーション）を扱います。ステージ 1 は主に送信リレー側の責務であり、ステージ 3 と 5 はコンテンツおよびオーディエンスに関する判断で、到達率ガイドの範囲外です。ステージ 6 は出力に当たります。一般的な商用送信者の場合、ステージ 2 と 4 を正しく設定するだけで受信トレイ到達率は 60〜80% から 95% 以上へと改善します。

本ガイドは、各種パラメーターを自らチューニングする立場にあるセルフホスト運用者を対象に書かれています。SaaS ではプラットフォームがこれらの大部分を抽象化しますが、セルフホストでは SPF レコード、DKIM 鍵ペア、DMARC ポリシー、IP ウォームアップスケジュールのすべてを自分で管理します。良いニュースは、標準仕様は公開済みかつ安定していることです。悪いニュースは、近道は存在しないことです。

§2 · SPF

SPF — Sender Policy Framework。

SPF（RFC 7208）は、自社ドメインを名乗ってメールを送信する権限を持つ IP アドレスの公開リストです。送信ドメインの単一の TXT レコードとして公開します。メールボックスプロバイダーは @yourcompany.com を名乗るメッセージを受信すると、yourcompany.com の SPF レコードを参照し「このメッセージはリストされた IP のいずれかから来たか？」と確認します。Yes なら SPF 合格、No なら不合格です。

構文

v=spf1 include:amazonses.com ~all

読み方は「SPF バージョン 1、Amazon SES が認可するものをすべて認可、それ以外はソフトフェイル」です。末尾の ~all は catch-all 句です。~all = ソフトフェイル（疑わしいとマークするが受け入れ）、-all = ハードフェイル（拒否）、?all = 中立（判断なし）。DMARC が健全になるまでは ~all を使用し、その後 -all へ引き締めます。

複数の送信元（例：アウトバウンド用の Google Workspace + マーケティング用の SES + トランザクション用の Mailgun）を使用する場合は、複数の include: メカニズムで連結します。

v=spf1 include:_spf.google.com include:amazonses.com include:mailgun.org ~all

DNS ルックアップ 10 回制限。RFC 7208 §4.6.4 では SPF 解決に必要な DNS ルックアップは合計 10 回までと定められています。各 include: は 1 回としてカウントされます。よくある失敗：5 ベンダー以上を連結して制限を超え、SPF が permerror に解決されて不合格扱いになるケース。制限に近づいている場合は dig TXT yourcompany.com と SPF フラットナーで監査してください。

AcelleMail における SPF

AcelleMail の SendingDomain モデルは app/Model/SendingDomain.php:154 で getSpf() を公開しており、グローバル設定の spf_record を読み込んで TXT レコード値を描画します。363 行目の verifySpf(string $ipOrHostname) メソッドは Mika56\SPFCheck ライブラリのラッパーで、実行時に DNS をライブで照会し RESULT_PASS を検証します。管理 UI の検証画面では、レコードが存在し送信 IP を認可していれば緑、それ以外は赤で表示されます。

実務的なヒント：SPF はエンベロープ送信者（SMTP レベルの MAIL FROM）のみを認証し、表示される From ヘッダーは認証しません。この差を埋めるのが DMARC のアライメントです — §4 を参照。

§3 · DKIM

DKIM — DomainKeys Identified Mail。

DKIM（RFC 6376）は送信する全メッセージに暗号署名を付与します。受信サーバーは DNS の TXT レコードから公開鍵を取得し、特定のメッセージヘッダーと本文に対して署名を検証し、計算が正しければ認証済みとして受け入れます。SPF は「この IP は当社の代理として送信を許可されている」と主張するのに対し、DKIM は「このメッセージの本文と From ヘッダーは署名後に改ざんされていない」と主張します。

仕組み

1. RSA 鍵ペアを生成します（最小 1024 ビット、新規セットアップでは 2048 ビット推奨）。
2. 公開鍵を {selector}._domainkey.{yourdomain} の TXT レコードとして DNS に公開します。セレクタは任意の文字列（例：k1、mail、20251208）で、配信中のメッセージを壊さずに鍵をローテーションするために自由に選べます。
3. 秘密鍵は送信サーバー側に保持します。MTA（または送信リレー）は送信する各メッセージを秘密鍵で署名し、DKIM-Signature ヘッダーを付加します。
4. 受信側メールサーバーは署名ヘッダーから d=（ドメイン）と s=（セレクタ）の値を読み取り、{s}._domainkey.{d} を照会して公開鍵を取得し、検証します。

AcelleMail における DKIM

app/Model/SendingDomain.php:221 の SendingDomain::generateDkimKeys() は PHP の OpenSSL バインディングを介して 1024 ビット RSA 鍵ペアを生成し、秘密鍵を dkim_private に、公開鍵を dkim_public に保存します。セレクタはモデルの dkim_selector から読み込まれ、未設定の場合はグローバル設定の dkim_selector にフォールバックします。DNS レコード値は $this->getDomain()->getDkimDnsRecord()（270 行目）で描画され、「公開する値」の横にコピーボタン付きで運用者に表示されます。

鍵生成のパターン（generateDkimKeys() より）：

$config = [
    'digest_alg' => 'sha256',
    'private_key_bits' => 1024,
    'private_key_type' => OPENSSL_KEYTYPE_RSA,
];
$res = openssl_pkey_new($config);
openssl_pkey_export($res, $privKey);
$pubKey = openssl_pkey_get_details($res)['key'];

検証：$this->getDomain()->verifyDkim() は {selector}._domainkey.{domain} に対して DNS を照会し、公開された公開鍵をローカルに保存されている値と比較します。モデル上の完全な verify() メソッドは、identity + DKIM + SPF + DMARC のチェックを 1 回の呼び出しで連携実行します（300 行目）。

ベンダー側で管理する DKIM

Amazon SES、SendGrid、Mailgun、その他ベンダー側で署名するサービスを使用する場合は、自前で生成する代わりにベンダーのセレクタと公開鍵を公開します。AcelleMail のドライバレベルの SignsDkimOnServer ケーパビリティ（app/SendingServers/Capabilities/SignsDkimOnServer.php を参照）は DKIM をリモートで処理するドライバを示すフラグで、UI はローカルで鍵ペアを生成する代わりにベンダーの CNAME レコードを表示します。SES は _domainkey を amazonses.com に委譲する 3 つの CNAME を使用 — 一度設定すれば、SES が背後の鍵を自動でローテーションしてくれます。

§4 · DMARC

DMARC — アライメント、ポリシー、レポーティング。

DMARC（RFC 7489）は SPF と DKIM の上に位置します。SPF や DKIM が単独では実現できない 3 つのことを行います。

1. アライメント。SPF で検証されたエンベロープドメインまたは DKIM 署名ドメインのいずれかが、表示される From ヘッダーのドメインと一致することを要求します。アライメントがないと、SPF と DKIM は受信者から見えるドメインとは異なるドメインに対して合格でき、フィッシングが悪用するのはこの隙間です。
2. ポリシー。アライメントが失敗したときに受信サーバーが取るべき動作を指示します：none（何もしない、レポートのみ）、quarantine（迷惑メールに振り分け）、reject（SMTP 段階でメッセージを拒否）。
3. レポーティング。集計レポート（RUA — 自ドメインからのすべての送信に関する日次 XML レポート）と詳細レポート（RUF — 失敗ごとの個別レポート）を指定した宛先に送信します。レポートによって、自社を名乗って送信している主体を可視化できます。

構文

_dmarc.yourcompany.com.    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com; pct=100; aspf=s; adkim=s"

読み方は「DMARC バージョン 1、アライメントに失敗したメッセージは quarantine、集計レポートを dmarc@yourcompany.com に送信、失敗メッセージの 100% にポリシーを適用、SPF と DKIM の両方で strict アライメントを要求」となります。

標準的なロールアウト

1. 0 日目：監視中のメールボックスを指す rua= を付けて p=none を公開。7〜14 日間レポートを受信します。これは観測のみのフェーズで、メッセージは拒否されません。
2. 14 日目：レポートをレビュー。正規の送信元（自社の SES、CRM の送信 IP、トランザクション系プロバイダー）を特定し、すべて SPF + DKIM アライメントに揃えます。
3. 30 日目：p=quarantine; pct=10 へ引き締め。アライメント未達のメールは受信者の 10% について迷惑メール送りになります。2 週間レポートを観察します。
4. 45 日目：pct=50、続いて pct=100 へ 2〜4 週間かけて段階的に引き上げます。
5. 60〜90 日目：p=reject へ引き締め。アライメント未達のメールは SMTP 段階でバウンス — 自社ドメインを使用するフィッシャーはハード拒否に直面します。

ロールアウトを飛ばさないでください。DMARC 未設定から一気に p=reject へ移行することは、自滅的な到達率事故の最も多い原因です — 忘れていたトランザクション送信者（CRM、サポートツール、請求システム）が p=reject 伝播の瞬間からハードバウンスを起こし始めます。

メールボックスプロバイダーの義務化

2024 年 2 月以降、Gmail と Yahoo は、自社ドメイン宛に 1 日 5,000 通超を送信するすべての送信者に対し DMARC を必須化し、加えてアライメント済みの SPF または DKIM、ワンクリック List-Unsubscribe（RFC 8058）も求めています。Microsoft 365 も執筆時点で同じ標準に揃えています。「商用送信」のハードルは恒久的に上がりました — DMARC は約 1,000 件超のリストにとって、もはや任意ではありません。リストが小さい段階でも早めに設定してください。

§5 · BIMI

BIMI — ブランドロゴのボーナス。

BIMI（Brand Indicators for Message Identification）は、受信者の受信トレイ内でメッセージ横にブランドロゴを表示します。2025 年時点で Gmail、Yahoo、Apple Mail、Fastmail がサポートしています。認証そのものではなく到達率に隣接する機能ですが、前提条件として DMARC が p=quarantine または p=reject である必要があるため、本ガイドに含めています。

セットアップ手順（DMARC が quarantine 以上に達した後）：

1. BIMI SVG Tiny PS 仕様に従ってロゴの SVG 版を作成 — 正方形、マーク外にテキストなし、シンプルなパス。
2. 公開アクセス可能な HTTPS URL で SVG をホストします。
3. オプションで CA から Verified Mark Certificate（VMC）を取得 — Gmail で青いチェックマーク付きでバッジを表示するために必須、年額約 $1,500。未登録ブランド向けには Common Mark Certificate（CMC）という安価な代替もあります。
4. BIMI レコードを公開：default._bimi.yourcompany.com TXT "v=BIMI1; l=https://yourcdn/logo.svg; a=https://yourcdn/vmc.pem"

BIMI による到達率への影響は間接的ですが測定可能です：受信トレイ内のブランドロゴは、公開されたケーススタディ（Yahoo Mail のパイロットデータ、Mailchimp の BIMI レポート）で開封率を 5〜20% 押し上げます。また強力な推進力にもなります — DMARC を強化しなければ BIMI を有効化できないため、認証クリーンアップのインセンティブとして活用するチームも多いです。

§6 · レピュテーション

レピュテーション — メールボックスプロバイダーが実際に評価する指標。

認証はバイナリです — レコードが解決してアライメントが揃うか、揃わないかのいずれかです。レピュテーションは連続値で、0 から 100 のスコアを各メールボックスプロバイダーが、送信 IP と From ドメインそれぞれに対して独立に維持しています。2 つのスコアが組み合わさってルーティング判定（受信トレイ／プロモーション／迷惑メール／拒否）が決まります。

シグナル

レピュテーションスコアを確認できる場所

• Google Postmaster Tools（postmaster.google.com）— Gmail から見た IP およびドメインレピュテーション、認証コンプライアンス、暗号化率、スパム率。無料。
• Microsoft SNDS（postmaster.live.com/snds/）— Outlook.com の IP レベルデータ、送信元レピュテーション分類。無料、登録が必要。
• Yahoo Sender Hub — 新しめ、Yahoo Postmaster ページから登録。ドメイン別の集計統計。
• プロバイダーダッシュボード — Amazon SES の Reputation Dashboard はバウンス率と苦情率をしきい値付きで表示。SparkPost、Mailgun、SendGrid も同様の機能を提供。

最低でも週 1 回はどこかをチェックしてください。先行指標（スパム率の傾向、IP レピュテーションの低下）は下流効果（開封率の低下）の数日前に現れます — キャンペーンの低調に気づく頃には、レピュテーションの問題はすでに 2 週間前から始まっています。

§7 · IP ウォームアップ

IP ウォームアップ — 6 週間スケジュール。

新規送信 IP はゼロレピュテーションから始まります。メールボックスプロバイダーは設計上、新規 IP からの大量送信をスロットルします — スノーシュー型スパマーがクラウドインスタンスを立ち上げて一斉送信するのを防ぐ主要な防衛策だからです。ウォームアップとは、日次・時間次のスロットル上限の範囲内で 4〜6 週間かけて段階的に送信量を増やし、レピュテーションを有機的に構築する運用です。

これは IP ごとに 1 回だけ実施します。Amazon SES、SendGrid、Mailgun の共有 IP はウォームアップ済みで提供されるため、多くのチームはウォームアップを行う必要がありません。ウォームアップが重要になるケース：SES の専用 IP（通常は月 100 万通超で正当化）、新規クラウドインスタンス上のセルフホスト Postal MTA、ドメイン変更を伴う ESP 間移行など。

スケジュール

SparkPost / Postmark / SES が公開しているウォームアップ推奨を 1 つの週次テーブルにまとめたスケジュールです。苦情率が上昇傾向にあれば、これより遅いペースで増やしてください。各ステップでプロバイダーから明確に「レピュテーション良好」のサインが得られた場合に限り、これより速く増やせます。

AcelleMail のウォームアップトラッキング

AcelleMail の SendingServer モデルはウォームアップ状態をファーストクラスで保持します。warmup_enabled、warmup_strategy_id、warmup_started_at は sending_servers テーブルに存在し、app/Model/SendingServer.php:333 の isWarmupEnabled() が送信時の判定をゲートします。連携する SendingServerWarmupLog テーブルは、ウォームアップ期間中のすべての送信を日付・ステータス・シリアライズされたメタペイロードとともに記録します — app/Model/SendingServerWarmupLog.php を参照。

パターン：WarmupStrategy（日次送信量カーブを定義する行）を送信サーバーに割り当て、warmup_enabled = true に切り替え、warmup_started_at = now() を設定します。送信パイプラインの SendingServerWarmupUsage がその日のカウントを追跡し、戦略の日次上限を超えるディスパッチを拒否します。戦略の N 日目の上限が通常の日次送信量を超えた時点で、サーバーは卒業し、ウォームアップモードは自動的に解除されます。

DynamicRateTracker および InMemoryRateTracker クラス（app/Library/）は SMTP 層での分次・時次のレート制限を処理します — ウォームアップ外でも AcelleMail はリレーが公開しているレート上限を強制し、キューのサージがプロバイダー側のスロットリングを引き起こさないようにします。

§8 · バウンスと苦情

バウンス、苦情、フィードバックループ。

ハードバウンスとソフトバウンス

ハードバウンスは恒久的な失敗です — 典型的には 5xx の SMTP コード：アドレスが存在しない、ドメインが解決しない、受信者のメールボックスが恒久的に無効化された、など。AcelleMail の BounceLog モデルは app/Model/BounceLog.php:33 で定数 HARD と SOFT を定義し、ハードバウンスは即座にアドレスを抑制リストに入れます。ソフトバウンスは一時的なもの — 4xx コード：メールボックス満杯、サーバー一時利用不可、メッセージが大きすぎる、など。ソフトバウンスはバックオフスケジュールでリトライされ、複数回の送信を跨いで繰り返しソフトバウンスするアドレスは最終的にハードへ降格されます。

AWS SES バウンス通知の分類マップ（AcelleMail の BounceLog.php:32 のドキュメントが参照しているソース）：バウンス種別は Permanent（ハード）にサブタイプ General / NoEmail / Suppressed / OnAccountSuppressionList；Transient（ソフト）にサブタイプ General / MailboxFull / MessageTooLarge / ContentRejected / AttachmentRejected；加えて Undetermined（ソフトとして扱いリトライ）。

苦情

苦情とは、受信者がメールクライアントで「スパムとして報告」を押すことです。苦情はフィードバックループ（FBL）経由で届きます — ISP が虐待として報告されたメッセージを送信者に転送するプロバイダー別の通知チャネルです。AcelleMail の app/Model/FeedbackLoopHandler.php にある FeedbackLoopHandler は IMAP/POP 経由で受信した FBL メッセージを処理し、Abuse Reporting Format（ARF、RFC 5965）ヘッダーを解析して元のメッセージ ID とフィードバック種別を抽出します。

AcelleMail が処理する ARF フィードバック種別（35 行目の FeedbackLoopHandler::FEEDBACK_TYPES による）：

• abuse — 受信者が明示的にスパムとしてマーク。即座に抑制。
• fraud — 受信者がフィッシングとしてマーク。抑制 + セキュリティレビューにログ。
• virus — 受信者のウイルス対策ソフトがペイロードを検知。抑制 + コンテンツ監査。
• other — 一般的な苦情。抑制。
• not-spam — 「これはスパムではない」という明示的な報告（まれ）。抑制対象外 — EXCLUDED_FEEDBACK_TYPES を参照。

FBL に参加している主要メールボックスプロバイダー：AOL、Yahoo、Microsoft（JMRP 経由）、Comcast、BlueTie。Gmail は公開 FBL を運用していません — 「スパムとしてマーク」のフィードバックは Postmaster Tools ダッシュボードと集計 DMARC レポートを通じて配信されます。

抑制ルール

1. ハードバウンス → 恒久的に抑制。再試行は不要、アドレスは死んでいます。
2. 苦情 → 恒久的に抑制。受信者が能動的に停止を求めています。再送はほとんどの法域で違法であり、レピュテーションを焼き払います。
3. 30 日以内に 3 回のソフトバウンス → ハードへ降格し抑制。持続的なソフトバウンスはメールボックス満杯か恒常的な接続障害 — 死んだアドレスとして扱います。
4. 配信停止 → マーケティングは抑制、トランザクションは継続。注文受領やパスワードリセットは継続、キャンペーンは停止します。
5. スパムトラップ命中 → 調査にエスカレーション。その購読者の取得元全体を引き上げます。リストが購入またはスクレイピングされたアドレスで汚染されていた可能性が高いです。

§9 · リストクリーニング

リストクリーニング — レピュテーションを高く保つ運用規律。

認証はワンタイムのセットアップ、レピュテーションは継続的な運用規律です。指標を動かす 7 つの習慣：

1. マーケティング登録はすべてダブルオプトイン。登録アドレスがアクティブリストに加わる前に確認クリックを求めます。タイプミス、役職アドレス（info@、sales@）、収集アドレスを排除します。登録フローに 10〜20% の摩擦を加える代わりに、バウンス／苦情リスクの 50〜80% を削減できます。
2. ワンクリック配信停止（RFC 8058）。ワンクリック URL を指す List-Unsubscribe ヘッダー。2024 年 2 月以降、自社ドメイン宛 1 日 5K 通超の送信者には Gmail と Yahoo が必須化しています。配信停止を苦情よりも簡単にしてください — 「スパム」を押そうとした受信者が代わりに「配信停止」を押すようになります。
3. 抑制前の再エンゲージメント。90 日間開封していない購読者に「引き続き有益でありたい」キャンペーンを送ります。開封 → 維持。未開封 → サンセットキューへ移動。180 日後も未開封 → 抑制。
4. バウンスの自動抑制。バウンス webhook を数分以内に処理し、次回キャンペーンの前にアクティブ送信リストから除外します。AcelleMail の BounceLog::record() と vbrandsync 系のバウンス webhook ハンドラがこれを自動で行います。
5. 購入リストは絶対にインポートしない。購入リストにはスパムトラップが種まきされています。トラップに 1 回命中するだけでドメインが 30 日以上 Spamhaus に掲載されます。計算は決して合いません — 購入リストはレピュテーションの恒久的な吸い込み穴です。
6. エンゲージメントでセグメント。エンゲージメント上位 50% へは 2 倍頻度で、コールド 50% へは半分の頻度で送ります。全体の開封率は上昇し、苦情率は低下し、メールボックスプロバイダーに「この送信者は関連性が高い」という強いシグナルを送れます。
7. オートメーション頻度に上限を設ける。ウェルカムシリーズ + 買い物かご放棄 + 購入後 + バースデー + 再エンゲージメントを組み合わせると、1 週間に 8 通になることもあります。受信者あたり 48 時間に 1 通までを総オートメーション上限とし、トランザクション（領収書、パスワードリセット）のみ厳格な例外として扱います。

§10 · AcelleMail のツール

AcelleMail の到達率ツール — ソースが同梱するもの。

app/Model/ と app/Library/ 配下のソースツリーから直接抜粋しています。各項目は実在するモデル、ケーパビリティインターフェース、ライブラリクラスであり、マーケティング上の表現ではありません。

§11 · トラブルシューティング

よくある到達率の問題と対処法。

§12 · FAQ

メール到達率の FAQ。

クラスターヘッド

次に読むべきページ。

認証済みドメイン。追跡されたバウンス。受信トレイ品質のレピュテーション。

AcelleMail は SPF/DKIM/DMARC 検証、ARF フィードバックループ処理、IP ウォームアップステートマシン、サーバー別レート制限を標準で同梱します。本ガイドのすべての主張は、ソースツリーの AcelleMail の app/Model/ または app/Library/ 内のクラスに対応しています。