SPF、DKIM、DMARC：コールドメールのための完全な DNS 認証ガイド

コールドメールキャンペーンを運用しているなら、到達率にとって「認証」が重要だと聞いたことがあるでしょう。しかし、それは実際に何を意味するのでしょうか。そしてもっと重要なのは、それをどう正しく設定するかです。

この包括的なガイドでは、メール認証の3つの柱、SPF、DKIM、DMARC を分解します。各プロトコルが何をするのか、それらを正しく設定する方法、そしてなぜコールドメールに本気の人にとってそれらが交渉の余地のないものなのかを、正確に学べます。

最近の調査によると、適切に認証されたメールは、認証されていないメッセージと比べて、最大50%高い確率で受信トレイに届きます。Google と Microsoft はどちらも2024年からより厳格な認証要件を発表しており、この知識をこれまで以上に重要なものにしています。

なぜコールドメールにメール認証が重要なのか

メール認証は2つの主要な目的を果たします。あなたが名乗る通りの人物であることを検証すること、そして悪意ある行為者によってドメインがなりすまされるのを防ぐことです。コールドメールの送信者にとって、これは直接、より優れた到達率と受信トレイ到達につながります。

適切な認証がなければ、メールプロバイダーは、あなたのドメインからだと主張するメールが実際にあなたから来たものかを検証する手段がありません。この不確実性は、しばしばあなたのメールを次のような状態にします。

• スパムフォルダに直接フィルタリングされる
• セキュリティ警告（あの恐ろしい「このメッセージにご注意ください」）が付けられる
• 受信サーバーによって完全に拒否される
• 受信トレイのアルゴリズムで優先度を下げられる

SPF（Sender Policy Framework）：最初の防衛線

SPF とは何か？

SPF は、どのメールサーバーがあなたのドメインに代わってメールを送ることを認可されているかを指定する、DNS ベースの認証プロトコルです。あなたのドメインの DNS レコードに公開された、承認済み送信者のホワイトリストのようなものだと考えてください。

受信メールサーバーがあなたのドメインからメールを受け取ると、送信サーバーの IP アドレスが承認済みリストに載っているかを確認するため、あなたの SPF レコードをチェックします。載っていれば、そのメールは SPF 認証に合格します。載っていなければ、失敗します。

SPF の仕組み（ステップごと）

1. あなたが your-domain.com からメールを送信する
2. 受信サーバーが your-domain.com の DNS レコードを確認する
3. 認可された IP アドレスとサービスを列挙したあなたの SPF レコードを見つける
4. 送信サーバーの IP をあなたの認可リストと照合する
5. IP が一致するかどうかにもとづいて、メールが SPF に合格または失敗する

SPF レコードの構文と例

SPF レコードは、あなたのドメインの DNS に追加される TXT レコードです。主要な構成要素は次のとおりです。

各部分を分解してみましょう。

• v=spf1 - バージョン識別子（常に spf1）
• include:_spf.google.com - Google のメールサーバーを認可する
• ~all - 認可されていない送信者に対するソフトフェイル（推奨）

コールドメールを送る Google Workspace ユーザーにとって、完全な SPF レコードは次のようになるかもしれません。

SPF 修飾子の解説

避けるべきよくある SPF のミス

• 複数の SPF レコード： ドメインごとに SPF レコードは1つしか持てません
• DNS ルックアップが多すぎる： SPF には10回の DNS ルックアップの上限があります
• +all を使う： これは事実上 SPF の保護を無効にします
• サードパーティのサービスを忘れる： あなたに代わって送信するすべてのサービスを含めましょう

DKIM（DomainKeys Identified Mail）：暗号によるメール署名

DKIM とは何か？

DKIM は、公開鍵暗号を使ってあなたのメールにデジタル署名を追加します。（送信サーバーを検証する）SPF とは異なり、DKIM はメールの内容が転送中に変更されていないことを検証し、メッセージがあなたのドメインから来たことを確認します。

DKIM を、荷物に貼られた改ざん防止シールのようなものだと考えてください。メールを送るとき、あなたのメールサーバーは秘密鍵でそれに署名します。受信サーバーは、（DNS に公開された）あなたの公開鍵を使って署名を検証します。メールが何らかの形で変更されていれば、署名は一致しません。

DKIM の仕組み

1. あなたのドメインは公開鍵／秘密鍵のペアを持つ（公開鍵は DNS に、秘密鍵はメールサーバーに）
2. メールを送るとき、サーバーは指定されたヘッダーと本文のハッシュを作成する
3. このハッシュはあなたの秘密鍵で暗号化される（署名）
4. 署名がメールのヘッダーに追加される
5. 受信サーバーが DNS からあなたの公開鍵を取得する
6. 署名を復号し、それを自身が計算したメールのハッシュと比較する
7. 一致すれば DKIM は合格し、しなければ失敗する

DKIM レコードの構造

DKIM レコードは、特定のサブドメインに公開される TXT レコードです。Google Workspace では、通常次のようになります。

構成要素を分解してみましょう。

• google._domainkey - セレクターと _domainkey 識別子
• v=DKIM1 - DKIM バージョン
• k=rsa - 鍵の種類（RSA 暗号）
• p=... - 公開鍵（base64 エンコード）

Google Workspace 用の DKIM 鍵を生成する

1. Google 管理コンソール > アプリ > Google Workspace > Gmail に移動する
2. 「メールを認証する」をクリックする
3. ドメインを選択し「新しいレコードを生成」をクリックする
4. 2048ビットの鍵長を選択する（推奨）
5. 生成されたレコードを DNS プロバイダーにコピーする
6. DNS の伝播を待ち、それから「認証を開始」をクリックする

DMARC（Domain-based Message Authentication, Reporting & Conformance）：ポリシーの層

DMARC とは何か？

DMARC は、SPF と DKIM の上に位置するポリシーの層です。3つの重要なことを行います。

1. アラインメントのチェック： From: ヘッダーが SPF/DKIM のドメインと一致することを確認する
2. ポリシーの強制： 失敗したメールを受信サーバーがどう扱うべきかを伝える
3. レポート： メール認証の結果についてのレポートをあなたに送る

DMARC がなければ、SPF と DKIM が個別に合格しつつも、なりすましのメールを通してしまうことがあります。DMARC は、目に見える From: アドレスと認証されたドメインの間のアラインメントを求めることで、このギャップを塞ぎます。

DMARC レコードの構造

DMARC レコードは、_dmarc.yourdomain.com にある TXT レコードです。

各タグの意味は次のとおりです。

• v=DMARC1 - バージョン（常に DMARC1）
• p=quarantine - ポリシー：none、quarantine、または reject
• rua=mailto:... - 集約レポートの送り先
• pct=100 - ポリシーを適用するメールの割合
• adkim=s - DKIM のアラインメントモード（s=厳格、r=緩和）
• aspf=s - SPF のアラインメントモード（s=厳格、r=緩和）

DMARC ポリシーの進行

DMARC の実装には段階的なアプローチを推奨します。

フェーズ1：監視（p=none）

配信に影響を与えずにデータを収集します。2〜4週間実行しましょう。

フェーズ2：隔離（p=quarantine）

25%から始め、数週間かけて徐々に100%まで増やします。

フェーズ3：拒否（p=reject）

最大の保護です。十分なテストの後にのみ実装しましょう。

すべてをまとめる：コールドメールのための完全な DNS 設定

Google Workspace を使うコールドメールのドメインに必要な、すべての DNS レコードの完全な例を以下に示します。

メール認証の設定を確認する方法

方法1：メールヘッダーを確認する

Gmail の自分自身にテストメールを送り、それから元のメッセージ（三点リーダー > 元のメッセージを表示）を表示します。Authentication-Results ヘッダーを探しましょう。

方法2：オンラインツール

• MXToolbox： すべての DNS レコードを確認し、詳細な診断を得られます
• mail-tester.com： テストメールを送り、到達率のスコアを得られます
• DMARC Analyzer： DMARC レポートを解析し可視化します
• Google Postmaster Tools： Gmail であなたのドメインレピュテーションを監視します

方法3：コマンドラインでの検証

コールドメール送信者のための高度なヒント

1. コールドメールにサブドメインを使う

ルートドメインではなく、サブドメイン（例：mail.yourdomain.com）からコールドメールを送ることを検討しましょう。これは、キャンペーンで何かがうまくいかなくなった場合に、メインドメインのレピュテーションを守ります。

2. DMARC レポートを監視する

DMARC の集約レポート（rua）は、あなたのメール認証について貴重な洞察を提供します。それらは次を示します。

• どの IP があなたのドメインからメールを送っているか
• 何通のメールが認証に合格または失敗しているか
• あなたのドメインに対する潜在的ななりすましの試み

3. SPF の10ルックアップ上限に対処する

SPF レコードは10回の DNS ルックアップに制限されています。多くのサービスを使うと、この上限に達することがあります。解決策には次が含まれます。

• include を IP アドレスに変換する SPF フラット化サービス
• 可能な場所では include の代わりに ip4/ip6 メカニズムを使う
• メールサービスを統合してルックアップ数を減らす

4. 新しいドメインをウォームアップする

完璧な認証があっても、新しいドメインはレピュテーションを築くのに時間が必要です。少量から始め、2〜4週間かけて徐々に増やしましょう。ウォームアップツールを使ってオーガニックなエンゲージメントを模倣し、ポジティブな送信パターンを確立します。

結論：認証は交渉の余地がない

SPF、DKIM、DMARC はメール到達率の基盤を形成します。それらがなければ、あなたは、認証されていないメールをますます疑うスパムフィルターと ISP のアルゴリズムを相手に、勝ち目の薄い戦いを繰り広げることになります。

よい知らせは、いったん正しく設定されれば、これらのプロトコルはバックグラウンドで静かに機能し、あなたが送るすべてのメールで受信トレイ到達率を改善するということです。それらを適切に設定するための時間の投資は、より優れた到達率、より高い開封率、より多くの返信という形で配当をもたらします。

覚えておいてください。Google や Microsoft のようなメールプロバイダーは、認証要件を継続的に厳格化しています。5年前には任意だったものが、今やメールアウトリーチに本気の人にとって必須となっています。今日あなたの認証を正しく設定すれば、要件が進化し続ける中で、あなたは時代の先を行けるでしょう。