なぜ1つだけでなく3つすべてが重要なのか
SPFだけでは、ドメインの承認済みリストにあるサーバーから送信しつつ表示名を偽装するといった攻撃を防げず、DKIMだけでは表示上の「差出人」アドレスが署名ドメインと一致しているかは検証できません。DMARCは、表示上の送信者と実際にSPFまたはDKIMを通過したドメインとの整合性を要求することでこの隙間を埋めます。セキュリティを意識する組織が1つだけに頼らず3つすべてを組み合わせて設定するのはこのためです。
設定を誤った厳格なDMARCポリシーの代償
サードパーティのマーケティングツールやCRMなど、正規の送信元をすべて適切に認可する前にDMARCポリシーを積極的にreject(拒否)へ設定してしまうと、自組織の正規のメールが他のメールサーバーで静かに拒否されてしまうことがあります。多くの組織はまずnone(何もしない)ポリシーから始めてレポートを収集し、正規の送信元がすべて把握できたことを確認してから、段階的にquarantine、さらにrejectへと移行します。
導入の順序:いきなりrejectにしない
実務では、次の順序で進めるのが定石です。まず自社が使っているすべての送信サービス(自社サーバー、メール配信サービス、問い合わせ管理、請求書システムなど)を洗い出し、SPFに登録します。次に各サービスでDKIM署名を有効にし、署名ドメインを自社ドメインに揃えます。その後、p=noneとruaを設定して数週間レポートを集め、認証に失敗している正規の送信元がなくなったことを確認してからquarantineへ、さらに問題がなければrejectへ進みます。サブドメインに別のポリシーを適用したい場合はspタグを使います。レコードの確認は、コマンドラインのnslookupやdigでTXTレコードを引くか、無料の検査サイトで行えます。
認証に通る=安全、ではありません
SPF・DKIM・DMARCが保証するのは「そのドメインを名乗る権限があるか」だけで、メールの中身が安全かどうかは別問題です。攻撃者が自分で取得した類似ドメイン(例えばアルファベットを一字入れ替えたもの)から送れば、そのドメインの認証には正当に合格します。また、正規のアカウントが乗っ取られて送られたメールも認証には通ります。つまり、これらの技術は「ドメインの直接的な偽装」を防ぐものであり、類似ドメインや内容による詐欺は、リンク先のドメイン確認や送信者への別経路での確認といった利用者側の注意が引き続き必要です。
よくある質問
SPFに合格すれば、そのメールは確実に正規のものと言えますか?
それだけでは言えません。SPFは送信サーバーがそのドメインについて認可されているかを確認するだけで、表示上の「差出人」アドレスが一致しているか、内容が送信途中で改ざんされていないかまでは検証しません。DKIMとDMARCがこれらの隙間を補うため、3つを組み合わせて運用することが前提とされています。
正規のメールなのになぜDMARCに失敗することがあるのですか?
マーケティングプラットフォームやチケット管理システムなど、サードパーティのサービスを経由してメールを送信している場合に、そのドメインのSPFレコードに適切に追加されていなかったり、独自のDKIM署名が設定されていなかったりすることが原因でよく起こります。ドメインのメールを管理する担当者は、自社のメールサーバーだけでなく、すべての正規の送信元を認可しておく必要があります。
自分のドメインの設定が正しいか、どう確認すればよいですか?
TXTレコードを直接見る方法が基本です。SPFはドメイン名そのもの、DMARCは_dmarc.ドメイン名、DKIMはセレクタ._domainkey.ドメイン名をnslookupやdigで引きます。最も確実なのは、自分のドメインから実際にGmailなどへテストメールを送り、「メッセージのソースを表示」でAuthentication-Resultsにspf=pass・dkim=pass・dmarc=passが並ぶかを確認することです。
個人のドメインでメールを送るだけでも設定は必要ですか?
送信量が少なくても、設定しておくメリットは大きいです。SPFとDKIMがないと迷惑メールに振り分けられやすくなりますし、DMARCを公開しておくと、第三者があなたのドメインを騙って送ったメールを受信側が拒否しやすくなります。まずはp=noneで始め、レポートを見ながら調整すれば、正規のメールを止めるリスクを抑えられます。