DMARCの認証ってSPFやDKIMと何が違うんですか？を説明してみる。
よくある質問「メール認証ならSPFやDKIMがあるのに、なんでDMARCがあるんですか？」
こんにちは、株式会社WOW WORLDの藤田です。メール送信のお仕事をしていて最近よくある質問に「メールの送信ドメイン認証って、SPFがあってDKIMがあって、さらにこのDMARC……このDMARCって何ですか？」があります。
このDMARCがSPFやDKIMという他の送信ドメイン認証と、どう違って、どんなメリットがあって、どんな注意点があるのかを書いていきます。
今回は「DMARCの判定がSPFやDKIMという他の送信ドメイン認証とどう違うか」です。次回以降、DMARC導入のメリット、DMARC導入時の注意点について解説します。（ですので今回は、DMARCをこう設定する、という内容ではありません。）
DMARCが他の送信ドメイン認証と違う点の1つは、「DMARCがpassしている＝メールを受信した人が見る"送信者のドメイン"から来たメールであることが認証されている」ということです。
「SPF・DKIMはそうじゃないの？SPF・DKIMがpassしていたらメールにある送信者のドメインから来たメールであることが認証されていないの？」という疑問を持つ方がいると思います。答えは「はい」です。SPF・DKIMは、認証されたからといってメールにある送信者から来たかというと（規格としては）無関係です。
ときおり、メールに関するBlogで「SPFとDKIMとDMARCを設定するとメールがちゃんと届いていいよ」といった記載があります。いずれも設定するのは設定しないよりずっといいのですが、3つの送信ドメイン認証の中で、DMARCはしていることが全然違うよ、と読むたび思うわけです。
SPFやDKIMの送信ドメイン認証は何のドメインを認証しているのか、そして、DMARCの送信ドメイン認証とはどういう仕組みなのか、順を追って説明します。
SPF・DKIM・DMARC、3つの送信ドメイン認証のドメインは何を指しているか？
インターネットのメール送信に使用されるSMTP自体は「メールの送信者が正当である」と送る側が主張し、それを受け取る側が検証する仕組みを有しません。そのため、送信ドメイン認証という仕組みが2000年代後半から普及し、2022年現在インターネットへ送信する正当なメールのほとんどはSPF・DKIMどちらかの送信ドメイン認証を使用しています。
受け取る側のシステムもSPF・DKIMどちらかの送信ドメイン認証やIPレピュテーションを使用してメールの出元を検証し、受信者に正当なメールを届けるようになっています（それでも迷惑メールが届くときがありますが）。2022年現在、SPF・DKIMどちらかの送信ドメイン認証で認証されていないメールはインターネット広くに届かないと捉えて間違いありません。
※IPレピュテーションについてはこちらを参照
そのインターネットへのメール送信に不可欠な送信ドメイン認証（Email domain authentication）は、送ってきたメールにある何かのドメインに関連付いています。それぞれ見ていきます。
※以下では、SPFやDKIM自体の細かな説明は割愛します。概要は
・SPF＝メールを送ってくるIPアドレスを対象ドメインのDNSに書いておき、そこから来たメールは検証がpass
・DKIM＝メール送信時に秘密鍵を元にした署名をメールに付与して送信、公開鍵をDNSにのせておく。受け取った側は公開鍵をDNSで取得して署名を検証できたらpass
という仕組みです。
SPFでは送信ドメイン認証のドメインは何か？
SPFの「送信ドメイン認証のドメイン」は Envelope-From のメールアドレスにあるドメインです。言い換えると、SPFは Envelope-From のメールアドレスが正しいことを認証された状態、Envelope-From のドメインは信用してよい状態で受信者の手元に届きます。
インターネットのメールには
・Envelope-From：メールを送り中継するシステム（MTA）のため送信者、宛先に届かないと分かったとき、この Envelope-From に戻る
・ヘッダFrom ：受信者が見る届いたメールに表示されている送信者。RFC5322.From とも書かれる。
のように送信者のメールアドレスが2つあります。SPFの対象は Envelope-From です。
そして、Envelope-From は、私達がスマートフォンやPCでメールを見たときに送信者に表示されている「ヘッダFrom」とは異なる場合が多数あります。大雑把には
・人が送ってきたメール＝Envelope-FromとヘッダFromが同じ
・システムが送ってきたメール＝Envelope-FromとヘッダFromが違う、ドメインから違う場合も多い。
という傾向です。
Envelope-From とヘッダFrom がドメインから違う、の例として、勉強会に使われる connpass さんからのメールヘッダを見てみます。
Envelope-From は、届いたメールでは通例 Return-Path というヘッダに記載されます。このメールでは Envelope-From のドメインは @amazonses.com （AWSのサービス）で、ヘッダFromのドメインは @connpass.com です。
このメールをGmailが検証した結果は下のようになります。この結果に書かれたIPアドレスは amazonses.com のものであり、connpass.com は検証結果に関係ありません。
このようにSPFがpassしていても、この場合、amazonses.com のシステムから送信されたことが認証されているもので、SPFだけではメールに表示される送信者（ヘッダFrom）が正しいとは言い切れないのです。
※このconnpassさんのメールはDKIMもあって、そちらで送信者（ヘッダFrom）が正しいと言い切れます。
極端な例を挙げると、
・Envelope-From：user@example.com
・ヘッダFrom (RFC5322.From)："首相官邸" <info@kantei.go.jp>
といったメールを首相官邸にまったく関係ない example.com の持ち主が送信し、受信した側でSPFをpassさせることはできます。けれど、受信者が見る肝心の "首相官邸" <info@kantei.go.jp> はSPFでは認証されたものでなく、送信者は嘘なのです。
なぜ、SPFが ヘッダFrom ではなく Envelope-From を対象にしているかというと、導入の容易さがあります。SPFの対象を ヘッダFrom にすると導入する組織で「私達の ヘッダFrom （のドメイン）でメールを送るシステムはどのシステム？」と洗い出しから始まってしまいます。一方、Envelope-From を対象にすれば、導入の単位はそれぞれメールを送るシステムになるので洗い出しから始めなくてもよくなります。このためSPFは、導入の容易な Envelope-From を対象にしています。
DKIMでは送信ドメイン認証のドメインは何か？
DKIMの「送信ドメイン認証のドメイン」は、 DKIM-Signatureヘッダにある dタグのドメインです。……SPFよりもややこしくなってきました。
実例で見てみましょう。例として
①みんな大好きQuora（Q&Aサイト）から来るメール
②Microsoft365から既定の設定で送信されるメール
2つを見ます。
まず、①Quora（Q&Aサイト）から来るメールのヘッダです。
このメールをGmailが検証した結果はこうなります。
これは、分かりやすい結果です。「DKIM-Signatureヘッダにある dタグ＝DKIMの署名情報に対応する公開鍵があるドメイン」なのですが、DKIMで認証されたドメイン @quora.com は、ヘッダFrom＝送信者メールアドレス（Quoraダイジェスト）のドメインでもあるので、DKIMの設定内容及び検証結果から、このメールは Quora から来たメールと受信者が判断してよいケースです。このように、DKIM-Signatureヘッダにある dタグのドメイン＝送信者メールアドレスのドメインであるDKIMは「作成者署名」と呼ばれます。
次に、②Microsoft365から既定の設定で送信されるメールのヘッダです。手元で作って見ました。
このメールをGmailが検証した結果はこうなります。
これが、分かりづらい結果です。「DKIM-Signatureヘッダにある dタグ＝DKIMの署名情報に対応する公開鍵があるドメイン」が、○○.onmicrosoft.com（○○は会社のIDが入る）です。DKIMの検証結果は、onmicrosoft.com からのメールとしては正当ですよ、というものです。それはヘッダFrom＝送信者メールアドレス（上の例なら@wow-world.co.jp）と関連ないものです。
本当に送信者メールアドレス（@wow-world.co.jp）からメールがきたかどうかは、このDKIMでは分かりません。このような「DKIM-Signatureヘッダにある dタグのドメイン≠送信者メールアドレスのドメイン」であるDKIMは「第三者署名」と呼ばれます。
なぜ、第三者署名のようなDKIMが利用されるかというと、こちらも導入が容易だからです。Microsoft365のような多数の組織が利用するサービスで、利用開始時にDKIMの公開鍵までDNSにのせることを必須にすると、サービス利用時の敷居が高くなってしまいます。それよりは、第三者署名でいいから onmicrosoft.com のDKIMを付与し、受け取る方に「onmicrosoft.com……本当の送信者は信頼できないけど、とにかく Microsoft365 から来たものには間違いないな」と捉えさせることで、メールが届くようにする考えです。（Microsoft365に限らずよくある形態です。）
※Microsoft365ではDKIMを作成者署名にすることを推奨しています。
DMARCでは送信ドメイン認証のドメインは何か？
ようやく本題にたどり着きました。DMARCの「送信ドメイン認証のドメイン」は、受信者が目にするヘッダFrom＝送信者メールアドレスのドメインです。DMARCの検証結果がpassしたメールは、見ているメールの送信者メールアドレスのドメインが正当で信頼できるものです。……ようやく多くの人にとって自然な結果がやってきました。
DMARCの認証は「SPFまたはDKIMどちらかで、受信者が目にする送信者メールアドレスのドメインからのメールであることが認証されていること」がpassの条件です。受信者が目にする送信者メールアドレスですので、ヘッダFrom（RFC5322.From）です。Envelope-Fromではありません。
「DMARCのためにはDKIMが必須」といった記事もインターネットには散見されますがそうではありません。
例えば、
・Envelope-Fromのドメイン＝ヘッダFromのドメインであるメールのみ送る
・SPFは設定済み
という組織であれば、DMARC導入にあたりDKIMは不要です。（DKIMを設定しないほうがいいというものではありません。）
SPFまたはDKIMをpassしたメールが、DMARCでpassするかを表にするとこのようになります。
繰り返すと、DMARCは受信者が目にする送信者のドメインからメールが来たかを認証するもの、です。
終わりと次回・次々回予告
このヘッダFromを元にするというDMARCの性質から
・メリット1.自組織以外からのメール≒フィッシングメールを相手に届かないようにできる（相手が対応していれば）
・メリット2.自組織以外からのメール≒フィッシングメールの送信状況がわかる
といったDMARC固有のメリットが派生します。これを次回説明します。
また、ヘッダFromを元にするというDMARCの性質から、導入時にはシステムごとの対応で済んだSPFやDKIMと比べて、組織全体の対応が必要となります。このような導入時の注意点や望ましい方法を次々回説明します