DMARCとは？SPF・DKIMとの違いと設定手順を段階導入で解説

サーバー 公開 2026-10-06　/　最終確認 2026-10-06　/　サイトスカウター編集部

DMARC（ディーマーク）とは、SPFとDKIMの認証結果を使って「自社ドメインを名乗るメールが認証に失敗したとき、受信側にどう扱ってほしいか」をDNSで宣言し、さらにその結果のレポートを受け取る仕組みです。なりすましメール対策では、SPF・DKIM・DMARCの3つを組み合わせて使います。

この記事では、3つの役割分担、DNSのTXTレコードの具体的な書き方、いきなり拒否設定にして自社メールを止めないための段階導入（none→quarantine→reject）、Gmail・Yahoo!メールの送信者要件、そして現場でよく踏む失敗（SPFのDNS参照10回制限、SPFレコードの重複など）を順に説明します。

内容はRFC、Google・Yahooの公式ドキュメント、総務省の資料で2026年10月6日に確認しました。なお、DMARCの標準仕様は2026年にRFC 7489から新しいRFC（RFC 9989など）へ改訂されています。設定の基本は変わりませんが、後述のとおり一部のタグが整理されています。

目次
1. DMARC・SPF・DKIMの役割分担と違い 2. SPFレコードの書き方（DNS TXTレコードの例） 3. DMARCポリシーの段階導入：none→quarantine→reject 4. Gmail・Yahoo!メールの送信者ガイドライン（2024年〜） 5. DMARC・SPFでよくある失敗と対処 6. サーバー情報調査でDNSレコードを確認する よくある質問 出典・参考資料

DMARC・SPF・DKIMの役割分担と違い

メールの「差出人」は、実は誰でも自由に書き換えられます。メールには、封筒にあたるエンベロープ送信者（Return-Path、MAIL FROM）と、受信者の画面に表示される From ヘッダーの2種類の差出人があり、From ヘッダーは何の認証もなしに偽装できます。これを防ぐために作られたのが、次の3つの技術です。

SPF（Sender Policy Framework）

「このドメインのメールは、このIPアドレスから送ってよい」という送信元の許可リストをDNSに公開する仕組みです。受信側は、メールを送ってきたサーバーのIPアドレスがリストに載っているかを確認します。仕様はRFC 7208です。ただしSPFが確認するのは主にエンベロープ送信者のドメインで、受信者に見える From ヘッダーとは別物です。

DKIM（DomainKeys Identified Mail）

送信側がメールに電子署名を付け、受信側がDNSに公開された公開鍵で署名を検証する仕組みです。署名はヘッダーのDKIM-Signatureに入り、d=（署名したドメイン）とs=（セレクタ）で公開鍵の場所が決まります。公開鍵は「セレクタ._domainkey.ドメイン」というホスト名のTXTレコードに置きます（RFC 6376）。メール本文や主要ヘッダーが転送途中で改ざんされていないかも分かります。

DMARC

SPFとDKIMは、それぞれ単体では「From ヘッダーのドメインと一致しているか」までは見ません。DMARCはここを補い、SPFまたはDKIMのどちらかが成功し、かつその認証ドメインが From ヘッダーのドメインと一致（アライメント）していることを要求します。そのうえで、失敗時の扱い（何もしない・迷惑メール扱い・拒否）を送信ドメインの持ち主がポリシーとして宣言し、集計レポートを受け取れるようにします。

項目SPFDKIMDMARC
確認するもの送信元IPが許可済みか電子署名が正しいかSPF/DKIMの結果が From と一致するか
DNSの置き場所ドメイン直下のTXTセレクタ._domainkey のTXT_dmarc のTXT
失敗時の扱いの指定限定的（~all / -all）なしnone / quarantine / reject
レポートなしなしあり（rua）

つまり、SPFとDKIMは「検査の道具」、DMARCは「検査結果をFromドメインに結びつけ、方針とレポートを決める司令塔」です。DMARCだけを置いても、土台のSPF・DKIMが設定されていなければ機能しません。

図1　なりすまし対策の3層構造
DMARCFromとの一致を要求し方針を宣言DKIM電子署名で改ざんと送信者を検証SPF送信元IPの許可リストを公開DNSすべての設定の置き場所
下から順に土台を作り、最後にDMARCで方針を決めます。

SPFレコードの書き方（DNS TXTレコードの例）

以下は example.com の例です。IPアドレスは文書用のものを使っています。実際には自社のメールサービスの案内に従って書き換えてください。

SPFレコードの例

ドメイン直下（ホスト名は @ または空欄）にTXTレコードを1つ作ります。

example.com.  TXT  v=spf1 ip4:192.0.2.10 include:_spf.google.com ~all
  • v=spf1：SPFレコードであることを示す必須の書き出しです。
  • ip4: / ip6:：自社サーバーのIPアドレスを直接許可します。
  • include:：Google WorkspaceやメールマガジンASPなど、外部サービスの許可リストを取り込みます。
  • ~all：リストにない送信元は「ソフトフェイル」（疑わしいが拒否はしない）、-all は「ハードフェイル」（許可していない）を意味します。Googleのヘルプは Google Workspace 向けに v=spf1 include:_spf.google.com ~all を示しています。

DKIMレコードの例

DKIMの鍵ペアは、使っているメールサービス側で生成するのが一般的です。管理画面に表示される公開鍵とセレクタを、DNSに登録します。

selector1._domainkey.example.com.  TXT  v=DKIM1; k=rsa; p=MIIBIjANBgkq...（公開鍵。長いため省略）

セレクタ名（ここでは selector1）はサービスごとに決まります。複数のサービスからメールを送るなら、サービスの数だけ別のセレクタを登録できます。

DMARCレコードの例

ホスト名は _dmarc です。最初は監視モード（p=none）から始めます。

_dmarc.example.com.  TXT  v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
  • v=DMARC1：DMARCレコードであることを示します。
  • p=：ポリシー（none / quarantine / reject）。
  • rua=：集計レポートの送り先。複数ある場合はカンマ区切りです。
  • adkim= / aspf=：アライメントの厳しさ（r=relaxed、s=strict）。省略時は relaxed で、Googleのヘルプも「なりすまし防止には relaxed で通常十分」という趣旨の案内をしています。

ブラウザで確認する(DNSルックアップ)

コマンドを使わずに、公開済みのSPFレコードを確認したい場合は、IPアドレス確認ツールズのDNSルックアップが使えます。ドメイン名を入力すると、A・AAAA・MX・NS・CNAME・TXT・SOAの各レコードをまとめて表示し、無料で登録も不要です。SPFはドメイン直下のTXTレコードに v=spf1 で始まる形で書かれているので、TXTの欄で内容を確認できます。MXの欄からは、メールの受け口(受信サーバー)も同時に分かります。

DNSルックアップでdnsblchecker.comを検索した結果。TXTの欄にv=spf1 ip4:160.248.0.73 ~allと表示されている
実際の表示例(DNSルックアップで dnsblchecker.com を検索)。TXTの欄に v=spf1 ... で始まるSPFレコードが表示されます。

なお、DMARC(_dmarc. を付けたホスト名)やDKIM(セレクタ._domainkey. を付けたホスト名)のレコードは、先頭がアンダースコアのホスト名です。2026年10月6日時点で、このツールの入力欄は _dmarc. で始まる名前を「有効なドメイン名ではない」として受け付けませんでした。DMARC・DKIMの確認は、次のdig／nslookupを使ってください。

登録後に確認するコマンド

DNSの反映後、次のコマンドで公開内容を確認できます（Windowsなら nslookup を使います）。

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.com

# Windows の場合
nslookup -type=TXT _dmarc.example.com
図2　DNSに登録するTXTレコード一覧
SPFドメイン直下に v=spf1 で始まる1件DKIMセレクタ._domainkey に v=DKIM1DMARC_dmarc に v=DMARC1 で始まる1件rua宛先実在し受信できるメールボックスTTL変更予定があれば短めにしておく
3種類とも別のホスト名に置きます。

DMARCポリシーの段階導入：none→quarantine→reject

DMARCの最大の落とし穴は、いきなり厳しいポリシーにして、正規のメールまで届かなくなることです。Googleのヘルプも、まず p=none で開始し、日次レポートで状況を確認しながら quarantine、最後に reject へ進める手順を案内しています。

3つのポリシーの意味

  • p=none：何もせず通常どおり配信し、レポートだけ受け取ります。導入の第一歩です。
  • p=quarantine：認証に失敗したメールを迷惑メールフォルダーなどに隔離するよう求めます。
  • p=reject：認証に失敗したメールを受信拒否するよう求めます。なりすましに対して最も強い設定です。

導入の手順

  1. 送信元を洗い出します。自社のメールサーバーに加え、メルマガ配信、予約・決済システム、問い合わせフォームなど、自社ドメインで送信するサービスをすべて一覧にします。
  2. SPFとDKIMを整えます。Googleのヘルプでは、SPFまたはDKIMの設定後、48時間以上待ってからDMARCを有効にするよう案内しています。
  3. p=none でDMARCレコードを公開し、rua のレポートを数週間以上観察します（期間は送信パターンによるため目安です）。
  4. レポートに現れる、認証に失敗している正規の送信元を1つずつ直します（SPFに追加、DKIMを設定など）。
  5. 失敗が想定外の送信元（なりすましの疑い）だけになったら、p=quarantine に変更します。
  6. quarantine でも問題が出ないことを確認してから、p=reject にします。

ruaレポートの活用

rua で届く集計レポートはXMLファイル（多くはgzip圧縮）で、どのIPアドレスから自社ドメインを名乗るメールがどれだけ届き、SPF・DKIMが成功したかをまとめたものです。標準仕様ではレポートの形式や、別ドメインの宛先へ送る際の許可確認（外部宛先の検証）が決められています。Googleのヘルプは、レポート専用のメールボックスやグループを用意し、個人のメールアドレスを宛先にしないよう勧めています。件数が多くなるためです。

XMLを手で読むのは大変なので、レポートを集計して表示してくれるサービスやツールを使う運用が一般的です。

2026年のRFC改訂について

DMARCの標準仕様は、2015年のRFC 7489から、2026年に公表されたRFC 9989（本体）などに置き換えられました（RFC 7489は obsolete）。集計レポートは別のRFC 9990として整理されています。新仕様では、存在しないサブドメイン向けの np タグや、テスト運用を示す t タグが加わる一方、旧仕様の pct（適用割合）・rf・ri タグは削除されています。受信側が旧タグをどこまで解釈するかは事業者により異なるため、本記事では pct に頼らず、ポリシーそのものを段階的に切り替える方法を前提にしています。

図3　DMARC段階導入の流れ
1送信元の洗い出し2SPF・DKIM設定3p=none で監視4失敗元を修正5p=quarantine6p=reject

Gmail・Yahoo!メールの送信者ガイドライン（2024年〜）

DMARCが一気に広まった理由は、2024年2月から適用されたGmailとYahoo!メールの送信者要件です。両社の公式ドキュメントの内容を整理します。

Gmail（Google）

Googleの「メール送信者のガイドライン」は、2024年2月1日から適用されています。

  • すべての送信者：SPFまたはDKIMによる認証、正引き・逆引きDNSの整備、TLS接続、迷惑メール報告率を0.3%未満に保つこと、RFC 5322準拠の形式など。
  • 1日5,000通以上をGmailの個人アカウントに送る一括送信者：上記に加えて、DMARC認証の設定、マーケティング・購読メールでのワンクリック登録解除（List-Unsubscribe と List-Unsubscribe-Post ヘッダー）、From ヘッダーのドメインがSPFまたはDKIMのドメインと一致していること。

Yahoo!メール（Yahoo Sender Hub）

  • すべての送信者：最低でもSPFまたはDKIMを実装し、スパム報告率を0.3%未満に保ち、正引き・逆引きDNSを整えること。
  • 一括送信者：SPFとDKIMの両方に加え、有効なDMARCポリシー（最低でも p=none）を公開し、DMARCを通過させること。From ヘッダーとのドメイン一致も必要です。ワンクリック登録解除に対応したList-Unsubscribeヘッダー（RFC 8058方式を強く推奨）と、本文内の見える登録解除リンクも求められ、登録解除の依頼は2日以内に処理するとされています。

つまり、少量のメールしか送らない小規模サイトでも「SPFまたはDKIM」は事実上必須で、大量送信する企業は「SPF・DKIM・DMARCの3点セット」が前提になっています。詳細な条件は各社の最新ドキュメントで確認してください。

日本国内の導入状況

総務省の情報通信白書（令和6年版）は、JPドメインにおける送信ドメイン認証の導入状況として、2023年12月時点でSPFが約82.9%、DMARCが約10.2%と記載しています。SPFが普及している一方、DMARCはこれからという状況でした。最新の数値は、総務省の公表資料で確認してください。

DMARC・SPFでよくある失敗と対処

失敗1：SPFのDNS参照が10回を超える

RFC 7208は、SPFの評価中にDNS照会を伴う項目を合計10個までに制限しています。数えられるのは include、a、mx、ptr、exists の各メカニズムと redirect モディファイアで、ip4・ip6・all は数えません。しかも include で取り込んだ先の中にある include も合算されます。メルマガ配信、CRM、チケット管理など、外部サービスを足すたびにincludeを追加していくと、いつの間にか10回を超えます。

10回を超えると評価結果は permerror（恒久的エラー）となり、SPFが成功しない状態になります。また、存在しない名前を引く「空の参照（void lookup）」も2回までが目安とされています。対処は次のとおりです。

  • 使っていないサービスのincludeを削除する。
  • 固定IPのサービスは ip4: / ip6: で直接書く（照会が発生しない）。
  • mx や a を安易に使わず、必要な範囲に絞る。
  • 送信元ごとにサブドメインを分け（例：news.example.com）、それぞれにSPFを持たせる。

失敗2：SPFレコードを複数作ってしまう

1つのドメインに v=spf1 で始まるTXTレコードを2つ以上置いてはいけません。RFC 7208は、認証の判定で複数のレコードが選ばれる状態を許さず、その場合は permerror になると定めています。外部サービスの案内どおりに新しいSPFレコードを「追加」してしまうのが典型的な原因です。必ず既存のレコードに include を追記して1行にまとめてください。

# NG：2行に分かれている
example.com. TXT v=spf1 include:_spf.google.com ~all
example.com. TXT v=spf1 include:mail.example.net ~all

# OK：1行にまとめる
example.com. TXT v=spf1 include:_spf.google.com include:mail.example.net ~all

失敗3：アライメントが合わない

外部のメール配信サービスは、既定では配信会社のドメインでSPF・DKIM署名をすることがあります。この場合、認証自体は成功しても From ヘッダーのドメインと一致しないためDMARCは失敗します。サービスの設定で、自社ドメインでDKIM署名する（独自ドメイン認証）設定を有効にしてください。

失敗4：いきなり reject にする

送信元の洗い出しが不完全なまま p=reject にすると、社内システムや委託先からの正規メールまで拒否されます。前章の段階導入を守ってください。

失敗5：rua宛先を見ていない

レコードだけ置いてレポートを誰も確認していない状態では、DMARCの価値の半分が失われます。別ドメインのメールボックスへ送る場合は、受け取る側のドメインで許可の設定が必要になる点にも注意が必要です。

図4　SPFレコードの書き方の違い
×　NG例×v=spf1 のTXTを2行作る×includeを10個以上並べる×不要になった外部サービスを残す○　OK例○1つのレコードにまとめる○固定IPは ip4: で直接書く○使わないincludeは削除する

サーバー情報調査でDNSレコードを確認する

サイトスカウターの「サーバー情報調査」（/server/）は、入力したドメインのDNSレコード（A・AAAA・MX・NS・TXT・SOA・CNAME）を表示します。ドメイン直下のTXTレコードには SPF が載るため、MXと合わせて、メールまわりの設定が公開されているかを手早く確認できます。

同じ画面ではあわせて、サーバー証明書、セキュリティヘッダー、DNSブラックリスト（DNSBL）への掲載状況なども調べます。送信元IPがブラックリストに載っていないかの確認は、メールが届かないときの切り分けに役立ちます。

ただし、現在のサーバー情報調査が確認するのは調査対象のホスト名そのもののDNSレコードです。_dmarc や DKIM のセレクタ（selector._domainkey）といった別ホスト名のTXTレコードは調べていません。DMARCとDKIMの公開内容は、本記事で紹介した dig / nslookup のコマンドで確認してください。

なお、このツールが行うのはDNS照会、WHOIS、TLSハンドシェイク1回、HTTP GET 1回といった非侵襲な確認だけです。ポートスキャンなどは行いません。

SPFの確認に使えるツールの使い分け

IPアドレス確認ツールズのDNSルックアップは、1つのドメインのDNSレコードを素早く引きたいときに向いています。サイトスカウターのサーバー情報調査は、DNSに加えて、HTTPS・証明書・セキュリティヘッダー・WHOIS・ブラックリスト掲載(DNSBL)などを1回で点検できます。「メール認証の設定を確かめたい」ならDNSルックアップ、「サイト全体の状態を見たい」ならサーバー情報調査、と使い分けてください。

サイトスカウターで調べる

メール認証の設定だけでなく、HTTPS・証明書・セキュリティヘッダーまで含めてサイトの状態を点検したい場合は、サーバー情報調査が便利です。

サーバー情報調査を使う
DNSルックアップの検索結果（TXTにSPFレコードが表示された例）
SPFレコードをブラウザで確認する

ドメイン名を入力するだけで、TXT(SPF)・MX・NSなどのDNSレコードを無料で確認できます。登録は不要です。

DNSルックアップを使う

よくある質問

DMARCは必須ですか？

法律上の義務ではありません。ただし、Gmailは1日5,000通以上、Yahoo!メールも一括送信者にDMARCを求めています。少量の送信でも、自社ドメインのなりすまし対策として設定が推奨されます。まずは p=none で開始するのが安全です。

SPFだけ設定すればなりすまし対策になりますか？

不十分です。SPFが主に確認するのはエンベロープ送信者のドメインで、受信者に見える From ヘッダーとは別です。DKIMで署名し、DMARCで From ドメインとの一致を要求することで、なりすましへの効果が高まります。

p=none のままでも意味はありますか？

p=none でも、レポートで自社ドメインを名乗る送信元を把握できます。Yahooは一括送信者に最低でも p=none を求めています。ただし、なりすましメールを止める効果はないため、状況を確認したうえで quarantine や reject への移行を検討してください。

SPFレコードを2つ書くとどうなりますか？

RFC 7208では permerror（恒久的エラー）となり、SPFが成功しなくなります。1ドメインにつきSPFレコードは1つにまとめ、include を追記する形で管理してください。

DMARCの設定後、どのくらいで反映されますか？

DNSのTTL（キャッシュ時間）に依存します。短ければ数分から数時間で反映されますが、受信側の集計レポートが届くのは通常、設定の翌日以降です。レポートの頻度は受信事業者によって異なります。

出典・参考資料

最終確認日：2026-10-06。制度・仕様は変更されることがあるため、実施前に各一次情報をご確認ください。

本記事は一般的な情報提供を目的としており、法的助言ではありません。被害に遭われた場合や判断に迷う場合は、消費者ホットライン（188）や警察相談専用電話（#9110）などの公的窓口にご相談ください。