SPF・DKIM・DMARCとは？3つの違いと仕組みをわかりやすく解説

メルマガや会社のメールを設定するときに出てくる「SPF・DKIM・DMARC」。

どれもメールのなりすまし対策ですが、名前だけでは違いが分かりませんよね。

そもそも、いつもは自分のアカウントにログインして送っているのに、なぜ他人が会社のアドレスを名乗れるのでしょうか。

この疑問が解けると、3つの仕組みが必要な理由も見えてきます。

この記事では、会社から取引先へ見積書メールを送る場面を例に、順番に説明します。

設定を担当する人に「何を確認してほしいか」を伝えられるところまで、一緒に整理しましょう。

この記事で分かること

• なぜ会社のアドレスを、他人が差出人として名乗れるのか
• SPF・DKIM・DMARCは、それぞれ何を確かめるのか
• Web担当者が、自社のメールについて確認したいこと

そもそも、なぜ他人のメールアドレスを名乗れるの？

例えば、営業担当者が「sales@example.com」から見積書を送ったとします。

この記事では架空の会社のアドレスとして使います。

@より後ろの「example.com」が、この会社の「ドメイン」です。

会社のアカウントに入れなくても、会社のアドレスを名乗れてしまう

普段は、Gmailや会社のメールにログインして、自分のアドレスで送信しますよね。

そのため、「会社のアドレスで送れるのは、会社のアカウントにログインできる人だけ」と思うのが自然です。

ところが、メールには意外な落とし穴があります。

会社のアカウントにログインできない第三者でも、差出人欄に会社のアドレスを書いたメールを作れてしまうのです。

例えば、見積書メールの差出人に「sales@example.com」と表示されていても、実際には無関係な人が、自分の設備から送信している可能性があります。

会社のパスワードが盗まれたから、とは限りません。

なぜ、そんなことができるの？

メールの差出人欄は、送る側が「私はこのアドレスの人です」と書き込む情報だからです。

メールをやり取りする基本の仕組みだけでは、その申告が本当かまでは確認しません。

この仕組みを悪用した差出人の偽装は、Cloudflareの解説でも説明されています。

手紙の封筒にも、差出人の名前と住所を書きますよね。

そこに他社の名前を書けてしまうのと同じで、メールにも「名乗ること自体はできてしまう」という問題があります。

普段それができないように見えるのは、利用しているサービス側で制限しているためです。

例えばGmailでは、差出人として別のアドレスを追加するときに、そのアドレスを使えるか確認する手順があります。

一方、なりすましをする人は、その画面を使わず、自分で用意した設備からメールを送ろうとします。

Gmailの送信画面に制限があっても、それだけでは、外から来るメールの差出人まで保証できないのです。

だから、差出人の「自己申告」以外も確認する

受け取る側が「差出人に会社のアドレスが書いてあるから、この会社のメールだ」と信じてしまうと、なりすましを見抜けません。

そこで、「このメールは、送信に使うことを許可された設備から来たのか」も確認します。

そのための仕組みの一つが、SPFです。

ただし、SPFだけで画面の差出人を完全に確かめられるわけではありません。

まずはSPFが何を調べるのかを見てから、DKIM・DMARCがどこを補うのかへ進みましょう。

SPFは「会社が許可した送信設備か」を調べる

では、受け取る側は、何を手がかりに送信設備を確かめるのでしょうか。

手がかりになるのは、メールを出す会社が公開しておく「使ってよい送信設備のリスト」です。

メールの送信を担うコンピューターを「メールサーバー」といいます。

会社の担当者は、利用しているメールサービスの送信サーバーを、このリストに登録します。

例えば、メールサービスAを使っているなら、Aのサーバーを許可するわけです。

取引先のメールサービスは、メールが来たときに、そのリストと実際の送信サーバーを照合します。

リストに載っていれば「許可されたサーバーから来た」、載っていなければ「このリストでは、許可を確認できない」と分かります。

この照合を行う仕組みが、SPF（エスピーエフ）です。

SPFの基本は、Cloudflareの解説でも紹介されています。

差出人の名乗りだけで信用せず、送信サーバーが許可されているかも確かめる。それがSPFの役割です。

ただし、SPFが調べるドメインは、画面の差出人と違うことがあります。

メールには、画面表示用とは別に、配達できなかったときのエラー連絡に使う送信元アドレスもあるためです。

SPFが主に確認するのは、このエラー連絡用アドレスのドメインです。詳しい確認対象はSPFの技術仕様に定められています。

例えば、画面には会社のアドレスを出し、エラー連絡はメルマガ配信サービス側で受け取る、という使い方もあります。

その場合、SPFの確認に成功しても、確認できたのは配信サービス側のドメインです。

画面の差出人まで確かめるために、あとで説明するDMARCを使います。

DKIMは「メールに付けた封印が正しいか」を調べる

DKIM（ディーキム）は、送るメールに、そのドメイン用の封印を付けるような仕組みです。

受け取る側は「そのドメインの封印として正しいか」「封印を付けた内容が途中で変わっていないか」を調べます。

実物の印鑑を押すわけではありません。

送信側のメールサービスが、メールの内容と、秘密に持っている情報を使って、照合用のデータを作ります。

このデータを「電子署名」と呼び、メールに付けて送ります。

例えば、見積書の本文などをもとに、example.com用の電子署名を付けて送ったとします。

途中で誰かが署名の対象になった金額などを書き換えると、受信側が確かめたときに、署名と内容が合わなくなります。

また、署名を作るための秘密の情報を持たない第三者は、正しい署名を勝手に作れません。

DKIMは、そのドメインの電子署名が正しいか、署名を付けた内容が保たれているかを調べます。

この封印のたとえは、途中の書き換えを確かめるためのものです。

DKIMを付けても、メールの内容が読めなくなるわけではありません。

受信側には、署名を確かめるための情報だけをDNSで公開します。

「作るための情報は秘密にする」「確かめるための情報は公開する」と使い分けているわけです。

この仕組みは、CloudflareのDKIM解説で確認できます。

なお、DKIMで署名を付けるドメインも、自社とは限りません。

配信サービス側のドメインで署名する場合もあるからです。

「正しい署名だった」と分かっても、それがどのドメインの署名なのか、もう一つ確認が必要です。

DMARCは「その確認結果は、画面の差出人のものか」を調べる

例えば、誰かが「あなたの会社の担当者です」と訪ねてきたとします。

その人が見せた社員証は本物でも、別の会社の社員証だったら、あなたの会社の担当者だという証明にはなりませんよね。

メールにも、これと似た確認が必要です。

SPFで許可されたサーバーだと分かっても、DKIMの署名が正しくても、「どのドメインについて確認できたのか」を見ないと、画面の差出人と結びつきません。

今回の見積書メールなら、画面の差出人は「sales@example.com」です。

ところが、確認できたのが別の人の「example.net」だけだったらどうでしょうか。

example.netの認証に成功しても、example.comの会社から来た証拠にはなりません。

DMARC（ディーマーク）は、SPFやDKIMで確認できたドメインが、画面の差出人のドメインと合っているかを調べます。

今回なら、example.comの確認が必要です。

DMARCに合格するには、SPFまたはDKIMの少なくとも一方で、確認に成功し、差出人のドメインと一致する条件を満たさなければなりません。

この条件は、Googleのメール認証ガイドラインにも示されています。

両方を設定することは大切ですが、メール1通がDMARCに合格する条件は「必ず両方とも成功すること」ではありません。

なお、設定によってはexample.comとmail.example.comのような関係も一致として扱います。

確認できなかったメールの扱いも伝える

DMARCには、もう一つ役割があります。

会社の管理者が「このドメインを名乗っているのに確認に失敗したメールは、こう扱ってほしい」と、受信側に方針を伝えられます。

これは受信側への依頼なので、最終的には受信側のメールサービスの判断も関わります。

noneにすれば、必ず受信箱に届くという意味ではありません。

また、レポートの送信先を設定すると、対応する受信サービスから認証結果などの報告を受け取れます。

自社の正規のメールに設定漏れがないか、調べる材料になります。

方針とレポートの役割は、JPNICのDMARC解説でも整理されています。

3つの違いを、見積書メールの例で整理しよう

SPF・DKIM・DMARCは、同じ検査を3回行っているわけではありません。

どこを確かめるかが違います。

例えば、メールが転送されると、最後に送ってきたサーバーが変わり、SPFの確認に失敗する場合があります。

それでも、内容が変わらずDKIMの署名が有効なら、そちらで確認できる場合があります。

こうした違いは、SPFの技術仕様とDKIMの技術仕様で扱われています。

SPFとDKIMで別の手がかりを調べ、DMARCで画面の差出人と結びつける。この組み合わせで確認します。

認証できたら、メールの内容も安全？

そこまで確認できるわけではありません。

例えば、会社のアカウントを乗っ取られ、正規のメールサービスから、振込先を書き換えた見積書を送られたとします。

送信元の認証に成功しても、その見積書の内容が正しいとはいえません。

Web担当者は、自社の何を確認すればよい？

最初にすることは、会社のアドレスを使ってメールを送るサービスを書き出すことです。

普段の業務メールだけでなく、メルマガ、請求書サービス、問い合わせフォームの自動返信なども含みます。

例えば、営業担当者の見積書メールは正しく設定できていても、新しく使い始めたメルマガ配信サービスは未設定、ということがありえます。

同じ会社のアドレスを表示していても、実際に送るサービスが違えば、別途設定の確認が必要です。

一覧ができたら、社内のメール管理者や、設定を担当した制作会社へ渡します。

「このサービスから送るメールも、会社のメールとして認証できるか確認したい」と伝えれば、相談を始められます。

会社で使う送信サービスを一覧にし、それぞれのメールが認証できるか、担当者に確かめてもらいましょう。

設定は、メールサービスの管理画面と、ドメインのDNS設定の両方に関わります。

DKIMでは署名を付ける側の設定も必要なので、DNSに情報を書くだけで終わるとは限りません。

DNSから知りたい方は、こちらの記事も参考にしてください。

DMARCで受け取りの拒否を求める前には、会社の正規のメールが認証できているかを確認します。

メルマガ配信サービスなどの設定が抜けたまま方針を厳しくすると、本来届けたいメールまで拒否されるおそれがあるためです。

また、認証に成功しても、受信側の別の判定で迷惑メールになることはあります。

「設定項目を埋めたか」だけで終わらせず、実際に送ったメールの認証結果と到着を、セットで確かめてもらってください。