公開2026.06.04更新2026.10.09 11 人が閲覧（直近 30 日）セキュリティ

フィッシング対策ガイドライン2026年度版のDMARC要件｜p=reject推奨の中身とnoneからの移行手順

フィッシング対策協議会は2026年6月1日、事業者向けの「フィッシング対策ガイドライン 2026年度版」を公開しました。送信ドメイン認証の記述で目立つのは、重要項目1に「DMARCポリシーの設定において、『p=reject』（排除）を設定することを推奨する」という一文が加わり、要件1に「ポリシーが『p=none』では意味をなさない」と書かれた点です。この記事では、2025年度版の本文と突き合わせて変わった箇所を特定し、改定の背景にある総務省の要請と日本証券業協会のガイドライン、p=noneからp=rejectへ移す手順、rejectにしても防げないフィッシングまでを、一次資料の記述に沿って整理します。DMARCの仕組みやレコードの基本はDMARCの仕組みとレコードの書き方の解説を参照してください。

まとめ｜2026年度版がDMARCに求めることと移行の要点

2026年度版は重要項目1に「p=reject」の推奨を明記しました。2025年度版の重要項目1は送信ドメイン認証の利用を求めるだけで、ポリシーの値までは書いていませんでした。
要件1（考慮を必須とする◎項目）には「p=noneでは意味をなさない」「直ちにp=rejectが難しければまずp=quarantine、最終的にp=rejectを目指す」と移行の順番が入りました。
必須なのは送信ドメイン認証への対応で、rejectは「推奨」「望ましい」の扱いです。チェックリスト（付録H）の必須項目もDMARC等の導入までで、ガイドラインは対応期限を定めていません。
メールを送らないドメインや保有しているだけのパークドメインはrejectにする、という記述は2025年度版から続いています。
改定の背景には、総務省が2025年9月1日に電気通信事業者へ出した要請（受信側のDMARC処理も対象）と、2025年10月15日施行の日本証券業協会ガイドライン（rejectを「スタンダード」とする）があります。
rejectで止められるのは自社ドメインを詐称するメールです。フィッシングレポート2026によると、2025年12月には独自ドメインでDMARC認証を通過させる手口が報告の約75.3%を占めました。ドメイン名の周知やBIMIと組み合わせる必要があります。
移行は、送信元の棚卸し、p=noneでの集約レポート収集、SPF・DKIMのアライメント修正、quarantine、rejectの順に進めます。

2026年度版でDMARCの記述が変わった箇所（2025年度版との比較）

2026年度版の序文は、2025年度に項目構成を整理したことを受け、その枠組みを基礎に各項目の内容を精査・更新したと説明しています。重要5項目と要件10項目という骨格は2025年度版と同じで、変わったのは各項目の説明文です。送信ドメイン認証と認証方式に関わる箇所を、2025年度版PDFと2026年度版HTMLの本文で比べると次のとおりです。

箇所	2025年度版	2026年度版
重要項目1	送信ドメイン認証で詐称を防ぐ	p=rejectの設定を推奨と追記
要件1（◎）	rejectに設定することが望ましい	p=noneでは意味をなさない、まずquarantineを追記
重要項目3・要件4（◎）	多要素認証を要求	フィッシング耐性を有する多要素認証を要求
重要項目4（パークドメイン）	rejectポリシーにする	変更なし
マニュアル4.1.1（段階移行）	none、quarantine、rejectの順	変更なし

none、quarantine、rejectと段階的に進める考え方そのものは、2025年度版でも第4章のマニュアル（4.1.1 送信ドメイン認証への対応）に書かれていました。2026年度版は、読者が最初に確認する第2章の重要項目と第3章の要件にp=rejectとp=noneの評価を引き上げた、と読むのが正確です。

DMARC要件の必須・推奨区分とrejectの位置付け

ガイドラインは要件ごとに「◎（考慮を必須とする項目）」と「〇（考慮を推奨する項目）」を区別しています。要件1の見出しは「外部送信用メールサーバーを送信ドメイン認証に対応させること」で、これが◎です。rejectについては本文で「設定することが望ましい」「推奨する」と書かれており、付録Hのチェックリストも重要項目1の必須を「メール送信に使うドメイン名についてDMARC等の送信ドメイン認証技術を導入している」とし、VMC等のブランドアイコンとS/MIMEを推奨に置いています。

民間の自主ガイドラインなので罰則も対応期限もありません。ただし、チェックリスト上の導入確認と、なりすましメールを隔離・拒否する実効性は分けて考える必要があり、本文はp=noneについて、なりすましメールが受信者へ素通しで届き続け、フィッシングで狙われ続ける要因になると書いています。監査や取引先のチェックでガイドラインを根拠にするなら、DMARCの有無ではなくポリシーの値まで確認する前提で準備しておくべきです。

用語集はRFC 7489のまま｜2026年5月のRFC 9989との差

2026年度版の用語集は、DMARCを「RFC7489で標準化されている」と説明しています。DMARCの仕様はその後、2026年5月発行のRFC 9989に置き換わっており、段階適用に使われてきたpctタグは廃止され、試験運用を示すtタグ（t=y）が追加されました。レコードを設計するときは、ガイドラインの用語集ではなくRFC 9989の定義を基準にします。pctとt=yの扱いや、受信側の処理に関する新しい規定は、DMARCのquarantineとrejectの違いを解説した記事で詳しく比較しています。

改定の背景にある総務省要請と業界ガイドライン

2026年度版の序文は、2025年度の情勢として、フィッシング報告件数が月によって20万件を超えたこと、証券口座の乗っ取りによる高額被害、生成AIによる文面の巧妙化を挙げ、制度面の動きとして総務省の要請と日本証券業協会のガイドライン改定に触れています。

総務省の要請（2025年9月1日）｜受信側のDMARC処理まで対象

総務省は2025年9月1日、電気通信事業者協会、テレコムサービス協会、日本インターネットプロバイダー協会、日本ケーブルテレビ連盟の4団体を通じて、電気通信事業者に「フィッシングメール対策の強化について（要請）」を出しました。要請は3点で、2点目が「なりすましメール対策として有効なDMARCの導入やDMARCポリシーの設定（隔離、拒否）を行うこと。送信側だけでなく受信側についても、適切なDMARCポリシーに基づく処理やレポート送信を設定すること」です。ドメインレピュテーション、BIMI、踏み台送信対策の検討も求め、2025年9月から2026年8月末までの取組状況を3か月ごとに報告するよう依頼しています。行政手続法上の行政指導で、処分ではないと明記されています。

事業会社にとって意味が大きいのは受信側への要請です。国内のプロバイダーがDMARCポリシーに従って隔離・拒否するようになるほど、送信側がp=noneのままにしている差がそのまま結果に出ます。p=noneのドメインを詐称したメールは、受信側が要請どおりに処理してもポリシー上は止める指示がないためです。

日本証券業協会のガイドライン（2025年10月15日施行）｜rejectがスタンダード

日本証券業協会は「インターネット取引における不正アクセス等防止に向けたガイドライン」を改正し、フィッシング詐欺等の被害を未然に防ぐ措置として、顧客へ送信する電子メールのドメインを特定してDMARC等を計画的に導入し、DMARCレポート等を確認したうえでポリシーを「reject」にすることを【スタンダード】に定めました。同じ節では、メールやSMSにパスワード入力を促すページのURLやログインリンクを記載しないこともスタンダードとし、BIMIとS/MIMEによる電子署名は【ベストプラクティス】に置いています。証券会社の設定状況は、日経225企業との比較とあわせてDMARCの設定率を扱った記事でまとめています。

大手メールサービスの送信者要件

国内の制度とは別に、海外の大手メールサービスも送信者にDMARCを求めています。Gmailは2024年2月から、個人のGmailアカウントへ1日5,000通以上送る送信者にDMARCの設定を必須にしました。MicrosoftもOutlook.com（hotmail.com・live.com・outlook.com）宛てに1日5,000通を超えて送るドメインへSPF・DKIM・DMARCを求め、2025年5月5日に施行しています。Gmailの要件はp=noneでも満たせますが、p=noneのままでは受信側にDMARCによる隔離・拒否を求めていないことになります。2026年度版がp=noneを「意味をなさない」と書いたのは、この段階からの引き上げを促す記述と読めます。

p=rejectで防げるなりすましと防げないフィッシング

DMARCが守るのは、差出人（ヘッダーFrom）に自社ドメインを使ったメールです。rejectにしても、似た綴りのドメイン、無関係な独自ドメイン、表示名だけを偽ったメール、正規のアカウントを乗っ取って送るメールは止まりません。攻撃側はこの境界に合わせて手口を変えています。

フィッシングレポート2026（JPCERTコーディネーションセンター執筆の節）によると、2025年2月にはなりすまし送信メールが報告全体の約69.0%に急増し、DMARCポリシーがnoneか未設定のドメインが選ばれて悪用されていました。10月以降はその割合が約27.0%まで下がり、代わりに独自ドメインを使ってDMARC認証を通過させる手口が増え、12月には全体の約75.3%に達しています。レポートは、9月の総務省要請を受けて攻撃者がDMARC失敗による検知を避ける動きを強めた可能性を指摘しています。

つまりrejectは、自社ドメインを詐称の道具にさせないための前提条件で、フィッシング対策の完了ではありません。ガイドラインがrejectと並べて求めているのは、ドメイン名を自社のブランドとして管理し利用者に周知すること（重要項目4）、Webサイトとメールの送信者アドレスに同一のドメイン名を使うこと（要件6の推奨）、BIMIや認証マーク証明書（VMC）で正規メールの見た目を区別できるようにすることです。BIMIでは、Fromドメインと組織ドメインにquarantineまたはrejectを適用する必要があります。ロゴ表示には受信サービスごとの条件もあるため、rejectへの移行とあわせて対応範囲を確認します。表示側の対応状況はBIMIの設定手順と対応メールサービスの解説を参照してください。

p=noneからp=rejectへ移行する手順

ガイドラインのマニュアル4.1.1は、受信に影響のないnoneで現状を把握し、正規メールが認証されて届いていることを確かめてから、quarantine、rejectと受信制御を強める順番を示しています。以下は、その順番を作業に落としたものです。

手順1｜送信元の棚卸しとp=noneでの集約レポート収集

最初に、自社ドメインを差出人にしてメールを送っている仕組みをすべて書き出します。社内のメールサーバーやMicrosoft 365・Google Workspaceに加え、メール配信サービス、MAツール、基幹システムやECの通知、問い合わせフォームの自動返信、委託先が代行している送信が漏れやすい箇所です。そのうえで、ruaタグに集約レポートの送付先を指定したp=noneのレコードを公開します。

_dmarc.example.co.jp.  IN TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

集約レポートは受信側から1日単位などでXMLで届き、送信元IPごとにSPF・DKIMの結果とアライメントの成否が記録されます。棚卸し表にない送信元がレポートに現れたら、正規の業務か詐称かを切り分けます。ガイドラインの4.2.7も、DMARC集約レポートの収集・分析で自社ドメインがなりすましに使われているか、その送信元と規模を把握できると書いています。レポートを社外の解析サービスへ送る場合は、送付先ドメイン側に受け取りを許可するレコードが必要になるので、サービスの案内に従って設定します。

手順2｜SPF・DKIMのアライメント修正

DMARCに合格するには、SPF認証とSPFアライメント、またはDKIM認証とDKIMアライメントのどちらかを満たす必要があります。ガイドラインの説明では、SPFアライメントはFromヘッダーとReturn-Pathのドメインの一致、DKIMアライメントはFromヘッダーと署名の「d=」のドメインの一致です。一致の判定は既定が緩和モード（relaxed＝組織ドメインが同じなら一致）で、aspf=s・adkim=sを指定すると完全一致を求める厳格モード（strict）になります。

p=noneの段階でつまずくのは、SPFもDKIMも「認証には成功しているのにアライメントで落ちる」ケースです。配信サービスの初期設定では、Return-PathもDKIMの署名ドメインもサービス側のドメインになっていることが多く、Fromの自社ドメインと一致しません。サービスの管理画面で独自ドメインのDKIM署名（多くはCNAMEで公開鍵を委任する方式）を有効にし、可能ならReturn-Pathも自社のサブドメインに変えます。

SPFは、評価中にDNS問い合わせを伴う仕組み（include・a・mx・ptr・exists・redirect）の合計を10回までに制限しており（RFC 7208 4.6.4節）、超えるとpermerrorになります。配信サービスを追加するたびにincludeを足していくと上限に届きやすいので、使わなくなったサービスのincludeは削除します。DKIMでRSA鍵を使う場合、RFC 8301は1024bit以上を必須、2048bit以上を推奨としているため、新しく発行する鍵は2048bitにします。

手順3｜quarantineからrejectへの移行判断

棚卸しした正規の送信元がすべて、集約レポート上でDMARCに合格している状態になったらquarantineへ上げます。ガイドラインは移行の判断に使う合格率などの数値基準を示していないので、基準は「棚卸し表の全送信元がDMARCに合格し、未知の送信元が詐称と判断できるものだけになっている」ことに置くのが現実的です。quarantineで通常配信と定期配信の周期を含めて観測し、集約レポート、送信ログ、主要な宛先へのテスト送信で正規メールへの影響を確認してからrejectにします。既存のDMARCレコードのp値を変更し、次の2段階のレコードを同時には公開しません。

; 段階2：隔離
_dmarc.example.co.jp.  IN TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

; 段階3：拒否
_dmarc.example.co.jp.  IN TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]"

移行にかける期間について、フィッシング対策ガイドラインは目安を示していません。参考になるのは政府機関向けの「政府機関等の対策基準策定のためのガイドライン（令和7年度版）」で、2025年9月5日一部改定版の基本対策事項6.2.2(1)-3の解説は、p=noneでは受信側に特別な処理を求めないため、DMARCの導入から一年以内に実施するなどp=noneの期間をできるだけ短くし、quarantineかrejectを設定するのが望ましいとしています。

従来の解説で定番だったpct=10のような段階適用は、RFC 9989で廃止されました。試験運用を示すt=yを解釈しない受信側ではpの値がそのまま効くので、試験タグに頼らず、quarantineで様子を見る期間を確保するほうが安全です。

メールを送らないドメインとサブドメインの塞ぎ方

ガイドラインは、メールを送らないドメイン名（Webサービスでのみ使うものなど）や保有しているだけのパークドメイン名をrejectにするよう求めています。送信しないことを確認できたドメインには、最初から次のSPF・DMARCレコードを設定できます。3行目のNull MXは、メールの受信もしない場合に限って設定し、既存のMXレコードとは併用しません。

example-campaign.jp.         IN TXT  "v=spf1 -all"
_dmarc.example-campaign.jp.  IN TXT  "v=DMARC1; p=reject"
example-campaign.jp.         IN MX   0 .

3行目は「このドメインはメールを受け付けない」と示すNull MX（RFC 7505）です。運用中のドメインでは、サブドメインの扱いも確認します。pタグの値は独自のDMARCレコードを持たないサブドメインにも及び、spタグ（存在するサブドメイン）とnpタグ（DNSに存在しないサブドメイン）で上書きできます。組織ドメインをrejectにしてもsp=noneを残すと、サブドメインを使った詐称は止まりません。

reject後に正規メールが届かなくなる経路と予防策

rejectへ上げた後に問題になりやすいのは、自社の送信ではなく途中の経路です。

転送：受信者が別のアドレスへ自動転送すると、転送サーバーのIPアドレスは自社のSPFに含まれないためSPFが失敗します。本文や件名を書き換えない転送ならDKIM署名は残るので、DKIMのアライメントを確実に満たしておくことが対策になります。
メーリングリスト：件名へのタグ付けや本文末尾への署名追加でDKIM署名が壊れます。RFC 9989の7.4節は、受信側に対してp=rejectだけを根拠に拒否せず、ほかの判断材料がなければquarantineとして扱うよう求め、メーリングリストに投稿する利用者を抱えるドメインはp=rejectを公開すべきでないとしています。社員が外部のメーリングリストに投稿する業務用ドメインは、quarantineで止めるか、投稿用のドメインを分ける判断があり得ます。
新しく契約したSaaS：別の部署が導入した配信サービスや業務SaaSが自社ドメインを差出人にして送る場合、DKIM・SPFのどちらでも認証とアライメントを満たせなければDMARCに失敗し、rejectポリシーに従う受信側で拒否されるおそれがあります。契約前に独自ドメインでのDKIM署名に対応しているかを確認する手順を、情報システム部門の承認フローに組み込んでおきます。

中継サーバーが受け取った時点の認証結果を署名付きで引き継ぐARC（RFC 8617）もあります。RFC 9989は、Fromを書き換えずにメーリングリストを機能させる方法の代表例としてARCを挙げる一方、そうした方法はまだ広く使われていないとしています。送信側ではDKIMのアライメント確保と集約レポートの継続監視に加え、メーリングリストの利用状況に応じて投稿用ドメインの分離やポリシーの見直しを行います。

ガイドラインに基づくDNS設定と対応状況の確認

まず、ヘッダーFromに使っているドメインと、取得したまま使っていないドメインの一覧を作り、それぞれのレコードを確認します。macOSやLinuxではdigで引けます（example.co.jpは自社ドメインに置き換えてください）。

dig +short TXT _dmarc.example.co.jp
dig +short TXT example.co.jp
dig +short TXT selector1._domainkey.example.co.jp

1行目でDMARCのポリシー、2行目でSPF（v=spf1で始まる行）、3行目でDKIMの公開鍵を確認します。3行目のselector1には受信メールのDKIM-Signatureヘッダーのs=値を、example.co.jpには同じ署名のd=値を指定します。問い合わせ先は「s=値._domainkey.d=値」で、d=値は差出人のドメインと異なる場合があります。そのうえで、付録Hのチェックリストのうちメールとドメインに関わる項目を次のように照合します。

チェック項目（付録H）	区分	確認する値
DMARC等の送信ドメイン認証を導入	必須	全送信ドメインの_dmarc
VMC等のブランドアイコンを導入	推奨	BIMIレコードとVMC
S/MIMEを導入	推奨	通知メールの電子署名
SPF・DKIM・DMARCに対応（要件1）	必須	3レコードとアライメント
割り当てドメイン名を把握	必須	ドメイン一覧の有無
ライフサイクル管理・ドロップキャッチ対策	必須	更新期限と廃止手順

代表ドメインの確認だけで完了とせず、キャンペーン用や子会社のドメインについても個別にポリシーを確認します。TwoFiveの2026年5月の調査では、日経225企業の69.8%が少なくとも1つのドメインでquarantineかrejectを設定していた一方、ドメイン単位の実質保護率は18.5%でした。調査の詳細は前述のDMARC設定率の記事にまとめています。政府機関や独立行政法人は、前述の1年以内という目安を含む政府統一基準の要件もあわせて確認が必要で、政府統一基準の令和7年度版と2026年6月改定の要件を実装に落とした記事で扱っています。

よくある質問

フィッシング対策ガイドライン2026年度版はいつ公開されましたか？

2026年6月1日です。事業者向けの「フィッシング対策ガイドライン 2026年度版」と利用者向けの「利用者向けフィッシング詐欺対策ガイドライン 2026年度版」が同じ日に公開され、フィッシング対策協議会のサイトでHTML版とPDF版を読めます。

ガイドラインはDMARCのp=rejectを義務付けていますか？

義務ではありません。必須（◎）とされているのは送信ドメイン認証への対応で、p=rejectは推奨です。ただし本文はp=noneを「意味をなさない」と評価し、まずquarantine、最終的にrejectを目指すよう書いています。証券会社の場合は、日本証券業協会のガイドラインがrejectをスタンダードとしています。

DMARCのアライメントとは何ですか？

SPFやDKIMで認証されたドメインと、受信者に表示される差出人（ヘッダーFrom）のドメインが一致しているかの判定です。SPFはReturn-Pathのドメイン、DKIMは署名のd=のドメインと比べます。既定は組織ドメインが同じなら一致とみなす緩和モードで、aspf=s・adkim=sで完全一致を求める厳格モードになります。