先日、DMARC対応の話を書いた。
すでにSPFとDKIMに対応していればTXTレコード1つ足すだけだね、
とは書いたものの、実はSPF対応していても、場合によってはDKIM対応していても、
そのままではDMARC対応できないケースというのが存在するという。
メールの送信者にはFromとして表示されるヘッダーFromと、
メールサーバーが認識して不達時の連絡先(Return-Path)として利用されるエンベロープFromがある。
SPFは後者、エンベロープFromのドメインに対するなりすましチェックである。
例えば、Return-Pathが …@risonabank.co.jp なのに、同ドメインのTXTレコードに記載されていないサーバーから届いたらNGとすると。
ただ、一般的なメール受信者はReturn-PathではなくヘッダーFromを見る。
Return-PathとヘッダーFromは必ずしも一致している必要はない。
外部のメール送信サービスを利用する場合に一致しないことは珍しくない。
なのでReturn-Pathには自分が管理する適当なメールアドレスでSPFをPassさせて、
Fromになりすましたい会社や公的機関のメールアドレスを書く手法がありうるとは気づいていた。
DKIMについても似たような問題がある。
DKIMの場合はメールに付ける署名の公開鍵をDNSのTXTレコードに書いて、
署名を検証すればドメイン所有者の認めたサーバーから届いたことがわかる。
では、このドメインとは何なのかというと、DKIM-Signatureヘッダのdレコードに記載されたドメインである。
FromのアドレスのドメインとDKIM-Signatureヘッダのdレコードに書くドメインは当然一致していると思ったが、
外部のメール送信サービスが自社の公開鍵で署名する第三者署名というケースもあるらしい。
DKIMをそういう使い方をする理由はよくわからないのだが、DKIM=Passでもこのような場合はアテにならない。
DMARCはSPFとDKIMの両方がNGのメールの処理を規定するものだが、
DMARCでSPF=Passとなるためには、ヘッダーFromとエンベロープFrom(Return-Path)のドメインが一致してなければならない。
全く同じである必要はなく、標準設定ではサブドメインでもよい。
例えば Return-Pathが xxx@foo.example.com でSPF=Pass、
Fromが yyy@example.com であればDMARCはPassとなる。
DKIMも同様でDKIM-SignatureヘッダのdレコードとFromのドメインが一致していなければPassにならない。
こちらについては第三者署名は無効ですよと捉えればよいと思う。
外部のメール送信サービスを使っている場合には、ここを対応しなければDMARC対応とはならない。
例えば、Amazon SESではこのように対応できると書かれている。
Amazon SES の DMARC 認証プロトコルへの準拠 (AWS)
SPF対応については「カスタムの MAIL FROM ドメインを使用する」という対応をすればよいとある。
これは適当なサブドメインをAmazon SESのReturn-Path用に利用できる様にすると。
すなわち、従来はReturn-Pathを zzzz@amazonses.com としていたのを、
bar.example.com宛のメールはAmazon SESのサーバーで処理する設定をして、
かつ、同サブドメインのSPF設定にAmazon SESのサーバーを記載する。
その上でReturn-Pathを zzz@bar.example.com に変更してもらう。
こうすればFromに @example.com から始まる適当なメールアドレスを使えるようになる。
不達時の通知はAmazon SESで処理できるので従来と使い勝手は変わらない。
DKIM対応については3つの方法があると書かれている。
1つはAmazon SESの公開鍵を自分のドメインの公開鍵として公開する方法である。
これで、DKIM-Signatureヘッダのdレコードにそのドメインを指定して、
Amazon SESで持っている秘密鍵で署名できるようになる。
なるほど、その手があったかという感じである。確かにこれは簡単。
2つ目は自分で用意した鍵ペアの公開鍵をドメインで公開、秘密鍵をAmazon SESに支給する方法である。
僕は最初、この方法しかないと思っていた。もっとも素直な方法である。
3つ目はAmazon SESに送信依頼するメールにあらかじめDKIM-Signatureヘッダを付けておく方法。
この方法はエラーをAmazon SES側で検出できないから注意しろとはあるが、
DKIM-Signatureを任意に設定できるメールサーバーであれば、
メールサーバー側がDKIM対応してなくてもDKIM対応できる仕組みである。
ところでGmailでは大量にメール送信する人にSPFとDKIMの両対応を求めている。
DMARCではどちらか一方だけ対応していればOKなのに、なぜ両対応が必要なのか。
これはおそらく転送メールの都合ではないかと思う。
SPFは送信元のメールサーバーとReturn-Pathの一致を確認するが、
転送メールは他のサーバーから転送されてくるのでこれを満たせない。
一方のDKIMは元々Passしていたメールをそのまま転送すれば当然Passする。
大量送信すれば、そのうち一定割合は転送サービスで転送されてしまうだろう。
そうなったときSPFだけだとPassできなくなってしまう。
だからDKIMも付けて転送メールでもDMARCをPassできるようにしてね。
こういう趣旨なのではないかと思う。
じゃあ、逆にDKIMだけでDMARC対応してしまえという考えもありそうだが。
SPFでDMARC対応するにはReturn-PathとヘッダーFromのドメインを一致させる必要がある。
DKIMの場合はここが一致しなくてもFromとDKIM-Signatureのドメインが一致すればよい。
でも、実際はそういう例はあまり多くないのだろう。
Return-Pathのドメインを合わせるカスタマイズの方が結局は容易なのだろう。
ちなみにヘッダーFromとエンベロープFrom(Return-Path)の不一致については、
Gmailではこれまでも自主的に「xxxxx.xxx経由」という表示をしてきた。
これを表示する条件はDMARCのNG条件に似ていて、
ヘッダーFromとエンベロープFromのドメインが一致しなくて、
かつヘッダーFromのドメインでDKIMをPassしていない場合である。
DMARC対応となればエンベロープFromのドメインを一致させる方向に動いたと思うが、
それ以前はDKIMの導入で「xxxxx.xxx経由」の表示を消す考えもあったかもしれない。
今日、ちょうどSPFがPassでDMARCがFailとなるメールが届いたんですよね。
Return-Path: <amz@shxiudada.com> DMARC-Filter: OpenDMARC Filter v1.4.2 hdmr.org 9CE2FDBA40 Authentication-Results: hdmr.org; dmarc=fail (p=quarantine dis=none) header.from=mastercard.com
Authentication-Results: hdmr.org; spf=pass smtp.mailfrom=shxiudada.com
From: "MasterCard" <info@mastercard.com>
Authentication-Resultを見るとspf=passとなっているが、
同ヘッダーには検証されたドメインの名前が書いてあるがヘッダーFromとはまるで一致しない。
なので、DMARCの判定においてはこの結果は利用しないということになる。
DKIMについてはそもそも署名なし。
その上でヘッダーFromのmastercard.comのDMARCポリシーは存在しているので、
DMARCの判定をして、SPF無効・DKIMなしで dmarc=failと判定。
p=quarantineと記載されているので、迷惑メールとして扱うのが相当とわかる。
導入早々わかりやすい例がきてDMARCの効果を確認出来た。