SPF・DKIM・DMARCを解説:メール送信者認証の仕組み

かつては誰でもメールの「差出人」を偽装できました。SPF・DKIM・DMARCがどのようにそれを難しくしたのかを解説します。

メールの送信者偽装(スプーフィング)問題

メールをやり取りする基本プロトコルであるSMTPは、そもそも送信者アドレスを検証する仕組みを持っていませんでした。そのため誰でも「差出人」欄に銀行や会社のアドレスをそのまま記載して送ることができ、これが長年にわたるフィッシングメールの土台になっていました。

SPF:送信サーバーのホワイトリスト

SPF(Sender Policy Framework)は、ドメインの所有者がDNSのTXTレコードに「このドメイン名でメールを送信できるサーバーの一覧」を登録しておく仕組みです。受信側のメールサーバーは、実際にメールを送信したサーバーのIPアドレスがこの一覧に含まれているかを確認し、偽装かどうかを判断する材料にします。

DKIM:電子署名で改ざんを検知

DKIM(DomainKeys Identified Mail)は、メールを送信する際に本文と主要なヘッダーの一部を送信ドメインの秘密鍵で署名し、メールヘッダーに付加します。受信側のサーバーはDNSに公開された公開鍵でこの署名を検証し、送信後に内容が変更されていないかを確認します。

DMARC:結果を統合してポリシーを指定

DMARC(Domain-based Message Authentication, Reporting & Conformance)は、SPFとDKIMの検査結果に加えて、実際の差出人アドレスと認証に使われたドメインが一致しているか(アライメント)まで確認します。ドメイン所有者は認証に失敗したメールをそのまま配送するか(none)、迷惑メールに振り分けるか(quarantine)、完全に拒否するか(reject)をポリシーとして指定でき、失敗状況をまとめたレポートを受け取ることもできます。

3つの技術の関係

SPFとDKIMはそれぞれ独立して動作する個別の認証手段であり、DMARCはこの2つの結果を統合して「認証に失敗した場合どう処理するか」を指示する上位のポリシー層です。3つすべてを揃えて初めて、なりすまし防止の効果が十分に発揮されます。

受信メールで確認する方法

メールの生ヘッダーを開くと、「Authentication-Results」というフィールドに、spf=pass、dkim=pass、dmarc=passのように各検査結果が表示されます。この値がfailやnoneになっている場合は、送信者が本当に名乗っている本人かどうかを改めて疑ってみる必要があります。

なぜ1つだけでなく3つすべてが重要なのか

SPFだけでは、ドメインの承認済みリストにあるサーバーから送信しつつ表示名を偽装するといった攻撃を防げず、DKIMだけでは表示上の「差出人」アドレスが署名ドメインと一致しているかは検証できません。DMARCは、表示上の送信者と実際にSPFまたはDKIMを通過したドメインとの整合性を要求することでこの隙間を埋めます。セキュリティを意識する組織が1つだけに頼らず3つすべてを組み合わせて設定するのはこのためです。

設定を誤った厳格なDMARCポリシーの代償

サードパーティのマーケティングツールやCRMなど、正規の送信元をすべて適切に認可する前にDMARCポリシーを積極的にreject(拒否)へ設定してしまうと、自組織の正規のメールが他のメールサーバーで静かに拒否されてしまうことがあります。多くの組織はまずnone(何もしない)ポリシーから始めてレポートを収集し、正規の送信元がすべて把握できたことを確認してから、段階的にquarantine、さらにrejectへと移行します。

よくある質問

SPFに合格すれば、そのメールは確実に正規のものと言えますか?

それだけでは言えません。SPFは送信サーバーがそのドメインについて認可されているかを確認するだけで、表示上の「差出人」アドレスが一致しているか、内容が送信途中で改ざんされていないかまでは検証しません。DKIMとDMARCがこれらの隙間を補うため、3つを組み合わせて運用することが前提とされています。

正規のメールなのになぜDMARCに失敗することがあるのですか?

マーケティングプラットフォームやチケット管理システムなど、サードパーティのサービスを経由してメールを送信している場合に、そのドメインのSPFレコードに適切に追加されていなかったり、独自のDKIM署名が設定されていなかったりすることが原因でよく起こります。ドメインのメールを管理する担当者は、自社のメールサーバーだけでなく、すべての正規の送信元を認可しておく必要があります。