1. なぜ「3 兄弟」が必要か
2024 年 2 月、 Google (Gmail) と Yahoo! が 「送信ドメイン認証必須化」のガイドラインを発表しました。 これは 1 日 5,000 通以上送る大量送信者に対して SPF / DKIM / DMARC の 3 つすべてを必須化するもの。
しかし実際は 大量送信者以外でも影響が出ています。 認証が不備のドメインから送られたメールは、 受信側で 迷惑メールフォルダ行き / 配送拒否 されるケースが増加。 メルマガが届かない、 注文確認メールが届かない、 取引先からの返信が来ない ── すべて認証不備が原因の可能性があります。
💡 業界調査: 国内中小企業ドメインの約 96% が DMARC 未設定。 ほとんどの会社が「自社ドメインのなりすましメール」のリスクを抱えたまま運営しています。
2. SPF ── 送信元 IP を宣言する
SPF (Sender Policy Framework) は、 メール送信できる IP アドレスを DNS の TXT レコード で宣言する仕組みです。
具体的には、 こんな TXT レコードを ドメインに追加します:
example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"
これは「example.com からのメールは Google (Gmail) と SendGrid のサーバーから送られます。 それ以外は -all = 拒否してください」という宣言。
受信側 (Gmail 等) は、 メールヘッダの 送信元 IP と SPF レコードを照合して、 SPF レコードに含まれない IP からのメールは怪しいと判定します。
⚠️ 注意: SPF は 10 個までの DNS 参照 制限 (RFC 7208)。 include を増やしすぎると無効化されます。 Google Workspace + SendGrid + メルマガ業者 + CRM ... と増えると、 すぐ 10 個オーバー。
3. DKIM ── メール本文に電子署名
DKIM (DomainKeys Identified Mail) は、 送信時にメール本文 + ヘッダの一部に 電子署名 を付ける仕組み。 受信側は 送信ドメインの公開鍵 (DNS の TXT レコードに登録) を取得して署名を検証し、 本文が改ざんされていないか判定できます。
DNS には次のような TXT レコードを追加:
selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..." selector1 は鍵の識別子 (Google Workspace なら google など)。
複数のセレクタを並べることで 定期的な鍵ローテーション ができます。
⚠️ よくある失敗: 鍵ローテーション時に古いセレクタを削除して、 過去メールの検証が失敗 → なりすまし疑い。 セレクタは 90 日以上 残すのが推奨。
4. DMARC ── 失敗メールの扱いを指示
DMARC (Domain-based Message Authentication, Reporting & Conformance) は、 SPF / DKIM のどちらか (または両方) で認証失敗したメールを 受信側でどう扱うか を指示するポリシーです。
DNS には次のような TXT レコード:
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100"3 つのポリシー値があります:
p=none: 観測モード。 認証失敗メールでも普通に届くが、 失敗レポート (rua) を受け取れる。 導入直後の 1 ヶ月推奨。p=quarantine: 隔離モード。 認証失敗メールは 迷惑メールフォルダ行き。 観測モードで問題なし確認後に。p=reject: 拒否モード。 認証失敗メールは 配送拒否。 最強の対策、 完全なるなりすまし防止。
💡 段階導入: p=none で 1 ヶ月観測 → 問題なければ p=quarantine に上げる →
さらに 1 ヶ月後 p=reject へ。 段階を踏まないと正常メールも巻き添えで配送拒否 され大事故になります。
5. 設定の優先順位 (段階導入の正解ルート)
3 兄弟は 必ずこの順番 で設定します:
- SPF: TXT レコード 1 個追加。 5 分で完了、 即効。
- DKIM: メールサービス (Google Workspace 等) の管理画面で生成、 公開鍵を DNS に登録。 30 分。
- DMARC (p=none): 観測モードで TXT レコード追加。 失敗レポート受信用メールアドレスを設定。 1 ヶ月モニタ。
- DMARC (p=quarantine): 観測で問題なければポリシー強化。 1 ヶ月モニタ。
- DMARC (p=reject): 完全防御モード。 これで第三者なりすましは事実上不可能。
所要期間は 合計 2-3 ヶ月。 急ぐと正常メールが届かない事故が出るので、 焦らず段階導入。
6. よくある失敗パターン 7 つ
SPF は 1 ドメインに 1 個のみ。 2 つあると無効化されます。 include で 1 つにまとめる。
+all や ~all で甘い設定+all = 全 IP 許可 = 認証の意味なし。 必ず -all (拒否) か ~all (ソフトフェイル) を使う。
SPF Flattener (テキスト展開ツール) で 1 レコードに圧縮、 または ip4: で直接指定。
RSA 2048 ビットの鍵は 256 文字以上、 DNS の TXT 制限 (255 文字) で 勝手に切られる ケース。 必ず 引用符で分割 して入れる。
p=reject観測なしで強化すると、 正常メールも巻き添えで配送拒否。 メルマガが全部届かない事故が起きる。 必ず none → quarantine → reject 段階導入。
mail.example.com など独立サブドメインからメール送る場合、 そのサブドメイン用にも SPF 設定が必要。
XML 形式の DMARC レポート、 読まずに放置するケースが多い。 専用ツール (dmarcian / postmark など) で可視化すると不正送信源が一目瞭然。
7. まとめ
- SPF / DKIM / DMARC の 3 兄弟が すべて揃って 初めてメール認証は機能
- 2024 年 Gmail 新ガイドラインで 事実上全送信者に必須化
- 96% の国内中小企業ドメインが DMARC 未設定 ── 自社が安全な方が珍しい現状
- 段階導入 (
p=none→p=quarantine→p=reject) で 事故なく強化 - 本ツール (Chrome 拡張) で 3 兄弟の設定状況を 1 クリック判定