本エントリは「コネヒト Advent Calendar 2024」14日目の記事です！

こんにちは。本年アドカレ2回目の登場となる @sasashuuu です。

先日 村営山中湖キャンプ場 に行ってまいりました。さすがにもう冬ということもありかなり寒さが厳しくなっておりましたが、雰囲気が良く富士山や山中湖の近さも相まって道中にも素敵な景色を楽しめる最高なキャンプ場でした...！

さて、本日はメール技術である SPF/DKIM/DMARC についての記事となります。

背景

Email sender guidelines に記載されているように Gmail のスパム規制が本格化している昨今ですね。

最近弊社内でも従業員から「xxx を使ったメールが届かなくなった」、「xxx を最後にメールが届いていない」という問い合わせが発生しておりました。

取り急ぎ現状復旧はできているものの、追われるがままの対応となっており、「そのそものメールの認証技術についてちゃんと理解できているのか？」とふと思い、このブログの執筆に至りました。

より理解を促すために、やらない場合どのような問題が発生するのかという観点で内容をまとめました。この情報が誰かのお役に立てば幸いです。

はじめに

SPF/DKIM/DMARC はメールの差出人から正規のメールサーバーを経由して受信者に届いたかを認証する技術です。これがないと不正なメールが送信者・受信者に届くリスクが高まります。それぞれの認証技術は単体で利用するのではなく組み合わせて利用することに意味があります。

各認証技術については追って説明していきます。

前提となる用語の基礎知識

SPF/DKIM/DMARC を理解するにあたり、整理しておいた方が良さそうなメール技術における用語を一部ピックアップして解説しておきます。

ヘッダー From
- 差出人の情報です。メールヘッダー上で「From」と表記されています
- メールを郵便物に模して「封筒の中の便箋に書かれている名前」と例えられることがあります
- 容易に偽装することが可能です
エンベロープ From
- こちらも差出人の情報です
- メールを郵便物に模して「便箋が入った封筒に書かれている名前」と例えられることがあります
- メール送信時に「エンベロープ From」という情報として送られますが、受信後は「Return-Path」という情報でメールヘッダーに追加されます（Return-Path の用途としてはバウンスメールなどの発生時の返送先として機能します）
- ヘッダー From ほど容易には偽装できませんが、メールサーバーへログインした上でメールを送信することで偽装が可能です

SPF の認証

概要

メールが正当な送信元ドメインから送られたものであるかを検証する目的で用いられます。

なりすまし防止の目的で用いられます。

設定例

例として以下のように DNS において SPF レコードを登録します。RFC7208 に記載されていたサンプルです。

example.com.   IN TXT  "v=spf1 ip4:192.0.2.1 ip4:192.0.2.129 -all"

"v=spf1" ではバージョンを指定しています。

"ip4:x.x.x.x" では送信元として許可をするメールサーバーの ip アドレスを指定しています。

"-all" は指定されたもの以外からのメール送信を許可しないという設定です。この場合は "ip4:x.x.x.x" で指定されたものが許可対象ということになります。

このような設定によって、SPF は「エンベロープ From の情報」と「実際の送信元メールサーバーの ip アドレス」が一致しているかを検証しています。

上記は ip アドレスの指定というシンプルな例を紹介しましたが、他にも記法が色々とあるので RFC7208 を参考にしてください。

DKIM の認証

概要

公開鍵暗号方式を使った認証技術です。

メールが改ざんされていないかを検証する目的で用いられます。

設定例

例として以下のように DNS において DKIM レコードを登録します。RFC6376 を参考に組み立てたものです。

brisbane._domainkey.example.com. IN TXT (
    "v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ"
    "KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt"
    "IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v"
    "/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi"
    "tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB"
)

"brisbane" はセレクタと呼ばれる設定値で受信側のメールサーバーにて公開鍵を探すための識別となるものです。一意であれば任意の値で良いものですが、サンプルでは RFC に記載の文字列をそのまま引用しました。

"v=DKIM1" ではバージョンを指定しています。

重要となるのが "p=..." の部分です。公開鍵を Base64 でエンコードしたものです。ポイントとなるのは全文を1つの文字列として取り扱っていない点です。これは RFC1035 の仕様上、最大文字数制限（255 byte 以内）があるためです。

DMARC の認証

概要

DMARC は一言で表現しづらいですが、以下を担う認証技術です。

ヘッダー From を組み合わせた認証（SPF/DKIM で認証した送信元と一致しているか）
SPF や DKIM の検証結果をもとに受信側でメールをどう処理するかを制御
SPF や DKIM の検証結果をレポートとして通知

設定例

例として以下のように DNS において DMARC レコードを登録します。RFC7489 を参考に組み立てたものです。

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com"

"_dmarc" は DMARC を利用するにあたり必要となるサブドメインです。

"v=DMARC1" ではバージョンを指定しています。

"p=none" は適用ポリシーを指定しています。これが検証に失敗したメールをどうするかという制御を司る部分です。以下のような種類があります。

ポリシー	内容
none	何もしないことを意味します。DMARC の検証に失敗した旨の情報は追加されますが、通常通りメールは届きます。
quarantine	隔離を意味します。迷惑メールフォルダに振り分けられます。
reject	拒否を意味します。バウンスメールとして返送されます。

上記の例では RFC のサンプルの通り "none" を指定していますが、これだと受信側の制御としては何もしないため隔離や拒否の対応が必要な場合は "quarantine" や "reject" にする必要があります。

"rua=" は DMARC のレポートの報告するためのメールの送信先です。検証の結果がこのメールアドレス宛に届くようになります。

その他の仕様については、RFC7489 を参考にしてください。

SPF/DKIM/DMARC を適切に設定しないとどういった問題が起こるのか

SPF はなりすまし防止、DKIM は改ざん防止、そして DMARC は SPF と DKIM の検証結果をもとに検証を行う技術かつ SPF や DKIM で補えない脆弱性をカバーしているといった関係性があります。

したがって先述したように認証技術としては分かれているものの単体で利用するのではなく、組み合わせて利用することに意味があります。

ここからはさらに掘り下げて、SPF/DKIM/DMARC の3つを適切に設定をしないとどうなってしまうのかについて見ていきます。

ケース1：何も設定していない場合

言わずともがなで不正メールが送られ放題です...。

設定していないことで必ず不正メールが送られてしまうとは限りませんが、「容易に送ることができる環境を提供する」ことに繋がります。

ケース2：SPF 認証は設定済みで DMARC は未設定の場合（DKIM は不問）

まず1つめに「ヘッダー From は偽装しつつ本命のドメインの SPF の検証は pass しない状態でメールが届く」といったことが起こり得ます。

例えば SPF 設定済みの「hoge@example.com」を装い、SPF 未設定の「narisumashi@example.net」からメールを送信する例を考えます。

エンベロープ From は「narisumashi@example.net」とし、ヘッダー From は「hoge@example.com」とします。すると「narisumashi@example.net」では SPF の検証は行われず検証結果が「spf=none」となり、結果的に不正なメールが届いてしまうことになります。

受信者側で届いたメールの検証結果のステータス（このケースでは「spf=none」）を見抜くことができれば怪しいメールだと気づけるかもしれませんが、毎回人力で目を通してチェックするのは大変です。よって DMARC による検証が必要です。

2つめに「ヘッダー From は偽装しつつ偽のドメインの SPF 認証を pass した状態でメールが届く」といったことも起こり得ます。

送信例は先ほどと同じですが、今度は「narisumashi@example.net」で SPF を設定済みにしておく場合を考えます。

すると SPF の検証結果が「spf=pass」となり、SPF 検証が pass した状態で不正なメールが届きます。

エンベロープ From は転送などの関係で必ずしもヘッダー From と一致するとは限らないため、受信者側では「正規のメールサーバーから送られてきたか」を判断するのは困難となります。よって DMARC による検証が必要です。

ケース3：DKIM は設定済みで DMARC は未設定の場合（SPF は不問）

まず1つめに「ヘッダー From は偽装しつつ偽のドメインの DKIM 検証を pass しない状態でメールが届く」といったことが起こり得ます。

詳細なフローは割愛しますが、DKIM における検証はざっくり以下のようなフローです。

（送信側メールサーバー）公開鍵/秘密鍵ペアを生成
（送信側メールサーバー）公開鍵は DNS に TXT レコードとして登録、秘密鍵は安全にメールサーバーで保持
（送信側メールサーバー）送信時にメールの一部（ヘッダーや本文）をハッシュ化し、秘密鍵で署名を生成して DKIM-Signature ヘッダーとして追加
（受信側メールサーバー）DNS から公開鍵を取得し、メールの内容から計算したハッシュ値と署名を照合して検証

この上で DKIM 設定済みの「hoge@example.com」を装い（ヘッダー From に「hoge@example.com」を指定）、DKIM 未設定の「narisumashi@example.net」からメールを送信する例を考えます。

「narisumashi@example.net」から送られたメールは DKIM の検証を行いませんので、DKIM の検証結果は「dkim=none」となった上で不正なメールが届きます。

SPF の時と同様、ヘッダー From を偽装してなりすました上で改ざんメールを送ることが可能ですし、受信者側で「DKIM の検証が pass しているか」と毎回確認するのも大変です。よって DMARC による検証が必要です。

2つ目に「ヘッダー From は偽装しつつ偽のドメインの DKIM 検証を pass した状態でメールが届く」といったことも起こり得ます。

「narisumashi@example.net」で DKIM を設定済みにしておく場合を考えます。

すると DKIM の検証結果が「dkim=pass」となり、DKIM 検証が pass した状態で不正なメールが届きます。

こちらも SPF の際と同様、受信者側では「正規のメールサーバーから送られてきたか」を判断するのは困難となります。よって DMARC による検証が必要です。

ケース4：DMARC のみ設定している場合

基本的に DMARC は SPF や DKIM の検証結果をもとに検証を行う技術ですので、意味がありません。SPF や DKIM の設定を行った上で DMARC の設定を行ってください。

参考

SPF/DKIM/DMARC に限ったことではありませんが、メールに関する技術仕様等を体系的に学ぶのには以下の書籍が参考になりました。プロトコルレベルの話からサーバー構築方法、本エントリで解説した SPF/DKIM/DMARC 等網羅的に解説されているのでおすすめです。

実務で使えるメール技術の教科書基本のしくみからプロトコル・サーバー構築・送信ドメイン認証・添付ファイル・暗号化・セキュリティ対策まで

また、その他 RFC では以下が該当するドキュメントとなりますので、詳細な技術仕様等はそちらを見てもらうのがよいかと思います。

RFC1035
RFC6376
RFC7208

おわりに

Gmail のスパム規制がきっかけとなりましたが、SPF、DKIM、DMARC という3つの認証技術の役割を深く理解することができました。 Saas 側の規制強化の意図やどうして認証技術が必要なのかといった部分の解像度が上がった気がします。メールセキュリティを高めるための実践的な知識を得るとともに、今後のメール運用にも活かしていきたいと思います。

コネヒト開発者ブログ