この記事の目的：SPF・DKIM・DMARCを「DNSへ3つのTXTレコードを入れる作業」としてではなく、それぞれ何を検証し、どこまでを守る仕組みなのか理解することです。
3つは同じ機能ではない
| 方式 | 主に確認するもの | 役割 |
|---|---|---|
| SPF | 送信元サーバー | そのドメインから送信してよいサーバーかをDNSで示す |
| DKIM | 電子署名 | メールへ署名し、配送途中の改変や送信ドメインとの関係を検証する |
| DMARC | Fromとの整合性 | SPF/DKIM結果と利用者に見えるFromドメインを結びつけ、失敗時の方針を示す |
SPFが確認するもの
SPFは、メール配送時に使われるMAIL FROM側のドメインについて「どの送信元IPやサービスから送ってよいか」をDNSで公開します。ただし、利用者がメールソフトで見るFromアドレスと完全に同じドメインかどうかをSPF単独で保証する仕組みではありません。
DKIMが確認するもの
DKIMでは送信側がメールへ暗号学的な署名を付け、受信側がDNSに公開された鍵を使って検証します。正しく検証できれば、署名対象部分が配送中に変更されていないことや、署名に使われたドメインを確認できます。
DMARCが重要な理由
DMARCは、SPFまたはDKIMの認証結果に加え、利用者から見えるFromドメインとの「アラインメント」を確認します。Microsoftも、SPFとDKIMだけではMAIL FROMとFromのドメインが一致する必要はなく、DMARCがこの整合性を扱うと説明しています。
送信サービス
├─ SPF：この送信元は許可されているか
└─ DKIM：署名は正しいか
↓
DMARC：Fromドメインと認証結果が整合するか
↓
受信側：none / quarantine / reject 等の方針を参照設定時に最も注意すること
すべての送信経路を把握する
会社のメールはGoogle WorkspaceやMicrosoft 365だけから送られるとは限りません。Webフォーム、予約システム、請求書サービス、メールマガジン、複合機なども独自ドメインで送信している可能性があります。これらを把握せずSPFやDMARCを厳しくすると、正規メールまで失敗することがあります。
SPFレコードを複数作らない
SPFは単純にサービスごとにTXTレコードを追加すればよいわけではありません。既存レコードを確認し、必要な送信元を一つのポリシーとして整理します。
DMARCをいきなりrejectにしない
Google Workspaceの管理者向け資料でも、SPFとDKIMを先に整え、DMARCは監視から段階的に強化する方法が案内されています。まずレポートで送信経路を確認し、問題がないことを確認してからquarantineやrejectへ進めます。
よくある誤解
- SPFがPASSなら、なりすまし対策は完了している
- DKIMを設定すればDMARCは不要
- DNSにレコードが存在すれば正しい
- Google Workspaceだけ設定すれば、Webフォームなど他の送信経路も自動的に認証される
専門対応では何を確認するか
DNSレコードだけでなく、実際のメールヘッダーに記録されるSPF/DKIM/DMARC結果、Return-Path、DKIM署名ドメイン、Fromドメイン、利用している全送信サービスを確認します。設定値よりも「実際にどの経路でメールが出ているか」の把握が重要です。