「ドメインは持ってるけどメールに使ってないよ」という方が割りと大勢いるのではないかなと思いますが、今回対策したのは自分がメールを使っているかどうかに関係のない部分です。
私はこのブログを公開しているドメイン含めて、いくつかの独自ドメインを保有・管理しています。今回、これらのドメインに対して迷惑メール対策、特に「なりすまされメール対策」を施してみました。
「独自ドメイン持ってるけど、特にそんな事してないよ」という皆さんにこそ、ぜひ確認していただきたい内容です。
TL; DR
「メール送受信には一切使わないドメイン」については、以下の3つのTXTレコードを追加してなりすまされないように設定しておくのが最善です。
また、不要なMXレコードは削除しておくほうが良いでしょう。
なりすまされメール対策とは
一般的な感覚では「迷惑メール対策」と言えば迷惑メール（なりすましメール）を受信しないような設定をすることをイメージしますが、今回対策したのは"なりすましされない"設定です。
すなわち、見知らぬ誰かが勝手にあなたのドメインを名乗って迷惑メールを送ったりできないようにしておく設定になります。
Fromアドレスの種類
メールには「エンベロープFrom」と「ヘッダーFrom」と呼ばれる2種類の送信者アドレスが利用されます。
エンベロープFrom
エンベロープFromは、メールサーバ同士が「どこから送信されたメールか」を判断するために利用される送信元アドレスです。
メールヘッダ上では「Return-Path」として記録されることが多いため、メールソースを表示する機会があれば内容を確認できますが、メールを表示するユーザの画面上には表示されないことが殆どです。
ヘッダーFrom
ヘッダーFromは、メールクライアント（メーラー）が画面に「差出人」として表示するアドレスです。
画面上に表示されるアドレスであるため、利用者が「どこから来たメールか」を確認する際は多くの場合このアドレスを参照することが殆どです。
なりすましメールの原理
なりすましメールとしては、「迷惑メールの送信元を隠蔽する」という目的のためにエンベロープFromを詐称するパターンと「送信者を本物っぽく見せる」という目的のためにヘッダーFromを詐称するパターンの2種類があり、多くはこの2つを組み合わせた形で送信されます。
後者はユーザを騙すためという目的がハッキリしていますが、前者は何のために実施するのでしょうか。
"なりすまされ"を許容するドメインたち
実際には、エンベロープFromを隠蔽したところで、メールヘッダに記録されるReceivedヘッダ等を追跡することで「どのサーバから送られてきたか」は確認できる場合が殆どのため、詐称することによるメリットは多くありません。
ところが、昨今では「Fromアドレスのドメインが許容したサーバ以外からのメールは受け取らない」という仕組みを多くのメールサーバが導入しています。
それが、「SPF（Sender Policy Framework）」と呼ばれる仕組みです。
SPFは各ドメインの持ち主がDNSのTXTレコードとして「このアドレス以外からはうちのメールは送らないよ」を宣言しておくことで、受信したサーバがこのレコードと各メールの送信元を照合してなりすましメールを判断する仕組みです。
迷惑メールの送信者たちは、この仕組みによって適当なエンベロープFromを指定してメールを送ることが出来なくなりました。
そこで、代わりとして「SPFを設定していない、なりすましを許容するドメイン」になりすますことに替えたようです。
SPFを使わないドメインでの認証
また、「サーバを指定しない方法」でのドメイン認証としては、メールそのものに電子署名をし、DNSレコードに登録した公開鍵情報と照合することで「正しい送信者によるメールか」を判別する DKIM（Domain Keys Identified Mail） もあります。
メール送信側で署名などの仕組みを導入する必要から国内では特に普及率が低く、SPFほど導入が進んではいませんが、こちらもなりすまし防御には一役買う仕組みです。
なりすましメールの処置を明示する仕組み
SPFやDKIMによって「なりすましメール」と判断されたメールについて、メールを破棄するのか迷惑メールボックスに入れるのか普通に受信ボックスに入れるのかは、標準では受信側メールサーバの設定に準じてしまいます。
一方で、"なりすまされる側"としてはドメインの信用度などにも関わるため、なりすましメールはなるべく受信してほしくないと考えることも多いでしょう。
そこで、ドメイン所有者が「自分になりすましているメールは破棄/隔離/受信してください」といった指示を出す仕組みとして導入されたのが DMARC（Domain-based Message Authentication、Reporting and Conformance） です。
DMARCの設定によっては、「なりすましメールを受信した場合は、○○宛にその旨を通知するように」といった設定もできるため、ドメイン管理者側は「なりすまされたかどうか」まで判断できるようになります。
なりすまされ対策を導入する
SPF / DKIM / DMARC のいずれの対策についても、基本的には管理しているDNSのTXTレコードとして定義することにより作用します。
対策にあたっては、ドメインを管理している権威DNSサーバ上でレコード編集を行います。
SPFの設定をする
SPFの書式については、 RFC7208 にて定義されています。
特に「メールを送信しないドメインのレコード」については、「10.1.2. Administrator's Considerations」に記載されており、具体的には以下のようなRRとなります。
www.example.com. IN TXT "v=spf1 -all"
-all のみを指定することにより、全てのサーバからのメールをなりすましと判定します。
ドメイン以下のすべてのサブドメインに適用したい場合は、レコード名を空白にしてドメインルートに対して設定します。
DKIMの設定をする
DKIMの書式については、 RFC6376 にて定義されています。
メールを送信しない場合は「どのような署名も認証しない」と言った意味となるように空の公開鍵を登録します。
具体的には、「3.6.1. Textual Representation」に記載されている通り、p=タグを空白として扱うことによって公開鍵がRevokeされたという指定が可能になります。
p= Public-key data (base64; REQUIRED).
An empty value means that this public key has been revoked.
具体的には以下のようなRRとなります。
*._domainkey.example.com. IN TXT "v=DKIM1; p="
DKIMはサブドメインごとに指定が必要となってしまうため、すべてのサブドメインに適用する場合はワイルドカードレコードを利用します。
DMARCの設定をする
DMARCの書式については、RFC7489 にて定義されています。
DMARCでは、受信されたメールをどのように扱うかといった記述がメインになりますが、メールを送信しないドメインの場合は原則としてすべて「拒否＝reject」とする設定とします。
具体的には以下のようなRRとなります。
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s;"
p=reject にてドメインルートでの扱いを、sp=reject にてサブドメインでの扱いを指定しています。
また、adkim=s および aspf=s にてDKIMおよびSPFについてサブドメインを許容しない（strict）モードに指定しています。
上記の例では記載していませんが、 rua=メールアドレス; を追加することで、なりすまされた際に通知メールを受け取ることが可能です。
備考：CloudFlare DNSの場合
CloudFlare DNSを権威DNSとして利用している場合、MXレコードが非登録なドメインの場合はDNS管理画面のトップにて「なりすましメールを防ぎます」といった通知が出てくるため、ここから対象レコードをワンクリックで追加することができます。
レコードの値等を特別に指定する必要もなく、右下の「Submit」を押すだけで対策用のレコードを追加することが可能です。
また、DMARCによる通知メールが必要な場合は「Reporting email addresses」の欄に入力することで、通知メールを受け取ることも可能です。
（DMARCレコードにruaタグが追加されます）
対策を確認する
SPF / DKIM / DMARC の動作確認は、基本的には任意のクライアントから自ドメインの対象TXTレコードを引くだけで確認可能です。
手軽に確認をする場合は、dmarcian.com のサービスを利用することで確認が可能です。
Domain Health Checker | dmarcian.com
ドメイン入力欄にドメイン名を入力して「Check domain」を押し、「Well done!」が表示されれば問題なく設定ができています。
おさらい
改めてになりますが、メール送受信に利用しないドメインには以下のDNSレコードを追加して「なりすまされ対策」をしましょう。
