「迷惑メール対策ソフトを導入しているから、メール対策はできている」

そう考えている会社は少なくありません。

しかし、迷惑メールを受け取らないための対策と、自社のドメインを悪用したなりすましメールを送らせないための対策は、同じではありません。

例えば、ライトハウスコンサルタントのドメインが「example.jp」だったとします。

攻撃者が実際にはexample.jpのメールサーバーを使っていないにもかかわらず、差出人欄へ「請求担当者@example.jp」と表示し、取引先へ偽の請求書を送る可能性があります。

このような自社ドメインのなりすましを受信側が判定するための仕組みが、SPF、DKIM、DMARCです。

ただし、この三つを設定すれば、すべてのフィッシングメールやビジネスメール詐欺を防げるわけではありません。

SPF・DKIM・DMARCが主に扱うのは、メールで使用されたドメインが正当に使われているかどうかです。正規アカウントの乗っ取り、見た目が似た別ドメイン、表示名だけを偽装する手口、メール以外の連絡手段を組み合わせた詐欺は、別の対策が必要です。

本記事では、専任の情報システム担当者がいない中小企業を想定し、SPF・DKIM・DMARCを導入する順番、設定前に調べる内容、導入後の確認方法を整理します。

2026年5月にDMARCの標準が更新された

DMARCは新しい技術ではありません。

一方、2026年5月には、DMARCの中核仕様を定めるRFC 9989が公開され、従来のRFC 7489とRFC 9091を置き換えました。DMARCの集約レポートはRFC 9990、失敗レポートはRFC 9991として、それぞれ独立した仕様に整理されています。RFC 9989は、実験的仕様ではなく、標準化過程の「Proposed Standard」として公開されています。

2026年6月29日には、日本スマートフォンセキュリティ協会も改版内容について注意喚起し、既存のDMARC設定に複数レコードや廃止されたタグが残っていないかを確認するよう呼びかけました。

会社ですでにDMARCを設定していても、何年も前に設定したままなら、現在の仕様に照らして再確認する必要があります。

SPF・DKIM・DMARCは何が違うのか

三つの仕組みは、役割が異なります。

仕組み主な役割確認するもの
SPFそのドメインのメールを送信してよいサーバーか確認する送信元サーバーとエンベロープFrom等
DKIMメールへ電子署名を付け、署名したドメインと改ざんの有無を確認するDKIM署名とDNS上の公開鍵
DMARC受信者に見えるFromドメインと、SPF・DKIMで認証したドメインの関係を確認するアラインメント、処理方針、レポート

SPFは「どのサーバーから送ってよいか」を示す

SPFでは、ドメイン所有者がDNSへ、メールを送信してよいサーバーやサービスを登録します。

受信側は、実際に接続してきた送信元とDNSのSPFレコードを照合します。

ただし、SPFが主に確認するのは、利用者がメールソフトで見る差出人欄ではなく、配送処理に使われるMAIL FROMやHELOのドメインです。このため、SPFだけが成功していても、利用者に表示されるFromドメインが正しいとは限りません。

DKIMは「署名したドメイン」を確認する

DKIMでは、送信側が秘密鍵を使ってメールへ電子署名を付けます。

受信側は、DNSで公開されている公開鍵を取得し、署名を確認します。これにより、どのドメインが署名したのか、署名対象となった本文やヘッダーが配送途中で変更されていないかを検証できます。

ただし、DKIM署名に成功したことだけで、差出人欄のドメインが正しいとは限りません。

正規のメール配信サービスが、自社とは異なるサービス事業者のドメインで署名している場合もあるためです。

DMARCは「利用者に見えるFromとの関係」を確認する

DMARCでは、メール利用者に表示されるFromドメインと、SPFまたはDKIMで認証されたドメインが、所定のアラインメント条件を満たしているかを確認します。

DMARCは、次のどちらかが成立すると合格します。

  • SPFが成功し、SPFで認証されたドメインとFromドメインがアラインメントする
  • DKIMが成功し、DKIM署名のドメインとFromドメインがアラインメントする

つまり、「SPFがpassだった」「DKIMがpassだった」という結果だけでは不十分です。

利用者に見える差出人ドメインと結び付いていることが重要です。

SPFに成功してもDMARCに失敗する例

例えば、次のメールを考えます。

項目使用されたドメイン
利用者に見えるFromaccounting@example.jp
SPFで確認されたドメインbounce.mailservice.example
DKIM署名のドメインmailservice.example

メール配信事業者のサーバーが正式にSPFへ登録されていれば、SPF自体は成功する可能性があります。

しかし、SPFで認証されたドメインはmailservice.example側であり、利用者に見えるexample.jpとはアラインメントしていません。

DKIM署名も同様にサービス事業者のドメインであれば、DMARCは失敗する可能性があります。

対策としては、メール配信サービス側で、自社ドメインまたは自社ドメインのサブドメインを使ったDKIM署名や、カスタムReturn-Pathを設定します。

実際に使用できる設定はサービスによって異なるため、各事業者の公式手順を確認してください。

DMARCに成功しても「安全なメール」とは限らない

RFC 9989は、DMARCに成功したことが、そのメールの内容まで安全であることを保証するわけではないと明記しています。

DMARCで確認できるのは、主としてドメインが正当に使用されたかどうかです。

例えば、次のメールはDMARCだけでは防げない場合があります。

  • 取引先の正規メールアカウントが乗っ取られて送信された
  • example.jpに似せたexamp1e.jpなどの別ドメインが使われた
  • 差出人名だけを「代表取締役」「取引先経理部」などに変更された
  • 正規ドメインを取得した詐欺事業者がメールを送信した
  • メール本文に記載された電話番号やQRコードへ誘導された
  • 社内アカウントから不正な自動転送が設定された

RFC 9989も、DMARCが主に対抗するのは自社と同一のドメインを使ったなりすましであり、類似ドメインや表示名の悪用を直接防ぐものではないと説明しています。

IPAが紹介した相談事例でも、攻撃者が差出人ドメインを偽装していないケースでは、SPF・DKIM・DMARCだけでは攻撃メールを排除できないことが示されています。

したがって、SPF・DKIM・DMARCは重要ですが、請求書詐欺や振込先変更詐欺を防ぐ社内確認手順と組み合わせる必要があります。

DNSを変更する前に送信元を洗い出す

DMARC導入で最も重要なのは、DNSへ文字列を登録する作業ではありません。

自社ドメインを使って、どのサービスがメールを送っているかを把握することです。

例えば、次のサービスが自社ドメインのメールを送っている可能性があります。

  • Microsoft 365やGoogle Workspace
  • ウェブサイトの問い合わせフォーム
  • WordPressの通知メール
  • メールマガジン配信サービス
  • 会計・請求書発行サービス
  • 顧客管理システム
  • 予約・受付システム
  • 採用管理サービス
  • 電子契約サービス
  • ヘルプデスクや問い合わせ管理サービス
  • 複合機やスキャナー
  • NAS、サーバー、ネットワーク機器の監視通知
  • 給与・勤怠管理システム
  • 以前の制作会社が設定したメール送信機能

このうち一つでも漏れている状態で、いきなり厳しいDMARCポリシーを設定すると、正規のメールまで隔離・拒否される可能性があります。

反対に、設定が壊れることを恐れてp=noneのまま放置すると、レポートを受け取っていても改善につながりません。

まずは、送信元台帳を作ります。

メール送信元台帳の記載例

項目記録する内容
サービス・システム名Microsoft 365、問い合わせフォーム、請求書サービスなど
管理部署総務、営業、経理、広報など
管理責任者設定変更を判断する人
運用事業者メール・ウェブ・DNSの保守事業者
利用目的通常メール、請求書、通知、メールマガジンなど
Fromアドレス利用者に表示される差出人
Fromドメインexample.jp、notice.example.jpなど
Return-PathSPFで使用される可能性があるドメイン
DKIMの署名ドメインDKIM-Signatureのd=に表示されるドメイン
SPFpass、fail、permerror、未確認
DKIMpass、fail、未設定、未確認
DMARCpass、fail、未確認
送信量1日・1か月のおおよその通数
送信先顧客、従業員、一般利用者など
契約終了日不要な送信元を残さないための確認日
最終確認日実際のメールヘッダーを確認した日

サービス名だけではなく、実際に受信したテストメールのヘッダーを確認することが重要です。

管理画面に「DKIM設定済み」と表示されていても、送信経路や差出人アドレスによっては署名されない場合があります。

手順1　DNSとメールの管理者を確認する

最初に、次の管理者を確認します。

管理対象確認する内容
ドメイン契約誰の名義で、どの事業者と契約しているか
DNS誰がレコードを変更できるか
メールサービス誰が管理者アカウントを持っているか
ウェブサイトフォームメールを誰が設定したか
外部サービスどの部署が契約し、誰が設定したか

ドメイン管理者、DNS管理者、メール管理者が別の会社になっていることもあります。

設定作業を開始する前に、現在のDNSレコードを保存し、変更日時、変更者、変更理由を記録します。

DNSレコードを誤って変更すると、メールだけでなく、ウェブサイトや他のクラウドサービスへ影響する場合があります。作業は、サービス事業者や保守事業者の公式資料を確認して行ってください。

手順2　SPFレコードを整理する

SPFレコードは、DNSのTXTレコードとして設定します。

ここで多い誤りが、利用するサービスごとに別々のSPFレコードを追加することです。

例えば、すでにSPFレコードがある状態で、新しいメール配信サービスから示されたSPFレコードを、そのまま二つ目として追加すると、複数のSPFレコードが存在する状態になります。

RFC 7208では、対象ドメインに複数のSPFレコードが存在し、複数のレコードが選択される状態を認めていません。この場合、SPFはpermerrorになる可能性があります。

SPFで確認する項目

  1. SPFレコードが一つにまとまっているか
  2. 現在使用していない送信サービスが残っていないか
  3. 現在使用しているすべての送信元が含まれているか
  4. include先のサービスが正しいか
  5. DNS参照回数が上限を超えていないか
  6. 意図せず広い範囲のサーバーを許可していないか
  7. サブドメインにも必要なSPFがあるか

SPFでは、include、a、mx、redirectなど、DNS検索を伴う仕組みの使用回数に上限があります。RFC 7208では、対象となるDNS検索は合計10回までとされ、超えた場合はpermerrorになります。

複数のメール配信サービスを利用している会社では、提供されたincludeを追加していくだけで、上限を超えることがあります。

Microsoftも、SPFレコードはドメインごとに一つとし、複数の外部サービスを利用する場合は、サブドメインを分ける方法を検討するよう案内しています。また、SPFだけでは十分ではなく、DKIMとDMARCも構成する必要があると説明しています。

SPFの文字列は、他社の設定例をそのままコピーしてはいけません。

利用しているメールサービス、サーバー、サブドメインによって内容が異なるためです。

手順3　すべての正規送信元でDKIMを有効にする

次に、各メールサービスでDKIMを有効にします。

DKIMは一般に、次の流れで設定します。

  1. メールサービス側でDKIM鍵を生成する
  2. サービスから指定された公開鍵をDNSへ登録する
  3. サービス側でDKIM署名を有効にする
  4. テストメールを送信する
  5. 受信したメールのヘッダーでdkim=passを確認する
  6. DKIM-Signatureのd=が想定したドメインか確認する

重要なのは、dkim=passだけを見るのではなく、どのドメインで署名されているかを確認することです。

例えば、Fromがexample.jpなのに、DKIM署名のd=がサービス事業者のドメインになっている場合、DMARCのアラインメントを満たさないことがあります。

また、通常の従業員メールではDKIMが有効でも、ウェブサイトのフォームや複合機から送るメールには署名されていない場合があります。

送信経路ごとに確認してください。

手順4　DMARCレポートの受信先を用意する

DMARCでは、集約レポートの送信先を指定できます。

レポート専用として、例えば次のようなアドレスを用意します。

dmarc-report@example.jp

通常の問い合わせ窓口や代表メールと共用すると、XML形式のレポートが大量に届き、重要な業務メールを見落とす可能性があります。

専用アドレスまたは専用の共有メールボックスを用意し、次の事項を決めます。

  • 誰が受信するか
  • どのサービスで解析するか
  • どの頻度で確認するか
  • 異常を誰へ報告するか
  • 解析結果をどこへ保存するか
  • 外部サービスへレポートを送る場合、契約やデータ取扱いを確認したか

DMARCの集約レポートは、2026年のRFC 9990で仕様が整理されています。

手順5　最初はp=noneで観測する

送信元の確認とSPF・DKIMの準備ができたら、最初のDMARCレコードを公開します。

以下は、ドメイン構造を説明するための例です。

ホスト名：_dmarc.example.jp
種類：TXT
値：v=DMARC1; p=none; rua=mailto:dmarc-report@example.jp

実際には、example.jpを自社のドメインへ置き換え、DNS事業者とメールサービス事業者の公式手順に従ってください。

p=noneは、受信側へ隔離や拒否を求めず、主に状況を観測するためのポリシーです。

ただし、p=noneを設定しただけで、自社ドメインを使ったなりすましが受信拒否されるわけではありません。

RFC 9989は、導入時にはSPFとDKIMを整備し、DMARCをp=noneで公開してレポートを収集し、正規メールの失敗原因を解消してから、隔離や拒否を検討する流れを示しています。

手順6　テストメールのヘッダーを確認する

社内から社内へ送るだけではなく、異なる事業者のメールアドレスへテスト送信します。

例えば、次の送信経路を確認します。

  • 従業員が通常使用するメール
  • 代表メール
  • ウェブサイトの問い合わせ自動返信
  • 請求書発行サービス
  • メールマガジン
  • 複合機
  • 監視システム
  • 採用・予約システム
  • 顧客サポートサービス

受信したメールのヘッダーでは、一般にAuthentication-Resultsなどの項目を確認します。

spf=pass
dkim=pass
dmarc=pass

ただし、passという文字だけで判断せず、SPFで確認されたドメイン、DKIMのd=、利用者に見えるFromドメインを照合してください。

また、メール転送やメーリングリストによって、SPFやDKIMの結果が変わることがあります。特定の受信先だけで失敗する場合は、途中でどのような配送処理が行われているかを確認します。

手順7　DMARCレポートを分析する

DMARCレポートには、どのIPアドレスや送信元から、自社ドメインを使用したメールが送られ、SPF・DKIM・DMARCがどのような結果になったかが集約されます。

最初の確認では、送信元を次の三つに分類します。

分類状態対応
確認済み台帳にある正規サービスSPF・DKIM・アラインメントを確認
要確認自社利用かどうか不明利用部署、契約、保守事業者へ確認
未承認自社では使用していないなりすましや設定誤りとして調査

見覚えのない送信元が表示されたからといって、直ちに攻撃と断定してはいけません。

現場が独自に契約したクラウドサービス、以前の制作会社が設定したフォーム、古い監視システムなど、会社が把握していなかった正規送信元の場合があります。

一方、すべてを「何かの正規サービスだろう」と放置してもいけません。

利用部署、契約書、管理画面、送信メールの実物を確認し、正規利用かどうかを記録します。

手順8　p=quarantineやp=rejectを検討する

正規の送信元が整理され、継続的なDMARC失敗を解消したら、より強いポリシーを検討します。

ポリシー受信側へ示す方針主な段階
p=noneDMARC失敗を理由とした特別な処理を求めない調査・導入初期
p=quarantine迷惑メール等として隔離するよう求める移行・確認段階
p=reject受信を拒否するよう求める十分な確認後

DMARCポリシーは、受信事業者への処理要求です。

受信側が必ず指定どおりに処理するとは限らず、DMARCの結果は受信側が行う総合的な判定の一要素です。

また、p=rejectをすべてのドメインに一律に設定すればよいわけではありません。

RFC 9989は、一般利用者がメーリングリストへ投稿する可能性があるドメインについて、相互運用上の問題を十分に調査せずp=rejectを公開しないよう注意を示しています。p=rejectを検討する場合は、少なくとも約1か月間p=noneで観測し、その後も同程度の期間p=quarantineで確認してから比較・判断する流れが示されています。

したがって、「最終的には必ずrejectにする」という一律の目標ではなく、ドメインの用途に応じて判断します。

従業員が通常のメールやメーリングリスト投稿に使うドメインと、システム通知専用のサブドメインでは、適切なポリシーが異なる場合があります。

2026年版DMARCで特に確認したい設定

pctへ依存していないか

従来のDMARC設定では、ポリシーを適用するメールの割合を指定するpctタグが使われることがありました。

RFC 9989ではpctが削除されています。受信事業者が新仕様に従って処理する場合、既存のpctが期待どおりに機能するとは限りません。

日本スマートフォンセキュリティ協会は、約9万ドメインを対象とした同協会の調査で、pctを含むDMARCレコードが一定数残っていたとして、設定の再確認を呼びかけています。これは同協会による調査結果であり、インターネット全体の導入率を示す統計ではありません。

DMARCレコードが複数存在しないか

_dmarc.example.jpに複数のDMARCレコードを登録してはいけません。

古い設定を残したまま新しいレコードを追加すると、複数のDMARCレコードが返され、有効なポリシーとして扱われない可能性があります。

日本スマートフォンセキュリティ協会の調査では、対象とした約9万ドメインの約0.3％で複数のDMARCレコードが返されたと報告されています。これも同協会が調査した範囲での結果です。

DNS管理画面の表示だけでなく、外部から実際にどのTXTレコードが取得されるかを確認してください。

rufを安易に設定しない

DMARCの失敗レポートでは、rufを使って送信先を指定できます。

しかし、失敗レポートには、メールに関する個人情報や機密情報が含まれる可能性があります。また、失敗レポートを送信していない受信事業者もあります。

日本スマートフォンセキュリティ協会も、通常の利用では安易にrufを使用しないよう注意を示しています。

導入初期は、集約レポートのruaを中心に確認し、rufが本当に必要な場合だけ、受信先、アクセス権限、保存期間、委託先への送信について検討します。

SPF・DKIM・DMARCと請求書詐欺対策を分けない

送信ドメイン認証は、経理部門の業務手順と組み合わせる必要があります。

例えば、取引先の正規アカウントが乗っ取られ、「来月から振込口座を変更してください」というメールが送信された場合、そのメールはSPF・DKIM・DMARCのすべてに成功する可能性があります。

そのため、次のような業務ルールを設けます。

変更内容メール以外で行う確認
振込先口座の変更事前登録済みの電話番号へ連絡する
請求書の再発行契約台帳の担当者へ確認する
支払期限の急な変更上長と経理責任者が確認する
代表者からの緊急送金社内の正式な承認経路で再確認する
取引先担当者の変更既知の連絡先または代表窓口へ確認する

メール本文に記載された電話番号へ、そのまま連絡してはいけません。

攻撃者が用意した連絡先である可能性があるためです。契約書、取引先台帳、過去に確認済みの電話番号など、メールとは別に管理していた連絡先を使用します。

SPF・DKIM・DMARCは、メールの技術的な確認です。

送金承認、取引先マスターの変更、電話による再確認は、業務上の確認です。

どちらか一方ではなく、両方を整備します。

導入後に毎月確認したい項目

DMARCは、設定した日が完成日ではありません。

新しいクラウドサービスの導入、ウェブサイトの変更、メール配信会社の変更、組織再編などによって、正規送信元は変わります。

本稿では、少なくとも月1回、次の差分を確認する運用を提案します。確認頻度は法令上の一律義務ではなく、自社の送信量や情報の重要度に応じて調整してください。

確認項目確認する意味
新たな送信元未承認サービスやなりすましがないか
消えた送信元サービス停止や設定不良がないか
SPFのpermerrorレコード重複や参照回数超過がないか
DKIM失敗鍵、署名、DNS設定に異常がないか
DMARC失敗正規送信元の設定漏れがないか
DNSの変更承認されていない変更がないか
追加・終了した外部サービス台帳と実態が一致しているか
DMARCポリシー現在の業務と合っているか
最終確認日レポートが放置されていないか
対応記録誰が何を判断したか説明できるか

すべてのメールについて、単純な合格率だけを目標にするのは適切ではありません。

転送やメーリングリストなどの影響もあるためです。

重要なのは、正規送信元ごとに、DMARCが成功しているか、失敗している場合は理由を説明できるか、未確認の送信元が残っていないかを確認することです。

見覚えのない送信元が見つかった場合

DMARCレポートに未知の送信元が表示された場合は、次の順番で確認します。

  1. 対象ドメインと送信日時を確認する
  2. メール送信元台帳と照合する
  3. ウェブ、経理、営業、採用などの各部署へ確認する
  4. 契約中のクラウドサービスを確認する
  5. 過去の制作会社や保守会社へ確認する
  6. 正規サービスであればSPF・DKIMを修正する
  7. 正規サービスでなければ、なりすましの可能性として記録する
  8. 同じ送信元が継続していないか確認する
  9. 必要に応じてDMARCポリシーの強化を検討する

DMARCレポートだけでは、メール本文の内容や、受信者が実際に被害を受けたかまでは分からない場合があります。

取引先から不審メールの連絡があった場合は、可能であれば元メールを転送してもらうのではなく、ヘッダーを含む原本形式で提供してもらい、送信経路、認証結果、本文、URL、添付ファイルを確認します。

30日で「観測できる状態」まで進める

以下は、専任担当者がいない中小企業向けの実務上の導入例です。

30日でp=rejectにする計画ではありません。30日で正規送信元を把握し、DMARCレポートを確認できる状態まで進める計画です。

期間実施すること完成させるもの
第1週DNS、メール、外部サービスの管理者を確認する管理者・事業者一覧
第1週自社ドメインを使う送信元を洗い出すメール送信元台帳の初版
第2週SPFの重複、不要設定、参照回数を確認するSPF確認記録
第2週各サービスでDKIMを有効化するDKIM設定記録
第3週テストメールを送り、認証結果を確認するテスト結果一覧
第3週p=noneとruaを設定するDMARC設定記録
第4週集約レポートを分析する正規・要確認・未承認一覧
第4週設定漏れと不要な送信元を整理する改善計画、次回確認日

その後、少なくとも約1か月以上の観測結果を確認し、正規メールへの影響を調査したうえで、p=quarantineを検討します。

p=rejectについては、さらに隔離段階の結果と、メーリングリストや転送への影響を確認して判断します。

経営者が確認したい五つの質問

経営者がDNSレコードの文字列を確認する必要はありません。

担当者や保守事業者へ、次の五つを質問してください。

  1. 自社ドメインを使ってメールを送信するサービスを一覧にできるか
  2. SPF、DKIM、DMARCの現在の状態を説明できるか
  3. DMARCレポートを最後に確認した日はいつか
  4. 見覚えのない送信元が見つかったときの確認担当者は誰か
  5. 振込先変更をメール以外で確認するルールがあるか

この五つに答えられないからといって、直ちに自社ドメインが悪用されているとは限りません。

しかし、会社としてメールの送信経路を把握できていない可能性があります。

まとめ

SPF・DKIM・DMARCは、DNSへ三つの文字列を追加すれば終わる設定ではありません。

導入の中心となるのは、次の運用です。

  1. 自社ドメインを使うすべての送信元を洗い出す
  2. SPFを一つのレコードへ正しく整理する
  3. 各送信サービスでDKIMを有効にする
  4. Fromドメインとのアラインメントを確認する
  5. 最初はp=noneでDMARCレポートを収集する
  6. 正規メールの失敗原因を修正する
  7. 業務への影響を確認してポリシー強化を判断する
  8. 請求書・振込先変更はメール以外の経路でも確認する

DMARCに成功していることは、メール内容の安全を保証するものではありません。

一方で、DMARCを設定していなければ、自社ドメインがどこから使われ、どの程度認証に失敗しているのかを把握しにくくなります。

最初の一歩は、DNSを変更することではなく、自社ドメインでメールを送っているサービスを一枚の台帳へまとめることです。

ライトハウスコンサルタントでは、専任担当者がいない中小企業を想定し、メール、ドメイン、クラウド、アカウントを含む情報セキュリティ対策を、現在の業務と管理体制に合わせて整理しています。

メールサービスとDNSの管理者が分からない、ウェブサイトや請求書サービスの送信経路を把握できない、DMARCレポートを受信しているが確認方法が分からない場合は、まず管理者と正規送信元を特定するところから始めてください。

投稿タグ
, , , , , , , , ,