DMARCとは?SPF・DKIMの設定と自社でできる範囲・頼む範囲

DMARC(ディーマーク)は、自社のドメインを名乗るメールがSPF・DKIMの確認に通らなかったとき、受け取る側にどう扱ってほしいか(そのまま届ける・迷惑メールにする・受け取らない)を自社で決めて公開し、結果の報告も受け取れる仕組みです。 設定は自社のドメインのDNSにレコードを1行足すことで、その前にSPFかDKIMの設定が要ります。

なりすましメールが送られたときに最初にすること、DNSに置く3つのレコード、p=none から reject までの進め方、自社でできる範囲と頼む範囲、取引先やGmailから求められる理由を順に説明します。

DMARCとは(SPF・DKIMとの関係)

送信ドメイン認証は、受け取ったメールが正規の送信元から送られたかを確かめる技術で、SPF・DKIM・DMARCの3種類があります。 3つの違いは、何を確かめるかにあります。SPFは、メールが正規のサーバー(IPアドレス)から送られたかを確かめる仕組みで、確かめる対象はメールソフトに表示されない方の差出人のアドレス(エンベロープFrom)です。DKIMは、メールに付けた電子署名で確かめる仕組みで、署名を確かめるための公開鍵を自社のドメインのDNSに置きます。DMARCは、SPF・DKIMの結果を使い、メールソフトに表示される方の差出人のアドレス(ヘッダーFrom)のドメインと一致しているかを確かめます[12]。

SPFやDKIMだけでは、なりすましメールが確認をすり抜けることがあります。例えば、表示されない方のアドレスに偽のメールの送り手が自分のドメインを使うと、SPFの確認には通ります。DMARCは表示される差出人のドメインと照らし合わせるため、こうしたなりすましを見つけられます[12]。

DMARCに通るには、「SPFの確認とドメインの一致」か「DKIMの確認とドメインの一致」のどちらか一方を満たせばよく、両方そろっている必要はありません[1][8]。このドメインの一致を「アライメント」と呼びます。3つを並べると、次のとおりです。

技術何を確かめるか自社がDNSに置くもの
SPF正規のサーバー(IPアドレス)から送られたか送ってよいサーバーの一覧
DKIMメールの電子署名が正しいか署名を確かめる公開鍵
DMARC表示される差出人のドメインが、SPF・DKIMで確かめたドメインと一致しているか確認に通らなかったメールの扱いと、レポートの送り先
SPF・DKIM・DMARCの関係の図。受け取ったメールを、SPF(送ってよいサーバーか)とDKIM(署名は正しいか)で確かめ、DMARCが表示される差出人のドメインと一致しているかを確かめる。SPFかDKIMのどちらかで一致すれば合格。合格しなかったメールの扱いは、none(そのまま届ける)・quarantine(迷惑メールにする)・reject(受け取らない)の3つから決める
SPF・DKIM・DMARCの関係

DMARCで決められる扱いは、次の3つです。

  • none: そのまま届ける
  • quarantine: 迷惑メールにする
  • reject: 受け取らない

DMARCのレコードにレポートの送り先(rua)を書いておくと、受け取る側のメールサービスから結果のレポートが届くことがあります。レポートを見ると、自社のドメインがなりすましに使われているか、使われているならどこから・どのくらいの規模で送られているかがわかります[1][8]。受け取ったメールを見分ける手がかりは、標的型メール攻撃の手口と見分ける手がかりで扱っています。

自社の名前でなりすましメールが送られたら

まず、外から自社のドメインを名乗って送られたのか、自社のメールのアカウントが乗っ取られて送られたのかを分けます。 前者は、DMARCのポリシーを quarantine か reject にしておけば、DMARCで確かめている受け取る側で、迷惑メールにしたり受け取りを拒否したりできます[1]。後者は自社の正規のメールの仕組みから送られるため、SPF・DKIMの確認にもドメインの一致にも通り、DMARCでは見分けられません[12]。

の10大脅威2026のビジネスメール詐欺の事例では、偽の支払いの依頼が、取引先の担当者の正規のメールアドレスから送られていました。担当者のアカウントが乗っ取られていたとみられています[4]。乗っ取りが疑われるときは、パスワードを変え、多要素認証をどのアカウントから入れるかを決めて設定しましょう。偽の送金の依頼への備えは、送金のルールの決め方が参考になります。

外から名前を使われているときは、その兆しが自社に届くことがあります。偽のメールが存在しないアドレスに送られると、届かなかったことを知らせるメール(バウンスメール)が、名前を使われた側に戻ってくることがあるためです[1]。身に覚えのないバウンスメールが届き始めたら、なりすましを疑いましょう。

送られたとわかったら、次の3つを進めます。

  • 取引先・お客に注意を知らせる
  • 届いたメールを報告する
  • 被害が出たら警察に相談する

注意の知らせには、いつの情報か、どんなメールが届くかを書きます。偽のサイトのURLはそのまま載せず、伏せ字などにします。差出人のアドレスや送信元は偽装できるため、受け取った人に正しいアドレスかどうかを確かめさせる呼びかけは、見分ける方法として頼りにしません[1]。

届いたなりすましメールは、フィッシング対策協議会のフィッシングの報告のページの案内に沿って転送できます。報告した情報は、警察や名前を使われた会社に提供されることがあり、迷惑メールフォルダーに入ったメールは報告しなくてかまいません[13]。お金や情報の被害がすでに出ているときは、都道府県警察のサイバー犯罪相談窓口に相談します。

正規のドメインを差出人に使う「なりすまし送信メール」は2020年以降急増し、今もフィッシングメールの半分以上を占めています[12]。受け取った人は差出人を見ても本物と見分けられないため、自社のドメインの側で次の見出しの設定を整えておくことが大切です。

何を設定する?DNSに置く3つのレコード

設定するのは、自社のドメインのDNSに置く3つのレコードです。 SPFには送ってよいサーバーの一覧、DKIMには署名を確かめる公開鍵、DMARCには確認に通らなかったメールの扱いとレポートの送り先を書きます。DNSは、ドメインとサーバーを結びつける情報を置く仕組みで、ドメインを買った会社などの管理画面で編集します。

最初にやるのは、自社のドメインでメールを送っているサービスの洗い出しです。 社員のメールのほかに、自社のドメインを差出人にして送っている仕組みがないかを確かめます。例えば、次のようなものです。

  • 社員のメール
  • メールマガジンの配信サービス
  • Webサイトの問い合わせフォーム
  • 請求書を送るシステム

外のサービスから送るメールも、そのサービスでSPF・DKIMの確認に通るように設定されている必要があります[8]。漏れがあると、DMARCを強めたときに、そこから送った正規のメールが届かなくなるおそれがあります。

SPFは、TXTという種類のレコードです。Google Workspace だけでメールを送る会社なら、次の1行になります[6]。

v=spf1 include:_spf.google.com ~all

Microsoft 365 では include の後ろが spf.protection.outlook.com になり、Microsoft 365 のドメインでは末尾を -all にするのが推奨です[9]。ほかのサービスからも送るときは、include を足して1つのレコードにまとめます。1つのドメインに置けるSPFのレコードは1つだけで、2つあるとエラーになるためです[9]。

DKIMは、Google Workspace では、特権管理者が管理コンソールで鍵を作り、表示された値をTXTレコードとして足してから、管理コンソールで認証を始めます[7]。Microsoft 365 では、自社のドメイン(独自ドメイン)でDKIMの署名を有効にし、DNSにCNAMEという種類のレコードを2つ足します。onmicrosoft.com のドメインだけで送っているなら、自動で署名されるため何もしなくてかまいません[10]。

DMARCは、_dmarc という名前のTXTレコードです。例えば、次の1行になります(example.com は自社のドメインに置き換えます)。

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

p は確認に通らなかったメールの扱い(none・quarantine・reject)、rua はレポートの送り先のアドレスです。Google Workspace では、SPF・DKIMでメールが認証されるようになってから、48時間以上あけてDMARCを足します[8]。

メールを送らないドメインも守ります。 持っているだけのドメインや、Webサイトにしか使わないドメインも、なりすましに使われないようDMARCを reject にします[1]。SPFも、送ってよいサーバーを何も書かない形(-all だけ)にできます[9]。

3つのレコードをまとめると、次のとおりです。

レコードレコードの種類何を書くかどこで作るか
SPFTXT送ってよいサーバーの一覧DNSの管理画面
DKIMGoogle Workspace はTXT、Microsoft 365 はCNAME 2つ署名を確かめる公開鍵鍵はメールのサービスで作り、DNSに足す
DMARCTXT(名前は _dmarc)扱い(p)とレポートの送り先(rua)DNSの管理画面

進め方: p=none から reject まで

最初は p=none で始め、レポートで正規のメールが確認に通っていることを確かめてから、quarantine、reject の順に強めます[8][11]。最初から強い設定にすると、思いがけない失敗で、正規のメールまで拒否されるおそれがあるためです。

ただし、none のままでは、なりすましメールは受け取る人にそのまま届き続けます。フィッシング対策協議会のフィッシング対策ガイドライン 2026年度版の要件1には、「DMARCを導入していても、ポリシーが『p=none』では意味をなさない」とあります。すぐに reject にするのが難しいときは、まず quarantine にして、最後に reject を目指すのが適切で、reject は「望ましい」設定です[1]。このガイドラインは、Webサイトを運営する事業者に向けたものです。none は、強めるための準備の段階と考えましょう。

レポートの受け取り先は、個人のアドレスではなく、専用のメールボックスかグループにします。毎日多くのレポートが届くことがあるためです。quarantine・reject に上げるときは、pct(ポリシーをかける割合)で一部のメールから始め、100%まで少しずつ広げる方法もあります。

3つの段階で見ることは、次のとおりです。

段階p の値受け取る側の扱い見ること
1p=noneそのまま届け、レポートだけ届く洗い出したサービスのメールが、SPF・DKIMの確認に通っているか
2p=quarantine迷惑メールにする正規のメールが迷惑メールに入っていないか
3p=reject受け取らない新しく使い始めたサービスがレポートに出てこないか
DMARCを強める3段階の図。1 p=none: そのまま届けてレポートを見る。2 p=quarantine: 迷惑メールにする。3 p=reject: 受け取らない。レポートで正規のメールが通っているのを確かめてから、次の段階に進む
p=noneからrejectへの3段階

次に進む時期は送っているメールの種類や量で変わるため、日数で決めず、レポートで正規のメールが通っているかを見て決めましょう。ドメインをいくつか持っているときは、送るメールの少ないドメインから進めると、正規のメールを止める心配が小さくなります。

自社でできる範囲と頼む範囲

送っているサービスの洗い出しと、どこまで強めるかの判断は自社で行い、DNSへのレコードの追加は、DNSを管理している会社の管理画面で行います。 管理画面を触れない・触ったことがないときは、その会社に頼みます。

Microsoft 365 には、自社のドメインのSPFやDMARCのレコードを管理する画面がありません。ドメインの登録の会社かDNSのホスティングの会社(同じ会社のことが多い)で作り、DNSの設定に慣れていなければ、ドメインの登録の会社に助けを求めます[9][11]。Google Workspace でも、DMARCの設定で管理コンソールですることはなく、ドメインホスト(通常はドメインの販売元)でレコードを足します。外のサービスから送るメールのSPF・DKIMは、そのサービスに問い合わせて確かめます[8]。

これをもとに役割を分けると、次のようになります。

やること自社(IT担当・経営者)DNSを管理している会社・保守会社メールのサービス・配信サービス
送っているサービスの洗い出し一覧を作る—自社のドメインで送っているか答えてもらう
SPFを1つにまとめる足す値を集めるレコードを書き直す足す値を教えてもらう
DKIMの鍵を作る管理画面で作る公開鍵のレコードを足す鍵の値を出してもらう
DNSにレコードを足す管理画面を触れるなら自社で触れないなら頼む—
レポートを読む受け取り先を決めて目を通す見方を相談する—
ポリシーを強める判断自社で決める書き換えを頼む—

DNSを管理している会社や保守会社に頼むときは、次のことを伝えましょう。

  • 対象のドメイン名
  • 送っているサービスの一覧
  • 始めるポリシー(p=none)
  • レポートの送り先のアドレス

経営者は担当者に「DNSを管理している会社に相談して進めて」と伝え、強める時期の判断に加わりましょう。DNSの設定を頼むのに費用がかかるかは、契約しているサーバー・ドメインの会社や保守会社との契約で変わるため、この記事では目安を載せていません。

取引先やメールの送り先から求められたら

送り先のメールサービスの要件や国の要請で、送信ドメイン認証をそろえることが求められる流れがあります。

Gmail: 2024年2月1日から、個人用のGmailのアカウント(@gmail.com・@googlemail.com)にメールを送るすべての送信者に、SPFかDKIMの設定などが求められています。個人用のGmailのアカウントに1日5,000件以上送る送信者には、SPF・DKIM・DMARC(ポリシーは none でもよい)の設定などが求められ、ダイレクトメールでは表示される差出人のドメインとSPFかDKIMのドメインの一致も要ります。認証されていないメールは、迷惑メールに分類されたり、拒否されたりすることがあります[5]。

国の要請: 2023年2月1日、総務省・警察庁・はクレジットカード会社等に、メールを送らないものも含め、利用者向けに公開するすべてのドメインでDMARCを導入し、なりすましメールの受け取りを拒否するポリシーで運用するよう要請しました[2]。2025年9月1日には、総務省が電気通信事業者協会など通信の事業者の4つの団体に、DMARCの導入とポリシー(隔離・拒否)の設定、受け取る側でのDMARCの処理やレポートの送信などを、会員の事業者に周知するよう要請しています[3]。どちらも、中小企業に直接向けた要請ではありません。

取引先から「DMARCを設定していますか」と聞かれたら、今の状態と次の予定を答えましょう。例えば、「SPF・DKIMは設定済みで、DMARCは p=none でレポートを見ている段階です。quarantine に上げる予定です」のような答え方です。取引先のチェックシートで、まだできていない設問への答え方は、「いいえ」の設問はどう書くかを参考にしてください。

設定でつまずきやすいこと

つまずきやすいのは、SPFのレコードの書き方と、送っているサービスの洗い出しの漏れです。

SPFのレコードを2つ作ってしまう: サービスを足すたびに新しいレコードを作るとエラーになるため、1つのレコードにまとめます。

SPFの参照が10を超える: include などによるDNSの参照が10を超えるとエラーになります。include の中でさらに参照していることがあり、include が10個より少なくても超えることがあります[9]。

外のサービスが洗い出しから漏れる: 配信サービスや問い合わせフォームのメールが確認に通らないまま強めると、正規のメールが届かなくなるおそれがあります。

Microsoft 365 で SPF の末尾が ~all のまま: DKIMの署名がないメールでは、DMARCのポリシーが実質的に効かないため、Microsoft 365 のドメインでは -all が推奨です。

転送やメーリングリスト: 途中で送り主の情報や本文が変わり、DMARCに通らないことがあります。

メールの末尾に文言を足す仕組み: 送るメールに一律でフッターを付ける送信ゲートウェイを使っていると、DKIMの確認に影響することがあります。

サブドメインにもかかる: 親のドメインのDMARCは、自分のレコードを持たないサブドメインにもかかります。一致の確かめ方を厳格(adkim=s・aspf=s)にすると、サブドメインからのメールが拒否されることがあり、通常は緩い一致で足ります。

中小企業が今日やること

よくある質問

DMARCを設定すれば、なりすましメールは届かなくなる?

受け取る側がDMARCで確かめ、自社のポリシーが quarantine か reject なら、なりすましメールは迷惑メールにされるか受け取りを拒否され、受信トレイに届きにくくなります。none のままでは届き続けます。また、乗っ取られた正規のアカウントから送られたメールは、正規の仕組みから自社のドメインで送られるため、DMARCでは見分けられません[12]。

p=none のままでもいい?

Gmailの大量送信の要件のうち、DMARCのポリシーは none でも満たせます[5]。ただ、none ではなりすましメールがそのまま届くため、レポートで正規のメールが通っていると確かめられたら、quarantine・reject へ強めましょう。

メールを送っていないドメインも設定する?

設定します。持っているだけのドメインも、なりすましメールに使われないよう、DMARCを reject にします。2023年の国の要請でも、クレジットカード会社等に、メールを送らないドメインを含めたDMARCの導入が求められています[2]。

費用はかかる?

レコードを足すこと自体は、DNSの設定の作業です。頼むときの費用は、契約しているサーバー・ドメインの会社や保守会社との契約で変わるため、この記事では目安を載せていません。まずは契約先に、頼めるか・費用がかかるかを聞いてみましょう。

出典

  1. フィッシング対策ガイドライン 2026年度版(フィッシング対策協議会) 2026年10月28日確認
  2. クレジットカード会社等に対するフィッシング対策強化の要請(総務省・警察庁・経済産業省) 2026年10月28日確認
  3. フィッシングメール対策の強化について(要請)(総務省) 2026年10月28日確認
  4. 情報セキュリティ10大脅威 2026 解説書(組織編)(IPA) 2026年10月23日確認
  5. メール送信者のガイドライン(Google) 2026年10月28日確認
  6. SPF を設定する(Google) 2026年10月28日確認
  7. DKIM を設定する(Google) 2026年10月28日確認
  8. DMARC を設定する(Google) 2026年10月28日確認
  9. カスタム クラウド ドメインの有効なメール ソースを識別するように SPF を設定する(Microsoft) 2026年10月28日確認
  10. クラウド ドメインからメールに署名するように DKIM を設定する(Microsoft) 2026年10月28日確認
  11. クラウド送信者の差出人アドレス ドメインを検証するように DMARC を設定する(Microsoft) 2026年10月28日確認
  12. なりすまし送信メール対策について(フィッシング対策協議会) 2026年10月28日確認
  13. フィッシングの報告(フィッシング対策協議会) 2026年10月28日確認

改訂履歴

  • 公開

この記事は編集方針に沿って作成しています。誤りに気づかれた場合は訂正方針をご覧のうえ、info@cybersecurity-navi.com までお知らせください。