DMARCポリシーとは?noneからrejectに強化が必要な理由を紹介

DMARCを設定していても、ポリシーが「p=none」のままでは、なりすましメールを完全に防ぐことはできません。DMARCポリシーは、認証に失敗したメールを受信側でどう扱うかを示す重要な設定であり、noneからquarantine、rejectへ段階的に強化することで、自社ドメインの悪用防止やメール到達率の維持につながります。本記事では、DMARCポリシーの基本から、rejectへ移行する理由、具体的な設定手順、運用時のポイントまでわかりやすく解説します。

目次[非表示]

  1. 1.DMARCポリシーとは何か
    1. 1.1.3つのレベル
    2. 1.2.DMARCポリシーの設定コード
    3. 1.3.DMARCポリシーの影響範囲を分けたい場合
    4. 1.4.spタグを使用する
    5. 1.5.サブドメインごとにDMARCレコードを設定する
  2. 2.DMARCポリシーをnoneからrejectに変更する理由
    1. 2.1.なりすましメールを防止できないため
    2. 2.2.ブランド信頼や顧客体験を守るため
    3. 2.3.ドメインのレピュテーション低下を防ぐため
    4. 2.4.セキュリティ対策としての評価を高めるため
  3. 3.DMARCポリシーnoneからquarantine・rejectへ強化する手順
    1. 3.1.DMARCレポートの収集を始める
    2. 3.2.送信環境を棚卸しする
    3. 3.3.SPF・DKIMの設定を整備する
    4. 3.4.quarantineへ段階的に移行する
    5. 3.5.rejectへ移行する前に最終確認をおこなう
  4. 4.DMARCポリシーを運用する時のポイント
    1. 4.1.DMARCレポートを定期的に確認する
  5. 5.DMARCポリシーのレポートオプションとは
  6. 6.DMARCポリシーのエラーメッセージ
  7. 7.メールシステムの導入を検討中なら「アララ メッセージ」へ
  8. 8.まとめ

DMARCポリシーとは何か

DMARCポリシーとは、DMARC認証に失敗したメールを受信側でどのように扱うかを指定する設定です。DMARCレコード内の「p=」で指定し、監視のみ・隔離・拒否の3段階で運用します。

3つのレベル

DMARCポリシーには、「none(監視のみ)」「quarantine(隔離)」「reject(拒否)」の3つのレベルがあります。導入初期は「none」で送信状況を把握し、問題がなければ「quarantine」「reject」へ段階的に強化するのが一般的です。

図(DMARCポリシーの3段階)

none

監視のみ

quarantine

迷惑メールフォルダへ隔離

reject

受信拒否


DMARC認証失敗時の処理

使用場面

none

そのまま受信者に配信される

メール送信状況を把握したい場合

quarantine

迷惑メールフォルダなどに隔離される

ポリシー強化の影響を確認したい場合

reject

受信側で拒否され、届かない

なりすましメールを拒否強く防ぎたしたい場合

「p=none」は状況把握には有効ですが、なりすましメール自体を防ぐ効果はありません。そのため、DMARCをセキュリティ対策として機能させるには、最終的に「quarantine」や「reject」への移行を検討する必要があります。

DMARCポリシーの設定コード

DMARCポリシーは、DNSに登録するDMARCレコードのpタグで指定します。たとえば、監視のみで運用する場合は以下のように記述します。

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


隔離や拒否に変更する場合は、「p=」の値を変更することでポリシーを切り替えられます。

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


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

ただし、いきなり「p=reject」に変更すると、正規のメールまで受信拒否されるリスクがあります。そのため、まずは「p=none」でDMARCレポートを確認し、送信元やSPF・DKIMの設定を整えたうえで、段階的に強化することが大切です。

DMARCポリシーの影響範囲を分けたい場合

DMARCポリシーは、基本的に対象ドメインだけではなくサブドメインにも適用されます。そのため、用途や送信環境が異なる場合は、影響範囲を適切に分けて運用しましょう。

spタグを使用する

spタグを使用することで、サブドメインに適用するDMARCポリシーを親ドメインとは別に設定できます。これにより、親ドメインは監視のみ(none)、サブドメインは隔離(quarantine)といったように、異なるポリシーを適用することが可能です。

例えば、以下のように設定します。

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

この設定では、親ドメインは「none」、サブドメインは「quarantine」が適用されます。ただし、spタグはすべてのサブドメインに一律で適用されるため、細かく制御したい場合には注意が必要です。

サブドメインごとにDMARCレコードを設定する

より柔軟に運用したい場合は、サブドメインごとにDMARCレコードを個別に設定する方法が有効です。メール配信サービスや用途ごとに送信環境が異なる場合、それぞれに適したポリシーを設定できます。

例えば、マーケティングメール用のサブドメインと、システム通知用のサブドメインでポリシーを分けることで、それぞれの影響を最小限に抑えながら運用が可能です。

この方法により、特定のサブドメインだけ段階的にポリシーを強化するなど、実際の運用に合わせた調整が可能になります。

DMARCポリシーをnoneからrejectに変更する理由

DMARCポリシーは「p=none」のままでは監視機能にとどまり、なりすましメールを防ぐ効果はほとんどありません。自社ドメインの悪用を防ぎ、メールの信頼性を維持するためには、「quarantine」や「reject」へ段階的に強化することが重要です。

なりすましメールを防止できないため

「p=none」は、DMARC認証に失敗したメールでも、そのまま受信者に配信されます。そのため、攻撃者が自社ドメインを装ってフィッシングメールを送信した場合でも、それをブロックすることができません。

DMARCの本来の目的は、ドメインのなりすましを防ぐことです。そのため、認証に失敗したメールを隔離・拒否する「quarantine」や「reject」に設定することで、初めて実効性のあるセキュリティ対策として機能します。

ブランド信頼や顧客体験を守るため

なりすましメールが拡散されると、受信者は「この企業のメールは危険かもしれない」と感じるようになります。その結果、正規のメールであっても開封されにくくなり、企業のブランドイメージや顧客体験にも悪影響を及ぼします。

DMARCポリシーを強化することで、こうした不正メールの流通を抑え、顧客や取引先が安心してメールを受信できる環境を整えやすくなります。

ドメインのレピュテーション低下を防ぐため

自社ドメインがスパムやフィッシングに悪用されると、受信側のメールサービスからの評価(レピュテーション)が低下する可能性があります。近年は送信元ドメインの信頼性評価がメールの到達率に大きく影響する傾向にあり、悪用されることで正規メールの到達率低下につながることもあります。

DMARCポリシーを「reject」まで強化しておくことで、不正なメール往診を防ぎ、ドメインの信頼性を維持しやすくなります。

セキュリティ対策としての評価を高めるため

DMARCポリシーはDNSで公開されるため、外部からも確認できます。そのため、「p=none」のままではセキュリティ対策が不十分と見なされる可能性があります。

実際に、公的機関や大手企業ではDMARCの強化が推奨されており、「p=reject」または「quarantine」での運用が求められるケースも増えています。ポリシーを強化することで、対外的な信頼性やセキュリティ意識の高さを示すことにもつながります。

参考:内閣サイバーセキュリティセンター「政府機関等のサイバーセキュリティ対策のための統一基準群」

DMARCポリシーnoneからquarantine・rejectへ強化する手順

DMARCポリシーは、いきなりnoneからrejectへ変更するのではなく、送信状況や認証結果を確認しながら段階的に強化することが重要です。正規メールが届かなくなるリスクを抑えるため、レポート確認、送信元の棚卸し、SPF・DKIMの整備をおこなったうえで、quarantine、rejectへ移行します。

DMARCレポートの収集を始める

まずは「p=none」の状態でDMARCレポートを受け取れるように設定します。DMARCレコードにruaタグを追加すると、送信元IPや認証結果、送信通数などを確認できる集約レポートを受信できます。

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

レポートを確認することで、自社ドメインを使ってどの送信元からメールが送られているかを把握できます。XML形式で届くことが多いため、必要に応じて解析ツールを使うと管理しやすくなります。

送信環境を棚卸しする

次に、自社ドメインでメールを送信しているシステムやサービスを洗い出します。メール配信システム、問い合わせフォーム、ECサイト、CRM、請求書送付ツール、採用管理システムなど、部署ごとに利用している外部サービスも含めて確認しましょう。

この作業が不十分なままポリシーを強化すると、正規のメールがDMARC認証に失敗し、迷惑メール扱いや受信拒否の対象になる可能性があります。そのため、誰がどの送信環境を管理しているかまで整理しておくことが大切です。

SPF・DKIMの設定を整備する

送信元を洗い出したら、それぞれのSPF・DKIM設定を確認します。DMARCでは、SPFまたはDKIMの認証に成功するだけでなく、認証に使われたドメインとヘッダFromのドメインが一致している必要があります。

外部のメール配信サービスを利用している場合は、SPFのinclude設定やDKIM署名が正しく設定されているか確認しましょう。特に、DKIM署名の「d=」が自社ドメインになっているか、Return-PathのドメインがヘッダFromと整合しているかを確認することが重要です。

quarantineへ段階的に移行する

正規メールのDMARC認証が安定して成功するようになったら、「p=quarantine」へ変更します。quarantineに設定すると、DMARC認証に失敗したメールは迷惑メールフォルダへ振り分けられやすくなります。

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

不安がある場合は、pctタグを使って適用割合を調整できます。

v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@example.com

この設定では、認証に失敗したメールの50%に対してquarantineが適用されます。段階的に割合を上げることで、業務メールへの影響を確認しながら移行できます。

rejectへ移行する前に最終確認をおこなう

quarantineで大きな問題がないことを確認できたら、最終的に「p=reject」へ移行します。rejectは、DMARC認証に失敗したメールを受信側で拒否する、最も厳格なポリシーです。

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


移行前には、請求書、契約関連、システム通知、会員登録メールなど、重要な正規メールが問題なく届いているかを必ず確認しましょう。また、社内関係者に周知し、未着やバウンスが発生した場合にすぐ対応できる体制を整えておくことも大切です。

DMARCポリシーを運用する時のポイント

DMARCポリシーは、設定して終わりではありません。ポリシーを「quarantine」や「reject」に強化した後も、送信環境の変更や新しいツールの導入に合わせて、認証状態を継続的に確認することが重要です。

DMARCレポートを定期的に確認する

ポリシー強化後も、DMARCレポートは定期的に確認しましょう。認証失敗が急に増えていないか、不審な送信元がないか、正規メールが失敗していないかを把握することで、トラブルを早期に発見できます。

特に「p=reject」で運用している場合、設定ミスがあると正規メールが受信拒否される可能性があります。そのため、月1回以上を目安にレポートを確認し、認証エラーが見つかった場合は、送信元やSPF・DKIMの設定を速やかに見直すことが大切です。

DMARCポリシーのレポートオプションとは

DMARCには、認証結果や送信状況を把握するためのレポート機能が用意されています。主に「集約レポート(rua)」と「フォレンジックレポート(ruf)」の2種類があり、それぞれ役割が異なります。これらを適切に設定することで、なりすましの検知や設定ミスの早期発見が可能になります。

まず、集約レポート(rua)は、一定期間におけるDMARC認証結果の概要をまとめたレポートです。送信元IPアドレス、送信通数、SPF・DKIMの認証結果などが集計形式で提供されます。どの送信元が正しく認証されているか、どこで失敗が発生しているかを全体的に把握するのに適しています。

一方、フォレンジックレポート(ruf)は、DMARC認証に失敗した個別のメールのに関する詳細情報を提供します。失敗したメールのヘッダ情報や本文の一部の本文が含まれる場合もあり、原因の特定や不正メールの分析に役立ちます。ただし、個人情報保護の観点から対応していないメールサービスもあるため、利用時には注意が必要です。

これらのレポートは、DMARCレコードに以下のように記述して設定します。

v=DMARC1; p=none; rua=mailto:aggregate@example.com; ruf=mailto:forensic@example.com

DMARCレポートを活用することで、送信環境の可視化、認証エラーの検知、不正利用の把握が可能になります。特にポリシーを「quarantine」や「reject」に強化した後は、レポートを定期的に確認し、問題がないか継続的に監視することが重要です。

DMARCポリシーのエラーメッセージ

DMARCを運用していると、設定ミスや認証不備によってさまざまなエラーが発生することがあります。これらのエラーを正しく理解し、早期に対処することが安定したメール運用のポイントです。ここでは代表的なエラーとその意味、対処法をまとめます。

・DMARC Policy Not Enabled

意味:DMARCレコードが未設定、または「p=none」のままになっている状態です。実質的にポリシーが有効化されていません。

対処法:DNSにDMARCレコードを追加し、「p=quarantine」や「p=reject」へ段階的に強化します。

・構文エラー(Syntax Error)

意味:DMARCレコードの記述ミス(セミコロンの欠落、タグの誤記など)により、正しく認識されていない状態です。

対処法:DMARCレコードの書式を見直し、正しい構文(例:v=DMARC1; p=none; rua=...)で記述し直します。

・設定エラー(Configuration Error)

意味:SPFやDKIMの設定不備、またはアライメント不一致によりDMARC認証が失敗している状態です。

対処法:SPF・DKIMの設定を確認し、ヘッダFromドメインとの一致(アライメント)を満たすよう修正します。

・DMARC spポリシー不整合

意味:親ドメインが「p=reject」でも、サブドメインポリシー(sp)が「none」など緩い設定になっているケースです。

対処法:spタグを見直し、「sp=quarantine」や「sp=reject」など適切なポリシーに変更します。

・認証失敗(DMARC Fail)

意味:SPFまたはDKIMの認証、もしくはアライメントが満たされず、DMARCチェックに失敗している状態です。

対処法:送信元IPや署名ドメインを確認し、SPFレコードやDKIM署名を適切に設定・修正します。

これらのエラーはDMARCレポートを活用することで早期に検知できます。特にポリシーを強化している場合、エラーの放置はメール不達や業務影響につながるため、定期的な確認と迅速な対応が重要です。

メールシステムの導入を検討中なら「アララ メッセージ」へ

メールの到達率やセキュリティ対策を強化するには、DMARCだけでなく、安定した配信基盤の構築も重要です。「アララ メッセージ」は、大量配信に対応したメール配信システムで、メルマガや通知メールなど幅広い用途に活用できます。SPF・DKIM・DMARCといった送信ドメイン認証への対応も踏まえた運用が可能で、到達率の改善や配信の安定化をサポートします。これからメール配信環境を整えたい方は、ぜひお問い合わせください。

まとめ

DMARCポリシーは、なりすましメール対策として非常に重要な役割を持ちますが、「p=none」のままでは十分な効果を発揮しません。まずはレポートを活用して送信状況を把握し、SPF・DKIMの設定を整えたうえで、「quarantine」「reject」へと段階的に強化していくことが重要です。適切に運用することで、ドメインの信頼性向上やメール到達率の維持につながります。継続的な監視と改善をおこないながら、安全で安定したメール運用を実現しましょう。

アララ アカウントグロース部 中村
アララ アカウントグロース部 中村
宣伝会議主催のセミナー等でも「顧客との絆を深めるために有効なメールマーケティングの戦略」などをテーマに登壇。日々、顧客に寄り添い、顧客が目指すゴールへ向けて、支援しています。 メール配信運用、メールマーケティングに関する情報、​​​​​​​“知ってるとちょっとイイコトがある”情報を発信していますので、ぜひ、チェックしてみてください。 アララ メッセージは、15年以上にわたり「国内開発・自社サポート」で提供している、純日本製のメール配信サービスです。画面操作による一斉配信はもちろん、システム連携によるAPI配信にも標準対応しています。 また、総務省後援「ASPICクラウドアワード2024」支援業務系ASP・SaaS部門にて「DX貢献賞」を受賞しています。

導入事例はこちら


関連コラム

メール配信サービスのお役立ち資料一覧

アララ メッセージ製品情報

アララ メッセージ導入事例集

成果に差が出る!「メルマガにおける目的設定」ガイド

安定配信を実現する!「メール配信API」選定のコツ

アララ メッセージのサービス詳細

CONTACT
お電話でのお問い合わせはこちら
平日10:00~18:00(日本時間)
ご不明な点はお気軽に
お問い合わせください
メール配信サービスの
お役立ち資料はこちら

サービス詳細


気記事ランキング


関連記事


サービス詳細