受信専用ドメインのSPFとDMARC｜なりすましを防ぐ設定

方向は2つ、設定したのはそのうち1つ

ドメインをここに向けるには、DNSレコードが1つあれば足ります。そのレコード — MX — が答える質問はただ1つ、このドメイン宛てのメールはどこへ行くのかです。キャッチオールに必要なものはそれがすべてであり、それが解決すればドメインは動き始めます。しかし同時に、その時点ではまだ半分しか設定できていません。ドメイン名は2つの方向で使われるのに、MXレコードは2つ目の方向については何も語らないからです。

興味深いのは2つ目の方向です。メールのプロトコルには、見知らぬ誰かが自分のマシンから送るメッセージのFrom:欄に、あなたのドメインを書き込むことを止める仕組みは何もありません。あなたのDNSにも、レジストラにも、メールボックスにもアクセスする必要はありません — メッセージ内のアドレスは、資格証明ではなく単なる主張であり、それは昔からずっとそうでした。その主張が信じられるかどうかを決めるのは、誰にそれを主張する権限があるかについて、あなたのドメインが何と言っているかです。

何も言わないドメイン

受信サーバーはSPFもDMARCのポリシーも見つけられず、自分自身のヒューリスティクス — 評判、内容、そのドメインが過去にどう振る舞ってきたか — に頼らざるを得なくなります。履歴もポリシーもない真新しいドメインは、なりすましの対象としてほぼ理想的です。偽装に反論する材料が何もなく、後になって非難する相手もいないからです。

だめだと言うドメイン

同じサーバーが、このドメインとして送信することはどのマシンにも許可されておらず、失敗したものは拒否すべきだと述べる公開済みのポリシーを見つけます。もはや判断に迷う余地はありません。メッセージは玄関先で突き返され、多くの場合、迷惑メールフォルダにすら届きません。

これは大企業のブランドについての仮の話ではありません。送信メールを持たないドメインが狙われるのは、まさにポリシーを持たないからです — 誰にも守られておらず、2週間ほど使われては捨てられる名前は、抵抗してくる名前よりも、迷惑メールの送り主にとって価値があります。

なぜ他の人が半年かける部分を、あなたは省略できるのか

これまでにDMARCについて何か読んだことがあるなら、それは時間をかけて慎重に進めるべきプロジェクトだと書かれていたはずです。その助言は正しいのですが、あなたには当てはまりません。それはメールを送信するドメインのために書かれたものであり、時間がかかる理由はただ1つ、失敗したものはすべて拒否せよと世界に告げる前に、自分を名乗って正規に送信しているすべてのシステムを見つけ出し、そのひとつひとつを通過させなければならないからです。普通の組織では、そのリストは誰もが思っているより長く、しかも最初から分かっているのではなく、後から発見されるものです。

1. 何もしないポリシーを公開する。p=noneは、受信側に報告だけを求め、何も変更しません。忘れられていた送信者が、ポリシー自体によって締め出されることのないようにするためです。
2. 何週間もレポートを読む。請求システム、ヘルプデスク、ニュースレター配信ツール、誰かが2019年に登録した採用プラットフォーム — そのひとつひとつが失敗する送信元として現れ、それぞれを許可するか廃止するかしなければなりません。
3. 段階的に締め付ける。quarantineへ移行し、待ち、様子を見て、そこで初めてrejectへ進みます。締め付けの一歩一歩が、誰かが頼っているメールを静かに止めてしまう可能性があるからです。

これらの手順はすべて、正規の送信者を自分自身のポリシーから守るために存在します。受信専用の受信箱に向けられたドメインには、正規の送信者が存在しません。リストが長いとか、見つけにくいとか、一部だけ分かっていないとかいう話ではなく、そもそも空です。そして、すべてを拒否するポリシーは、存在しない送信者を壊しようがありません。

最終形にいきなり進むべき理由は、もう一つ副次的にあります。p=noneのままのドメインは、何も求めないポリシーを公開していることになり、受信サーバーはそれをポリシーがまったくないドメインとほぼ同じに扱います。レコードは存在するので、対応済みに見えます — これは、明らかに未完成であるより始末が悪いのです。なぜなら、誰も後から仕上げに戻ってこないからです。

3つのレコード

3つともTXTレコードで、すでにあるMXレコードの隣に追加します。名前の書き方は、ほとんどのDNS管理画面が求める形式 — ゾーンからの相対表記で、@がドメイン自身を意味する形式です。完全修飾名を求められる場合は、代わりにyourdomain.com、_dmarc.yourdomain.com、*._domainkey.yourdomain.comと書いてください。

利用しているプロバイダが値を引用符で囲むことを求める場合は、そのとおりにしてください。管理画面によっては自動で引用符を追加し、結果として二重に保存してしまうことがあり、どんなチェッカーでも読めないレコードになります — digで確認した値が二重の引用符で囲まれて返ってきたら、それが原因です。

そのまま貼り付けられる3つの値です。打ち直すのではなくコピーしてください。DMARCレコードでセミコロンが1つ抜けるだけで、タグのリスト全体が解析不能になり、解析できないポリシーはポリシーがまったくないのと同じ扱いになります。

SPF — ドメイン自身にv=spf1 -allコピー

DMARC — _dmarcという名前にv=DMARC1; p=reject; sp=reject; adkim=s; aspf=sコピー

DKIM — *._domainkeyという名前にv=DKIM1; p=コピー

それらのレコードの一語一語が、実際に何をしているのか

5つの決定事項があり、どれがどれなのか知っておく価値があります — 主な理由は、もしこのドメインがいつか送信を始めることになったとき、どれを緩めればよいかを後で見分けられるようにするためです。

-all

SPFレコードの末尾にあり、ここで意味を持つのはこの部分だけです。これは上に挙げられていないものはすべて偽装であるという意味で、そして上には何も挙げられていません。よく使われる代替の~allはおそらく偽装だが、とにかく配信したうえで印を付けよという意味です — これは自分の送信元をまだ探している段階では正解ですが、送信元が存在しないと確信している場合には不正解です。

p=reject

このドメインを名乗りながら認証に失敗したメールを、受信サーバーがどう扱うべきかです。noneは報告のみ、quarantineは疑わしいものとして扱う、rejectはSMTPのやり取りの中で拒否する、という意味です。rejectだけが、メッセージを人の目に一切触れさせずに済ませます。

sp=reject

同じことを、すべてのサブドメイン — 存在しないものも含めて — に適用します。これがないと、偽装者は独自のレコードを持たないbilling.yourdomain.comを使います。このサブドメインは、それを止めるものを何一つ継承していません。このタグはpの値をデフォルトとして引き継ぐので、書かなくてもレコードの挙動は同じです。それでも書き出すのは、レコードを読み返したときに見えないポリシーは、存在しないと思い込んでしまうポリシーだからです。

adkim=s, aspf=s

厳格アラインメントです。認証されたドメインが、その親戚のようなものではなく、From:欄のドメインと完全に一致することを要求します — そのためanything.yourdomain.comからのメッセージは、親ドメインに与えられた合格証を借用できません。デフォルトは緩やか（relaxed）であり、厳格（strict）こそが、許可すべきものが何もないドメインが表明すべき設定です。

v=DKIM1; p=

中身の鍵が空のDKIM公開鍵です。仕様上、空の鍵は失効を意味すると明記されているため、このドメイン配下のどんなセレクタ名を指定した署名も、無視されるのではなく検証に失敗します。ワイルドカードは、偽装者が考え出すかもしれないあらゆるセレクタ名をカバーします。名前を選ぶのは偽装者の側だからです。

そして、絶対に変えてはいけないレコード

ここまでの内容はどれも受信メールに影響しませんし、影響してはいけません。MXレコードは、このドメイン上のすべてのアドレスをここのメールボックスにするものであり、これまでの変更のどれによっても変わりません。

MXレコード — 変更なし10 smtp.grabmail.ioコピー

新しい3つのレコードとこのレコードは、それぞれ別の質問に答えているので、互いに干渉しません。SPFとDMARCは、あなたを名乗るメールを受け入れるかどうかを判断するサーバーが読み、MXは、あなた宛てのメールをどこへ配信するかを判断するサーバーが読みます。この4つすべてを備えたドメインは、すべてを受け取りながら、誰の身元も保証しないドメインです。

3つのコマンドで、設定を確認する

DNSは推測で済ませる場所ではありません。これらのレコードはどれも、見知らぬ相手に読まれるために公開されているので、彼らとまったく同じようにあなた自身も読むことができます — アカウントも、専用ツールも、ドメインを貼り付けるサイトも必要ありません。

$ dig +short TXT      yourdomain.com
dig +short TXT _dmarc.yourdomain.com
dig +short MX       yourdomain.com

自分のドメインに置き換えてください。探すべきものはこれです。その名前にすでにある他のTXTレコードが多少混ざっていても構いません。

"v=spf1 -all"
"v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s"
10 smtp.grabmail.io.

うまくいかない場合のパターンは4つあり、だいたい頻度の高い順に並べています。

最初のコマンドが、何も返さない

レコードがまだ伝播していないか、間違った名前に追加されています。ドメイン自身に対するTXTレコードはwwwではなく@に置くものです — 直前に編集した名前をデフォルトにしてしまう管理画面が、たいていの原因です。

SPFレコードが2つ返ってくる

ドメインに許されるSPFレコードはちょうど1つです。2つあることは1つより厳格になるわけではなく、恒久的なエラーです。受信サーバーは2つ見つけると、SPFチェックを失敗ではなく壊れているものとして扱います。すでにSPFレコードがあった場合は、2つ目を追加するのではなく、そのレコードを編集してください。

DMARCの行は返ってくるのに、何も強制されていない

値を注意深く読んでください。v=DMARC1で始まっていなければならず、タグはセミコロンで区切られています。バージョンタグが抜けているレコードや、セミコロンがカンマに変わってしまったレコードは、弱いポリシーになるのではなく、解析不能なポリシーになります。これはポリシーが全くないのと同じ扱いです。

MXの応答が変わっている

本来、変わっているはずがありません。MXの行が消えていたり、ドットだけが表示されていたり、smtp.grabmail.io以外のホストが並んでいたりしたら、他の何よりも先に手を止めて元に戻してください — それは、あなたの受信箱が依存しているレコードです。

ほとんど誰もが見落とす部分 — サブドメイン

DMARCとSPFは、ネームスペースを同じ方法では分割しません。そしてこの違いこそが、丁寧に保護したはずのドメインが漏れる場所です。sp=rejectは、存在するかどうかにかかわらず、本当にすべてのサブドメインをカバーします。SPFはまったくそのようには動きません。エンベロープの正確な名前に対して検索が行われ、独自のSPFレコードを持たない名前は、SPFレコードを持たないままです — 親のレコードを継承することはありません。

2行目についてはDMARCだけでカバーできているので、これは穴を塞ぐというより二重の備えです — ただし、ワイルドカードSPFレコードはたった1行の追加でSPFの層でもこの隙間を塞いでくれます。これは、SPFはチェックするがDMARCは実装していない受信側にとって意味があります。

ワイルドカードSPF — もう1つのTXTレコード* TXT v=spf1 -allコピー

DNSのワイルドカードは、独自のレコードを持たない名前に対してのみ答えます。もしmail.yourdomain.comにすでに何らかのTXTレコードがある場合、その名前に対してワイルドカードは参照されず、そこにSPFレコードを明示的に公開する必要があります。キャッチオール専用のドメインでは、その状況はまれで、対策を練るほどではないにせよ、知っておく価値はあります。

レポート、そしてそれを受け取る価値はあるのか

DMARCにはレポートという側面もあります。ruaタグを追加すると、参加している受信側から、あなたのドメインを名乗ったものすべてと、それがどうなったかについての日次サマリーが送られてきます。これは、DMARCの中であなたがまだ知らなかった何かを教えてくれる唯一の部分であり、ここに向けたドメインでは、それを集めるのに一切コストがかかりません。送り先のアドレスを、このドメイン自身のアドレスにできるからです。

レポート付きDMARC — ドメイン部分を置き換えるv=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@yourdomain.comコピー

レポートを同じドメイン上のアドレスへ送るようにしておけば、多くの人が引っかかる仕様の一部を回避できます。もしruaが別のドメインのアドレスを指定していると、その別ドメインの側で、あなたのレポートを受け取ることを許可するレコードを公開しなければならず、それが公開されるまで、ほとんどの送信元は何も送ってきません。同じドメインであれば、そのようなレコードは不要で、間違えようがありません。有効にする前に、届くものが何であるかを知っておく価値があります。

• XML形式で、gzip圧縮された添付ファイルとして届きます。コーヒー片手にさっと読めるようなサマリーではありません。小規模なドメインでも、大手メールボックスプロバイダから1日に数件は届き、それぞれ数キロバイト程度です。解凍して読むための仕組みが必要になるでしょう。
• 空であることが良い結果です。何も送信しないドメインが生成するレポートには、失敗だけが並んでいるはずで、静かな1週間は、今のところ誰もあなたを装っていないことを意味します — これは立派な情報であり、それを知る唯一の方法でもあります。
• ごく普通のメールとして届きます。ここではそれは、ごく普通のメールボックスを意味します。ブラウザからも、API経由でも他のものと同じように読め、他のすべてと同じく5日後には削除されます。

そもそも集めたくないのであれば、このタグは丸ごと省いて構いません。ruaのないDMARCレコードも完全に有効なレコードであり、保護の効き目もまったく変わりません。レポートは何が起きているかを知るための手段であって、ポリシーを強制する仕組みではありません。

これがしないこと

これらのレコードが対応する範囲は狭く、その境界をはっきりさせておくことが、正しく頼れる対策と、間違って頼ってしまう対策との分かれ目になります。カバーしていないことが4つあります。

自分の受信箱をフィルタリングしない

あなたのドメインのSPFとDMARCは、あなたからのメールを受け取るサーバーへの指示です。それらは他人のメールシステムに読まれるものであって、あなた自身のシステムに読まれることは決してなく、キャッチオールに届くものには何の影響も与えません。届くものは相変わらず、唯一の資格証明がそれを知っていることであるアドレスに対して、世界中が送りつけてくるものすべてです。

Fromに表示される名前は止められない

Your Company <attacker@gmail.com>のようなメッセージは、すべてのチェックを通過します。認証されたドメインは、本当に攻撃者自身のものだからです。DMARCが守るのはドメインであって、その前に表示される名前ではありません — そしてスマートフォンでは、その表示名だけしか見えないことがよくあります。

見た目がそっくりな別ドメインには手が届かない

あなたのドメインと1文字違いのドメインは、他人のドメインであり、他人のレコードを持っています。あなたが何を公開しても、そこには届きません。それはレジストラと監視の問題であり、文字通り別の問題です。

メールボックスを非公開にはしない

ここのアドレスには、依然としてパスワードがありません。知っている人なら誰でも読むことができ、それがこのサービス全体の取り決めです。自分のドメインを使うことで無くなるのは推測される可能性であって、読まれる可能性ではありません — その点を正直に書いたものがキャッチオールドメインについてのガイドにあります。

最初から最後まで、実際にやってみる

作業全体を、どの段階でもドメインが動き続ける順序で並べました。

1. まずMXを確認する。dig +short MX yourdomain.comはsmtp.grabmail.ioだけを返すはずです。何かを追加する前にこれを直してください。受信できていないドメインでは、他の何をやっても無意味だからです。
2. SPFレコードを追加する。@に対して、すでにある場合を除いて。すでにある場合は編集してください。2つあることは厳格な設定ではなく、エラーだからです。
3. DMARCレコードを追加する。_dmarcに対して、いきなり厳格なポリシーで。ここには段階を踏むべき移行はなく、それを飛ばしても壊れるものは何もありません。
4. ワイルドカードDKIMレコードを追加する。*._domainkeyに対して。サブドメインの層を二重に塞ぎたいなら、ワイルドカードSPFレコードも追加してください。
5. 4つすべてを読み返す。TTLが切れるだけの時間が経ったら、パブリックリゾルバに対してdigで。
6. 自分宛てに何か送ってみる。どこからでもいいので、このドメイン上の自分のアドレスの1つにメールを送り、受信箱を開いてください。届けば、受信側はこの変更を無事に乗り越えたということであり、それこそが確認する価値のある唯一の退行です。

これでドメインは完成です。今後思いつくどんなアドレスも受け入れつつ、誰の身元も一切保証しません。まだドメインを接続していないなら、キャッチオールのガイドから始めてください — 必要なのはレコード1つ、同じく5分です — そのうえでこのページに戻ってくれば、何一つ中途半端に終わらせない順序になります。

質問