DMARC 実装していますか？
こんにちは、SYC 松本です。
ある時期に Google さんが 「メール送信者のガイドライン」を更新されまして、
個人用 Gmail アカウント向けに送信されたメールが正常に配信されるようにするには、
ガイドライン記載の条件を満たす必要がある、という事になりました。
ざっくり概要としては以下の通りです。
- メールの送信に TLS 接続を利用する
- SPF または DKIM メール認証実装。
- 送信元ドメインまたは IP に DNS レコード (正引き・逆引き) があること。
個人用 Gmail アカウント向けの制限であるので、企業用はまた違うのではあるのでしょうが、
実際には Gmail アカウントをサブで使われていたり、小規模なところでは Gmail をそのまま利用されていたり、
或いは就活されている方が利用さているなどもあって、それなりに影響はあったのかも、と思う次第です。
それから幾分か経ちまして、最近ですが Microsoft さんも hotmail.com、live.com、Outlook.com など
コンシューマ向けメールアドレス宛のメール送信者に対して同様の要件 SPF / DKIM / DMARC 実装が要件になる模様です。
参考 「Microsoft Defender for Office 365 Blog」
自分が送信したメールが、相手先に正常に配信されるためには DMARC 実装しておいた方が良い、という事になります。
DMARC を実装するには、先に SPF / DKIM を実装しなくてはなりません。
SPF (Sender Policy Framework) を実装する
SPF (えすぴーえふ) の実装はとても簡単で、殆どのメール環境で大きな苦労をせず実装できると思われます。
SPF て何するものぞ、ということですが。
受信者側のメールサーバーに、メールの出元が信頼できそうかどうか教えてあげることができます。
例えば、送信者：user_S@syc.co.jp 、 受信者：user_G@gmail.com のメールが送られたとします。
この時、Gmail のメールサーバーが Server1 (IP:xxx.xxx.xxx.xxx) から受け取ったとすると、
Gmail のサーバーはこのメールが正しいかどうか SPF の検証を実施します。
概要としては以下のような動きをします。
DNS クエリにて syc.co.jp の SPF レコードを照会し、その内容に Server1 が含まれているか確認します。
nslookup コマンドで言えば以下のような情報を確認しています。
nslookup -type=TXT syc.co.jp 8.8.8.8
サーバー: dns.google
Address: 8.8.8.8
権限のない回答:
syc.co.jp text =
“v=spf1 include:spf.protection.outlook.com include:spf.nlk.mailds.jp include:chohyo-bpo6.bk.mufg.jp include:_spf.activegate-ss.jp +ip4:58.13.69.218 +ip4:52.192.14.144 -all”
“v=spf1” で始まる TXT レコードが SPF レコードの含まれる情報です。
include は指定される FQDN に含まれる情報が対象、+ip4 はそれに続く IPv4 アドレスからの送出メールを信頼するというものです。
末尾の「-all」 はここに記載のあるもののみを信頼し、それ以外は不正であることを示唆します。
もし未認識の送信元（オンラインサービスなどから通知メールが出るが、そのメール送信元を未特定・未確認出あるなど）がある場合、「~all」としやや緩い条件と示すこともできます。
これらの設定がどう処理されるかは受信側のメールサーバー次第であることに注意してください。
オンプレミス環境に自前で構築したメールサーバーなどは明示的に判別機能が利用されるようになっているか要確認です。
Exchange Online など SaaS サービスでは判定機能は動作しています。
- 送信者ドメインの SPF レコードが未構成の場合、正規のメール、不正のメール判断つかないため、
総じて「なりすましメール」として誤認されやすくなる可能性があります。 - SPF レコードを構成している場合で、正規の発信元であり SPFレコード内に含まる場合、
正常なメールとして相手に配信されやすくなります。 - SPF レコードを構成している場合で、正規の発信元であるが SPFレコード内に含まれない場合、
「なりすましメール」として誤認されやすくなります。 - SPF レコードを構成している場合で、不正の発信元であり、SPFレコード内に含まれない場合、
「なりすましメール」として検疫されやすくなります。
このように、SPF レコードは DNS サーバーに所定の記述方法で記載された文字列 SPF レコードを追加するのみで実装できます。
もしも未構成である場合、ぜひ実装しましょう。
余談：
ここだけ見ると SPF レコードでの定義、検証だけでも十分そうに見えますが、そうではありません。
メールの送信者情報は、厳密には「Envelope from」というメーラーに通常表示されない送信元アドレスと、
メーラーに表示させる用 (わかりやすい様に表示されるもの) の 「header from」という送信元アドレスがあります。
SPF 検証は通常 「Envelope from」に対して実行されます。そして「なりすましメール」は「header from」 を偽装します。
ですので、不正メールサーバー badserver から本当の送信元は warumono@fake.baddomain だとしても、
メーラーには「user1@syc.co.jp」と見せることができ、攻撃者が DNS レコードで fake.baddomain の SPF レコードを正しく
構成していたら、それは正規のメールとして届いてしまうのです。
DKIM (DomainKeys Identified Mail) を実装する
DKIM (でぃーきむ) はメール送信サーバーがメッセージ アイテムに電子署名を行い、受信側サーバーがそれを検証することで正常性を確認する仕組みです。
SPF と比べると証明書関連の設定が増えるため、オンプレミス環境など自前で構成するとなると、それなりに面倒になります。
しかし、Exchange Online など SaaS サービスにおいては、より簡易な設定で実装可能な様に準備されています。
それぞれの環境で実装方法などについては、それぞれの環境に合わせてご確認ください。
メッセージアイテムに付与された電子署名を検証するための公開鍵は DNS サーバー上の TXT レコードで示されます。
ここでは、Exchange Online での DKIM 構成例を示します。
- Microsoft 365 管理センターのドメイン設定画面、または Microsoft Defender 管理センターで示された CNAME レコードを
外部公開 DNS サーバーに登録します。 - Microsoft Defender 管理センターで、[メールとコラボレーション]-[ポリシーとルール]-[脅威ポリシー] を選択します。
- 「メールの認証の設定」をクリックし、「DKIM」タブをクリックします。
- 登録済みドメイン一覧が表示されますので、対象ドメインの切り替えスイッチを「有効」に切り替えます。
このぐらい簡単だと嬉しいですね。ややこしいキー文字列をどうのこうのなどしなくて良いです。
オンプレミス自前サーバーですと、以下のような構成の実装が必要です。
- メールサーバー用に証明書を発行し、メールサーバ内でメッセージ アイテムに署名を行うように構成。
具体的な手順はご利用のメールサーバーソフトウェアによってそれぞれ確認が必要です。 - 公開鍵の文字列を外部公開 DNS サーバーに登録する。
- 証明書有効期限が切れる前に年次などの間隔で更新し、１、２の設定を繰り返す。
商用証明書を利用する場合は購入手続きなども含め、なんだか面倒そうです。
DKIM 有効化されたサーバーからメールを送信すると、受信したメールサーバー側はメールヘッダー内の情報を参照し、検証を開始します。
以下は DKIM-Signature: 情報部分の抜粋です。 ドメイン名が demo1.shimsoft.jp、 セレクターが selector1 と示されています。bh と b の部分に署名情報文字列が含まれています。
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=demo1.shimsoft.jp;
s=selector1;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh= <<省略 署名情報>>
b= <<省略 署名情報>>
これを元に、<セレクター>._domainkey.<ドメイン名> の情報を DNS クエリで照会します。
nslookup -type=TXT selector1._domainkey.demo1.shimsoft.jp
権限のない回答:
selector1._domainkey.demo1.shimsoft.jp canonical name = selector1-demo1-shimsoft-jp._domainkey.sycps.onmicrosoft.com
selector1-demo1-shimsoft-jp._domainkey.sycps.onmicrosoft.com text =
“v=DKIM1; k=rsa; p= <<省略 公開鍵情報>>”
署名情報と公開鍵を使用して検証します。
正常な場合、メールコンテンツが改変されていないと判定されます。
SPF レコードは Envelope From 情報を元に判定しますが、DKIM は Header From の送信者メールドメインを検証に利用します。
余談：
Exchange Online での DKIM 実装では CNAME レコードを指示されるままに登録すれが良いのでとても簡単に実装できます。
証明書更新なども特に利用者側で考えなくてよいのも助かりますね。
別の環境で「公開鍵」の情報を DNS サーバーに TXT レコードで記載する際に、最大文字列長の制限に引っかかってしまい、
「簡単だろ？」と思っていた TXT レコード登録操作に結構難儀しました。
DMARC (Domain-based Message Authentication Reporting and Conformance) を実装する
SPF だけ、DKIM だけでは、受け取ったメールを信じていいかどうか確信が持てない、という状況が残存してしまいます。
これをより改善する方式として DMARC を実装します。
DMARC (でぃーまーく) は SPF + DKIM の検証結果を合わせて評価する仕組みですので、先行して SPF / DKIM の実装が完了していることが前提となります。
SPF レコードでは、Envelope From 情報を検証し、DKIM は Header From を検証しているとも言えますので、両方の結果を組み合わせることにより、
目に見えにくい Envelope From 情報も、目に見える部分の Header From 問題なさそうであることが確認できる、という事になります。
DMARC は 目に見える Header From の情報を元に検証をします。
受信したメールサーバーは DMARC 検証のために DNS サーバーに _dmarc.<ドメイン名> の情報を照会します。
nslookup -type=TXT _dmarc.demo1.shimsoft.jp 8.8.8.8
サーバー: dns.google
Address: 8.8.8.8
権限のない回答:
_dmarc.demo1.shimsoft.jp text =
“v=DMARC1;p=quarantine;rua=mailto:dmarc@demo1.shimsoft.jp;ruf=mailto:dmarc-fail@demo1.shimsoft.jp;adkim=r;aspf=r;”
“v=DMARC1” で始まる TXT レコードが DMARC レコードの含まれる情報です。
p は ポリシー設定で、 none, quarantine, reject のいずれかを指定します。
DMARC 構成当初は、まず none を設定して様子を見てください。いきなり quarantine / reject にすると SPF レコードへの記載漏れや DKIM 実装が出来てないなどによって
相手先に本当は届いてほしいメールが届かなくなる場合があります。
none を指定した場合、「DMARC 検証失敗したとしても、正常なメールの可能性もあるので配信して欲しい」と相手側メールサーバーに伝えることができます。
quarantine を指定すると、「DMARC 検証失敗したメールは不正メールであるので検疫してよい」と伝えることになります。
reject を指定した場合、もっと強力に 「DMARC 検証失敗したメールは不正メールであるので破棄してよい」と伝えることになります。
本記事記載時点で、Gmail や outlook.com では p=none であっても、DMARC レコードまで登録されていれば OK とされています。
世の中の不正メールを効率的に、効果的に排除していけるようにするためには、メール送信元側で quarantine か reject を指定することが推奨されています。
rua は DMARK 検証統計レポートの通知先メールアドレスです。
日々相手先メールサーバーが DMARC 検証を行ってレポート通知してくれる限りにおいて、ほぼ毎日レポートが届きます。
XML ファイルが Zip 圧縮されて添付ファイルの形で届きます。
ruf は DMARK 検証失敗レポートの通知先メールアドレスです。
検証失敗したメールの詳細情報が含まれることとなっていますが、現在は様々な情報保全の目的でこのレポートを通知しないメールサーバーが多いようです。
実際私もいろいろ試しましたが、このレポートを受信できたことはありません。
adkim / aspf はそれぞれ DKIM / SPF 検証の動作を指定します。
r は relaxed モード であり、送信者のドメインがサブドメインでも検証 OK とします。
s は strict モード であり、送信者のドメインと完全一致していないと検証 OK となりません。
正直な所 DMARC レポートを毎日全部確認するのは大変なので、何らかの有償サービスなどを利用して分析するか、
何らかの方針を決めて一定期間頑張ってチェックするなどして、SPF レコード登録漏れや DKIM 設定漏れなど
正規のメールサーバーが不正として判断されていないかどうかを確認し、
最終的に p=none から quarantine や reject に移行できるとより良い運用が出来ていることを示すことができます。
もしも SPF / DKIM / DMARC に関する実装にお悩みがあれば、ぜひ弊社までご相談ください。
