SPF と DKIM に共通して残る穴を、DMARC がどう塞ぐのかを説明します。「揃っている（アラインメント）」の2通りの確かめ方、ゆるい一致と完全一致、1行の読み方と置く場所、p= による扱いのお願い、rua= の集計レポート、p=none から段階的に厳しくする理由、そして自分のドメインを守るための宣言としての DMARC まで。
5本目の SPF と6本目の DKIM を見終えて、1つの穴が残りました。
図のなりすましは、自分のドメイン evil.example で SPF の宣言を書き、自分の鍵で DKIM の署名を付けています。どちらも正しい手順で合格します。ところが、画面に出る From: には 〇〇銀行 <[email protected]> と書いてあります。
SPF も DKIM も、「何かのドメインとして正しく送られた」ことは確かめてくれます。でも、そのドメインが受信者の画面に出ている差出人と同じかどうかは、どちらも見ていません。
利用者がだまされるのは、画面に出ている差出人です。ここを確かめない限り、なりすましは止まりません。この作品では、この最後の穴を塞ぐ DMARC（Domain-based Message Authentication, Reporting and Conformance）を見ていきます。
DMARC は、手紙の `From:` のドメインを基準にして、次のことを確かめます。
SPF か DKIM のどちらかが合格していて、しかも、その合格したドメインが `From:` のドメインと揃ってい るか。
この「揃っている」ことをアラインメント（alignment）と呼びます。
図の正規のメールを見てみます。From: は mail.animemo.app です。DKIM の署名も d=mail.animemo.app なので、揃っています。DKIM は合格しているので、DMARC も合格です。
DMARC が新しく確かめているのは、実は「揃っているか」だけです。合格・不合格の判定そのものは、SPF と DKIM の結果をそのまま使います。DMARC は、2つの結果を画面の差出人に結びつける役目をしています。
「揃っている」の確かめ方は、SPF 側と DKIM 側で2通りあります。
| 側 | 比べるもの |
|---|---|
| SPF 側 | SPF が確かめた封筒のドメイン と From: のドメイン |
| DKIM 側 | DKIM の署名の `d=` と From: のドメイン |
DMARC が合格するのは、どちらか一方でも「合格 かつ 揃っている」ときです。両方そろう必要はありません。
これには意味があります。5本目で見たとおり、転送されると SPF は落ちます。そのとき SPF 側では揃いませんが、DKIM 側で揃っていれば DMARC は合格します。逆に、メーリングリストで DKIM が壊れても、SPF 側で揃っていれば合格できます。どちらか1つが生き残ればよいので、実際の配送で起きる事情に強くなっています。
ただし、確実に合格させるには、両方で揃えておくのがおすすめです。Resend の設定をきちんとすれば、両方で揃います（次のページ）。
図の例では、封筒のドメインは send.mail.animemo.app、From: は mail.animemo.app で、文字としては一致していません。それでも SPF 側で「揃っている」と判定されます。
理由は、揃っているかの判定が、既定ではゆるい一致（relaxed）だからです。ゆるい一致では、親のドメイン（組織のドメイン）が同じなら揃っているとみなします。この2つはどちらも親が animemo.app なので、揃っています。
| 判定 | 書き方 | send.mail.animemo.app と mail.animemo.app |
|---|---|---|
| ゆるい一致（既定） | adkim=r / aspf=r | 一致（親が同じ） |
| 完全一致 | adkim=s / aspf=s | 不一致 |
ゆるい一致が既定なのは、1つの組織がサブドメインを使い分けて送ることが多いからです。Resend のように封筒だけ send.〜 にする方式も、この規則のおかげで問題なく使えます。
完全一致は、より厳しく管理したい組織向けです。最初はゆるい一致のままで構いません。
最初のなりすましを、DMARC で確かめてみます。
From: のドメインは bank.example です。SPF が合格したのは evil.example、DKIM が合格したのも evil.example。親のドメインも別なので、ゆるい一致でも揃いません。DMARC は不合格です。
さらに、受け取る側は `From:` のドメインである `bank.example` の掲示板から DMARC の宣言を読みます。銀行が _dmarc.bank.example に p=reject（不合格なら受け取りを拒否して）と宣言していれば、このメールは受信トレイに入らず、拒否されます。
ここでようやく、「画面に出ている差出人は本物か」が確かめられるようになりました。SPF と DKIM だけでは止められなかったなりすましが、DMARC を足したことで止まります。
大事なのは、止めるための宣言をしたのは、名乗られた銀行の側だということです。この点は後のページでもう一度触れます。
DMARC の宣言は、From: のドメインの前に _dmarc. を付けた名前の TXT に書きます。
_dmarc.animemo.app TXT "v=DMARC1; p=none; rua=mailto:[email protected]"部品は ; で区切ります。
| 部品 | 意味 |
|---|---|
v=DMARC1 | これは DMARC の宣言です（必ず先頭） |
p= | 不合格のメールをどう扱ってほしいか（後のページ） |
rua= | 集計レポートの送り先（後のページ） |
sp= | サブドメインだけ別の扱いにしたいとき |
adkim= / aspf= | 揃っているかの厳しさ（r：ゆるい、s：完全一致） |
必須なのは v= と p= だけです。最初は v=DMARC1; p=none; rua=mailto:… の3つで十分です。
受け取る側は、From: のドメインから DMARC の宣言を探します。From: [email protected] なら、まず _dmarc.mail.animemo.app を 引きます。
そこに宣言が無ければ、親のドメイン（組織のドメイン） の _dmarc.animemo.app を引きます。そこにあれば、その宣言を使います。
つまり、親のドメインに1行置けば、その下のサブドメインすべてに効きます。Resend の案内でも、DMARC は animemo.app の掲示板に _dmarc という名前で置く形になっています（10本目）。
サブドメインだけ扱いを変えたいときは、親の宣言に sp= を書きます。たとえば p=none; sp=reject なら、親のドメイン自体は様子見のまま、サブドメインを名乗る不合格のメールは拒否してほしい、という意味になります。
DMARC の宣言には、不合格だったメールの扱いを書く p= があります。
| 値 | 意味 |
|---|---|
p=none | 何もしなくていい。結果の報告だけ送ってほしい |
p=quarantine | 迷惑メールフォルダに入れてほしい |
p=reject | 受け取りを拒否してほしい |
これは受け取る側へのお願いです。最終的に決めるのは Gmail などの受け取る側で、お願いを参考にしつつ、評判（8本目）など自分の判断も加えます。
それでも、このお願いの効果は大きいです。SPF や DKIM の fail を受け取る側がどう扱うかは、これまで受け取る側任せでした。DMARC によって初めて、ドメインの持ち主が「うちを名乗る偽物は捨ててください」と明言できるようになりました。
DMARC の名前にある「Reporting」がこの機能です。rua= にメールアドレスを書いておくと、Gmail や Yahoo などの受け取る側から、集計レポートが届くようになります。
レポートには、1日分をまとめて次のようなことが書かれています。
| 書かれていること | 例 |
|---|---|
| どの送信元（番号）から | Amazon SES のサーバー |
| 何通 | 1,204通 |
| SPF・DKIM・DMARC の結果 | すべて合格 |
これを見ると、自分のドメインを名乗ったメールが、どこから、どれだけ出ているかが分かります。正規の送信元なのに不合格になっているもの（設定漏れ）や、知らない送信元（なりすまし）も見つかります。
レポートは機械向けの形式（XML）で届き、数も多いので、そのまま読むのは大変です。無料で集計して見やすくしてくれるサービスもあります。受け取り専用のアドレスを用意しておくとよいでしょう。
最初から p=reject にすれば一番安全に見えますが、そうはしません。
会社やサービスでは、自分でも忘れているメールの送信元がよくあります。問い合わせフォームのサービスが自動返信を出していた、請求書の送付サービスが会社のドメインで送っていた、社内ツールの通知がそうだった、などです。これらが SPF や DKIM の設定から漏れていると、DMARC は不合格になります。
いきなり p=reject にすると、その正規のメールがすべて拒否されて消えます。しかも送った側には気づきにくい形で消えます。問い合わせへの自動返信が届かなくなっていた、と数か月後に気づく、ということが起こります。
そこで、まず p=none で始めて、前のページの集計レポートで実態を把握します。Animemo の手順書に「DMARC は p=none から始める」とあるのは、この理由です。
p=none で始めた後は、次の順に進めます。
| 段階 | やること |
|---|---|
1. p=none | 数週間、集計レポートを見て、自分のドメインから出ているメールを把握する |
| 2. 漏れを直す | 不合格になっている正規の送信元に、SPF や DKIM を設定する |
3. p=quarantine | 不合格は迷惑メールへ。問題が出ないか様子を見る |
4. p=reject | 不合格は拒否。ここで完成 |
p=none のままでも、Gmail や Yahoo の条件（8本目）は満たせます。ただし、p=none は「何もしなくていい」という意味なので、自分のドメインを名 乗るなりすましは止まりません。reject まで進めて初めて、なりすましを受け取り拒否してもらえるようになります。
焦る必要はありませんが、p=none を置いたまま忘れてしまうのは避けましょう。
この作品の途中で、銀行のなりすましが止まったのは、銀行が自分で DMARC を宣言していたからでした。
裏返すと、DMARC を宣言していないドメインは、名乗られても誰も止めてくれません。受け取る側には、その偽物を捨ててよいという根拠がないからです。4本目で見た「被害②：名乗られた側の評判が落ちる」を防ぐには、自分で宣言するしかありません。
この考え方は、メールを送っていないドメインにも当てはまります。たとえば、ブランドを守るために取っただけの別のドメインがあるなら、次の2行を置いておくと、そのドメインを名乗ったメールはすべて不合格・拒否になります。
（そのドメイン） TXT "v=spf1 -all"
_dmarc.（そのドメイン） TXT "v=DMARC1; p=reject"v=spf1 -all は「このドメインからは、どこからも送らない」という意味の SPF です。
5〜7本目で見た3つを並べます。
| 何を確かめるか | 弱点 | |
|---|---|---|
| SPF | 送信元の番号が、封筒のドメインの許可リストにあるか | 画面の From: を見ない。転送で壊れる |
| DKIM | メールに付いた電子署名が正しいか | 署名のドメインと From: が別でもよい |
| DMARC | SPF か DKIM で合格したドメインが、From: と揃っているか。不合格ならどうするか | 単体では何も確かめない（上の2つが前提） |
1つだけでは必ず穴が残ります。SPF の穴②（転送）を DKIM が補い、2つに共通する穴（画面の差出人を見ない）を DMARC が塞ぎます。3つそろって初めて、「画面に出ている差出人は本物」と言えます。
3つも設定が要るのは、このためです。どれか1つを省くと、その穴がそのまま残ります。
この作品で見たことをまとめます。
| 項目 | 内容 |
|---|---|
| 確かめること | SPF か DKIM が合格し、そのドメインが From: と揃っているか |
| 揃い方 | SPF 側（封筒）か DKIM 側（d=）のどちらかで揃えばよい |
| 揃いの厳しさ | 既定はゆるい一致。親のドメインが同じならよい |
| 置く場所 | _dmarc.（From のドメイン）。親に置けばサブドメインにも効く |
p= | none → quarantine → reject と段階的に |
rua= | 自分のドメインを名乗ったメールの集計が届く |
| 意味 | 受け取る人を守り、自分のドメインの名前も守る |
身元確認の3つは、ここで出そろいました。ところが、3つとも合格していても、メールが迷惑メールフォルダに入ることがあります。次の作品では、その理由である評判を見ていきます。
ログインするとコメントできます。
読み込み中…
権利侵害・不適切な内容の連絡: [email protected]