メールに表示されている差出人アドレスだけでは、本当にそのドメインから送られたか判断できません。
まずSMTPの仕組みを確認し、送信元を調べるSPF、電子署名を検証するDKIM、両者の結果を利用するDMARCの順に説明します。
SMTPでは差出人アドレスを偽装できる
SMTPは、メールをサーバー間で送るための通信方式です。SMTPでメールを送る際、送り主の情報には MAIL FROM と From という2つの異なる情報があり、送信側が指定します。画面に表示されるのは通常、 From です。
なぜ同じような概念が2つあるのかというと、例えば、ある会社が外部のメール配信サービスを使用する場合、Fromはその会社の従業員、MAIL FROMはそのメール配送サービスのアドレス、という風に分ける事ができるようにするためです。
SMTPの基本的な仕組みだけでは、第三者が他人のアドレスを差出人(From)に指定して、なりすますことができます(これは仕様上そうなっているから仕方が無い)。
従って、通常画面に現れないMAIL FROMを検証する仕組みとして SPF が必要になります。
SPF：DNSに送信を許可するサーバーを登録する
SPFは、接続してきたメールサーバーのIPアドレスを確認する仕組みです。ドメイン所有者は、そのドメインのDNSゾーンに、送信を許可するサーバーをTXTレコードとして登録します。これをSPFレコードと呼びます。
受信側は、配送用の差出人 MAIL FROM のドメインについてSPFレコードを調べ、実際の送信元IPアドレスが許可されているか照合します。
送信元IP：192.0.2.10
公開された送信許可を確認
そのドメインの送信元を確認
たとえば、example.com に次のTXTレコードを登録すると、192.0.2.10 を送信元として許可し、それ以外をSPFの失敗として扱う方針になります。
v=spf1 ip4:192.0.2.10 -allSPFが失敗したメールを拒否するかなどの最終的な処理は、受信側が判断します。
SPFが確認するのは、送信元IPアドレスが配送用の差出人ドメインから許可されているかどうかです。画面に表示されるFromのドメインとの一致までは確認しません。
一方、送信元IPアドレスではなく、メールに付けた電子署名を使って認証する仕組みもあります。それがDKIMです。
DKIM：秘密鍵で署名し、DNSの公開鍵で検証する
DKIMは、メールに電子署名を付ける仕組みです。送信側が秘密鍵を保持し、対応する公開鍵をDNSのTXTレコードで公開します。これをDKIMレコードと呼びます。
- 送信側が、本文と選択したヘッダーから計算したデータに、秘密鍵を使って電子署名を付けます。
- メールの
DKIM-Signatureヘッダーに、署名、署名ドメイン（d=）、鍵の識別名であるセレクター（s=）などを入れて送信します。 - 受信側がDNSから対応する公開鍵を取得し、署名を検証します。署名が正しく、署名対象の内容が検証に一致すればDKIM成功です。DKIMの仕様（RFC 6376）
電子署名を付けて送信
DKIMレコードを検索
DKIMの成功・失敗を判定
DKIMは、メール本文を暗号化する仕組みではありません。 本文を読めない状態にするのではなく、署名を検証することで、署名したドメインと署名対象の改変の有無を確認します。
ここまでのSPFとDKIMでは、それぞれ「送信元を許可したドメイン」「電子署名を付けたドメイン」を確認できます。ただし、どちらも、それだけでは画面に表示されるFromのドメインとの一致を保証しません。
そこで使うのがDMARCです。SPFまたはDKIMの認証結果と、Fromのドメインとの一致を確認します。
DMARC：認証結果をFromのドメインと結び付ける
DMARC（ディーマーク) は、SPF・DKIMの認証結果を利用し、画面に表示されるFromのドメインとの一致を確認する仕組みです。さらに、認証に失敗したメールの扱いをドメイン所有者が受信側に伝えられます。
DMARCは、SPF・DKIMで認証したドメインと、差出人欄のドメインが一致するかを確認します。この一致の確認を「アラインメント」と呼びます。Microsoftの解説
SPF・DKIM・DMARCの役割
SPFは送信元のIPアドレス、DKIMはメールに付けられた電子署名を確認します。DMARCはそれらの認証結果を差出人欄のドメインと結び付けて判定します。
送信元サーバーのIPアドレスが、配送用の差出人ドメインから送信を許可されているか確認します。配送用の差出人は、画面に表示されるFromとは異なる場合があります。
送信側が付けた電子署名を検証し、署名したドメインと、署名対象の本文・ヘッダーが改変されていないかを確認します。
SPFまたはDKIMが成功し、その認証で使われたドメインがFromのドメインと一致すれば合格です。失敗した場合の扱いも、ドメイン所有者が指定できます。
SPF・DKIMの両方が成功する必要はありません。少なくとも片方が「認証成功＋ドメイン一致」を満たせば、DMARCは合格です。 認証に成功していても、別ドメインの認証であれば、その結果だけではDMARCは合格しません。Microsoftの解説
受信側ではどのように判定するのか
ドメイン所有者は、DNS（ドメインの設定情報を公開する仕組み）に、DMARCの設定を登録します。受信側のメールサーバーが、その設定と認証結果を使って処理します。
DMARC設定をDNSで取得
Fromのドメインを比較
ポリシーを参照
たとえば、Fromが info@example.com で、example.com のDKIM署名を正しく検証できれば、DKIM側の条件でDMARCは合格します。
一方、SPFが成功しても、その対象がFromとは無関係な other.example で、DKIM側の条件も満たさなければ、DMARCは失敗します。
認証に失敗したメールの扱い
ドメイン所有者は、DMARCの設定で失敗時の**ポリシー（処理方針）**を指定します。Cloudflareの解説
DMARC失敗を理由にした隔離・拒否は要求しません。導入時の状況確認に使います。
迷惑メールフォルダーへの振り分けなど、通常の受信と分けた扱いを求めます。
DMARCに失敗したメールを、受信しないよう求めます。
また、報告先を設定すると、対応する受信側から認証結果の集計レポートを受け取れます。送信元や認証の成功・失敗を把握するために使います。Googleの導入ガイド
導入時に確認すること
- 普段のメールに加え、問い合わせフォームや配信サービスなど、ドメインを使う送信元を把握する。
- 各送信元で、SPFまたはDKIMの認証と、Fromのドメインとの一致を確認する。
- まず
p=noneと集計レポートで状況を確認し、正規メールへの影響を調べてから隔離・拒否へ移行する。
転送やメーリングリストでは認証結果が変わることもあります。送信元の確認をせずに拒否へ切り替えると、必要なメールが届かなくなる可能性があります。Googleの導入ガイド
DMARCはFromのドメインのなりすましを減らすための技術です。似た別ドメインや表示名だけの偽装、正規アカウントの乗っ取り、本文・リンク先の危険性まですべて判定できるものではありません。