Gmailが「メール送信者のガイドライン」を改訂し、なりすましメールへの対策を強化する旨を発表しています。今までは原則、なりすましメール対策の有無にかかわらず、メールはいちおうは届いていました。しかし今後は、なりすましとみなされたメールは届かなくなる方向に向かいつつあります。

なりすましメールとみなされないようにするために、メール送信者には、「メール送信ドメイン認証」への対応が求められます。メール送信ドメイン認証の技術には、主に以下の3つがあります。

• SPF: Sender Policy Framework (RFC 7208)
• DKIM: DomainKeys Identified Mail (RFC 6376)
• DMARC: Domain-based Message Authentication, Reporting, and Conformance (RFC 7489)

SPFは従来からよく利用されており、DKIMも普及が進んできていましたが、DMARCはまだそれほど広く普及していませんでした。しかし、GmailのガイドラインではDMARCへの対応も求められています。メール送信者の多くは、今回、DMARC対応に初めて直面することになります。

DMARCの設定については、各所で解説記事なども出ていて、情報はそれなりに充実しているように見えます。初心者向けの解説では、以下のように説明されていることがあります。

• SPF/DKIMと組み合わせて利用し、それらの判定に失敗した際のポリシーを指定する
• DNSにTXTレコードを設定するだけで、すぐ設定完了
• DMARCレポートというものを受け取れるので、それを見るようにすると良い

こうみると、SPF/DKIMが設定できていれば、すぐに対応できそうに見えます。このような説明は間違いとまでは言えないのですが、実際のところ、DMARCの設定には注意点や、検討が必要な点が多くあります。ここでは、そのようなDMARCの注意点について、いくつか見解を述べてみたいと思います。

• DMARC Failをなめるな
• 影響範囲をなめるな
• DMARCレポートをなめるな
• ポリシー設定をなめるな
• まとめ

DMARC Failをなめるな

「DMARCはSPF/DKIMと組み合わせて利用し、それらの判定に失敗した際のポリシーを指定するものである」という説明をよく見かけます。この説明は間違いではありませんが、説明不足です。実は、SPF/DKIMで認証に成功していても、DMARC自体の判定で認証失敗となる場合があるのです。

SPFやDKIMには、メールヘッダのFromのなりすましを防げないという問題があります。

• SPF: エンベロープFromに基づいてチェックを行う。メールヘッダのFromは見ていない
• DKIM: メールヘッダのFromの改ざん有無をチェックする機能はあるが、送信者が意図的に他人のFromを騙って送信した場合は検出できない

そのため、DMARCでは"Identifier Alignment"という概念を導入し、メールヘッダのFromのなりすましをチェックするようにしました。

• SPF Alignment: メールヘッダのFromとエンベロープFromのドメインが一致しているかチェックする
• DKIM Alignment: メールヘッダのFromとDKIM-Signatrueのd=のドメインが一致しているかチェックする

SPFとDKIMが両方使われていれば両方ともチェックします。DKIMが複数設定されていれば、それもすべてチェックします。それらのうち、いずれかでドメインの一致が見られればDMARC Pass、すべてが不一致であればDMARC Failとなります。

DMARCを有効にすると、このAlignmentのチェックが行われるようになります¹。SPFとDKIMで認証に成功していたはずのメールが、DMARCを設定したら認証に失敗するようになったという状況があり得るのです。そうならないように、既存メールのAlignmentに問題がないかを事前に確認しておく必要があります。

影響範囲をなめるな

既存メールのAlignmentを確認する、というのは一見簡単そうです。しかし、企業はさまざまなメールを送信しています。たとえば、Webサービスを運用する企業であれば、以下のようなメールを送信していることでしょう。

• 通常のメーラーを使ってやり取りする1対1のメール
• 1対1だが、顧客管理のシステムから送信されるメール (CRMやカスタマーサポートツールなど)
• 多数の顧客に同時に配信するマーケティングや告知などのメール
• 自社サービスのシステムからユーザーに向けて自動配信されるメール (アカウント登録時の電子メールアドレス確認など)

多くの場合、これらすべてのメールには同一のFromドメインが使用されています。DMARCポリシーの設定はDNSのTXTレコードで行いますが、1つのドメインに対して設定できるポリシーは1つだけです。つまり、あるドメインにDMARCポリシーを設定すると、そのドメインがFromになっているメール全てに同じポリシーが適用されることになります。

しかし、SPFやDKIMの設定はメールの種類によって異なります。たとえば、カスタマーサポート管理のためのSaaSを導入している場合、顧客の問い合わせへの返信はそのSaaSサービスのシステムを経由して送られ、DKIM署名もそのSaaSサービスによって行われます。他のメールとはDKIMの設定が異なるため、そのサービスから送られるメールだけがDMARC Failとなる可能性があります。

実際に過去にあった例として、とある企業がDMARCポリシーを設定したところ、ほとんどのメールは問題なかったものの、カスタマーサポートツールで管理されていた問い合わせ返信メールだけが認証に失敗する状態になったことがありました。顧客からの問い合わせの中には、重大で緊急性の高いものも含まれます。その返信が迷惑メール扱いされ、顧客から「重要事項なのに返信が遅い」と誤解されれば、信用を大きく損なってしまうでしょう。

このように、メールはさまざまなシステムを通じて送られるため、その一部だけにAlignmentの問題が発生することがあります。しかし、DMARC設定はドメイン全体に及び、Alignmentに問題があるメールだけを対象外にすることはできません。対象外にしたければ、そのメールのFromを別ドメインのものにしなければなりません。

幸い、DMARCには、既存メールの状態を確認する準備期間として利用できる運用モード(p=none)が用意されています。十分な準備期間を設けて、その期間中にDMARCレポートを確認することで、Alignmentの問題を確認することができるでしょう。

DMARCレポートをなめるな

DMARC設定について書かれた文書では、たいてい、DMARCレポートを受け取って確認することが強く推奨されています。Gmailの「メール送信者のガイドライン」でも、DMARCレポートを受け取ることが推奨されています。

ドメインから送信されたメールまたはドメインから送信されたと思われるメールを監視できるように、DMARC レポートを設定することをおすすめします。DMARC レポートは、ドメインになりすましている可能性のある送信者を特定するのに役立ちます。

レポートを受け取らないように設定することも可能ですが、その場合、認証の失敗に気づけません。また、DMARCポリシーはDNSに設定され全世界に公開されるため、なりすましメールを送信しようとする攻撃者は、事前にDMARCポリシーを調査し、レポートを受け取らないドメインを狙い撃ちするかもしれません。そのような理由もあり、基本的にはレポートを受け取ることが推奨されています。

DMARCのレポートには、以下の2種類があります。

• Aggregate feedback report: 統計情報レポート。rua=で指定したアドレスに送られてくる
• Failure report: 認証失敗時の個別メッセージごとのエラーレポート。ruf=で指定したアドレスに送られてくる(かも)

実際に受け取ってみると、まず、Failure reportのほうはそもそも送られてきません。仕様では規定されているものの、悪用される懸念もあることから²、実務上はほとんど使われていないようです。

Aggregate feedback reportは実際に送られてきます。初心者向けの解説記事では「レポートを確認しましょう」などと簡単に書かれていることが多く、中身に触れられていないことが多いのですが、実際に送られてくるのは以下のようなものです。

• 圧縮ファイルを添付したメールが送られてくる³
• 各種の受信側サービスそれぞれから個別に送られてくる
• デフォルトでは1日1回の頻度で送られてくる
• 圧縮形式はZIPの場合とGZIPの場合があり、展開すると中身はXMLファイル

レポートのボリュームはメール送信の規模によります。メール送信数が少なければ、人間が直接XMLを読んでも対応できるでしょう。しかし、規模が大きいサービスでは、数十のサービスから、それぞれ数万行のXMLファイルが送られてくることもあります。それが毎日届くのです⁴。人間が直接読んで確認することは、全く不可能とまでは言いませんが、現実的であるとはお世辞にも言えないでしょう。

大規模サービスでDMARCレポートをまともに扱おうとするなら、集計・解析を行う仕組みの導入が事実上必須となります⁵。DMARCの設定を行う際には、レポートを扱う仕組みについても検討しておく必要があります。

ポリシー設定をなめるな

DMARC設定について書かれた文書を見ると、「最初はp=noneで良い」という旨のことが書かれていることがほとんどです。このp=の値は、DMARCの認証に失敗したメールに対し、どのように扱ってほしいかを指定するものです⁶。認証失敗メールに対する処理は2通りあります。

• quarantine: 検疫処理をする。たとえば迷惑メールフォルダに入れる、迷惑メールフラグをつけるなどですが、具体的な動作は受信側依存です
• reject: 受信拒否する。受け取って捨てるのではなく、SMTPトランザクションの途中で拒否することが期待されます⁷

処理はこの2通りですが、ポリシーとして指定できる値はもう一つあります。

• none: 特別な処理をしない。DMARCポリシーが存在しない場合と同じ動作になることが期待されます。具体的な扱いは完全に受信側依存です

p=noneは「特別な処理をしない (nospecific action be taken)」という意味です。「検疫も拒否もせずに受け取る」という意味ではないことに注意してください。基本的には、DMARCポリシーが存在しない場合と同じ処理が行われることが期待されます。SPF/DKIMの認証に失敗していれば、受信側のポリシーによって検疫されることがほとんどでしょう。

要するにこの場合、DMARCの認証は機能しません。ただし、rua=を指定すればDMARCレポートを受け取ることはできますので、何もしたくないがレポートだけは受け取りたい、という場合に利用できます⁸。先にも触れたとおり、DMARCの導入時には既存のメールに問題が起きないか調査する必要があるため、その準備期間として利用できます。

p=noneのままにしておくことは推奨されていません。確認を終えたらp=quarantineに変更し、それでも問題がなさそうであればp=rejectに変更することが推奨されています。設定を変更する際にはpct=パラメータを設定し、より厳しい設定を適用するメールの割合を徐々に増やしいてくやり方が推奨されています。

p=rejectにしない運用を続けた場合、なりすましメールは受信者に届いてしまうことに注意してください。DMARCを設定するのは、(実際のところは「Gmailがやれと言うから仕方なく……」が本音でしょうけれども、本来の建前としては)自社のドメインがなりすましメールに悪用され、それが受信者に届くことを防ぐためです。その目的を果たすためには、最終的にp=rejectを設定する必要があります。p=rejectを設定すると、なりすましメールの到達が抑制され、迷惑メール報告率を下げる効果も期待できます。

つまり、DMARCは一度設定したらそれで終わりではない、ということです。メールに問題がないかレポートを常に見て、問題がなさそうであれば設定を変えていく、という運用が求められているのです。

まとめ

DMARCについて、DNSを設定すれば終わりだと思っていた方もいらっしゃるのではないでしょうか。メール配信の量が少ない組織であればその通りかもしれませんが、規模の大きい組織では、考えること、対応が必要なことがたくさんあります。あらためて、ここまで述べてきたことを簡単にまとめておきます。

• DMARC Failがある: DMARCを設定するとAlignmentの判定が追加され、SPF/DKIM PassのメールがDMARC Failになる場合がある
• 影響範囲がドメイン全体に及ぶ: DMARCの設定はドメイン全体に及ぶ。同じFromドメインを使ったメールがさまざまなサービスから配信されている場合、それらすべてについてAlignmentに問題ないか確認する必要がある。問題のあるメールだけを対象外にするようなことはできない。準備期間のモードで運用し、レポートを確認することが望ましい
• DMARCレポートの確認が大変: DMARCレポートとしてXMLが大量に送られてくる。サービス規模にもよるが、人力で見るのは現実的でない可能性が高いため、何らかの対応を考える必要がある
• ポリシー設定を見直す必要がある: DMARCポリシーは一度設定して終わりではなく、準備期間を経て、そのあともレポートを見ながら設定を変えていく必要がある。運用が必要になる

結論を一口で言えば、世間で思われているよりもはるかに面倒なので覚悟しましょう、ということになります。Gmailのなりすましメール対策が強化されるのは2月からだと言われており、残された期間はそれほど長くありません。その後も、DMARCとは長い付き合いになるかもしれません。この記事をきっかけに、DMARCの運用についていろいろと考えを巡らせていただければ幸いです。