メール認証

メール認証とは、受信メールサーバーがメッセージを本当にそれが名乗るドメインから送られてきたのかを検証し、そうでない場合は拒否できるようにする、DNS ベースの標準規格の総称です。 この役割を担うのが 3 つの中核標準です。SPF はどのサーバーがあなたのドメインとして送信してよいかを認可し、DKIM はメッセージが改ざんされていないことを証明する暗号署名を付与し、DMARC はその両方を可視の From アドレスに結び付け、チェックに失敗したときに受信側が何をすべきかを指示します。

SPF、DKIM、DMARC を組み合わせることで、「誰も信頼しない」オープンなプロトコルは、受信プロバイダーがあなたの正当なメールとなりすましを見分けられるものへと変わります。このハブでは、各標準が何を証明するのか、それらがどのように組み合わさって 1 つの重層的な判定になるのか、そしてそれぞれをさらに深く学ぶにはどこを参照すればよいのかを解説します。

なぜメール認証が存在するのか

ほぼすべてのメールを運ぶプロトコルである SMTP は、相互信頼を前提とした時代に設計されました。送信者が名乗るとおりの本人であるかを確認する仕組みは、もともと備わっていません。誰でもメールサーバーに接続し、From アドレスを何にでも設定できます。あなたの銀行、あなたの CEO、あるいはあなた自身のドメインでも構いません。基盤となるプロトコルには、それを止めるものが何もないのです。

攻撃者が悪用するのは、まさにこの隙間です。メールなりすましは送信者アドレスを偽装してメッセージを正当に見せかけ、フィッシングキャンペーンはそれに便乗して認証情報を盗み、請求書の送金先を変え、あるいはマルウェアを仕込みます。メール認証は、検証可能なシグナルを DNS に公開することでこの隙間を塞ぎます。あなたのドメインと秘密鍵を掌握しない限り、偽造者には偽れないシグナルです。これらのシグナルが整い、強制されていれば、なりすましメールは受信トレイに届く前に検出され、拒否されます。

SPF、DKIM、DMARC を一目で

各標準はそれぞれ異なる問いに答え、それぞれ異なる場所に置かれます。以下がその対応関係です。

標準	何を証明するか	どこに置かれるか
SPF	接続してきたサーバーがあなたのドメインとして送信する権限を持っている	ドメインの DNS 内の TXT レコード
DKIM	メッセージが有効な暗号署名を持ち、転送中に改ざんされていない	メッセージ上の署名ヘッダー。DNS 内の公開鍵に照らして検証される
DMARC チェッカー	SPF や DKIM が合格し、かつ可視の From ドメインと整合しているうえ、失敗時のポリシーを備えている	DNS 内の TXT レコード。受信側が適用する

SPF と DKIM は、それぞれパズルの 1 ピースを検証します。DMARC は、それらのピースが受信者の目に触れるアドレスを実際に保護しているかどうかを判断する層です。

3 つがどのように連携するか

この 3 つの標準は、受信サーバーがすべてのメッセージに対して実行する重層的なチェックを形成します。

まず、SPF は接続してきた IP アドレスを見て、あなたのドメインの SPF レコードがその IP に送信を認可しているかを問います。これはエンベロープ、つまりメッセージそのものではなくサーバーを検証します。

次に、DKIM はメッセージに付与された暗号署名を、あなたの DNS に公開された公開鍵に照らして検証します。有効な署名は、署名後にメッセージ本文と主要なヘッダーが改ざんされていないことを証明します。

そして、DMARC はその両方の結果を、受信者が実際に From 欄で目にするドメインに結び付けます。DMARC は整合性を要求します。SPF または DKIM に合格したドメインが、From ドメインと一致していなければなりません。これが重要なのは、なりすまし者が自分の管理下にあるドメインについて SPF や DKIM を簡単に合格させられるからです。整合性こそが、そのチェックをあなたのドメインへと向けさせるものです。

決定的に重要なのは、DMARC は SPF か DKIM の少なくとも一方が合格し、かつ整合していることを必要とするという点です。DMARC 単独では何も認証しません。DMARC は、SPF と DKIM に実効性を与えるポリシーと整合性の層なのです。整合性が失敗したとき、DMARC はあなたが公開した強制を適用します。none（監視のみ）、quarantine（迷惑メールへ振り分け）、あるいは reject（メッセージを即座に拒否）です。none から reject へ移行することが、なりすましを傍観する状態から、それをブロックする状態へと進む道筋です。

一対一で比較する

3 つの標準は目的が重なり合う一方で仕組みが異なるため、ペアで比較すると理解が深まります。以下の各ガイドは 1 つの比較を掘り下げ、それぞれが何を証明し、どこが違い、なぜ通常は両方が必要なのかを解説します。

• SPF vs DKIM — サーバー認可とメッセージ署名。
• DKIM vs DMARC — 署名と、整合性およびポリシー。
• SPF vs DMARC — 経路認可と強制。

主要 3 標準の先へ

より新しい 2 つの標準が、認証済みの基盤の上に構築されています。

BIMI（Brand Indicators for Message Identification）は、対応する受信トレイにおいて、認証済みメッセージの隣にあなたの検証済みロゴを表示できるようにします。これは DMARC が quarantine または reject で強制されて初めて機能するため、基礎を正しく整えたことへのご褒美であって、それらの代替ではありません。詳しくは BIMI ガイドをご覧ください。

MTA-STS（Mail Transfer Agent Strict Transport Security）は、送信サーバーに TLS 暗号化を要求させ、傍受のリスクにメッセージをさらすダウングレード攻撃を拒否させることで、転送中のメールを保護します。SPF、DKIM、DMARC が送信者を検証するのに対し、MTA-STS は接続そのものを保護します。設定については MTA-STS ガイドをご覧ください。

3 つすべてを正しく整える

レコードが有効かどうかを推測する必要はありません。専用ツールで各層を構築し検証しましょう。送信者ポリシーは SPF Checker で確認し、署名が公開され正しく解析されることは DKIM Lookup で確かめ、整合性とポリシーは DMARC チェッカー で検証します。

設定を静かに壊す最も一般的な原因は、10 ルックアップ制限を超える SPF レコードです。レコード内のすべての include、a、mx、redirect がカウントされ、DNS ルックアップが 10 を超えた瞬間、SPF は permerror を返します。レコードが一見問題なさそうでも、正当なメールが認証に失敗し始めるのです。AutoSPF は、あなたのレコードをコンパクトで常に有効な IP のセットへとフラット化し、送信者が変わっても制限内に保ち続けることで、これを自動的に防ぎます。この失敗モードが二度と再発しないようにします。

よくある質問

メール認証とは何ですか？

メール認証とは、受信メールサーバーがメッセージを本当にそれが名乗るドメインから送られてきたのかを検証できるようにする、DNS ベースの標準規格の集まり — 主に SPF、DKIM、DMARC — です。SMTP には送信者検証の仕組みが組み込まれていないため、これらの標準は偽造者に偽れないシグナルを公開し、受信プロバイダーがなりすましやフィッシングメッセージを検出しブロックできるようにします。

SPF、DKIM、DMARC の違いは何ですか？

SPF はどのサーバーがあなたのドメインのメールを送信してよいかを認可します。DKIM はメッセージが転送中に改ざんされていないことを証明する暗号署名を付与します。DMARC は整合性を通じて両方の結果を可視の From アドレスに結び付け、チェックに失敗したときに受信側が何をすべきかを指示します。SPF と DKIM はそれぞれ 1 ピースを検証し、DMARC はそれらを強制可能なポリシーへとまとめ上げます。

SPF、DKIM、DMARC の 3 つすべてが必要ですか？

はい。SPF と DKIM はそれぞれ全体像の一部しかカバーせず、DMARC は受信者が実際に目にするアドレスを保護できるようになる前に、少なくとも一方が合格し整合していることを必要とします。どの層を省いても隙間が残ります。DMARC がなければ強制がなく、SPF も DKIM もなければ DMARC が整合をとる相手が何もありません。

SPF、DKIM、DMARC のうち、どれを最初に設定すべきですか？

SPF から始めましょう。公開が最も簡単で、他の層がそれに依存しているからです。次に DKIM を追加し、メッセージが検証可能な署名を持つようにします。DMARC は最後にデプロイし、まずはポリシー none でレポートを監視し、その後 quarantine へ、そして正当なメールが合格し整合していることを確認したら最終的に reject へと強化していきます。