注意: この記事はLLMによって英語から翻訳されたものです。正確性については保証いたしかねますので、あらかじめご了承ください。英語の原文はこちら。
現在、メールは広く使用されているコミュニケーション手段です。そのため、攻撃ベクトルとしても広く使用されています。2020年に世界中の組織の75%がフィッシングを経験したと言われており、ソーシャルエンジニアリング攻撃の最大95%がメールを通じて配信される可能性があるとされています。もちろん、これらすべての攻撃を防ぐ魔法はありませんが、悪意のある人物がメールであなたになりすますことを防ぐのに役立ついくつかのメカニズムがあります。これらのメカニズムは、いくつかのDNSエントリを設定するだけで済みます（独自のメールサーバーを運用している場合を除きます。ここではそれについては扱いません）。さらに良いことに、これらのDNSエントリを設定することで、メールがスパムとしてフラグされにくくなるため、メールの配信性も向上します。
Sender Policy Framework (SPF)#
簡単に言えば、SPFはドメイン名を使用してメールを送信することを許可されたサーバーをリストアップすることができます。メールが送信されると、受信サーバーは送信者ドメイン（envelope-fromから取得）のSPFエントリを照会し、メールを受信しているサーバーと比較します。一致しない場合、メールはフラグされるか拒否される可能性があります（最終的には、受信サーバーが何をするかを決定します）。
設定は非常にシンプルで、DNS設定にTXTエントリを追加するだけです。例えば、以下の（DNS TXTエントリの内容）は1.1.1.1、192.168.0.1/8、およびexample.comのAレコードからのすべてのメールを許可し、他のサーバーはこのドメイン名でのメール送信を許可されていないことを示しています。なお、ルールには10個以上のルックアップ（例：aエントリの解決）を含めることはできません。
v=spf1 ip4:1.1.1.1 ip4:192.168.0.1/8 a:example.com -all
IPv4アドレスと範囲、ドメイン名に加えて、IPv6やMXなど多くの他のオプションが利用可能です。
許可されたサーバーからメールが送信されていない場合にSPFチェックを失敗させる-allの代わりに、~allでソフトフェイルを発生させたり、?allで明示的にマークされていないアドレスについて何も言えないことを示したりできます。+allは、ドメイン名の代わりに任意のサーバーがメールを送信することを許可することを示すために使用できます。
これはすべて良いのですが、SPFは完璧ではありません。メールボックスemail@example.comがemail@example.netに自動的にメールを転送するように設定したとします。SPFで許可されていないIPからemail@example.comにメールを送信した場合、email@example.netは元のSPFが無効であることを検知できません。
Domain Keys Identified Mail (DKIM)#
前のパートで、SPFだけではメールの転送時に無視されるなどの理由からメールの認証を保証するには不十分であることを述べました。DKIMはメールを認証するもう1つのオプションであり、メールが転送されても失われないという利点があります。
DKIMの仕組みは非常にシンプルです。送信者のドメインには公開鍵を含むDNSエントリが必要です（設定方法についてはメールホスティングプロバイダーのドキュメントを参照してください）。対応する秘密鍵は送信メールの署名に使用されます。メールを受信すると、受信サーバーは送信者が使用したドメイン名のDNSレコードから公開鍵を取得し、署名が正しいかどうかを確認します。
例を見てみましょう。以下は、DKIMを使用するサーバーから送信された受信メールのヘッダーの一部です。
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=haveibeenpwned.com;
h=content-type:from:mime-version:to:subject:list-unsubscribe;
s=s1; bh=XnUR5B4bb9/iGnKkBNkjeCE5H9eTJoZZhuc28eSwj/Y=; b=CwFiOJD
nrpW8docGIVBd/A+bPcOjmmVg0letY5gf43QQTSD3V1bJ4wkt3l1LSBT1uDqhkzK
QxBQttzZIxnmcYY5E/sP/tj1UseO0KEBq/s6Mt1X5AHtvDScaIJgoTfeay3sIU+O
6Edb/G0uCDhSW6JY8gAnXgVKFcooGBp43+yk=複数のフィールドを確認できます：
a=rsa-sha256はメッセージの署名に使用されたアルゴリズムを示しますc=relaxed/relaxedは送信ドメインの正規化ポスチャーを定義します。ここでは、ハッシュ前にヘッダー名を小文字にしたり、行末の空白を削除するなどの再フォーマットが行われます。relaxedの代わりにstrictを使用することもでき、その場合はコンテンツが100%同一であることが要求されます。例えば、c=relaxed/strictはメールのヘッダーの再フォーマットを許可しますが、本文は厳密に変更されていないことを要求します。relaxedオプションは、メールサーバーが処理中にヘッダーを再フォーマットすることがあるため、不必要な失敗を避けるのに便利ですd=haveibeenpowned.comは署名がどのドメイン用に作成されたかを示しますh=[...]はメッセージが署名された時に存在していたヘッダー（つまりハッシュに含まれたもの）をリストしますs=s1はドメインの公開鍵のセレクタがs1であることを示します。後で説明しますbh=[...]は正規化されたメッセージ本文のbase64ハッシュを含みます。なお、パラメータにlオプションを指定して、ハッシュの計算に使用する本文の最大長を指定することもできます。つまり、長さlの後にコンテンツが含まれていてもDKIMは有効のままですb=[...]はbase64署名を含みます
受信サーバーがメッセージを受け取ると、bに提供された署名が有効かどうかを確認しようとします。そのために、メールを送信したドメインの鍵を取得するDNSクエリを行い、以下のような応答を受け取ります：
user@Host ~ % dig TXT s1._domainkey.haveibeenpwned.com
[...]
;; ANSWER SECTION:
s1._domainkey.haveibeenpwned.com. 300 IN CNAME s1.domainkey.u3489673.wl174.sendgrid.net.
s1.domainkey.u3489673.wl174.sendgrid.net. 474 IN TXT "k=rsa; t=s; p=[key]"digクエリのs1に注目してください。これはメールのDKIMヘッダーのsフィールドにあったセレクタ値です。DKIMエントリは常に[selector]._domainkey.domain.tldに保存されます。
DNS応答で提供された鍵を取得した後、受信サーバーは署名が有効でコンテンツと一致することを確認します。一致しない場合、検証は失敗します。そうでなければ、以下のようなものがメールヘッダーに追加されます。
Authentication-Results: mailin007.protonmail.ch; dkim=pass (1024-bit key)
header.d=haveibeenpwned.com header.i=@haveibeenpwned.com header.b="EwFk1JDn"Domain-based Message Authentication, Reporting and Conformance (DMARC)#
ここまでの内容を理解していれば、メールサーバーのアドレスはSPFエントリの一部であり、メッセージはDKIMのおかげで署名されています。これは良いことですが、攻撃者がメッセージを偽造して自分のサーバーから（DKIMを含めずに）送信した場合はどうなるでしょうか？このシナリオでは、メールは受信サーバーで許可される可能性が高く、受信者のメールボックスに届くことになるでしょう。
ここでDMARCが役立ちます。このメカニズムには以下の利点があります：
- SPFまたはDKIMチェックに失敗したメールの処理方法について、受信メールサーバーにガイドラインを提供できます（サーバーがそれを強制する義務は一切ありませんが）
- サブドメインでのSPF管理のための追加オプションを提供します（~allに一致するサーバーはfailとしてマークされます）
- ドメイン名を使用して送信されたメールについてフィードバックを受け取ることができ、デバッグや悪意のある活動の検出に便利です
- DMARCはRFC5321のMailfromヘッダーとRFC5322のMailfromヘッダーが一致することを確認し、DMARCとSPFの弱点に対処します
他の2つの項目と同様に、DMARCは_dmarc.domain.comに配置される単一のTXT DNSフィールドで設定されます。以下のスニペットは設定の例を示しています。
v=DMARC1; p=reject; sp=reject; ruf=mailto:security@example.com; aspf=s; adkim=s; fo=1;各フィールドを見てみましょう：
v（必須）はDMARCバージョンです（常にDMARC1）p（必須）はSPFまたはDKIMチェックが失敗した場合のexample.comから送信されたドメインのポリシーを定義します。rejectに設定するとユーザーのメールボックスには何も届かず、quarantineはメールをスパムに送り、noneは何もしませんpoはpと同じことをサブドメインに対して行いますrufはメールが検証に失敗した際にフォレンジックレポートを受け取るメールアドレスを定義できます。ruaは同様のオプションで、ドメインに関するアクティビティの日次（簡略化された）集約レポートを送信します（例えば、日中にGmailにメールを送信した場合、Gmailは1日の終わりにさまざまな操作を集約したレポートを送信します）。一部のサーバーはレポートを送信しない場合がありますaspfはSPFの追加ポリシーを設定できます。strict（s）またはrelaxed（r）のいずれかです。example.comのSPFレコードがある場合、mail@test.example.comから送信されたメールは、ポリシーがstrictの場合SPF検証に失敗し、relaxedの場合は成功しますadkimはaspfと同じことをDKIMに対して行いますfoはメールが検証に失敗した際のログレベルを設定できます。0（デフォルト）はSPFとDKIMの両方が失敗した場合にレポートを送信し、1はDKIMまたはSPFのいずれかが失敗した場合に送信し、dはDKIMが失敗した場合にメールを送信し、sはSPFの場合です。ルールを組み合わせることも可能で、例えばfo=0:d;のようにできます。
便利なツール#
メールのDNSエントリを設定する際に役立つと思うツールのリストです。
- mxtoolbox.com - メール設定を確認するためのさまざまなオンラインツール
- mail-tester.com - メールサーバーから送信されたメールに点数を付け、問題があるか改善すべき点があるか教えてくれます
- whatsmydns.net - DNSエントリが適切に伝播しているか確認できます