SPF・DMARCの確認方法：レコードの調べ方・読み方・直し方

SPF・DKIM・DMARCはそれぞれ何を確認するのか

SPFとDKIMは、どちらも読み手の目に触れないドメインで成功することがあります。DMARCはこの隙間をアライメント（整合）で埋めます。Fromのドメインと整合するドメインでSPFかDKIMが成功すればメッセージはpassになり、整合した成功が一つあれば足ります。既定の緩やかなアライメント（relaxed）では組織ドメインが同じであればよく、bounce.example.comはexample.comと整合します。厳格なアライメント（strict）では完全一致が必要です。

架空のメール配信サービスで考えてみます。このサービスはnews@example.comとしてメールを送りますが、エンベロープ送信者には自社のexample.netのバウンス用ドメインを使います。SPFはexample.netで成功しても整合しないため、DMARCでpassになるのは、サービスがd=example.comでDKIM署名している場合だけです。

digやnslookupでSPF・DMARCレコードを確認する方法

必要なのはdig（Linux、macOS）かnslookup（Windows）だけです。

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short MX example.com
nslookup -type=TXT _dmarc.example.com

SPFレコードは、v=spf1で始まるTXTレコードです。ほかのサービスの所有確認用トークンが同じ名前に並んでいることもよくあります。DMARCレコードは、_dmarcにあるv=DMARC1で始まるTXTレコードです。SPFはエンベロープ送信者のドメインで確認します。これはFromのドメインと異なる場合があり、届いたメールのReturn-Pathヘッダーで分かります。

DKIMの公開鍵は外から一覧できません。鍵がセレクターごとの名前に置かれているためです。自分が送ったメールのDKIM-Signatureヘッダーでs=とd=の値を読み、その名前を問い合わせます。たとえばdig +short TXT s1._domainkey.example.comです。

レコードを変更した直後は、TTLが切れるまでリゾルバーが古い応答を返すことがあります。いま公開されている内容を見るには、dig +short NS example.comで権威DNSサーバーを調べ、そこへ直接問い合わせます（dig +short TXT example.com @ns1.example.net）。最後に、自分で管理しているメールボックスへ実際にメールを送り、Authentication-Resultsヘッダーを読みます。Gmailなら「メッセージのソースを表示」で確認できます。受信側がSPF、DKIM、DMARCをどう判定したかが書かれており、最終的に意味を持つのはこの結果です。

SPFレコードの読み方

v=spf1 ip4:192.0.2.10 include:_spf.mail.example.net -all

メカニズムは左から順に評価され、最初に一致したものが結果を決めます。それぞれに修飾子を付けられます。+はpass（省略時の既定）、-はfail、~はsoftfail、?はneutralです。

~allと-allのどちらにするか

~allは、記載のないサーバーは「おそらく許可されていない」という意味で、受信側はそれだけを理由に拒否すべきではないとされています。-allは「許可されていない」という意味で、その後どう扱うかは受信側のポリシー次第です。どちらも妥当な選択で、ドイツの連邦情報セキュリティ庁（BSI）もどちらでもよいとしています。RFC 9989は一つ注意を加えています。-allの場合、SMTPセッションの早い段階でSPFを確認する受信側は、整合したDKIMがあればpassになったはずのメッセージ（典型的には転送されたメール）を拒否することがあり、その拒否はDMARCレポートに現れません。?allや、allの記載がないレコードは、記載のないサーバーについて何も表明していません。+allはインターネット上のあらゆるIPアドレスをpassにするので、決して公開しないでください。

DNSルックアップは10回まで

受信側が評価する、DNS問い合わせを伴う項目は、includeで参照したレコードの中のものも含めて最大10個です（4.6.4節）。超えると結果はpermerrorになり、SPFはDMARCのpassに役立たなくなります。応答が返らない参照（void lookup）にも別の上限があり、2回を超えた場合もpermerrorにすべきとされています。見た目には4項目しかないレコードでも、参照先のレコードがさらにincludeを含んでいれば上限を超えることがあるので、再帰的に数えてください。上限内に戻すには、使っていないサービスを外し、自社で管理するアドレスはip4/ip6で書き、大量に送信するサービスには専用のバウンス用サブドメインとそのSPFレコードを用意します。プロバイダーのIPアドレス範囲を自分のレコードに書き写す「フラット化」は、プロバイダーが範囲を変えると古くなります。

1つの名前にレコードは1つ

同じ名前にv=spf1で始まるTXTレコードが2つあるとpermerrorになるので、1つにまとめます。255文字を超えるレコードは、1つのTXTレコードの中で複数の引用符付き文字列に分けて書きます。受信側はそれらを空白なしで連結します。SPFは継承もされません。example.comのレコードはmail.example.comには適用されないので、エンベロープ送信者として使う名前ごとにレコードが必要です。

DMARCレコードの読み方

DMARCの仕様は現在RFC 9989（2026年5月）です。RFC 7489に代わる、標準化過程（Standards Track）の仕様です。レコードは引き続き_dmarcに置き、v=DMARC1で始めます。

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

example.comのレコードは、自身のレコードを持たないサブドメインにも適用されます。受信側はRFC 9989が「DNS Tree Walk」と呼ぶ方法でこれを見つけます。集計レポートを送る受信側は、通常1日ごとにXMLファイルで届け、そのドメインを名乗って送信したIPアドレスと、その認証結果を一覧にします。ruaの宛先がレポート分析サービスなど別の組織ドメインにある場合は、そのドメインがexample.com._report._dmarc.reports.example.netのような、v=DMARC1で始まるTXTレコードを公開している必要があります（RFC 9990の4節）。ない場合、受信側はその宛先を無視します。

noneからrejectへ

1. そのドメインで送信しているサービスをすべて洗い出します。メールサービス、メルマガ配信、CRM、請求、サポートデスク、Webサイトの問い合わせフォームなどです。
2. rua付きでp=noneを公開し、レポートを読みます。
3. 正規の送信元が、アライメント付きでpassになるまで一つずつ直します。優先するのはDKIMです。転送されてもたいてい残るのに対し、SPFは転送で失敗します。
4. quarantineに移行し（先にt=y付きで試してもかまいません）、その後rejectを検討します。

国内では、フィッシング対策協議会の解説資料も迷惑メール対策推進協議会のDMARC導入ガイドラインを引き、p=noneから始めてレポートで認証結果を確かめながら、quarantine、rejectと強度を上げていく進め方を紹介しています。RFC 9989は、利用者がメーリングリストに投稿するドメインはrejectを公開すべきでない（SHOULD NOT）としています。それでもrejectにしたい場合は、少なくとも1か月はnone、同じくらいの期間quarantineで運用し、結果を比べてからにするよう求めています。rejectを公開するドメインは、メールにDKIM署名をしなければなりません（MUST）。BSIのTR-03182はより厳しい立場で、送信ドメインはrejectを要求すべき（SHOULD）としています。請求書や通知だけに使うドメインと、社員がメーリングリストで使うドメインとでは事情が違います。RFC 9989は受信側にp=rejectだけを理由に拒否しないよう求めていますが、実際にはFrom行を変えずに配送されるメーリングリストのメールがしばしば拒否されていることも認めています。

メールを送らないドメインの設定

使っていないドメイン、タイプミス対策で取得したドメイン、Webのリダイレクトにしか使わないドメインも、偽装されたFrom行に使われることがあります。RFC 7208は、メールを送らないドメインにSPFレコードを公開することを確立したベストプラクティスとしています。架空の未使用ドメインに設定する一式は次のとおりです。

example.net.         TXT  "v=spf1 -all"
_dmarc.example.net.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
example.net.         MX   0 .

SPFレコードは誰も許可せず、正規のメールがないのでp=rejectにしても失うものはありません。RFC 7505のnull MXは、このドメインがメールを受け取らないことを示します。そのためレポートはexample.comで受け取り、example.com側でexample.net._report._dmarc.example.comを公開します。BSIのTR-03182も、未使用ドメインにはこの組み合わせを必須（MUST）としています。DMARCのポリシーはサブドメインにも及びますがSPFは及ばないので、独自のAレコードやMXレコードを持つサブドメインにもv=spf1 -allを設定してください。

Gmail・Yahoo・Outlook.comが送信者に求める要件

Gmailは2025年11月から、拒否を含めて適用を段階的に強めています。Googleのルールが対象とするのは個人のGmailアカウントで、Google Workspaceの受信者は含みません。GoogleとYahooは1024ビット以上のDKIM鍵を求めています。Microsoftは要件を満たさないメールを550 5.7.515で拒否します。3社ともp=noneを認めていますが、これは要件を満たすだけで、なりすましメールをどう扱ってほしいかは何も表明していません。完成形ではなく、途中の段階として扱ってください。なお、表のYahooは米Yahoo（Yahoo Mail）の送信者向けページの内容です。日本のYahoo!メールは別の事業者が運営しているサービスなので、送信要件はそちらの案内で確認してください。

国内の導入状況と行政の要請

総務省の令和7年版 情報通信白書によると、JPドメインでの導入率は2024年9月時点でSPFが約88.4%、DMARCが約32.6%です。フィッシング対策協議会の解説資料によれば、同協議会が観測しているメールアドレスに届いたフィッシングメールのうち、平均74.9%が正規サービスのドメイン名を送信元に使った「なりすまし」でした。同じ資料によれば、2023年2月には経済産業省・総務省・警察庁が連名で、クレジットカード会社などにDMARCの導入をはじめとするフィッシング対策の強化を要請しています。2025年9月1日には総務省が事業者団体を通じて電気通信事業者にフィッシングメール対策の強化を文書で要請し、その際、政府の「国民を詐欺から守るための総合対策2.0」が送信ドメイン認証技術（DMARC等）への更なる対応促進を掲げていることに触れています。

MTA-STSとCAA：あわせて確認したい2つのレコード

MTA-STS（RFC 8461）は受信するメールを守る仕組みです。信頼できる証明書でTLSを提供していないMXホストには配送しないよう、送信側に伝えます。_mta-sts.example.comにv=STSv1; id=20261001000000Z;のようなTXTレコードを置き、https://mta-sts.example.com/.well-known/mta-sts.txtにモード、MXの名前、max_ageを書いたポリシーファイルを公開します。最初はtestingモードで始めます。このモードでは送信側は配送を続け、_smtp._tls.example.comでTLSレポートを設定していれば失敗を報告してくれます。その後enforceに切り替えます。ポリシーを変えたら、そのたびにidも変えてください。

CAA（RFC 8659）は、そのドメインのTLS証明書を発行してよい認証局を指定します。たとえばCAA 0 issue "ca.example.net"です。公的に信頼された認証局は、発行前にこれを確認しなければなりません。ただし、許可された認証局による誤発行は防げず、ブラウザもCAAを使いません。example.comのレコードは、自身のレコードを持たないサブドメインにも適用されます。CDNが使う認証局も含めて利用中の認証局をすべて記載しないと、証明書の更新に失敗することがあります。証明書についてはTLSとセキュリティヘッダーの解説で詳しく扱っています。

SPF・DMARCのよくある設定ミスと直し方

無料の公開準備スナップショットがメールのDNSで確認すること

Sitelemetryの無料の公開準備スナップショットは、登録なしで1つの公開オリジンに8項目のパッシブなチェックを行います。ペネトレーションテストではなく、6領域の監査でもありません。8項目のうち一つがメール関連のDNSレコードの確認です。

• 入力したホスト名そのものを調べます。MX、TXT、_dmarc、_mta-sts、CAAを入力したホスト名で問い合わせ、親ドメインにはさかのぼりません。www.example.comにレコードがなくても、example.comが無防備だということにはなりません。メールに使っているドメインのレコードを読ませたいときは、そのドメイン自体（www.example.comではなくexample.com）を入力してください。スコアを出すには、そのドメインがアドレスに名前解決できる必要があります。
• SPF。レコードがないことは、そのホストにMXレコードがある場合に限って指摘されます（重要度「中」）。+allは「高」、?allは「低」で、~allと-allでは何も指摘されません。DNS問い合わせを伴う項目が10個を超えると指摘されますが（「中」）、include:の中はたどらないため、数えるのは最上位のレコードの項目だけです。
• DMARC。レコードがないことは、MXレコードがある場合に限って指摘されます（「中」）。p=noneは監視モードとして「低」で示され、quarantineかrejectなら合格です。sp、pct、rua、アライメントは評価しません。
• MTA-STSとCAA。_mta-stsのTXTレコードがないことは、MXレコードがある場合に限って「低」として示されます。ポリシーファイルは取得しません。CAAはレコードがあれば合格、なければ「低」のシグナルで、内容と実際の証明書の照合はしません。
• 確認しないもの：DKIM、TLSレポート、DNSSEC。

結果は、スコアとグレード、堅牢化グレード、リスクシグナルと合格チェックの数、重要度の高い順に最大3件のシグナルです。そのため、メールに関する指摘がWebの指摘に押し出されて表示されないこともあります。アドレスに名前解決できない名前にはスコアが出ません。8項目すべての確認方法はWebサイト公開前チェックリストで、継続的な見直しはDNSとメールの安全性の解説で扱っています。