DMARCレコードの作成と公開方法（2026年版 ステップバイステップガイド）

DMARCレコードとは、認証チェックに失敗したメールを、受信メールサーバーがどのように処理すべきかを指示するDNS TXTレコードのことです。このガイドでは、DMARCレコードの作成、ドメインのDNSへの登録、動作確認、および現在このプロトコルを規定している2026年の標準規格（RFC 9989）について解説します。

初めてメール認証を設定する場合でも、2025年および2026年のコンプライアンス要件を満たすためにレコードを更新する場合でも、10分以内に正常に動作するDMARCレコードを生成して公開することができます。このガイドは、ITプロフェッショナル、ドメイン管理者、MSP、およびコンプライアンス担当者を対象としています。

注：DMARCは2026年5月に更新されました（RFC 9989）。本ガイドに記載されているすべてのレコード例は、更新後の規格に基づいています。

DMARCレコードとは何ですか？

DMARCレコードとは、_dmarc.yourdomain.com に公開されるDNSのTXTレコードであり、認証チェックに失敗した、あなたのドメインからの送信を装ったメールを、受信メールサーバーがどのように処理すべきかを指示するものです。

DMARCは、既存の2つの電子メール認証プロトコルを基盤としています：

• SPF（Sender Policy Framework）：特定のIPアドレスに対して、あなたのドメインからメールを送信することを許可する仕組み
• DKIM（DomainKeys Identified Mail）：メールに暗号的な署名を施し、そのメールが自分のドメインから送信されたものであることを証明する

DMARCがない場合、SPFやDKIMの検証に失敗した際に受信側がどう対応すべきかを定めたポリシーが存在しません。そのため、受信側は独自に判断することになり、多くの場合、なりすましメールを通してしまうことになります。

DMARCが電子メール認証においてどのような役割を果たすか

1. SPFは、このメールを送信しているサーバーが、そのドメインのSPFレコードによって承認されているかどうかを確認することで、送信元IPを検証します。
2. DKIMは、メールのデジタル署名がドメインの公開DKIM鍵と一致するかどうかを確認することで、署名の有効性を検証します。
3. DMARCは、SPFおよび／またはDKIMの検証に失敗した場合の対応を決定します。DMARCポリシー（およびアラインメントルール）によって、受信側に対してそのメールを拒否、隔離、または許可するよう指示します。

DMARCレコードを公開する前に

DMARCレコードを設定するには、少なくともSPFまたはDKIMのいずれかを公開し、送信ドメインと整合させる必要があります。これらがない場合でも、p=none（監視）でDMARCレコードを公開することは可能ですが、強制措置（p=quarantineまたはp=reject）を適用するには、少なくとも1つのプロトコルが検証に合格している必要があります。

簡単な確認事項：

• SPFレコードを確認してください
• DKIMが設定されていることを確認する

DMARCレコードの構造

DMARCレコードとは、セミコロンで区切られたタグと値のペアの列のことです。必須となるタグは2つだけで、それ以外はすべてオプションですが、指定することが推奨されています。

アクティブなタグ

psd= に関する注記：このタグは、主に国別コードレジストリや gTLD 運営者などのパブリックサフィックス運営者（PSO）を対象としています。一般的なドメイン所有者のほとんどは、このタグを完全に省略してください。このタグが関係するのは、ドメインが .gov.uk や .bank のようなパブリックサフィックスである場合のみです。

rufに関する注記：主要な受信者（Google、Microsoft、Yahoo）は、もはや障害報告を送信しなくなりました。

非推奨のタグ

RFC 9989 では、実装上の不整合を引き起こしていた 3 つのタグが非推奨または削除されました：

注：既存のレコードにこれらのタグが含まれている場合でも、受信側はそれらを無視するため、機能には影響ありません。ただし、次回レコードを編集する際には、RFC 9989 に準拠させるためにこれらのタグを削除し、新しいレコードを公開する際には含めないようにしてください。

DMARCポリシーの比較

DMARCレコードの例

以下の例はすべて、非推奨となったタグを省略し、必要に応じて新しいタグを追加するなど、RFC 9989 を反映したものです。

例 1：モニタリングモード（ここから開始）

v=DMARC1; p=none; rua=mailto:[email protected]

ユースケース：DMARCの初回設定。強制適用は行わない。認証結果を追跡するため、集計レポートを毎日送信する。

各タグの機能：

• v=DMARC1：これをDMARCレコードであることを示します
• p=none 何も行わず、監視のみを行う
• rua= mailto:[email protected] このメールアドレスに日次レポートを送信してください

例 2：部分的な施行（移行措置）

v=DMARC1; p=quarantine; sp=quarantine; np=reject; rua=mailto:[email protected]

ユースケース：ポリシーの徹底に向けた取り組み。配信に失敗したメールを隔離する。存在しないサブドメインに対するポリシーを厳格化する。

新着情報：

• sp=quarantine サブドメインは検疫ポリシーを継承する
• np=reject 存在しないサブドメインは拒否されます（RFC 9989 に基づく保護）

例 3：完全な施行

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected]

ユースケース：本番環境での完全な適用。要件を満たさないメールはすべて拒否する。当該ドメインではメーリングリストをホストしていない。

例 4：送信不可／保留中のドメイン

v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s

ユースケース：メールを送信しないが、なりすましからの保護が必要なドメイン。

違いは：

• adkim=s; aspf=s 厳密な位置合わせ（緩和モードは不要）
• No rua= レポートを監視していない（ドメインから送信されていない）
• np=reject 存在しないサブドメインであっても、なりすましメールを拒否する

攻撃者がフィッシング攻撃において未使用のドメインを偽装する可能性があるため、使用されていないドメインであっても保護する必要があります。

例 5：より厳格なポリシーが適用されたサブドメイン

親ドメイン：v=DMARC1; p=quarantine; rua=mailto:[email protected]
サブドメイン（marketing.yourdomain.com）：v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected]

ユースケース：親ドメインでは隔離が許可されている（メールが転送されている）。マーケティング用サブドメインは専用の送信元であり、p=reject を適用する。

例 6：Microsoft 365 / Google Workspace

v=DMARC1; p=reject; rua=mailto:[email protected]

注：Microsoft 365 や Google Workspace では、固有の DMARC 構文は必要ありません。このレコードは、他の DMARC 導入と同様に DNS に公開されます。適用を開始する前に、すべての送信元についてSPF および DKIMの設定を確認してください。

詳しい手順については、当社の「Microsoft 365 DMARC 設定ガイド」および「Google Workspace DMARC 設定ガイド」をご参照ください。

DMARCレコードの作成方法

方法 1：PowerDMARC の無料ジェネレーターを使用する

1.DMARCレコードジェネレータにアクセスする

2. 希望する適用レベル（なし／監視、隔離、拒否）を選択してください。

3. ドメインとレポート受信用メールアドレスを入力してください

4. 必要に応じて、サブドメインポリシーを有効にし、存在しないサブドメインを保護します（任意）

5. 「生成」をクリックします

6. DMARCレコードが作成されました

方法 2：手動で作成する

テキストエディタを開き、レコードを手入力で記述します：

v=DMARC1; p=none; rua=mailto:[email protected]

まずは p=none（監視）から始めてください。メールのトラフィックを把握したら、後でポリシーを調整してください。

必須：

• v=DMARC1（常に）
• p=（設定：なし、隔離、または拒否）
• rua= (報告用メールアドレス)

DMARCレコードの公開方法 – DNSプロバイダーによるステップバイステップガイド

ドメインのDNSは、ドメイン登録業者（GoDaddy、Namecheapなど）、ウェブホスティングプロバイダー（cPanel）、またはCDN（Cloudflare）によって管理されています。それぞれのサービスにログインし、以下の各プロバイダーごとの手順に従ってください。

一般的な手順（ご利用の通信事業者がリストにない場合）：

1. DNS管理コンソールを開く

2. DMARCを設定したいドメインをクリックします

3. 新しいTXTレコードを作成する

4. レコード名：_dmarc（フォームで完全なホスト名が必要な場合は、_dmarc.yourdomain.com）

5. レコード値：DMARCレコードの文字列を貼り付けてください

6. 保存し、反映されるまで待つ（24～48時間）

7. DMARCチェッカーを使用して確認する

GoDaddyでDMARCレコードを公開する

1. GoDaddyのドメインポートフォリオにログインします

2. ドメインの横にある「DNS」をクリックします

3. 「DNSレコード」までスクロールします

4. 「新しいレコードを追加」をクリックします

5. 形式：TXT

6. 名前：_dmarc

7. 値：DMARCレコードを貼り付けてください

8. 「保存」をクリックします

CloudflareでDMARCレコードを公開する

1. Cloudflareダッシュボードにログインします

2. ドメインを選択してください

3. 「DNS」＞「レコード」に移動します

4. 「レコードを追加」をクリックします

5. 形式：TXT

6. 名前：_dmarc

7. 内容：DMARCレコードを貼り付けてください

8. TTL：自動（または 3600）

9. プロキシの状態：DNSのみ（プロキシ経由ではない）

10. 「保存」をクリックします

注：プロキシの状態を「DNSのみ」（灰色の雲のアイコン）に設定してください。オレンジ色のアイコンにはしないでください。DMARCのクエリは、Cloudflareを経由せずに、DNSに対して直接行う必要があります。

cPanel / WHM で DMARC レコードを公開する

1. cPanelアカウントにログインしてください

2. 「ゾーンエディタ」（「ドメイン」の下）に移動します

3. ドメインの横にある「管理」をクリックします

4. 「+ 新しいレコードを追加」をクリックします

5. 形式：TXT

6. 名前: _dmarc.yourdomain.com

7. 値（TXTデータ）：DMARCレコードを貼り付けてください

8. 「レコードを追加」をクリックします

NamecheapでDMARCレコードを公開する

1. Namecheapアカウントにログインしてください

2. 「ダッシュボード」＞「ドメイン一覧」に移動します

3. ドメインの横にある「管理」をクリックします

4. 「詳細DNS」に移動します

5. 「新しいレコードを追加」をクリックします

6. タイプ：TXTレコード

7. ホスト: _dmarc

8. 値：DMARCレコードを貼り付けてください

9. TTL：自動（3600）

10. チェックマークをクリックして保存します

Amazon Route 53 に DMARC レコードを公開する

1. AWS Management Console にログインし、Route 53 を開きます

2. 「ホストゾーン」に移動し、ご自身のドメインを選択してください

3. 「レコードを作成」をクリックします

4. レコード名：_dmarc

5. レコードタイプ：TXT

6. 値：DMARCレコードを二重引用符で囲んで貼り付けてください

• 例：「v=DMARC1; p=none; rua=mailto:[email protected]」
• Route 53 では引用符が必要です。引用符がないと、レコードが保存されません。

7. TTL：300（または3600）

8. 「レコードを作成」をクリックします

注：Route 53 では、TXT レコードの値を二重引用符で囲む必要があります。レコードをそのままコピー＆ペーストし、その後「…」で囲んでください。

Microsoft 365 / Azure DNS に DMARC レコードを公開する

DNSがAzure DNSで管理されている場合：

1. Azure ポータルにログイン > DNS ゾーン

2. ドメインを選択してください

3. 「+ 記録セット」をクリックします

4. 名前：_dmarc

5. 形式：TXT

6. TTL：3600

7. 値：DMARCレコードを貼り付けてください

8. 「OK」をクリックします

DNSがレジストラ（GoDaddy、Namecheapなど）にある場合：

• 上記の登録担当者の手順に従ってください

DMARCレコードの伝播にはどれくらい時間がかかりますか？

DNSの変更は、TTL（Time To Live）と呼ばれる設定によって制御されます。これは、サーバーが更新を確認する前に、DNSレコードをキャッシュしておく期間を指定するものです。ほとんどのDNSプロバイダーでは、TTLはデフォルトで3600秒（1時間）に設定されています。

一般的なタイミング：

• ほとんどの地域では、DNSの反映には1～2時間かかります
• ごくまれに、全世界への反映に最大48時間かかる場合があります
• DMARCチェッカーで最初の1時間に「レコードなし」と表示されても慌てないでください。少なくとも30～60分待ってから、もう一度試してみてください。

グローバルな伝播状況を確認する：当社のDNS伝播チェッカーを使用して、レコードが世界中の複数のDNSサーバーで有効になっていることを確認してください。

DMARCレコードが正常に機能しているかを確認する方法

方法 1：PowerDMARC DMARC チェッカーツール

1.DMARCレコードチェッカーにアクセスする

2. ドメイン名を入力してください

3. 「確認」をクリックします

4. 結果によると：

• 有効：レコードの形式が正しく、公開されています
• 無効：構文エラーです。レコードを確認してください
• レコードが見つかりません：DNSの伝播状況を確認するか、レコードがDNSに保存されているか確認してください

方法 2: コマンドライン (nslookup または dig)

Windows（コマンドプロンプト）では：

nslookup -type=TXT _dmarc.yourdomain.com

Mac/Linux（ターミナル）の場合：

dig TXT _dmarc.yourdomain.com

正常な出力：

_dmarc.yourdomain.com. 3600 IN TXT “v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected]”

結果が表示されない場合は、DNSの反映がまだ完了していないか、レコードが正しく保存されていない可能性があります。

方法 3：メールのヘッダー（Authentication-Results）を確認する

テストメールを送信し、ヘッダーを確認してください。

ステップ

1. 自分のドメインから自分自身にテストメールを送信する（または、他社の誰かにメールを送ってもらう）

2. Gmailでは：

• メールを開く
• 3つのドットのメニュー（⋮）をクリック > オリジナルを表示

• 「認証結果」を検索

3. Outlookでは：

• メールを開く
• [ファイル] > [プロパティ] > [インターネットヘッダー] をクリックします
• 「認証結果」を検索

注目すべき点：

✅DMARC 合格：

認証結果: mx.google.com;
dmarc=pass (p=REJECT sp=REJECT np=REJECT dis=NONE) header.from=yourdomain.com

❌DMARC 失敗：

認証結果: mx.google.com;
dmarc=fail (p=REJECT sp=REJECT) header.from=yourdomain.com reason=”SPFが一致しない”

「合格」の意味：FromヘッダーのドメインとSPFまたはDKIM署名が一致しており、DMARCポリシーが適用されました。

「失敗」の意味：SPF または DKIM の検証に失敗したか、設定が一致しませんでした。SPF レコードと DKIM の設定を確認してください。

最初のDMARCレポートが届く時期

集計レポートは、記録の公開から24～72時間以内に送信されます。

本報告書の内容：

• お客様のドメインから送信されたすべてのメールの日次まとめ
• 認証結果（SPFの合格／不合格、DKIMの合格／不合格、DMARCの合格／不合格）
• IPアドレスの送信およびその送信量
• 原産国
• 管財人による政策執行措置

DMARCレコードに関するRFC 9989の変更点

2026年5月、RFC 9989がRFC 7489に代わり、DMARCの公式標準となりました。既存のリソースレコードは引き続き機能します。新しいリソースレコードにおける主な変更点は以下の通りです：

3つの新しいタグが追加されました：

1. np=（存在しないサブドメインに関するポリシー）：存在しないサブドメインを保護するには、np=reject または np=quarantine を追加してください。RFC 9989 が策定される前は、攻撃者は DMARC レコードのないランダムなサブドメインを偽装することができました。現在では、親ドメインレベルでそれらに対するポリシーを設定できるようになりました。ほとんどのドメイン所有者は、これを追加すべきです。
2. t=（テストモードフラグ）：ポリシーがテストモードであることを示すには、t=y を指定します。受信側は、p=reject; t=y を p=quarantine（1段階緩い設定）として扱い、安全な段階的な展開を可能にします。従来の pct= タグに代わるものです。
3. psd=（パブリックサフィックスドメインフラグ）：ドメインがパブリックサフィックス（.gov.uk や .bank など）であるかどうかを宣言します。これは、パブリックサフィックス運営者および複雑なドメイン階層にのみ関係します。ほとんどのドメイン所有者はこれを無視して構いません。

非推奨／削除されたタグ：

• pct= は非推奨です。受信側の実装に一貫性がありませんでした。段階的な導入を行う場合は、代わりに t=y を使用してください。
• rf= および ri= は削除されました。既存のレコードにこれらが含まれている場合は、削除してください。受信側はこれらを無視します。

RFC 9989 の変更点についてさらに詳しく知りたい場合は、当社の「DMARC RFC 9989ガイド」をご覧ください。

現在適用されているコンプライアンス要件

当社の「DMARC要件完全ガイド」で、地域および世界各国の要件についてご確認ください。

よくあるDMARCレコードのエラー

1. DMARCレコードが見つかりませんでした

原因：ドメインにDMARCレコードが公開されていない、設定に誤りがある、またはDNSの伝播が完了していないためです。

対処法：DNS にレコードが存在しないことを確認したら、DNS 管理コンソールにログインして新しいレコードを登録してください。レコードが存在する場合は、既存のレコードを編集して、エラーや設定ミスを修正してください。プロパゲーション時間が 48 時間を経過していない場合は、しばらく待ってから再度確認してください。

2. 構文エラー

よくある間違い：

• セミコロンが欠落しています：各タグの後には必ずセミコロンを付ける必要があります。
• 余分なスペース：セミコロン後や「」の周囲にスペースを入れないようにしてください
• 誤ったバージョン：v=DMARC1 である必要があります。v=DMARC2 や version=1 ではありません。
• 無効なタグ名：p=reject の代わりに po=reject といったようなタイプミス

重複するDMARCレコード

原因：ドメインごとにDMARC TXTレコードは1つだけである必要があります。複数のレコードが存在する場合、受信側は最初に検出したレコードのみを読み取ります。これにより、予期しないポリシー動作が発生する可能性があります。

修正方法：同じドメイン内の重複レコードを必ず削除するか、必要に応じてレコードを統合してください。

「nslookup -type=TXT _dmarc.yourdomain.com」というコマンドを実行するか、DMARCチェックツールを使用してください。DMARCレコードが2つ以上表示された場合は、重複しているものを直ちに削除してください。

DNSレコードの名前またはタイプが間違っています

原因：DNSレコードの名前またはタイプが無効です。たとえば、DMARC用のTXTレコードの代わりにMXレコードが設定されている場合などです。

修正：

• レコードの種類：TXT（A、CNAME、MXなどではない）
• レコード名：_dmarc（DNSプロバイダーによってはドメイン名が自動的に付加される場合もあれば、_dmarc.yourdomain.comと指定する必要がある場合もあります）

よくある間違い：

• DMARCレコードをAレコードまたはCNAMEレコードとして追加する
• _dmarc.yourdomain.com ではなく、ルートドメイン（yourdomain.com）に公開する
• _dmrc や dmarc（アンダースコアが抜けている）といったタイプミス

DNSマネージャーを確認し、正確な名前とタイプを確認してください。

さらにサポートが必要ですか？ トラブルシューティング完全ガイド

SPF/DKIMの整合性エラー、サードパーティの送信者に関するエラー、または正当なメールがスパムフォルダに振り分けられるといった問題については、DMARCのトラブルシューティングガイドの全文をご覧ください。

送信を行わないドメインおよびパークされたドメインのDMARCレコード

たとえそのドメインからメールが送信されていなくても、攻撃者はそのドメインを偽装して、顧客にフィッシングメールを送信する可能性があります。使用されていないドメインやパーキングドメインは、厳格なDMARCレコードを設定して保護してください。

送信元ではないドメインに対する推奨レコード

v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s

この機能は次のことを行います：

• p=拒否; sp=拒否; np=拒否：許可されていないメールをすべて拒否する
• adkim=s; aspf=s: 厳密な整合を要求する（緩やかな一致は認めない）
• No rua=: レポートを監視していない（ドメインから送信されていない）

送信元ではないドメインが標的とされる理由

攻撃者は、類似したドメインを登録したり、ポートフォリオ内の使用されていないドメインを乗っ取ったりする可能性があります。DMARCレコードが設定されていないパーキングドメインは、なりすましの格好の標的となります。全体に p=reject を設定することで、以下の事態を防ぐことができます：

• 「company.old」または「company.test」ドメインから送信されたフィッシングメール
• 風評被害
• 発覚していない虐待（通報がなければ、それが起きたことさえわからない）

DMARCの公開後の次の手順

p=none（監視モード）での公開では保護機能は提供されず、データの収集のみが行われます。ドメインをなりすましやフィッシングから保護するには、段階的に強制適用へと移行する必要があります。

3段階のアプローチ：

1. モニタリング（p=なし）：1～2週間、DMARCレポートを確認します。すべての正当な送信者、および貴社に代わってメールを送信している第三者（SaaSツール、マーケティングプラットフォーム、チケット発行システムなど）を特定します。
2. 移行（p=隔離）：不審なトラフィックをスパムフォルダに移動します。レポートの件数を監視しながら、このフェーズを1～4週間維持してください。正当なメールが隔離されている場合は、SPFまたはDKIMの設定が必要な送信者が見つかったことを意味します。
3. 強制（p=拒否）：許可されていないメールを完全に拒否する。すべての正当な送信者が適切に処理されていることを確認した後にのみ、この状態に移行する。

複数のドメインにおけるDMARCの大規模管理

複数のドメインを管理している場合、DNSレコードを1つずつ編集するのは時間がかかり、ミスも起こりやすくなります。PowerDMARCの「HostedDMARC」ソリューションなら、所有するすべてのドメインにわたるレコード管理を自動化できます。

メリット

• 1つのダッシュボードから無制限のドメインを管理
• ポリシーの一括更新（50のドメインに対して「承認」または「却下」を一括適用）
• AIを活用した脅威インテリジェンスにより、なりすまし攻撃を検知する
• きめ細やかな導入サポートと専門家のサポート

ホスト型DMARCについて詳しく知る。

よくあるご質問

1. SPFとDKIMをすでに導入している場合、DMARCは必要ですか？

はい。SPFとDKIMは個別の認証メカニズムですが、DMARCがなければ、これらのチェックに失敗した場合に受信側がどう対応すべきかを定めたポリシーが存在しません。また、DMARCは集計レポート機能も提供しており、これがなければ、自社のドメインから誰がメールを送信しているのかを把握することができません。

2. DMARCレコードがない場合、どうなりますか？

DMARCを導入していない場合、受信サーバーは認証されていないメールについて独自に判断を行うため、ドメインはなりすましやフィッシングの被害を受けやすくなります。多くのメール配信事業者（ESP）は、大量送信者に対してDMARCの導入を義務付けており、これを導入していないと配信率に深刻な悪影響を及ぼす可能性があります。

3. DMARCはサブドメインにも自動的に適用されますか？

サブドメインは、上書きされない限り、親ドメインのDMARCポリシーを継承します。既存のサブドメインに対して異なるポリシーを設定するには`sp=`タグを使用し、存在しないサブドメインのポリシーを設定するには`np=`タグ（RFC 9989で新たに導入）を使用します。`p=quarantine`を維持したまま`sp=reject`を設定することは、サブドメインの保護を強化するための一般的な手法です。

4. PCI DSS v4.0への準拠には、DMARCが必要ですか？

2025年に全面的に施行されたPCI DSS v4.0では、決済カードデータを処理する組織に対して、フィッシング対策が義務付けられています。DMARCはコンプライアンスの要件として明示的に求められてはいませんが、これを導入することで要件を満たすのに役立ちます。