セルフホストメール送信者に必要な 7 つの DNS レコード

メールはやや特殊です — 完全な送信者セットアップには 3〜4 のレコードタイプにまたがる別個の DNS レコードが 7 つあります。1 つでも欠ければ配線自体はメッセージを動かしますが、メールボックスプロバイダーは静かに spam フォルダへ降格させます。7 つすべてを公開すれば、/guide/email-deliverability の「Google が要求するすべて」の基準を越えられます。

順序が重要です。SPF と DKIM は DMARC がアラインメントを強制し始める前に着地させましょう、さもないと正当なメールが quarantine 行きになります。各ベンダー共通の標準ルールも「DNS の伝搬を待つ」ことです — レコードを公開してからメールボックスプロバイダーに再チェックを求めるまでに最低 30 分は空けてください。

MX レコード（RFC 1035 §3.3.9）はドメイン宛受信メールの配送先を世界に伝えます。送信ドメインが「outbound only」で返信を読まないとしても、MX レコードは依然として必要です — 多くのメールボックスプロバイダーは MX がないドメインのレピュテーションを下げます。正当な送信者は返信を受け付ける、という前提に基づいています。到達可能な任意のメールサーバーを指す 1 つのレコードで十分で、そのサーバーが postmaster の受信箱にしか配送しなくても構いません。

SPF（RFC 7208）は、ドメインの送信を許可する IP を列挙する単一の TXT レコードです。鉄則：再帰 DNS ルックアップの合計は 10 未満に保つこと（RFC 7208 §4.6.4）。各 include: は 1 つ消費し、ネストされた include は累積でカウントされます。ip4: / ip6: メカニズムはルックアップ 0 なので、カウントが増えてきたら古い include を明示的な IP レンジに畳んでください。

正当な送信元がすべてカバーされていることを確認できたら -all（hard-fail）で終端します。まだ確信が持てなければ ~all（soft-fail）で始め、DMARC レポートが 2 週間クリーンになったら -all に締めます。

DKIM（RFC 6376） は、署名鍵ペアの公開部分を {selector}._domainkey.{domain} の TXT レコードとして公開します。「selector」は自分で選ぶ識別子で、ベンダー固有または任意です。SES の場合、AWS は AWS が管理する TXT レコードへ解決される CNAME を 3 つ提供します（これにより AWS は DNS に触れずに鍵をローテーションできます）。

セルフホストの Postal や Postfix+OpenDKIM では、鍵ペアをローカルで生成し、MTA を署名するよう構成、公開部分を TXT として公開します。

どちらの経路を取るにせよ、DKIM を完了とする前に dig TXT {selector}._domainkey.{domain} で検証してください。

DMARC（RFC 7489）は _dmarc.{domain} に置きます。p=none のランプをスキップするのが最もありがちな間違いです — まだメールフローを完全に把握していないドメインに対していきなり p=reject へ飛ぶと、正当なメール（転送者、メーリングリスト、サードパーティ CRM 送信者）が静かにバウンスします。

段階の間は、rua メールボックスに届く日次集計 XML レポートを読んでください。Postmark の DMARC analyzer やセルフホストの Parsedmarc のようなツールが可視化してくれます。生 XML も密ですが読めます。

デフォルトでは AcelleMail の開封ピクセルとクリックトラッキング URL はインストールのプライマリドメインから配信されます。メールボックスプロバイダーは From、リンククリック、配信停止 URL のルートドメインが一貫していること — すべて同じ登録ドメイン上 — を好みます。ブランディング面でも、tracker.yourcompany.com を指すリンクは links.acellemail.com を指すリンクよりも信頼シグナルが強くなります。

CNAME が解決されると、AcelleMail は送信メッセージ内のクリックトラッキング URL をすべてそれを使うように書き換えます。配信停止リンクのドメインも同じルール（同じ CNAME）に従います。

MTA-STS（RFC 8461）は他の送信者に「私の MX に配送するときは常に TLS を要求してください」と伝えます。これがないと、経路上の攻撃者は TLS 対応のハンドシェイクを平文にダウングレードできます。これがあれば、TLS が確立できなければ送信側サーバーは配送を拒否します。実装はホストされたポリシーファイルを指す TXT レコード 1 つです。

最初の 1 週間はポリシーを mode: testing で運用し、その後 mode: enforce に切り替えます。多くの bulk sender が MTA-STS をスキップしています — デプロイすれば無料の信頼シグナルになります。

BIMI（Brand Indicators for Message Identification）は 7 つの中で最も新しく、唯一まだ確定 RFC ではありませんが、Gmail、Yahoo、Apple Mail、Fastmail その他のクライアントで本番運用中です。仕組みはこうです — SVG ロゴと（オプションで）Verified Mark Certificate（VMC）を指す TXT レコードを公開すれば、対応クライアントが受信箱リスト上のメッセージ横にロゴを表示します。

前提条件：DMARC ポリシーが最低 p=quarantine であること（BIMI は p=none では尊重されません）、SVG は SVG Tiny Portable / Secure（SVG-PS）であること。受け入れ状況には差があります — Gmail は受信箱リスト表示に有料 VMC（DigiCert / Entrust 経由で年 $1,500）が必要、Yahoo と Apple は VMC なしでも BIMI を受け入れます。公開ケーススタディでは開封率の 5〜20% 押し上げがよく報告されています。

公開後、自分宛にテストメッセージを送りヘッダを確認します。Gmail web：メッセージを開き、3 点メニュー → 「メッセージのソースを表示」。以下を確認：

3 つの pass 判定が基準です。それ以下 — fail、softfail、neutral — は、レコードが間違っているか、DNS がまだ伝搬していないか、メール本文が経路上で改変されている（稀）かを意味します。判定が曖昧な場合は正典の Authentication-Results ヘッダ（RFC 8601） 仕様と突き合わせてください。