DMARCの設定方法：完全なステップバイステップ設定ガイド（2026年版）

メールプロバイダーは、もはやDMARCの設定を「あれば望ましい」程度のセキュリティ対策とは見なしていません。Gmail、Yahoo、Microsoftがより厳格な認証要件を適用していることから、DMARCを導入していない組織は、メッセージが恒久的に拒否されたり、なりすまし攻撃が増加したり、コンプライアンス上の課題に直面したりするリスクがあります。

このガイドでは、DMARCをゼロから設定する方法、SPFおよびDKIMの設定を検証する方法、準拠したDMARCレコードを公開する方法、そして監視モードから完全適用モードへと段階的に移行する方法について解説します。また、最新のRFC 9989の更新内容、よくある設定ミス、そしてDMARCを安心して導入するための実践的なトラブルシューティングのヒントについても取り上げます。

このDMARC設定ガイドを読み終える頃には、正当なメールが引き続き受信トレイに届くようにしつつ、なりすまし攻撃からドメインを保護するための明確な道筋がわかるようになるでしょう。

2026年のコンプライアンス：施行が開始されました

Gmail および Yahoo（2025年11月）：大量送信者（1日あたり5,000通以上）を対象に、5xxエラーによる恒久的な受信拒否措置が適用されました。規定に準拠していないメッセージは、単にフィルタリングされるだけでなく、恒久的に受信拒否されます。

Microsoft Outlook（2025年5月）：SPF、DKIM、およびDMARCの適用が有効になっています。これらに準拠していないメールは、配信遅延または拒否の対象となります。

PCI DSS v4.0（2025年3月）：決済カードデータを扱うすべての事業体に対し、フィッシング対策が義務付けられます。

• CISA BOD 18-01：米国のすべての連邦機関は、p=reject ポリシーを設定した DMARC を導入しなければならない。
• 要件の詳細はこちらをご覧ください：グローバルおよび地域別のDMARC要件

DMARCとは何か、その仕組みは？

DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、ドメイン所有者が、SPFおよびDKIMの認証チェックに失敗したメッセージに対して、受信メールサーバーにどのような処理を行うべきかを指示できる電子メール認証プロトコルです。簡単に言えば、他者によるドメインのなりすましを防止し、受信者に対してなりすましメールの処理方法を指示するものです。

DMARCは、SPFとDKIMという2つの既存プロトコルを基盤として機能します。これら3つが一体となって、現代の電子メールセキュリティの基盤を形成しています。

DMARC、SPF、DKIM：これらがどのように連携するか

SPF（Sender Policy Framework）は、どのメールサーバーがあなたのドメインからメールを送信することを許可されるかを指定するものです。これは、「example.comを差出人とするメールを送信できるのは、これらのIPアドレスのみである」と指定するDNSレコードです。

DKIM（DomainKeys Identified Mail）は、メールに暗号署名を付与する仕組みです。これにより、そのメッセージが送信者本人から送信されたものであり、送信中に改ざんされていないことが証明されます。この署名は、DNSに登録された公開鍵を用いて検証されます。

DMARCはこれらを結びつけます。その内容は次の通りです。「これが私のポリシーです。私のドメインから送信されたと主張するメールは、SPFまたはDKIMの整合性チェックに合格しなければなりません。もし不合格となった場合、以下のいずれかの対応をしてください：なし（監視のみ）、隔離（スパムフォルダへ移動）、または拒否（完全にブロック）」。

当社の包括的なガイドで、DMARC、SPF、DKIMについて詳しくご覧ください。

メールがDMARCの検証に失敗するとどうなるのか？

受信者が、あなたのドメインから送信されたと主張するメールを受け取った場合、そのメールをあなたのDMARCポリシーと照合します。その結果は、あなたのポリシーによって異なります：

• p=none（監視）：結果にかかわらず、メールが配信されます。合格した項目と不合格だった項目が記載されたレポートが送信されます。
• p=quarantine：不審なメールはスパム／迷惑メールフォルダに振り分けられます。正当なメールは通常通り受信されます。
• p=reject：配信に失敗したメールは即座に拒否されます。送信者にはバウンスメッセージが送信されます。

DMARCの設定を行う前に：前提条件と送信元の一覧

多くの組織がDMARCの導入を急ぎ、すぐに「p=reject」設定に移行してしまうものの、その結果、正当な送信元（CRM、ESP、ヘルプデスク、マーケティングオートメーションプラットフォームなど）がブロックされてしまうことに気づくケースが少なくありません。このセクションでは、そのようなコストのかかるミスを防ぐための監査プロセスを順を追って解説します。

手順 1：ドメインに対して SPF が公開されていることを確認する

DMARCが機能するには、ドメインのDNSに有効なSPFレコードが設定されている必要があります。

1. 当社のSPFチェッカーを使用して、SPFレコードが存在することを確認してください。

2. ドメインに対してSPF TXTレコードが正確に1つだけ存在することを確認してください。SPFレコードが2つあると、受信側が両方を無視してしまうため、SPFが機能しなくなります。

3. レコードは、次のような形式になるはずです：v=spf1 include:sendgrid.net include:mailchimp.com ~all

SPFレコードが公開されていない場合や、矛盾するレコードが2つある場合は、先にこの問題を解決してから次の手順に進んでください。今すぐ当社の無料ツールを使ってSPFレコードを作成してください。

ステップ 2：SPF 10 の検索制限を確認する

SPFでは、メッセージの評価ごとに最大10回のDNSルックアップが許可されています。許可したサードパーティの送信者（`include:` を通じて）1件につき、このルックアップのうち1～3回が消費されます。この制限を超えると、一部の送信者に対してSPF検証に失敗することになります。

1. 当社のSPFチェッカーを使用して、SPFレコードの照会回数を確認してください

2. 必要なDNSルックアップの回数を数えてください。10回に近づいたり、10回を超えたりすると、エラーが表示されます。

3. 制限を超えている場合は、レコードを最適化して、`include:` ステートメントを明示的な IP アドレスに置き換えることで、ルックアップを統合してください。これは、多数のサードパーティ送信者を抱える大規模組織において、よく見られる障害要因です。

ステップ 3：すべての送信者に対して DKIM が設定されていることを確認する

Google、Yahoo、Microsoftでは、大量送信者に対してDKIMが必須とされており、任意ではありません。

1. メインドメインについては、当社の無料DKIMチェッカーを使用して、DKIMレコードが公開されていることを確認してください。

2. 各サードパーティの送信元（Salesforce、HubSpot、Klaviyoなど）について、DKIM署名が有効化されており、公開鍵がDNSレコードとして公開されていることを確認してください。これには通常、ベンダーに対して「お客様のドメイン向けにカスタムDKIMを有効にしてください」と依頼する必要があります。

3. 各送信者には、一意のDKIMセレクタ（例：k1._domainkey.example.com、sendgrid._domainkey.example.com）が割り当てられている必要があります。

DKIMが設定されていない場合は、DMARCの強制適用に移行する前に、今すぐ設定を行ってください。当社の無料ツールを使用して、お客様のドメイン用のDKIMレコードを生成してください。

ステップ4：すべてのサードパーティのメール送信元を一覧化する

ご自身のドメインからメールを送信するすべてのサービスのリストを作成してください：

• ESP（SendGrid、Mailchimp、Klaviyoなど）
• CRM（Salesforce、HubSpot、Pipedriveなど）
• ヘルプデスク／サポートシステム（Zendesk、Freshdeskなど）
• マーケティングオートメーション（Marketo、Pardot、ActiveCampaignなど）
• トランザクションメールプラットフォーム（Auth0、Stripe、AWS SESなど）
• 通知を送信する社内サーバーまたはアプリケーション
• 転送サービスまたはメーリングリスト管理者

各送信者について、以下を確認してください：

1. それらはSPFアラインメント（SPFレコードに含まれる）に合格しています
2. これらはDKIMの整合性チェックに合格しています（お客様のドメインでDKIM署名が有効になっています）
3. これらは、「From:」ヘッダーにあなたのドメインを使用するように設定されています

当社のDMARCレポートアナライザーを使用して、不正な送信者をスキャンしてください。

ステップ 5: DMARC レコードがすでに存在するかどうかを確認する

当社のDMARCチェッカーを使用して、お客様のドメインにすでにDMARCレコードが設定されているかどうかを確認してください。

• 「p=none」と表示されている場合：ドメインは監視モードになっています。このガイドを参照すれば、安全に強制モードへ移行できます。
• 非推奨のタグ（pct=、rf=、ri=）が見つかった場合：これらはRFC 9989規格から除外されたため、次回レコードを編集する際に削除してください。
• 該当する記録が見つからない場合：一から始めます。次のセクションに進んでください。

DMARCの設定方法：ステップバイステップ

ステップ 1: DMARC レコードを生成する

当社のDMARCジェネレーターツールを使用して、初期レコードを作成してください。

必須項目：

• ドメイン：ご自身のドメイン（例：example.com）
• ポリシー：初期値は p=none（監視モード、強制なし）
• レポートの受信先：集計レポートの受信を希望するメールアドレス（例：[email protected]）

おすすめの追加アイテム：

• np=reject:存在しないサブドメインをなりすましから保護する（RFC 9989で新たに規定、コストゼロ）
• ruaアドレス：集計レポートの送信先（監視に不可欠）

レコードの先頭例：

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

このレコードは受信側に、「私のドメインからのメールを監視し、毎日レポートを送ってほしいが、現時点では何もブロックしないでほしい」と伝えます。

ステップ 2：公開前に DMARC レコードの内容を確認する

DMARCレコードは、セミコロンで区切られたタグと値のペアの列です。必須なのは v= と p= のみです。それ以外はすべてオプションですが、指定することをお勧めします。公開する前に、各タグの役割を理解しておきましょう：

必要なタグ

タグ	概要とルール
v=(バージョン)	• 価値がある。 いつも v=DMARC1 • レコード内の最初のタグでなければならない • 有効な値は1つだけです
p=（ポリシー）	• 価値観： none, quarantine、または reject • DMARCチェックに失敗したメールの処理方法を受信者に通知する • 違いについては、以下のポリシー表をご覧ください

任意のタグ

np=（サブドメインポリシーが存在しない）

• 値：なし、隔離、または拒否
• DMARCレコードがないサブドメインにポリシーを適用します
• ランダムなサブドメイン（例：random123.example.com）によるなりすましを防止します
• 推奨事項：すべてのドメインについて、np=reject に設定してください。コストはかからず、なりすましの抜け穴を塞ぐことができます。

rua=（集計レポート用の報告先住所）

• フォーマット：rua=mailto:[email protected]
• カンマで区切って複数のアドレスを指定できます：rua=mailto:[email protected],mailto:[email protected]
• 集計レポートとは、受信者から毎日送信されるXML形式の要約です。
• これは監視において極めて重要です。これがなければ、メールの流通状況を把握することができません。

sp=（サブドメインポリシー）

• 値：なし、隔離、または拒否
• DMARCレコードが設定されているサブドメインにポリシーを適用します
• 指定がない場合は、メインポリシー（p=）が適用されます。
• サブドメイン（例：mail.example.com）に対してより厳格な適用を行いたい場合に使用してください。

fo=（障害報告オプション）

• 値：0（デフォルト）、1、d、s、またはそれらの組み合わせ（0:1:d:s）
• フォレンジック（障害）レポートの送信タイミングを制御します
• fo=0: すべての認証メカニズムが失敗した場合にのみレポートを生成する
• fo=1: 認証メカニズムのいずれかが失敗した場合にレポートを生成する（詳細な出力が得られ、セットアップ段階に有用）
• 通常は ruf= タグと組み合わせて使用されます（後述）。
• 推奨事項：初期設定時には、すべての不具合を検出するために fo=1 を使用してください。アライメントに問題がないと確信できたら、fo=0 に切り替えてください。

adkim= (DKIM アライメントモード)

• 値：r（緩やか、デフォルト）または s（厳格）
• 緩和条件：ドメインおよびDKIM署名対象ドメインが同一の組織ドメインである場合（例：mail.example.com と example.com が一致する場合）
• 厳格：ドメインは完全に一致する必要があります
• 推奨事項：最初は adkim=r（緩和）から始めてください。すべての署名元を管理できるようになってから、strict に移行してください。

aspf=（SPFアライメントモード）

• 値：r（緩やか、デフォルト）または s（厳格）
• 「Relaxed」：ドメインおよびSPFのReturn-Pathドメインが、同じ組織ドメインを共有している場合
• 厳格：ドメインは完全に一致する必要があります
• 推奨事項：まずは aspf=r から始めてください。すべての送信元を管理できるようになってから、strict に移行してください。

t=（テストモード）

• 値：y（テストモードオン）または省略（テストモードオフ）
• t=y に設定すると、受信側に対して、そのポリシーを1レベル下で適用するよう指示します
• p=隔離；t=yの場合、受信者にとってはp=なしと同様に振る舞う
• p=reject; t=y は、受信者にとっては p=quarantine と同様に振る舞う
• これは、非推奨となった pct= タグの代替です。
• より厳格なポリシーに移行する際に使用します：t=y を指定して公開し、レポートを監視した後、t=y を削除してポリシーを適用します

ruf=（鑑識報告書の送付先住所）

• フォーマット：ruf=mailto:[email protected]
• 認証に失敗したメッセージのコピーをリアルタイムで送信します
• 重要な注意：Google、Microsoft、Yahooは、RFC 9989に基づき、フォレンジックレポートの送信を停止しています。このタグを含めても問題はありませんが、主要な受信者からはレポートが生成されません。
• フォレンジックレポートを処理する自動化システムをお持ちの場合にのみ、これを含めてください

非推奨および削除されたタグ (RFC 9989)

これらのタグはRFC 7489に含まれていましたが、現在は標準仕様から除外されています。新しいレコードにはこれらを追加しないでください。既存のレコードにこれらのタグが含まれている場合は、次回のDNS編集時に削除してください。

pct=

• 失敗したメッセージの一定割合に対してポリシーを適用するために使用されていました
• 受信機ごとに結果にばらつきが見られた
• 代替案：段階的な導入には、代わりに t=y を使用してください
• もし古いレコードに残っている場合は、RFC 9989に準拠した受信側によって無視されます

rf=

• 障害報告のフォーマットタグ（使用された値は「afrf」のみでした）
• 現代のレポート機能では異なる仕組みが採用されているため、削除しました

ri=

• レポート間隔タグは
• 報告間隔が標準化されたため、削除されました

ステップ 2：DNS プロバイダーにログインする

DNS管理コンソール（GoDaddy、Cloudflare、Namecheap、cPanel、Route 53など）にログインしてください。

ステップ 3：DNS プロバイダーで DMARC レコードを追加する

新しいTXTレコードを追加するオプションを見つけ、ツールから値をコピーして貼り付け、保存アイコンをクリックしてください。

手順はすべてのプロバイダーで同じです。新しいTXTレコードを追加し、名前を「_dmarc」に設定し、値としてレコードを貼り付けて、保存します。プロバイダーごとの操作手順と、それぞれで最もよくある注意点については、以下の表をご覧ください。

プロバイダー	DNS設定の場所	備考	セットアップ完全ガイド
ゴーダディ	マイプロダクト → DNS → 新しいレコードを追加	一部のアカウントでは、ホスト欄に「.yourdomain.com」が自動的に追加されます。入力する際は「_dmarc」のみとし、「_dmarc.yourdomain.com」と入力しないでください。	GoDaddy DMARC 設定ガイド
クラウドフレア	ダッシュボード → ご自身のドメイン → DNS → レコードの追加	プロキシの状態を「DNSのみ」（灰色の雲）に設定してください。オレンジ色（プロキシ経由）に設定すると、DMARCの照会が機能しなくなります。	Cloudflare DMARC 設定ガイド
Namecheap	ダッシュボード → ドメイン一覧 → 管理 → 詳細DNS設定	ホストフィールドには「_dmarc」のみ指定可能です。TTLは「自動」のままにしておいてください。	Namecheap DMARC 設定ガイド
cPanel / WHM	ゾーンエディタ → 管理 → + TXTレコード	完全なホスト名を入力してください：_dmarc.yourdomain.com（cPanelではドメイン名が自動的に付加されません）。	cPanel DMARC 設定ガイド
Amazon Route 53	ホストゾーン → ご自身のドメイン → レコードの作成 → TXT	レコードの値を二重引用符で囲んでください：「v=DMARC1; p=none; ...」。引用符がない場合、Route 53 はそのレコードを拒否します。	Amazon DNSレコードガイド

ステップ 5: DNS の伝播を待つ

DNSの変更が全世界に反映されるまで最大48時間かかる場合がありますが、ほとんどのDNSプロバイダーでは1～2時間以内に反映されます。反映状況をリアルタイムで確認するには、当社の「DNSプロパゲーションチェッカー」をご利用ください。ドメイン名を入力し、_dmarc TXTレコードを確認してください。

ステップ 6：DMARC の設定が有効になっていることを確認する

DNSの伝播が完了したら、当社のDMARCチェッカーツールを使用してレコードを確認してください。

1. ドメイン名を入力してください
2. 「検索」をクリック
3. すべてのタグが解析された状態で、自分の記録が表示されるはずです
4. チェッカーがポリシーに対して「DMARCレコードが見つかりました」と表示された場合、設定は有効になっています

エラーが表示された場合、または48時間経過してもレコードが見つからない場合は、DNSエントリの構文や設定に誤りがないか確認してください。

RFC 9989に基づくDMARCの設定 – 2026年に何が変わったか

2026年5月、IETFはRFC 9989を公開し、RFC 7489に代わって公式のDMARC標準として採用しました。既存のv=DMARC1レコードは引き続き完全に有効であるため、緊急の移行は必要ありません。ただし、現在DMARCを設定しているすべての方には、3つの変更点が影響します。

RFC 9989がDMARCの設定に与える影響

1. pct= は現在、非推奨となっています

pct=タグは、失敗したメッセージの一部にポリシーを適用するために使用されていました。このタグは受信者間で結果にばらつきが生じるため、現在は標準仕様から除外されています。

対応：新規レコードから「pct=」を削除してください。既存のレコードに「pct=」が含まれている場合は、次回のDNS編集時に削除してください。受信側では無視されますが、混乱を招く恐れがあります。

2. np= は新規です

「np=」タグ（存在しないサブドメインポリシー）を使用すると、存在しないサブドメインを保護することができます。攻撃者は、DMARCチェックを回避するために、ランダムなサブドメイン（例：random123.example.com）を偽装することがあります。「np=reject」を設定することで、コストをかけずにこの脆弱性を解消できます。

操作：これは任意ですが、すべての新規レコードに追加することもできます。

3. t=y は、政策変更を段階的に実施するための新しい手法である

「t=y」タグは、受信側に対して、宣言されたレベルより1つ下のレベルでポリシーを適用するよう指示します。これにより、実際に適用する前に、より厳格なポリシーをテストすることができます。

• p=隔離； t=y の場合、p=なしと同様に振る舞う（受信側は隔離を行わず、配信と報告を行う）
• p=reject; t=y は p=quarantine と同様に動作する（受信側は拒否する代わりに隔離する）

アクション：p=none から p=quarantine または p=reject へ移行する際は、まず t=y を設定してください。1～2週間、レポートを監視してください。問題がないと確信できたら、t=y を解除して適用してください。

段階的な導入における「t=y」の使い方

具体的なワークフローは以下の通りです：

1. 現状：

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

2. 検疫機能のテスト準備が整ったら、公開してください：

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

受信側はこれを「p=none」として扱い、すべてのデータを配信して報告します。1～2週間、状況を観察してください。

3. 正常なメールに影響が出ていないことを確認したら、t=y を削除して適用します：

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

4. 現在、誤ってスパムとして分類されるメールはスパムフォルダに振り分けられますが、正常なメールには影響がありません。

5. リジェクトポリシーのテスト準備が整ったら、公開してください：

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

6. 受入先はこれを「p＝隔離」として扱います。1～2週間の経過観察が必要です。

7. 最終的な適用：t=y を削除する：

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

8. 完全拒否機能が有効になりました。

いずれかの段階で問題が発生した場合は、t=y を削除し、ポリシーレベルを1つ下げて、問題のある送信者を修正してから、処理を再開してください。

DMARCポリシーを安全に強化する方法

DMARCの失敗の多くは、組織がメールの流れを事前に確認せずに、いきなり p=reject に設定してしまうことが原因です。その結果、正当なメールがブロックされ、ユーザーから苦情が寄せられ、ドメイン所有者は慌てて設定を元に戻すことになります。このセクションでは、正しいアプローチ、つまり、各ステップの前に集計レポートを活用して信頼性を高めていく3段階の導入手順について解説します。

注：RFC 9989 では、間接的なメールフロー（転送、メーリングリストなど）の場合、受信側は p=reject を p=quarantine として扱う必要があると明示されています。ユーザーがメーリングリストに参加しているドメインについては、p=quarantine の方がより安全な恒久的な適用ポリシーとなります。一方、ユーザーのメールボックスを持たない、純粋なトランザクション用またはマーケティング専用のドメインについては、p=reject が適切です。

フェーズ1：モニタリング（p=なし）

所要期間：最低2～4週間。送信環境が複雑な場合（サードパーティの送信元が10以上ある場合など）は、さらに長くなります。

記録は次のようなものです：

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

何をすべきか：

1. 上記の記録を公開する

2. 受信者から集計レポートが送信されるのを待ちます（通常、24～48時間以内に送信が開始されます）。

3. 当社のDMARCレポートアナライザーを使用して、日次レポートを確認する

4. 以下の点を確認してください：

• レポートに記載されているすべての既知の送信元
• 送信者ごとのSPFおよびDKIMの通過率
• 見覚えのない差出人からのメール
• アライメントの状態（送信者はアライメントに合格していますか、それとも不合格ですか？）

いつ前進すべきか：

• 正当な送信元はすべて、SPF または DKIM の検証に合格しています
• 報告書には不明な情報源が含まれていない
• 少なくとも2週間分の一貫したデータを収集しました
• 送信に問題があった送信元はすべて修正しました

DMARCレポートについて初めての方は、DMARCレポートの読み方に関するガイドを参照して、わかりやすい手順をご確認ください。

フェーズ2：隔離（p=隔離）

期間：t=y（テストモード）で1～2週間、その後継続。

手順 A：t=y でテストする（試運転）

公開：

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

t=y の場合、受信側はポリシーを1段階下で適用します。つまり、隔離処理は「なし」と同様に動作します。配信に失敗したメールも引き続き配信されますが、本来なら隔離されていたはずのメールに関するレポートが表示されるだけです。

1～2週間、状況を観察してください。レポートを確認し、受信トレイをチェックしてください。以下の点に注意してください：

• 正当なメールがまだ届いている
• どの送信者が影響を受けるかを示した障害報告
• 通常のスパム通報率

手順 B: 適用（t=y を削除）

自信がついたら、t=y を削除してください：

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

現在、受信に失敗したメールはスパムフォルダに振り分けられています。正常なメールは引き続き通常通り届いています。

継続的なモニタリング：

• 集計レポートを毎週確認する
• スパムフォルダを監視して、正当なメールを見逃さないようにする
• 正当な送信元でエラーが発生し始めた場合は、直ちに p=none に戻し、アライメントの問題を修正してから、再度進行させる。

BIMI の適用要件に関する注意事項：Gmail でロゴを表示するために BIMI（Brand Indicators for Message Identification）を使用する場合は、p=quarantine または p=reject を設定している必要があります。p=none は適用対象外です。このため、ポリシーの策定を早急に進める必要があります。ドメインでBIMI を有効にする方法はこちらをご覧ください。

フェーズ3：却下（p=却下）

期間：t=yの時点で1～2週間、その後は継続。

手順 A：t=y でテストする（試運転）

公開：

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

t=y の場合、受信側は「reject」を「隔離」として扱います。配信に失敗したメールはスパムフォルダに振り分けられ、即座に拒否されることはありません。1～2週間ほど状況を監視してください。

手順 B: 適用（t=y を削除）

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

現在、配信に失敗したメールは即座に拒否されます。送信者にはバウンス通知が送信されます。

政策提言：

• ドメイン内に、メーリングリスト（NAR、MLS、協会リストなど）に登録されているユーザーが利用する個人用メールボックスがある場合は、適用ポリシーとして「p=quarantine」を設定してください。
• ドメインがトランザクション専用（SaaS、決済、フィンテック、ユーザーのメールボックスを持たないマーケティングメールなど）の場合は、p=reject を指定してください。

DMARC設定のトラブルシューティング：よくある問題と解決策

問題 1：チェック時に「DMARC レコードが見つかりません」と表示される

原因：DNSの反映がまだ完了していないか、ホスト名を間違って入力したためです。

どうすればいいのか：

1. 公開後、24～72時間お待ちください
2. ホスト名が正確に「_dmarc」であることを再確認してください（一部のツールでは「_dmarc.yourdomain.com」となっている場合がありますので、ご利用のプロバイダーの仕様をご確認ください）。
3. 当社のDNSプロパゲーションチェッカーを使用して、プロパゲーションの状態を確認してください
4. DMARCチェッカーをもう一度お試しください

問題 2：SPF と DKIM の不一致

原因：From: ヘッダーに記載されているドメインが、SPF または DKIM によって認証されたドメインと一致しません。

失敗例：

• From: ヘッダーには「[email protected]」と記載されています
• SPF認証済みドメインは mail.otherdomain.com です
• DKIM署名ドメインは newsletter.anotherdomain.com です
• 結果：整合性がありません。DMARCの検証に失敗しました。

どうすればいいのか：

1. レコードでは、まず「relaxed alignment」（adkim=r; aspf=r）を設定してください。これにより、サブドメインの一致が可能になります。

2. 当社のDKIMチェッカーを使用して、各送信者の署名ドメインを確認してください

3. 当社のSPFチェッカーを使用して、各送信者のSPF登録状況を確認してください

4. 送信に失敗した送信者ごとに、ベンダーにドメインの設定を依頼してください。例：

• 「example.com（サブドメインではありません）のドメインに対して、DKIM署名を有効にしてください」
• 「Return-Path/envelope-from ドメインには example.com を使用してください」

5. すべての送信者が「relaxed」アライメントで合格したら、必要に応じて「strict」（adkim=s; aspf=s）に移行できます。

問題 3：サードパーティの送信者による認証の失敗

原因：ESP、CRM、またはマーケティングプラットフォームが、お客様のドメインからメールを送信しているにもかかわらず、SPFレコードに設定されていない、および／またはDKIMが有効になっていないためです。

どうすればいいのか：

SPFの失敗については：

1. 送信者のドキュメントからSPFのインクルード情報を確認する（例：include:sendgrid.net）

2. SPFレコードに以下を追加してください：v=spf1 include:sendgrid.net include:mailchimp.com ~all

3. 当社のSPFチェッカーでテストする

DKIMの失敗については：

1. ベンダーに、ご自身のドメインでカスタムDKIMを有効にするよう依頼してください

2. 提供されたDKIM公開鍵を公開します（通常、形式は selector._domainkey.yourdomain.com です）。

3. 当社のDKIMチェッカーでテストする

問題 4：複数の SPF レコード、または SPF のルックアップ制限（10 回）を超えている

1. SPFレコードが複数ある場合：同じドメインに2つのSPF TXTレコードが存在すると、SPFは完全に機能しなくなり、受信側は両方のレコードを無視します。

解決方法：ドメインごとにSPF TXTレコードは1つしか設定できないため、SPFレコードを1つに統合してください。

例

• 古いレコード 1: v=spf1 include:sendgrid.net ~all
• 古いレコード 2: v=spf1 include:mailchimp.com ~all
• 新しい結合レコード：v=spf1 include:sendgrid.net include:mailchimp.com ~all

2. DNS 照会が 10 回を超える場合：各「include:」には 1～3 回の DNS 照会が必要になる場合があります。10 回を超えると、一部の送信者に対して SPF 検証に失敗します。

解決方法：当社のホスト型SPFを利用して、レコードを動的に最適化してください。これにより、`include:` ステートメントが具体的なIPアドレスに置き換えられ、ルックアップ回数が削減されます。

例

• 変更前（10回以上の検索）：v=spf1 include:sendgrid.net include:mailchimp.com include:klaviyo.com include:hubspot.com ~all
• 最適化後：v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 ip4:9.10.11.12 ~all

問題 5：p=quarantine 実行後に正当なメールがスパムフォルダに振り分けられる

原因：すべての正当な送信者が認証を通過したことを確認する前に、p=quarantine に進んでしまったためです。

どうすればいいのか：

1. 直ちに p=none に戻す
2. 集計レポートを確認し、どの送信者に問題があるかを特定してください
3. 認証設定を修正する（SPFまたはDKIMの整合性）
4. p=quarantine に再設定するが、t=y でテストを行い、適用する前に 1～2 週間監視する

問題 6：DMARC レコードの構文エラー

原因：レコード内の入力ミス、セミコロンが欠落している、またはサポートされていないタグ

どうすればいいのか：

1. 当社のDMARCチェッカーで検証してください。構文エラーが表示されるはずです。
2. 手動で編集するのではなく、当社のDMARCジェネレーターを使用してレコードを再作成してください
3. 生成されたレコードをコピーし、DNSプロバイダーに貼り付けてください

まとめ

DMARCを正しく設定することは、もはや任意の措置ではありません。Gmailによる恒久的な受信拒否措置、YahooおよびMicrosoftの要件、PCI DSS v4.0の推奨事項、そしてCISA BOD 18-01など、これらすべてがDMARCをコンプライアンス上の必須要件としています。

安全で確実な方法は、ゆっくりと進め、継続的に検証し、責任を持って適用することです。しかし、レポート処理の自動化、コンプライアンスの監視、継続的なサポートにより、より迅速かつ容易なDMARC管理を実現したい場合は、PowerDMARCのようなホスト型DMARCプラットフォームをご検討ください。このプラットフォームでは、セットアップ、スケーリング、適用を代行するため、お客様はセキュリティ対策に専念できます。今すぐ無料トライアルを開始するか、デモを予約して、ドメインのセキュリティを確保しましょう。

よくあるご質問

DMARCの設定にはどれくらい時間がかかりますか？

DNSレコードの初期設定には数分しかかかりません。DNSの反映には最大72時間かかります（通常は1～2時間）。完全な適用（p=rejectを確実に達成する状態）には、送信元の数や整合性の問題が解決される速さにもよりますが、通常4～8週間かかります。

DMARCの設定は、メールの配信率に影響を与えますか？

p=none の場合、モニタリングモードでは強制措置が行われないため、配信率への影響はゼロです。p=quarantine または p=reject の場合、影響を受けるのは認証されていないメールや設定が不適切なメールのみです。適切に認証されたメールは影響を受けず、多くの場合、配信率が向上します。DMARC は、受信プロバイダーに対してドメインの評判を確立することで、長期的に受信トレイへの到達率を向上させることができます。

複数のドメインに対してDMARCを設定するにはどうすればよいですか？

複数のドメインに対してDMARCを設定する際は、各ドメインごとに_dmarc.[domain]に独自のDMARC TXTレコードを設定する必要があることに注意してください。

例

• ドメイン 1: _dmarc.example.com の TXT レコード
• ドメイン 2: _dmarc.example.org の TXT レコード

多数のドメインを管理する組織にとって、ホスト型DMARCプラットフォームなら、1つのダッシュボードからすべてのレコードを管理できるため、スケールアップが容易になります。

DMARCアライメントとは？

「アライメント」とは、「From:」ヘッダーのドメインが、SPF または DKIM によって認証されたドメインと一致しなければならないことを意味します。緩和されたアライメント（デフォルト設定：adkim=r; aspf=r）では、組織のドメインとの一致が許容されますが、厳格なアライメント（adkim=s; aspf=s）では、完全な一致が求められます。