BLOG ベアメールブログ
DMARCは、メールソフト上で表示される送信元ドメイン（ヘッダFrom）のなりすまし対策に有効な送信ドメイン認証技術です。DMARCを設定することで、SPFやDKIMの認証結果と、ヘッダFromとのアライメントをもとに、認証に失敗したメールをどのように扱うかを受信側に伝えられます。
ただし、DMARCはレコードを設定するだけで十分に機能するものではありません。適切な設定・運用ができていないと、正規のメールが迷惑メールとして扱われたり、受信拒否されたりする可能性があります。DMARCを正しく運用するには、自社ドメインで送信しているメールの把握や、SPF・DKIMの設定状況の確認などの事前準備を行ったうえで、DMARCレコードを設定し、レポートをもとに継続的に認証状況を確認することが重要です。
本記事では、DMARCを設定する前に確認すべきことや、DMARCの設定方法、レコードの書き方、よくある失敗例について解説します。
目次
H2: DMARC設定前に準備すること
DMARCは、DNSにDMARCレコードを登録することで設定できます。ただし、DMARCを適切に機能させるには、事前に自社ドメインから送信されているメールの送信元や、SPF・DKIMの設定状況、DMARCレポートを受信するメールアドレスなどを確認しておく必要があります。
ここでは、DMARC設定前に準備しておきたいポイントを解説します。
自社ドメインで送信しているメールを洗い出す
DMARCを設定する前に、自社ドメインを使用して送信しているメールを洗い出します。社内のメールサーバーやGoogle Workspace、Microsoft 365などのメールサービスだけでなく、Webサイトの問い合わせフォーム、ECサイト、CRM・MAツール、メール配信システム、外部委託先やSaaSから送信しているメールも確認対象になります。
送信元の把握が不十分なままDMARCポリシーを強化すると、正規のメールがDMARC認証に失敗した場合に、迷惑メール扱いや受信拒否につながる可能性があるため、注意が必要です。
SPF・DKIMの設定状況を確認する
DMARCは、SPFまたはDKIMの認証結果と、ヘッダFromとのアライメントをもとに判定されます。そのため、DMARCを設定する前に、自社ドメインで送信しているメールについて、SPF・DKIMが正しく設定されているか確認しておくことが重要です。
SPFレコードに正規の送信元IPアドレスやメール配信サービスが含まれていない場合や、DKIM署名が付与されていない場合、DMARC認証に失敗する可能性があります。送信元ごとにSPF・DKIMの設定状況を確認し、必要に応じてDNSレコードや送信サービス側の設定を見直しましょう。
SPF・DKIMの設定を確認する方法については、以下の記事で詳しく解説しています。
DMARCレポートを受信するメールアドレスを用意する
DMARCを運用する際は、DMARCレポートを受け取るためのメールアドレスを用意しておきましょう。DMARCレポートを確認することで、自社ドメインを使ってメールを送信しているIPアドレスや、SPF・DKIMの認証に使用されたドメイン、認証結果を把握できます。
DMARCレポートは、受信側メールサービスプロバイダから定期的に送信されるため、送信規模や宛先によっては多くのレポートが届くことがあります。通常の業務用メールアドレスを指定すると管理しにくくなるため、DMARCレポート受信用のメールアドレスを用意しておくとよいでしょう。
DNSレコードの編集権限を確認する
DMARCレコードはDNSにTXTレコードとして登録するため、DNSレコードを編集できる権限が必要です。自社でDNSを管理している場合は、DNS管理画面にログインできるか、TXTレコードを追加・変更できる権限があるかを確認しておきましょう。
ドメイン管理やDNS管理を外部の事業者に委託している場合は、事前にDMARCレコードの設定を依頼できる体制を整えておく必要があります。設定作業をスムーズに進めるためにも、DNSの管理者や依頼先を確認しておきましょう。
DMARCの設定方法
事前準備が完了したら、DMARCレコードに記載する内容を決め、DNSに登録します。DMARCの設定では、ホスト名、ポリシー、レポート送信先などを正しく指定することが重要です。ここでは、DMARCレコードを設定する際の基本的な流れを、手順に沿って解説します。
1. DMARCレコードを登録するホスト名を確認する
まず、DMARCを設定する対象ドメインを確認します。DMARCレコードは、対象ドメインの先頭に _dmarc を付けたホスト名にTXTレコードとして登録します。例えば、example.com にDMARCを設定する場合は、DNS管理画面で以下のように設定します。
項目 設定例 ホスト名（名前） _dmarc.example.com type TXT Data（値） v=DMARC1; p=none; rua=mailto:report@example.com
DNS管理画面によっては、ホスト名に _dmarc だけを入力する場合と、_dmarc.example.com まで入力する場合があります。入力形式を誤ると、意図しないホスト名に登録される可能性があるため、管理画面の仕様を確認しておきましょう。
2. DMARCポリシーを決める
次に、DMARCポリシーを決めます。DMARCポリシーとは、DMARC認証に失敗したメールをどのように扱うかを受信側メールサーバーに伝えるための設定です。ポリシーには、「none」「quarantine」「reject」の3種類があります。
各ポリシーの意味は、以下の通りです。
DMARCポリシー 意味 none 監視のみを行い、認証に失敗したメールの隔離や拒否を要求しない quarantine 認証に失敗したメールを迷惑メールフォルダへ振り分けるなど、不審なメールとして扱うよう求める reject 認証に失敗したメールは配信せず、受信を拒否するよう求める
初めてDMARCを設定する場合は、まずp=noneから始めるのが一般的です。DMARCレポートで正規メールの認証状況を把握し、問題がないことを確認したうえで、quarantineやrejectへ段階的に移行しましょう。
3. DMARCレポートの送信先を指定する
次に、DMARCレポートの送信先を指定します。一定期間内のメール認証結果をまとめた「集計レポート」を受け取るには、レコード内にrua=mailto:メールアドレスの形式でレポート受信用のメールアドレスを指定する必要があります。
例えば、dmarc-report@example.com でレポートを受け取る場合は、rua=mailto:dmarc-report@example.com と記述します。
4. DMARCレコードをDNSに登録する
ホスト名やポリシー、レポート送信先を決めたら、DMARCレコードをDNSに登録します。DNS管理画面で対象ドメインを選択し、TXTレコードを追加します。
DMARCレコードの書き方については、次章で詳しく解説します。
5. 正しく設定できているか確認する
DMARCレコードを登録したら、正しく設定できているか確認しましょう。DMARCチェッカーを利用すると、DMARCレコードがDNS上に公開されているか、構文に誤りがないかを手軽に確認できます。
コマンドで確認する場合は、digやnslookupを使用します。例えば、example.comのDMARCレコードを確認する場合は、以下のように実行します。
dig TXT _dmarc.example.com
または、以下のコマンドでも確認できます。
nslookup -type=TXT _dmarc.example.com
実行結果に v=DMARC1 から始まるTXTレコードが表示されれば、DMARCレコードがDNS上に公開されています。レコードが表示されない場合は、ホスト名の入力ミスやTXTレコードの記述ミスがないかを見直しましょう。DNSの反映には時間がかかる場合があるため、登録直後に確認できない場合は、しばらく時間を置いてから再度確認します。
以下の記事では、無料で利用できるDMARCチェッカーを紹介しています。
DMARCレコードの書き方
DMARCを設定するには、DNSに登録するDMARCレコードを正しく記述する必要があります。DMARCレコードには、DMARCのバージョンやポリシー、レポートの送信先などをタグ形式で記述します。
ここでは、DMARCレコードの基本構文や必須タグ、よく使われるタグ、ポリシーの種類、用途別の設定例について解説します。
DMARCレコードの基本構文
DMARCレコードは、タグと値を組み合わせた1行のテキストで記述します。タグと値は = でつなぎ、各項目の間をセミコロン（ ; ）で区切ります。
基本的な構文は以下の通りです。
v=DMARC1; p=none; rua=mailto:dmarc-report@example.com
上記の例では、DMARCのバージョンを示す v タグ、DMARCポリシーを示す p タグ、DMARC集計レポートの送信先を示す rua タグを指定しています。
DMARCレコードでは、v=DMARC1 を先頭に記述します。タグの記述ミスやセミコロンの抜けがあると、レコードが正しく認識されない可能性があるため注意しましょう。
タグの種類
DMARCレコードでは、タグを使ってポリシーやレポート送信先などを指定します。ここでは、基本的なDMARCレコードで使われる主要タグと、運用方針に応じて指定するその他のタグに分けて紹介します。
主要タグ
vはDMARCレコードで必須のタグです。pはRFC上では推奨タグとされていますが、DMARC認証に失敗したメールの扱いを示すため、実務上は基本的に指定します。また、ruaは必須ではありませんが、DMARCレポートを受け取り、送信元や認証状況を確認するために設定しておくとよいでしょう。
sp、adkim、aspfは、サブドメインのポリシーやアライメント条件を明示したい場合に使用されます。
タグ 指定する値 内容 v
※必須DMARC1 DMARC のバージョンを示します。必ず先頭に記述します。 p
※推奨（実務上は基本的に指定）none / quarantine / reject 対象ドメインのDMARCポリシーを指定します。 sp none / quarantine / reject 既存のサブドメインのDMARCポリシーを指定します。このタグを使用しない場合、基本的には親ドメインのポリシーがサブドメインにも適用されます。 rua mailto:任意のメールアドレス 一定期間内のメール認証結果をまとめた「集計レポート」の送信先を指定します。 adkim r / s DKIMのアライメントチェックをどの程度厳密に行うかを指定します。
r：リラックスモード。同じ組織ドメインであれば一致とみなします。
s：ストリクトモード。ドメインが完全に一致する必要があります。aspf r / s SPFのアライメントチェックをどの程度厳密に行うかを指定します。
r：リラックスモード。同じ組織ドメインであれば一致とみなします。
s：ストリクトモード。ドメインが完全に一致する必要があります。
その他のタグ
以下のタグは、サブドメインの扱いや失敗レポートの送信条件などを細かく指定したい場合に使用されます。
タグ 指定する値 内容 t y / n DMARCポリシーのテストモードを指定します。ポリシーがnoneの場合には影響しません。
y：指定したポリシーをテスト中であることを示します。DMARC認証に失敗したメールには、指定ポリシーより一段階弱い扱いが期待されます。
n：デフォルト値。テストモードを無効化し、指定したポリシーの適用を求めます。np none / quarantine / reject 存在しないサブドメインに対するDMARCポリシーを指定します。このタグを使用しない場合、spがあればspで指定されたポリシー、spがなければpで指定されたポリシーが適用されます。 ruf mailto:任意のメールアドレス DMARC認証に失敗した個々のメールについて通知する「失敗レポート」の送信先を指定します。ただし、受信側の方針により、送信されない場合があります。 fo 0 / 1 / d / s 失敗レポートの送信条件を指定します。rufが指定されていない場合は無視されます。また、複数指定する場合はfo=0:dのようにコロンで区切ります。ただし、0と1は同時に指定できません。
0：SPF・DKIMのいずれもDMARCアライメントで passにならなかった場合
1：SPF・DKIMのいずれかがDMARCアライメントでpassにならなかった場合
d：DKIMの評価に失敗した場合
s：SPFの評価に失敗した場合psd y / n / u DMARCドメインがPublic Suffix Domainで公開されたものかどうかを示します。
y：Public Suffix Domainであることを示します。
n：Public Suffix Domainではなく、組織ドメインまたはその配下のドメインであることを示します。
u：デフォルト値。Public Suffix Domainではないが、組織ドメインかその配下のドメインかを明示しない場合に使用されます。
Public Suffix Domainとは、.com や .co.uk のように、その配下に複数の組織がドメインを登録できるドメインのことです。例えば、example.com に対して .com はPublic Suffix Domainにあたります。
参考：RFC9989 Domain-Based Message Authentication, Reporting, and Conformance (DMARC) https://datatracker.ietf.org/doc/html/rfc9989#name-dmarc-tags-registry-update（2026/6/18確認）
用途別の設定例
用途に応じたDMARCレコードの設定例を紹介します。実際に設定する際は、example.comやレポート送信先のメールアドレスを、自社で使用するドメイン・メールアドレスに置き換えてください。
監視から始める場合
初めてDMARCを設定する場合は、まずp=noneで監視から始めるのが一般的です。
ホスト名 TTL class type Data（値） _dmarc.example.com 3600 IN TXT v=DMARC1; p=none; rua=mailto:report@example.com
上記のレコードでは、対象ドメインのポリシーとして none を指定し、DMARC集計レポートの送信先として report@example.com を指定しています。
サブドメインのポリシーを指定する場合
既存のサブドメインに親ドメインとは別のポリシーを適用したい場合は、spタグを使用します。
ホスト名 TTL class type Data（値） _dmarc.example.com 3600 IN TXT v=DMARC1; p=none; sp=quarantine; rua=mailto:report@example.com
上記のレコードでは、親ドメインに対するポリシーは none、既存のサブドメインに対するポリシーは quarantineを指定しています。
失敗レポートの送信先やアライメント条件も指定する場合
失敗レポートの送信先や、SPF・DKIMのアライメント条件を明示したい場合は、ruf、adkim、aspfなどのタグを追加します。
ホスト名 TTL class type Data（値） _dmarc.example.com 3600 IN TXT v=DMARC1; p=none; sp=quarantine; rua=mailto:report@example.com; ruf=mailto:forensic@example.com; adkim=r; aspf=r
上記のレコードでは、以下の内容を指定しています。
指定内容 意味 p=none 親ドメインに対するポリシーはnone sp=quarantine 既存のサブドメインに対するポリシーは quarantinerua=mailto:report@example.com DMARC集計レポートの送信先は report@example.comruf=mailto:forensic@example.com DMARC失敗レポートの送信先は forensic@example.comadkim=r DKIMのアライメントチェックはリラックスモード aspf=r SPFのアライメントチェックはリラックスモード
DMARC設定・運用のよくある失敗例
DMARCの設定内容に不備がある場合や、運用方法が不適切な場合、正規のメールがDMARC認証に失敗し、意図せず迷惑メール扱いや受信拒否につながる可能性があります。ここでは、DMARCの設定・運用でよくある失敗例を紹介します。
ホスト名を誤って登録している
DMARCレコードの登録先ホスト名に誤りがあると、受信側のメールサーバーは正しいDMARCレコードを参照できず、DMARCポリシーが適用されません。設定後は、DMARCチェッカーやdig、nslookupなどのコマンドを利用して、対象ドメインのDMARCレコードが正しく取得できるかを確認しましょう。
DMARCレコードが複数存在している
同じドメインにDMARCレコードが複数存在していると、受信側メールサーバーが有効なDMARCレコードを判定できず、DMARCが正しく機能しない可能性があります。設定後は、DMARCチェッカーやコマンドでTXTレコードを確認し、_dmarc.example.com に複数のDMARCレコードが登録されていないかを確認しましょう。
送信元の追加・変更を把握できていない
DMARC設定後に新しいメール配信サービスやシステムを追加した場合、その送信元でSPF・DKIMが正しく設定されていないと、正規のメールがDMARC認証に失敗する可能性があります。
送信元に追加・変更があった場合は、その都度SPF・DKIMの設定状況を確認しましょう。DMARCレポートを確認することで、想定外の送信元や、認証に失敗している送信元を把握しやすくなります。
SPF・DKIMのアライメントに失敗している
SPFやDKIMの認証に成功していても、DMARC認証に失敗する場合があります。DMARCでは、SPFまたはDKIMの認証結果に加えて、認証に使用されたドメインとヘッダFromのドメインが一致しているか、または同じ組織ドメインであるかを確認します。これをアライメントといいます。
SPF・DKIMの認証結果がPassであっても、認証に使用されたドメインとヘッダFromのドメインが整合していなければ、DMARC認証には失敗する可能性があります。メール配信サービスや外部システムを利用している場合は、SPFで認証されるエンベロープFrom（Return-Path）ドメインや、DKIM署名ドメインがヘッダFromと整合しているか確認しましょう。
アライメントについては、以下の記事で詳しく解説しています。
いきなりquarantineやrejectを適用している
DMARCを初めて設定する段階で、いきなり quarantine や reject を適用すると、正規のメールがDMARC認証に失敗した場合に、迷惑メールとして扱われたり、受信拒否されたりする可能性があります。
まずは p=none でDMARCレポートを確認し、自社ドメインから送信されている正規メールがDMARC認証に成功しているかを把握しましょう。そのうえで、認証失敗の原因を解消し、問題がないことを確認してから、段階的に quarantine や reject へ移行することが重要です。
DMARCポリシー強化の進め方については、以下の記事で詳しく解説しています。
DMARCレポートを分析していない
DMARCレポートを放置していると、正規メールの認証失敗や、想定外の送信元に気づけない可能性があります。そのため、DMARCレポートを継続的に分析し、認証状況を把握しながら運用することが重要です。
ただし、DMARC集計レポートは、各メールサービスから個別にXML形式で送られてくるため、そのままでは内容を把握しづらく、手作業で集計するのは現実的ではありません。
ベアメールの「迷惑メールスコアリング」では、複雑なDMARCレポートを自動で集計し、グラフや表で分かりやすく可視化する「DMARC分析機能」を提供しています。SPF・DKIM・アライメントの認証状況を簡単に把握できるほか、送信元IPアドレスや認証結果などの条件でフィルタリングすることも可能です。これにより、問題のある送信元や対処が必要なメールの特定を行いやすくなります。
DMARCレポートの分析に課題を感じている方は、ぜひベアメールの「迷惑メールスコアリング」をご活用ください。
まとめ
DMARCはなりすましメール対策に有効な仕組みですが、設定や運用に不備があると、正規のメールが迷惑メールとして扱われたり、受信拒否されたりする可能性があります。本記事で紹介した設定手順や注意点を参考に、自社の送信環境に合わせて適切にDMARCを運用しましょう。
