取引先から「御社を名乗るメールが届いた」と連絡を受け、夜のデスクで自社ドメインのDNS設定を確認しようとしている保守運用の担当者
セキュリティ・パッチ約23分

なりすまし対策のDMARC設定手順｜p=noneから段階的に上げる

取引先から電話が来ます。「御社を名乗るメールが届いたんですが、これ本物ですか？」

添付ファイル付き。文面は日本語として少し不自然。差出人のアドレスは、確かに自社のドメイン。送った覚えはありません。

あるいは、もっと静かな形で来ることもあります。「最近、御社からのメールが迷惑メールに入るようになりました」。システムからの受注通知やパスワードリセットのメールが、いつの間にか届きにくくなっている。

どちらの場合も、行き着く先は同じ仕組みです。DMARC（ディーマーク）。ただ、これは「入れれば解決」の設定ではありません。入れ方を間違えると、自社の大事な通知メールまで止まってしまう、こわいところのある仕組みです。だからこそ、順番があります。

結論：DMARCは4段階に分けて進めます。①いまのSPF・DKIMがヘッダFromのドメインと揃っているかを確認する。②p=none（何も弾かない設定）とレポート送り先だけを書いたTXTレコードを1行、DNSに追加する。③2〜4週間レポートを読んで、自社のメール送信元を全部洗い出す。④漏れを直してから、quarantine（隔離）→reject（拒否）へ上げる。最初にやるのは「拒否」ではなく「記録」です。

いちばん大事なことを先に書いておきます。いきなり p=reject にしないでください。 これが、この記事でお伝えしたい事故防止のすべてです。逆に言えば、p=none から始める限り、DMARCは既存のメールの届き方を1通も変えません。安心して最初の1行を入れられます。

なお、DNSの管理権限や送信の経路は現場ごとに大きく違います。ここに書くのは出発点です。実際のレコードの値は、自分の環境と各サービスの公式情報で確認しながら進めてください。

何が起きているか：DMARCが「やったほうがいい対策」ではなくなってきた

DMARC自体は新しい技術ではありません。仕様（RFC 7489）が出たのは2015年です。長いあいだ「余裕があればやりたいセキュリティ対策」の位置にありました。

それが変わったのは、受信側の大手が、送信者に要件として求め始めたからです。

たとえばGoogleの「メール送信者のガイドライン」では、Gmail宛に1日5,000通以上を送る送信者に対して、SPF・DKIM・DMARCの設定が求められています（DMARCは p=none でも要件は満たせます）。それ未満の少量の送信者にも、SPFまたはDKIMのいずれかは求められています。ほかの大手の受信側も、おおむね同じ方向に進んでいます。

つまり、DMARCの位置づけが移りました。

保守運用の担当者にとって、これは他人事ではありません。システムから出るメールが届かなくなると、業務が止まります。 受注通知、パスワードリセット、請求書の送付、問い合わせの自動返信。どれも「届いて当たり前」で回っているものばかりです。

そして、いちばん厄介なのは「送信元を誰も把握していない」こと

ここが現場のしんどいところです。DMARCを入れようとすると、必ずこの壁に当たります。

自社ドメインでメールを出しているものを数えてみると、たいてい想像より多くなります。

そのうえ、DNSは制作会社やホスティング会社が管理していて、自分では触れない。メールサーバーは前任者が設定したまま。「うちのメール周り、誰が担当してるんでしたっけ」という状態は、まったく珍しくありません。

これは、把握を怠ってきたからではありません。メールの送信元は、業務が増えるたびに自然に増えていくもので、増えたことを記録する仕組みがどこにも無かっただけです。会社の歴史の分だけ散らばっているのが普通です。

そして、ここがこの記事のいちばん伝えたいところなのですが——DMARCの p=none は、その散らばった送信元を洗い出すための道具として使えます。 何も弾かずに、「いま、誰があなたのドメインを名乗ってメールを出しているか」だけを教えてくれる。セキュリティ設定である前に、棚卸しの道具なのです。

DMARCがやっていること（SPF・DKIMとの関係）

先に、3つの関係だけ整理します。

DMARCは、SPFとDKIMの上に乗る仕組みです。土台の2つが無いところにDMARCだけ置いても、何も守れません。 まだSPF・DKIMが入っていないなら、そちらが先です。

見落としやすい肝：「アライメント（ドメインの一致）」

ここがDMARCで最初につまずくポイントです。

DMARCは、SPFやDKIMが pass しただけでは合格にしません。その認証に使われたドメインが、受信者が画面で見る差出人（ヘッダFrom）のドメインと揃っているかまで見ます。これをアライメントと呼びます。

具体的に、こういうことが起きます。

メール配信SaaSを使っていると、SPFの検証に使われるのはエンベロープFrom（配送用の差出人）で、これがSaaS側のドメイン（bounce.example-mail.jp など）になっていることがあります。SaaS側の設定は正しいので、SPFは pass します。でも、利用者が見るFromは info@自社ドメイン。 ドメインが揃っていないので、DMARCとしては不合格です。

ヘッダFrom : info@example.com        ← 受信者が画面で見る差出人
SPFの検証  : bounce.example-mail.jp  ← pass するが、ドメインが違う
                                        → DMARCのアライメントは不合格

この場合の解決策は、DKIMを自社ドメインで署名することです。多くの配信SaaSには「独自ドメインでDKIM署名する」設定があり、DNSにCNAMEやTXTを1〜2件足せば有効になります。DMARCはSPFとDKIMのどちらか一方がアライメント込みで通っていれば合格なので、DKIMさえ自社ドメインで通っていれば大丈夫です。

そして実務上、DKIM側を通しておくほうが強い理由がもうひとつあります。後で触れる「転送されるとSPFが壊れる」問題に、DKIMは影響を受けにくいからです。

メールが届かない側の切り分け（送れていないのか、届いているのに埋もれているのか）はメールが届かない障害の切り分け｜SMTP・SPF・DKIMの確認に整理しています。この記事は「これから設定する側」の話です。

手順1：いまの状態を確認する（10分）

まず、自分のドメインに何が入っているかを見ます。dig コマンド3行です。

# SPF（v=spf1 で始まる行があるか）
dig +short TXT example.com

# DMARC（何も返らなければ、まだ未設定）
dig +short TXT _dmarc.example.com

# DKIM（セレクタ名が分かっている場合。例: セレクタが "default"）
dig +short TXT default._domainkey.example.com

DMARCの行が何も返ってこなくても、まったく問題ありません。 それが普通のスタート地点です。むしろ、身に覚えのない古いレコードが2行入っているほうが厄介なので、何も無いのは幸運なくらいです。

DKIMのセレクタ名が分からないときは、自分宛にテストメールを1通送って、受信したメールのヘッダー（詳細情報）を見るのが早いです。Gmailなら「メッセージのソースを表示」で確認できます。

Authentication-Results: mx.google.com;
       spf=pass (...) smtp.mailfrom=example.com;
       dkim=pass header.i=@example.com;
       dmarc=pass (p=NONE ...) header.from=example.com

見るのは3か所です。spf= dkim= dmarc= が、それぞれ pass か fail か none。そして smtp.mailfrom と header.i のドメインが、header.from と揃っているか。ここが揃っていれば、アライメントは足りています。

この時点で全部 pass していなくても、落ち込まなくて大丈夫です。いま何が通っていて何が通っていないかが分かった、それがこの10分の成果です。

手順2：レポートの受け先を先に決める

DMARCを入れると、受信側から集計レポートが届き始めます。ここで一つ、先に決めておくことがあります。

レポートの宛先を、自分の普段のメールアドレスにしないでください。

集計レポートは、受信側のサービスごとに1日1通ずつ、XMLファイルをzipやgzipで圧縮した添付ファイルとして届きます。相手が多ければ1日に十数通、送信量の多い会社ならもっと来ます。普段使いの受信箱に混ぜると、埋もれるか、うんざりして見なくなるかのどちらかです。

現実的な選択肢は3つです。

  1. 専用のメールアドレスを1つ作る（dmarc-report@自社ドメイン など）。いちばん手軽で、まずはこれで十分です。
  2. 共有メールボックスやチーム宛のアドレスにする。一人運用でも、引き継ぎを考えると個人アドレスより安全です。
  3. DMARCレポートの集約サービスを使う。XMLを読み解いてグラフにしてくれます。無料枠のあるサービスもあります。送信量が多い、あるいは早く全体像がほしいなら検討する価値があります。

最初は1で構いません。XMLを直接読むのはしんどいですが、最初の2週間だけの辛抱です（読み方は手順4で書きます）。

別ドメイン宛にレポートを送りたいときの注意：rua= に自社ドメイン以外のアドレス（集約サービスなど）を指定する場合、受け取る側のドメインに許可のレコードが必要です。サービス側から「このTXTレコードを追加してください」と案内されるので、そのとおりに入れます。形式は example.com._report._dmarc.受け先ドメイン に "v=DMARC1" を置くものです。ここを飛ばすと、レポートが届かないまま「設定したのに何も来ない」と悩むことになります。

手順3：p=none のレコードを1行だけ入れる

準備ができたら、DNSにTXTレコードを1件追加します。

項目値
ホスト名_dmarc.example.com（管理画面によっては _dmarc だけ）
タイプTXT
値v=DMARC1; p=none; rua=mailto:dmarc-report@example.com
TTL3600（1時間）程度。指定できるなら短めに

タグの意味は次のとおりです。最初は3つだけ書けば十分で、残りは省略して構いません。

タグ意味最初に入れる値
vバージョンDMARC1（固定）
pポリシー（失敗したメールの扱い）none（何もしない＝記録だけ）
rua集計レポートの送り先手順2で決めたアドレス
spサブドメイン用のポリシー省略（p を引き継ぐ）
adkim / aspfアライメントの厳しさ省略（r＝緩い判定になる）
pctポリシーを適用する割合省略（100%。手順5で使う）

p=none は「認証に失敗しても、受信側は何もしなくていい」という意味です。 つまり、このレコードを入れてもメールの届き方は1通も変わりません。変わるのは、レポートが届き始めることだけ。だから、業務時間中に入れても事故になりません。

反映されたか確認します。

dig +short TXT _dmarc.example.com
# → "v=DMARC1; p=none; rua=mailto:dmarc-report@example.com" が返ればOK

DNSのキャッシュの都合で、すぐには反映されないことがあります。数分〜TTL分だけ待って、もう一度叩いてみてください（名前解決がうまくいかないときの切り分けは名前解決できない障害の切り分け｜DNSを疑う順番にまとめています）。

DNSを他社が管理している場合の依頼文

自分でDNSを触れない現場のほうが多いと思います。そのまま使える依頼文を置いておきます。

お世話になっております。

example.com のDNSに、下記のTXTレコードを1件追加していただけますでしょうか。

  ホスト名：_dmarc.example.com
  タイプ　：TXT
  値　　　：v=DMARC1; p=none; rua=mailto:dmarc-report@example.com
  TTL　　 ：3600（指定可能であれば）

こちらはメール認証（DMARC）のレポート受信を開始するための設定です。
ポリシーは p=none のため、既存のメールの送受信可否には影響しません。

お手数をおかけしますが、ご対応のほどよろしくお願いいたします。

「p=none のため既存の送受信に影響しません」の一文を必ず入れるのがコツです。相手も慎重になる設定なので、影響範囲を先に伝えておくと、確認のやり取りが1往復減ります。

あわせて、入れた事実を記録に残しておきます。DNSの変更は、あとから「いつ誰が何のために入れたか」が分からなくなりやすい設定の代表です（→変更管理台帳の付け方｜いつ・誰が・何を変えたか残す）。

手順4：2〜4週間レポートを読んで、送信元を棚卸しする

DMARCのポリシーを「見るだけ」「隔離」「拒否」の3段階で少しずつ上げていく流れを、郵便物の扱われ方で表した図
いきなり拒否にしない。まず記録だけの「見るだけ」で送信元を洗い出し、確認できてから隔離・拒否へ上げる

ここが、DMARC導入でいちばん時間がかかり、そしていちばん価値のある工程です。

レポートのXMLは、見た目はごついですが、実際に見るのは3つの情報だけです。

<record>
  <row>
    <source_ip>203.0.113.25</source_ip>     ← どのIPから送られたか
    <count>142</count>                       ← その日、何通あったか
    <policy_evaluated>
      <dkim>fail</dkim>                      ← DKIMのアライメント結果
      <spf>pass</spf>                        ← SPFのアライメント結果
    </policy_evaluated>
  </row>
</record>

送信元IP・通数・SPF/DKIMの結果。 これだけです。あとは、出てきたIPを「うちのどのシステムか」に対応づけていきます。

分からないIPは、逆引きで当たりが付くことがあります。

dig +short -x 203.0.113.25
# → mail01.example-saas.jp のような名前が返れば、そのサービスだと分かる

こうして表を1枚作ります。これが、DMARCで手に入るいちばんの成果物です。

送信元何のメールかSPFDKIM状況
社内メールサーバー社員の通常メールpasspassOK
基幹システムのサーバー受注通知・出荷通知passfailDKIM未署名。要対応
メルマガ配信SaaS販促メールfailpassOK（DKIMで通っている）
複合機（事務所）スキャン文書の送信failfailSPFにIPが未登録。要対応
見覚えのないIP？failfail転送か、なりすましの可能性

この表を作っている途中で、たいてい「あ、これ忘れてた」が2つか3つ出てきます。それが正常です。 むしろ、それを見つけるためにこの2〜4週間を使っています。

「見覚えのないIP」を、いきなりなりすましと決めつけない

fail が並んでいると不安になりますが、正規のメールが fail することは普通にあります。代表的なのが転送です。

社員が自分のGmailに会社メールを転送している。取引先のメーリングリストを経由している。こういう経路では、途中のサーバーが送り直す形になるため、SPFは構造上どうしても失敗します。これは異常ではなく、SPFという仕組みの性質です。

一方、DKIMの署名は転送されても残ることが多い。だから、手順1で書いたとおり「DKIMを自社ドメインで通しておく」ことが効いてきます。転送されても届く状態を作れるのは、実質DKIMだけだと思っておくと判断しやすいです。

もちろん、本当のなりすましが混じっていることもあります。見分けの目安は、通数と継続性です。1日に数通で、逆引きが個人利用のプロバイダなら転送の可能性が高い。1日に数百通が海外の見知らぬIPから継続して出ているなら、なりすましを疑います。判断に迷うときは、量の推移を1〜2週間見てからで構いません。

なお、不審な送信が実際に確認できた場合の初動は不正アクセスの疑いがあるときの初動と保全を参考にしてください。DMARCはあくまで「受信側に弾いてもらう」仕組みなので、送信の踏み台にされていないかは別途確認が要ります。

手順5：漏れを直してから、段階的に上げる

表ができて、要対応の行を潰し終わったら、いよいよポリシーを上げます。

上げてよい合格ライン

判断はシンプルです。

レポートに出てくる自社の正規の送信元が、すべてSPFかDKIMのどちらかでアライメントを通せている。

「全部が両方 pass」である必要はありません。どちらか一方が通っていれば合格です。まだ fail が残っているシステムがあるなら、そこを直すのが先です。

quarantine（隔離）から

いきなり reject には行きません。まず隔離、それも一部だけから始めます。

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-report@example.com

pct=10 は「対象の10%にだけこのポリシーを適用してほしい」という指定です。万一漏れがあっても、影響が10分の1で済みます。 ここで1〜2週間様子を見て、問い合わせが来ないこと、レポートの pass 率が下がらないことを確認します。

問題なければ pct=50、さらに pct=100(pct省略）へ。それぞれ1〜2週間ずつ見ます。

pct の扱いは受信側によって差があります。過信せず、「影響を減らす目安」として使ってください。

そして reject（拒否）へ

v=DMARC1; p=reject; rua=mailto:dmarc-report@example.com

ここまで来て、ようやく「自社ドメインを騙ったメールは受信側に捨ててもらう」状態になります。

全体の期間は、急がなければ3〜6か月を見ておくとちょうどいいくらいです。送信元が少ない小さな環境なら1〜2か月で届きます。焦って縮めるメリットは、あまりありません。

上げる前に、必ずやっておく1つのこと

TTLを短くしておいてください。

p=reject にして、もし想定外の送信元が残っていたら、その瞬間からそのメールは届かなくなります。パスワードリセットが届かない、請求書が届かない、という形で表に出ます。

戻す作業自体は、DNSのレコードを p=none に書き換えるだけの1行です。でも、戻した設定が世界中に行き渡るまでには、TTLの分だけ時間がかかります。 TTLが86400（24時間）だと、最悪まる1日、届かない状態が続きうる計算です。300〜3600（5分〜1時間）にしておけば、切り戻しはその範囲で収まります。

「すぐ戻せるようにしてから、上げる」。 これはリリース作業の考え方とまったく同じです（→「すぐ戻せる」リリース設計｜ロールバック手順の用意）。

段階を上げる作業は、業務時間中の、午前中にやるのがおすすめです。夕方や金曜に上げると、異変に気づくのが遅れます。

影響：入れると、現場は何が変わるか

時間の目安も出しておきます。手順1〜3（現状確認・アドレス作成・レコード追加）で合わせて30分から1時間。手順4のレポート確認が週に15分×3〜4週間で、合計1時間ほど。手順5の段階上げは、1回あたり5分の作業を3〜4回。全部足しても、実作業は3時間前後です。長いのは待ち時間であって、手を動かす時間ではありません。

明日やること：30分でできるところまで

いきなり reject まで見通さなくて大丈夫です。明日やるのは、ここまでです。

  1. dig +short TXT _dmarc.自社ドメイン を1回叩く。何も返ってこないことの確認でOKです。
  2. dig +short TXT 自社ドメイン でSPFを確認する。v=spf1 の行があるかどうかだけ見ます。
  3. レポート受信用のアドレスを1つ作る（dmarc-report@自社ドメイン など）。
  4. DNSに v=DMARC1; p=none; rua=mailto:... のTXTを1件追加する。自分で触れないなら、上の依頼文をそのまま送る。
  5. 変更管理の記録に1行残す。
  6. カレンダーに「2週間後：DMARCレポートを見る」の予定を入れる。

1と2だけなら5分で終わります。 ここまでやれば、「うちはSPFは入っているがDMARCは未設定」という現状が分かります。それだけでも、次に「メール届いてますか」と聞かれたときの答え方が変わります。

3〜4に進めるなら、それで今日のDMARC導入は完了です。あとの2週間は、待っているだけで構いません。

「DMARC導入」チェックリスト

コピーして、進み具合の確認に使ってください。全部を今日そろえる必要はありません。

まず外せない最低ラインの3つです。

ここから先は、順に進めながら埋めていく項目です。

土台の確認

レポートの確認

段階を上げるとき

入れたあと

全部に○が付かなくて大丈夫です。最低ラインの3つ、とくに「p=none から始めた」さえ言えれば、いちばんこわい事故は避けられています。

DMARCは、一度きりの設定作業ではなく、送信元の変化に合わせて見続ける運用です。だから、今日100点を取る必要はまったくありません。

なりすましは、こちらが何かを間違えたから起きるものではありません。ドメインを名乗るのは、誰にでもできてしまう——それがメールという仕組みの、もともとの性質です。だから対策が要る。あなたの管理が甘かった、という話ではまったくありません。

そして、p=none の1行を入れた瞬間から、これまで見えなかった自社のメールの全体像が、勝手に集まり始めます。何年も誰も把握していなかったものが、待っているだけで表になっていく。これは、けっこう気持ちのいい仕事です。

今日は、dig を1回叩くところまでで十分です。

DMARCのレポートから自社のメール送信元の一覧を整理し終えて、朝の光の中で肩の力が抜けた穏やかな表情をしている保守運用の担当者

よければ、こちらも

メール周りは、設定・障害・引き継ぎの3方向から手が入る場所です。あわせて見ておくと、次に何か言われたときに落ち着けます。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語