MailData

御社のSPFは制限を超えてませんか？

DMARC VS SPF

SPFの限界を理解する

2021年12月11日
著者: Ahona Rudra
翻訳: 竹洞 陽一郎

この記事はPowerDMARCのブログ記事 DMARC Vs SPFの翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。

メールセキュリティは技術の進化により、以前ほど単純ではなくなっています。
メールセキュリティには、フィッシング攻撃、メールスプーフィング、マルウェア配布、暗号化の欠如、人為的エラー、認証技術の複雑さなどの課題が存在します。
これらの問題は、データ侵害、プライバシーの侵害、システムの損害を引き起こす可能性があり、強力な認証、ユーザ教育、高度な脅威検出、暗号化、効果的なインシデント対応策を含む多層的なアプローチの必要性を強調しています。

DMARCとSPFに関する議論をこれまで追っていない場合、それらが何であるか、どのように役立つかを理解しましょう。
メール認証に初めて触れる場合、おそらくDMARCやSPFのような耳慣れない用語に出会い、それをよく理解してどちらが適しているかを判断したいと思っているかもしれません。

SPFとDMARCの違いは何でしょうか。

SPF(Sender Policy Framework)は、顧客に代わってメールを送信することを許可されているIPアドレスのリストをキャッシュする仕組みです。（RFC7208）
一方、DMARCは認証に失敗したメールに対するポリシーを指定し、ドメイン所有者が実装したセキュリティプロトコルの厳格さを制御するのに役立ちます。

以下に、SPFとDMARCを詳しく説明します。

SPF: ドメインの送信者を認証する
SPFは、送信サーバがドメインに代わってメールを送信する許可を得ていることを確認します。
これは、IPアドレスやドメインの「VIPゲストリスト」を持つ個人的な門番のようなものです。
送信者がこのリストに記載されていない場合、メールの検証は失敗します。
DMARC: 整合性とフィードバックループ
DMARCは、SPFに失敗したメッセージに対する具体的な指示ルール（メールを拒否するか、隔離するか、配信するか）を定義します。
また、配信に関する問題をドメイン所有者に通知するフィードバックループを提供します。

SPFを導入していても、DMARCは必要ですか？

SPFには、配信失敗やなりすまし試行のレポートを送信する仕組みがありません。
ここでDMARCが役立ちます。
DMARCレポートをドメインで有効化すれば、SPF認証結果に関する通知を受け取ることができます。

これには、配信失敗やスプーフィング試行などが含まれますが、それだけに限りません。
この機能は、ドメインにSPFのみを導入している場合でも、メールセキュリティスイートに不可欠な追加機能といえる重要な特徴です。

ドメインの監視は、メールのパフォーマンスを把握し、メールマーケティングキャンペーンの成功率を測定するのに役立ちます。
また、攻撃への迅速な対応や、疑わしい送信者アドレスのブラックリスト化にも寄与します。

SPF単独の制限

SPFとDMARCは連携してメールスプーフィングやフィッシング攻撃を防ぐのに役立ちますが、それぞれに固有の制限があり、単独で使用する場合、これらの制限がメール通信の全体的なセキュリティに影響を与えることがあります。
以下に、いくつかの制限を説明します。

限定的な保護
SPFは、送信者のIPアドレスが特定のドメインに代わってメールを送信する許可を得ているかどうかを確認することで、ドメインスプーフィングを防止します。
しかし、メールの内容やメッセージの整合性といった他のメール認証の側面には対応していません。
ドメイン整合性の問題
SPFは、メールヘッダーの「From」アドレスが「Envelope From」アドレスと一致しているかどうかを検証しません。
この整合性の欠如は、フィッシングメールをより本物らしく見せるために攻撃者に悪用される可能性があります。
レポートと可視性の欠如
SPFにはレポート機能がないため、SPFチェックに失敗したメールに関する情報を受け取ることはできません。
この可視性の欠如により、ドメインに対する潜在的な問題や攻撃を特定することが難しくなります。
ポリシーの適用がない
SPFは、特定のドメインのメールを送信する許可を持つサーバを定義する単純な仕組みにすぎません。
SPFチェックに失敗した場合にどのようなアクションを取るべきかは指定しません。
DMARCなしではポリシーの適用が行われず、受信者がSPF失敗を異なる方法で処理したり、全く対応しない可能性があります。

DMARC, SPF, DKIM: 最適な組み合わせの選択

DMARCレコードは、DNSにDKIMレコードが存在しない場合でも公開可能です。
これは、メールがDMARCに準拠していると見なされるためには、SPFまたはDKIMのいずれかの認証を通過する必要があり、両方を通過する必要はないためです。
DKIMレコードが存在しない場合、受信側MTA（Mail Transfer Agent）はSPFの整合性のみを確認してメッセージの正当性を判断し、DKIMはすべてのメッセージで自動的に失敗します。

しかし、この状態は理想的ではありません。
以下にその理由を説明します。

メール転送の問題を解決する

転送されたメールの場合、メッセージは受信者の受信トレイに届く前に中間サーバを通過します。
このサーバは、ドメインのSPFレコードに含まれていない可能性がある異なるIPアドレスを使用します。
そのため、転送されたメールは受信側でSPFが失敗します。

DKIMレコードがない場合、SPFの失敗はDMARCの失敗に直結します。
ポリシーが「拒否」に設定されている場合、メーリングリストを介して送信された正当なメールが受信者に全く届かなくなります。
このため、ドメインにSPFとDKIMの両方を実装し、両方のプロトコルに基づいてメールを整合させて完全にDMARC準拠を達成することが、円滑なメール配信を確保するためのより良い方法です。

SPFとDMARCが偽陽性を減少させる

SPFとDMARCの両方は、正当なメールがスパムとしてマークされたり拒否されたりするのを防ぐのに役立ちます。
メールがSPFとDMARCチェックを通過すると、受信者の受信トレイに届く可能性が高まり、偽陽性（正当なメールが誤ってスパム扱いされること）のリスクが減少します。

DMARCは、SPFのサポートを得て、正当なソースから送信されたように見えるスプーフィングや不正なメールを特定し、ブロックします。
これにより、偽陰性（悪意のあるメールが誤って正当と見なされること）の可能性が低下します。

DMARCは認証結果に基づいてポリシーを実施する

DMARCが実装されると、受信側のメールサーバに対して、DKIMやSPFチェックに失敗したメールをどのように処理するかを指示します。
これにより、偽陰性が見逃される可能性が減少します。
ドメイン所有者は、認証に失敗したメールを隔離または拒否する選択が可能です。

SPFとDMARCはどのように連携してメールセキュリティを強化するのか

SPFとDMARCは、補完的な保護層を提供することでメール認証を強化します。
SPFは送信サーバの認可を確認し、DMARCは認証結果を基にポリシーを実施します。

正しく設定および実装された場合、この組み合わせによりメールスプーフィングやフィッシングを防ぎ、メール通信全体のセキュリティが向上します。
SPFは送信者の正当性を保証し、DMARCはポリシーの実施者として、許可されていないメールが受信者に届くのを防ぎます。
これにより、偽陰性のリスクを低減し、メールの配信成功率を高めます。

SPFとDMARCが連携することで、メールを介した攻撃に対する強力な防御が形成されます。
この協力により、偽陰性を最小限に抑え、メール認証を強化することで、悪意のある攻撃者がフィッシングやスプーフィング、その他のサイバー脅威をメールで実行することがより困難になります。

DMARCとSPF: 強力な組み合わせ

DMARCとSPFについての議論をまとめると、まずSPFのTXTレコードを公開し、DMARCレコードを「ポリシーなし（p=none）」に設定して集計レポートを有効化することを推奨します。
これにより、転送されたメールやメーリングリストを通じて送信されたメールの量を把握できます。
「none」ポリシーは、メールの配信可能性に影響を与えず、ドメインを効果的に監視することを可能にします。

しかし、フィッシング攻撃やスプーフィングからの防御を強化するには、DMARCのポリシーを「拒否（p=reject）」または「隔離（p=quarantine）」に設定する必要があります。
SPFのみの実装では、メール詐欺に対する保護は提供されないため、DMARCポリシーが不可欠です。

DMARCソフトウェアソリューションの利点

PowerDMARCのDMARCレポートアナライザーの利用をお勧めします。
これにより、メール認証基準を最大限に活用し、以下を実現できます。

ぜひ無料の15日間トライアル(代理店版のMailDataは1か月)でプラットフォームを試してください！