SPF・DKIM・DMARCの図解、設定の確認方法――GmailもOutlook.comも、なりすましメールを防ぐべく「DMARC必須」：意外と知らないメールサーバ構築・運用の基本（7）

　このように、DMARCはもはや「できれば導入した方がよい技術」ではなく、「導入しなければ確実に不利になる条件」に変わりつつあります。

メールプロバイダーがDMARCを推進する理由

　こうした動きの背景にあるのは、スパムメールの流通量を抑制し、メールエコシステム全体の健全性を保ちたいという、メールプロバイダー側の強い問題意識です。

　従来の迷惑メール対策は、受信側でスコアリングやフィルタリングすることでスパムメールを隔離する方法が主流でした。しかし、それでは対応しきれない巧妙ななりすましやフィッシングも増加し、ユーザー保護の限界が見えてきています。

　そこで、DMARCの導入を促進することで、「なりすましを根本からブロックし、スパムの流通自体を抑えよう」としているのです。

SPF・DKIM・DMARCとは？　送信ドメイン認証の基本

　このように、主要なメールサービスが送信ドメイン認証を求める中で、メールを届けるためには技術的な仕組みの理解が欠かせません。ここでは、SPF・DKIM・DMARCの3つについて、それぞれの仕組みを整理します。

SPF（Sender Policy Framework）

　SPFは、そのドメイン名を使ってメールを送信するIPアドレスを公表しておくことで、受信側が送信元サーバの正当性を確認できるようにする仕組みです。

　導入するには、送信を許可するメールサーバ情報をSPFレコードの形式で記述し、DNS（Domain Name System）にTXTレコードとして登録します。

SPFの仕組み

DKIM（DomainKeys Identified Mail）

　DKIMは、送信時に電子署名をメールに付与し、受信側が公開鍵を使って署名を検証することで、「メールが送信途中で改ざんされていないこと」「そのドメインのメールサーバから送られたこと」を確認できる仕組みです。

　導入するには、メールサーバにDKIM署名の仕組みを実装し、公開鍵をDNSにTXTレコードとして登録する必要があります。外部のメールサービスで署名する場合は、サービスで指定されたTXTレコードを登録するだけで対応可能です。

DKIMの仕組み

DMARC（Domain-based Message Authentication, Reporting and Conformance）

　DMARCは、SPFやDKIMによって認証した上で、「それらの認証に合格したドメインとヘッダFromのドメインが一致しているかどうか（＝アライメント）」を確認することで、ヘッダFromのなりすましを防ぐ仕組みです。

　導入するには、ドメインのDNSにDMARCレコードをTXTレコードとして登録します。DMARCレコードでは、DMARCポリシーやレポートの送信先なども指定できます。

DMARCの仕組み

DMARCの「アライメント」とは？

　なぜDMARCがアライメントを重視するかというと、ヘッダFromのドメインと関係のないドメインでのSPF・DKIMの認証や巧妙ななりすましメールを防ぐためです。

メッセージソース（ヘッダ情報）を確認すると……

　たとえSPFやDKIMの認証が通っていても、もしアライメントが取れていない場合、DMARCとしては認証失敗と判定されてしまいます。

SPFアライメント：エンベロープFromとの整合性

　SPFは、メールの配送時に使用されるReturn-Path（＝エンベロープFrom）のドメインと、送信元IPアドレスの関係を検証するものです。

　DMARCのSPFアライメントは、SPFで認証したエンベロープFromのドメインと、ヘッダFromのドメインが一致しているかどうかをチェックします。

　外部のメール配信サービスなどを利用している場合は、デフォルトでそのサービスドメインが設定されているケースがあり、アライメントが不一致になることがあります。

DKIMアライメント：署名ドメインとの整合性

　DKIMは、電子署名の検証時に、メールの署名に使用されたドメイン（d=）から、そのドメインのDNSに登録された公開鍵を取得する仕組みです。

　DMARCのDKIMアライメントは、署名に使われたドメイン（d=）と、ヘッダFromのドメインが一致しているかどうかをチェックします。

　外部のメール配信サービスを利用していて、そのサービスのドメインでDKIM署名を行っている場合、アライメントが不一致となってしまうので、自社ドメインで署名するようにカスタマイズが必要です。

自社は大丈夫？　SPF・DKIM・DMARC対応状況の確認方法

　SPF・DKIM・DMARCの導入自体は進んでいますが、意図せぬ設定ミスや、外部サービス利用によるアライメント不一致などにより、認証エラーが発生しているケースもあります。ここでは、自社の認証状況を確認するための基本的な方法を紹介します。

SPF・DKIM・DMARCが設定されているかどうか確認する

　まずは、ドメインに設定されているSPF・DKIM・DMARCのレコードを確認しましょう。

• SPF：ドメインのTXTレコードにv=spf1で始まるレコードがあるかどうかを確認する
• DKIM：selector._domainkey.example.comの形式で公開鍵のTXTレコードが登録されているかどうかを確認（セレクタ名はメールヘッダなどから確認）する
• DMARC：_dmarc.example.comにv=DMARC1で始まるレコードがあるかどうかを確認する

　確認には「MxToolBox」のようなツールを使うと、レコードの構文エラーなども含めチェックできるため便利です。

DMARCレポートを受け取り、認証状況を確認する

　DNSレコードが正しく設定されていても、「認証が成功している」とは限りません。送信メールが認証に成功しているかどうかをチェックするには、1通ずつメールヘッダを見ることもできますが、DMARCレポートを確認するのが効率的です。

　DMARCレコードに「rua=パラメーター」を追加すると、メール受信側から認証結果の集計レポート（RUAレポート）を受け取ることができます。

v=DMARC1; p=none; rua=mailto:[email protected];

　このレポートには、自社ドメインをヘッダFromに設定して送信されたメールについて、送信元IPアドレス、SPF・DKIMの認証結果、アライメントの結果などの情報がまとめられています。レポートを確認することで、どのIPアドレスから送信されたメールが認証に失敗しているのかどうか、そしてその原因は何か把握できます。

　ただし、DMARCレポートは、メールプロバイダーごとに日次でXML形式のファイルが送信されてくるので、人力で集計、確認するのは現実的ではありません。レポートの分析には、オープンソースの分析ツールや、有料の分析サービスなど、集計を自動化する仕組みを用意するようにしましょう。

　「SPF・DKIM・DMARCは設定したから終わり」ではありません。自社のメールの認証に問題がないかどうかをチェックすることで、迷惑メール扱いを防ぐことができます。

DMARCはポリシーを上げるまでがゴール

　DMARCレポートを分析することは、自社の認証状況の把握だけでなく、DMARCポリシーを強化するためにも不可欠です。

　DMARCには、認証失敗時のメールの扱いを明示するための「ポリシー（p=）」というパラメーターがあり、以下の3つから選ぶことができます。導入時はp=noneでの設定が推奨されますが、最終的にrejectまで上げることを目指すべきです。

なぜポリシーを強化すべきなのか

　quarantineやrejectにポリシーを上げることで、ようやくDMARCはなりすましメールに対して実効的な制御力を持ちます。

　現時点では、GmailやOutlookなどのガイドラインにおいて、DMARCの「ポリシーの強化」は明示的な要件には含まれていません。しかし、なりすましメールの流通を抑制するというDMARC本来の目的を踏まえると、将来的にはquarantineやrejectの設定まで求められる可能性も十分に考えられます。

　また、DMARCのポリシーがnoneのままでは、認証に失敗したメールでも受信側に届いてしまうので、攻撃者に悪用されるリスクが残ります。DMARCの導入が進んだ現在では、設定がないドメインだけでなく、ポリシーが緩いドメインもなりすましの標的になりやすい状況にあるのです。

　自社ドメインがなりすましに悪用されてしまうと、受信側の評価システムによってドメイン全体のレピュテーションが下がり、正当なメールの到達率にまで悪影響が及ぶ恐れがあります。

　このように、ポリシーの設定は単なるオプションではなく、自社のドメインを守るために欠かせない仕組みなのです。

まとめ

　Gmailをはじめとする主要なメールサービスが送信者要件を強化する中で、DMARCの導入は、今やメールの到達率を維持、向上させるための必須条件となりつつあります。加えて、将来的な変化に備えるという観点からも、DMARCポリシーの強化に向けて準備を進めることが重要です。

　次回は、メール配信を安定して運用するためのポイント、「メールが届かない」「迷惑メールに入る」といったトラブルの調査・対処方法について解説します。送信ドメイン認証だけでは解決できない問題にどう向き合うべきか、現場で役立つ視点をお届けします。