DMARCの設定手順とSPF・DKIM連携によるメールセキュリティ強化のイメージ画像

DMARC設定ガイド 2026年版

DMARC設定でなりすましを防ぎ信頼を守る


著者: Maitham Al Lawati
翻訳: 東條 百々朱

この記事はPowerDMARCのブログ記事 How to Setup DMARC: Complete Step-by-Step Configuration Guide (2026) の翻訳です。
Spelldataは、PowerDMARCの国内正規代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。

主なポイント

  1. DMARCを設定すると、SPFとDKIMによる認証結果を活用し、ドメインのなりすましやフィッシング攻撃への対策を強化できます。
  2. DMARCを導入する前に、SPFとDKIMの設定を確認し、自社ドメインを使用してメールを送信するすべてのサービスを把握することが重要です。
  3. DMARCはp=noneから開始し、認証レポートを確認しながら、段階的にp=quarantineやp=rejectへ移行する方法が推奨されます。
  4. 2026年5月に公開されたRFC 9989では、存在しないサブドメインに適用するnp=や、ポリシーのテスト運用に使用するt=などが規定されています。
  5. DMARCレコードの初期設定は短時間で完了しますが、適切な強制適用ポリシーへの移行には、数週間以上のモニタリングや送信元の設定確認が必要になる場合があります。
  6. 適切なDMARC設定は、メールセキュリティの強化、関連する要件への対応、正規メールの配信を妨げないなりすまし対策に役立ちます。

メール認証は、現在のメールセキュリティにおいて欠かせない対策の一つです。
Gmail、Yahoo、Microsoftなどの主要なメールプロバイダが送信者に対する認証要件を強化する中、DMARCを適切に設定する重要性が高まっています。
メール認証の要件を満たしていない場合、メールが拒否されたり、迷惑メールとして判定されたりする可能性があります。

また、自社ドメインのなりすまし対策が不十分な状態では、フィッシング攻撃に悪用されるリスクも高まります。
本記事では、DMARCを初めて設定する方に向けて、SPFとDKIMの確認方法、DMARCレコードの作成と公開方法、ポリシーを段階的に強化する手順を解説します。

さらに、RFC 9989で追加・変更された内容や、よくある設定ミス、トラブルシューティングについても紹介します。
正規のメール配信への影響を抑えながら、DMARCを安全に導入するための参考にしてください。

2026年のメール認証要件とDMARCの重要性

主要なメールプロバイダやセキュリティ基準では、メール認証に関する要件が強化されています。

GmailとYahoo
大量メール送信者に対して、SPF、DKIM、DMARCなどのメール認証要件が設けられています。
要件を満たしていないメールは、配信が制限されたり、拒否されたりする可能性があります。
なお、大量送信者の判定条件や適用される要件は、各プロバイダの規定に従います。
Microsoft Outlook
Microsoftも大量メール送信者に対する認証要件を強化しています。
要件を満たしていないメールは、配信が拒否されるなどの影響を受ける可能性があります。
PCI DSS v4.0
決済カード情報を取り扱う組織には、適用範囲に応じたセキュリティ対策が求められます。
フィッシングへの対策も重要ですが、PCI DSSがすべての対象組織にDMARCの導入を一律に義務付けているわけではありません。
CISA BOD 18-01
米国の対象となる連邦政府機関に対し、DMARCを含むメールセキュリティ対策を求める指令です。
対象機関には、DMARCの拒否ポリシーを適用する要件が含まれています。
各組織に適用される要件は、業種、送信量、利用するメールサービスなどによって異なります。
詳しくは、「DMARC要件とは？世界各地の規制・送信者ルール・技術要件」を参照してください。

DMARCとは？仕組みと役割

DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、SPFとDKIMの認証結果を利用し、メールの送信元ドメインが正しく使用されているかを確認する仕組みです。
ドメイン所有者は、DMARCポリシーをDNSに公開することで、認証に失敗したメールの取り扱いについて、受信側に方針を示すことができます。

また、DMARCレポートを受信することで、自社ドメインを使用したメールの送信状況や認証結果を把握できます。
DMARCは、SPFとDKIMを組み合わせて機能します。
この3つは、メールのなりすまし対策を支える重要な認証技術です。

DMARC、SPF、DKIMが連携する仕組み

SPF（Sender Policy Framework）
SPFは、特定のドメインについて、メール送信を許可するサーバをDNSレコードで指定する仕組みです。
受信側は、メールを送信してきたIPアドレスが、SPFで許可されているかを確認します。
DKIM（DomainKeys Identified Mail）
DKIMは、メールに電子署名を付与する仕組みです。
受信側は、DNSに公開された公開鍵を使用して署名を検証します。
これにより、署名に使用されたドメインを確認し、署名対象のメール内容が送信後に改竄されていないかを検証できます。
DMARC
DMARCは、SPFまたはDKIMの認証結果と、メールのFrom:ヘッダーに記載されたドメインとの一致を確認します。
この一致を「アライメント」と呼びます。
原則として、SPFまたはDKIMのいずれかが認証に成功し、アライメントも成立していれば、DMARC認証に合格します。
DMARCに失敗した場合の取り扱いは、ドメイン所有者が公開したポリシーを参考に、受信側が判断します。

DMARC認証に失敗するとどうなる？

DMARC認証に失敗したメールの取り扱いは、公開されているポリシーによって異なります。

p=none
DMARCによる隔離や拒否を要求せず、認証状況をモニタリングします。
p=quarantine
認証に失敗したメールを迷惑メールとして扱うよう受信側に要求します。
p=reject
認証に失敗したメールを拒否するよう受信側に要求します。

ただし、DMARCポリシーは受信側に対する取り扱いの要求であり、すべての受信側が必ず指定どおりに処理するとは限りません。
受信側は、転送やメーリングリストなどの状況も考慮して最終的な処理を判断する場合があります。

DMARCを設定する前に確認すること

DMARCの導入で重要なのは、正規のメール送信元を把握することです。
送信元を十分に確認せずにp=quarantineやp=rejectを設定すると、CRM、メール配信サービス、ヘルプデスクなどから送信される正規メールにも影響する可能性があります。
まずは、以下の項目を確認してください。

ステップ1：SPFレコードを確認する

最初に、自社ドメインのSPFレコードを確認します。

  1. PowerDMARCのSPFチェッカーを使用して、SPFレコードの公開状況を確認します。
  2. 同じドメインに複数のSPFレコードが公開されていないか確認します。
  3. メール送信に使用するサービスが適切に登録されているか確認します。
SPFレコードの例

v=spf1 include:sendgrid.net include:mailchimp.com ~all
これはSPFレコードの構文を示す例です。
実際の設定では、利用しているメールサービスが指定する値を使用してください。
同じドメインに複数のv=spf1レコードが存在すると、SPFの評価でpermerrorが発生します。

その場合は、必要な設定を1つのSPFレコードに統合してください。
なお、DMARCはDKIMによっても認証に合格できるため、SPF認証が成功することだけがDMARCの成立条件ではありません。
ただし、安定したメール認証を実現するためには、SPFとDKIMの両方を適切に設定することが重要です。

ステップ2：SPFのDNSルックアップ回数を確認する

SPFでは、評価時に参照するDNSルックアップ回数に上限があります。
include、a、mx、ptr、exists、redirectなど、DNS参照を伴う仕組みには、合計10回の上限が適用されます。
この上限を超えると、SPFの評価でpermerrorが発生します。

  1. PowerDMARCのSPFチェッカーを開きます。
  2. 対象ドメインを入力します。
  3. DNSルックアップ回数を確認します。
  4. 上限を超えている場合は、レコードの構成を見直します。

なお、includeごとのルックアップ回数は固定ではありません。
参照先のSPFレコードに含まれる設定によって、追加のDNSルックアップが発生する場合があります。

また、includeをIPアドレスに置き換える方法は、送信元のIPアドレスが変更された際に設定が古くなるリスクがあります。
最適化する場合は、利用しているメールサービスの推奨設定を確認してください。

ステップ3：DKIMの設定を確認する

続いて、各メール送信元でDKIMが適切に設定されているか確認します。

  1. PowerDMARCのDKIMチェッカーを使用して、対象のDKIMセレクタとドメインの公開鍵を確認します。
  2. 各メール配信サービスでDKIM署名が有効になっているか確認します。
  3. DKIM署名に使用するドメインが、From:ヘッダーのドメインとアライメントしているか確認します。
DKIMレコードの例

k1._domainkey.example.com
sendgrid._domainkey.example.com
DKIMセレクタは、署名に使用する公開鍵を識別するためのものです。
複数のサービスで異なるセレクタを使用すると、鍵の管理や更新がしやすくなります。
メール配信サービスによっては、独自ドメインを使用したDKIM署名を有効にするため、追加のDNS設定が必要です。
設定方法が分からない場合は、サービス提供元のドキュメントを確認してください。

ステップ4：すべてのメール送信元を洗い出す

自社ドメインを使用してメールを送信しているサービスを一覧にまとめます。

確認対象の例
  • メール配信サービス（SendGrid、Mailchimp、Klaviyoなど）
  • CRM（Salesforce、HubSpot、Pipedriveなど）
  • ヘルプデスク（Zendesk、Freshdeskなど）
  • マーケティングオートメーション（Marketo、Pardot、ActiveCampaignなど）
  • トランザクションメールの送信サービス（AWS SESなど）
  • 社内サーバや業務アプリケーション
  • メール転送サービスやメーリングリスト

各送信元について、次の項目を確認してください。

SPFまたはDKIMのいずれかで認証とアライメントが成立していれば、原則としてDMARCに合格します。
ただし、転送時にSPF認証が失敗したり、メール内容の変更によってDKIM署名が無効になったりする場合があります。

そのため、可能であれば両方の認証を適切に設定することが望まれます。
PowerDMARCのDMARCレポート分析機能を使用すると、送信元の確認や認証失敗の調査に役立ちます。

ステップ5：既存のDMARCレコードを確認する

新しいレコードを追加する前に、DMARCレコードがすでに公開されていないか確認してください。
PowerDMARCのDMARCチェッカーを使用すると、レコードの有無や設定内容を確認できます。

p=noneが設定されている場合
現在はモニタリングを中心とした運用です。
レポートを確認しながら、必要に応じてポリシーを強化できます。
p=quarantineまたはp=rejectが設定されている場合
すでに強制適用ポリシーが公開されています。
変更する前に、現在の認証状況や正規メールへの影響を確認してください。
pct=、rf=、ri=が含まれている場合
これらのタグはRFC 9989では削除され、現在のタグ登録では歴史的なものとして扱われています。
設定を見直す際に削除を検討してください。
レコードが見つからない場合
新しいDMARCレコードを作成します。

DMARCの設定方法

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

PowerDMARCのDMARC生成ツールを使用して、DMARCレコードを作成します。
主な設定項目は以下のとおりです。

Domain
DMARCを設定するドメイン
Policy
初期設定ではp=noneを選択
Reporting address
DMARC集約レポートの送信先メールアドレス

初期設定では、まずp=noneを使用して認証状況を確認することをおすすめします。

レコードの例

v=DMARC1; p=none; rua=mailto:dmarc@example.com
このレコードは、DMARC認証に失敗したメールについて、DMARCポリシーによる隔離や拒否を要求せず、集約レポートを受信するための設定です。
必要に応じて、サブドメインに関するポリシーも追加できます。
例えば、存在しないサブドメインに対する拒否ポリシーを指定する場合は、次のように設定します。

v=DMARC1; p=none; np=reject; rua=mailto:dmarc@example.com
ただし、np=rejectは存在しないサブドメインに対して強いポリシーを要求します。
初期導入時に必ず追加する必要はありません。
組織のドメイン構成や運用方針を確認したうえで設定してください。

ステップ2：DMARCレコードの各タグを理解する

DMARCレコードは、セミコロンで区切られたタグと値で構成されています。
公開する前に、各タグの役割を理解しておくことが重要です。

基本となるタグ
タグ 説明
v= DMARCのバージョンを指定します。
v=DMARC1を使用します。
p= DMARC認証に失敗したメールの取り扱いを指定します。
none、quarantine、rejectから選択します。

v=DMARC1はレコードの先頭に記述します。
RFC 9989ではp=は推奨タグであり、省略された場合はp=noneとして扱われます。
ただし、設定内容を明確にするため、通常はp=を明示することをおすすめします。
任意のタグ
タグ 役割 設定値・形式 補足
np= 存在しないサブドメインに適用するポリシー none、quarantine、reject 存在しないサブドメインを悪用したなりすまし対策に役立ちます。
rua= DMARC集約レポートの送信先 mailto:dmarc@example.com 送信元IPアドレスや認証結果などを確認できます。
sp= サブドメインに適用するポリシー none、quarantine、reject サブドメインに独自のDMARCレコードがある場合は、そちらが優先されます。
fo= 失敗レポートの生成条件 0、1、d、s 通常はruf=と組み合わせて使用します。
adkim= DKIMアライメントの判定方法 r：緩和
s：厳格		 緩和モードでは組織ドメインの一致、厳格モードでは完全一致が必要です。
aspf= SPFアライメントの判定方法 r：緩和
s：厳格		 From:ドメインとSPF認証ドメインの一致を確認します。
t= ポリシーのテストモード y：有効
n：無効		 テスト中は、通常より1段階緩いポリシーの適用が想定されています。
ruf= DMARC失敗レポートの送信先 mailto:forensics@example.com 詳細な失敗情報を受信するために使用します。
設定時の注意点
  • rua=には複数のメールアドレスを指定できます。
    外部ドメインを指定する場合は、必要な認可設定を確認してください。
  • adkim=とaspf=は、どちらもデフォルトでは緩和モード（r）です。
  • t=yを指定した場合、p=quarantineはnone相当、p=rejectはquarantine相当の処理が想定されます。
    ただし、実際の処理は受信側の判断にも左右されます。
  • ruf=による失敗レポートは、すべてのメールプロバイダから提供されるわけではありません。
    また、メール内容に関する情報が含まれる可能性があるため、取り扱いには注意が必要です。
RFC 9989で削除されたタグ
タグ 従来の役割
pct= DMARCポリシーを適用するメールの割合を指定します。
rf= 失敗レポートの形式を指定します。
ri= 集約レポートの送信間隔を指定します。

上記のタグは、以前のDMARC仕様で使用されていましたが、RFC 9989では削除されています。
新しいDMARCレコードには、これらのタグを追加しないでください。
ポリシーを段階的にテストする場合は、pct=ではなくt=を使用できます。

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

DMARCレコードを作成したら、ドメインのDNSを管理しているサービスにログインします。
例えば、次のようなサービスがあります。

DNS設定画面を開き、TXTレコードを追加できる場所を確認してください。Log_In_to_Your_DNS_Provider

ステップ4：DMARCレコードをDNSに追加する

DNS管理画面で新しいTXTレコードを作成します。
設定後、レコードを保存してください。Add_the_DMARC_Record_by_DNS_Provider

基本的な設定例
項目 設定値
Type TXT
Host/Name _dmarc
Value v=DMARC1; p=none; rua=mailto:dmarc@example.com
TTL DNSプロバイダの推奨値

DNSプロバイダによって、入力欄の名称やホスト名の指定方法が異なります。

プロバイダ DNS設定の場所 注意事項
GoDaddy My Products→DNS ホスト名に_dmarcを指定します。
Cloudflare Dashboard→対象ドメイン→DNS TXTレコードを追加します。
TXTレコードにはHTTPプロキシ設定は適用されません。
Namecheap Domain List→Manage→Advanced DNS Host欄に_dmarcを指定します。
cPanel/WHM Zone Editor→Manage ホスト名の入力形式は画面の仕様に従ってください。
Amazon Route 53 Hosted zones→対象ドメイン→Create record TXTレコードとして値を登録します。

ホスト名にドメイン名が自動的に追加されるかどうかは、管理画面によって異なります。
_dmarc.example.com.example.comのようにドメイン名が重複しないよう注意してください。

ステップ5：DNSの反映を待つ

DNSレコードを保存したら、変更が反映されるまで待ちます。
反映にかかる時間は、DNSのTTLやキャッシュの状態によって異なります。

短時間で確認できる場合もありますが、環境によっては時間がかかることがあります。
PowerDMARCのDNS Propagation Checkerなどを使用すると、各DNSサーバから新しいレコードを確認できるか調べられます。

ステップ6：DMARCレコードを検証する

DNSへの登録後は、PowerDMARCのDMARCチェッカーを使用して設定を確認します。

  1. DMARCチェッカーを開きます。
  2. 対象ドメインを入力します。
  3. 「Lookup」をクリックします。
  4. 公開したDMARCレコードが取得できるか確認します。
  5. ポリシーやタグの値が正しいか確認します。

レコードが正しく表示されれば、DNSへの公開を確認できます。
ただし、レコードが公開されていることと、実際に送信されるメールがDMARC認証に合格することは別です。
送信メールの認証結果については、DMARC集約レポートなどを使用して確認してください。

RFC 9989でDMARCの設定はどう変わった？

2026年5月、IETFはRFC 9989を公開しました。
RFC 9989は、従来のRFC 7489とRFC 9091に代わるDMARCの仕様です。

既存のv=DMARC1というバージョン表記は引き続き使用されるため、バージョン名を変更する必要はありません。
主な変更点を確認しましょう。

1.pct=タグが削除された
従来のpct=タグは、DMARCポリシーを適用する割合を指定するために使用されていました。
しかし、受信側によって処理に差が生じるなど、運用上の課題がありました。
そのため、RFC 9989では削除されています。
新しくDMARCレコードを作成する場合は、pct=を使用しないでください。
2.np=タグが規定された
np=は、存在しないサブドメインに対するDMARCポリシーを指定するタグです。
例えば、次のように設定できます。

v=DMARC1; p=none; np=reject; rua=mailto:dmarc@example.com
この設定では、組織ドメインにはp=noneを指定し、存在しないサブドメインにはrejectを要求します。
ただし、np=はすべてのドメインに必須の設定ではありません。
また、既存のサブドメインを保護するための設定とは区別する必要があります。
3.t=タグによるテストモードが追加された
t=は、ポリシーのテスト運用に使用するタグです。
例えば、次のように設定できます。

v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com
この設定では、隔離ポリシーをテストしていることを受信側に通知します。
RFC 9989では、テストモード中は通常より1段階緩いポリシーを適用することが想定されています。
ポリシーを強化する際は、集約レポートを確認しながら、正規メールへの影響を慎重に評価してください。

t=yを使用した段階的な設定例

以下は、DMARCポリシーを段階的に強化する場合の一例です。

1.モニタリングを開始する

v=DMARC1; p=none; rua=mailto:dmarc@example.com
まずは集約レポートを確認し、正規の送信元を把握します。
2.隔離ポリシーをテストする

v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com
隔離ポリシーをテストしていることを受信側に通知します。
3.隔離ポリシーを適用する

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
正規メールへの影響を確認できたら、テストモードを解除します。
4.拒否ポリシーをテストする

v=DMARC1; p=reject; t=y; rua=mailto:dmarc@example.com
拒否ポリシーへの移行による影響を確認します。
5.必要に応じて拒否ポリシーを適用する

v=DMARC1; p=reject; rua=mailto:dmarc@example.com
送信環境や転送メールへの影響を十分に確認したうえで適用します。

なお、p=rejectがすべてのドメインに最適とは限りません。
特に、ユーザが外部のメーリングリストに投稿する環境では、メールの転送や再配信に影響する可能性があります。

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

DMARCのポリシーを強化する際は、正規メールの認証状況を十分に確認することが重要です。
設定を急いで変更すると、正規メールが迷惑メールに振り分けられたり、拒否されたりする可能性があります。
以下の3段階で進める方法を紹介します。

ポリシー 主な動作 使用する場面
p=none DMARCによる隔離や拒否を要求しない 初期設定、送信状況の確認
p=quarantine 認証失敗メールの隔離を要求する 段階的なポリシー強化
p=reject 認証失敗メールの拒否を要求する 影響を確認したうえで拒否が適切と判断した場合

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

まず、p=noneを設定します。 


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

モニタリング期間は、送信環境の複雑さによって異なります。
一般的には、数週間以上かけて正規の送信元を確認することが望まれます。

実施すること
  1. DMARCレコードを公開します。
  2. 集約レポートの受信を確認します。
  3. PowerDMARCのDMARCレポート分析機能で送信状況を確認します。
  4. 正規の送信元を特定します。
  5. SPFとDKIMの認証結果、アライメントの状態を確認します。
  6. 認証に失敗している正規の送信元について設定を修正します。

次の段階に進む前に、主要な正規メールがDMARC認証に合格していることを確認してください。
なお、レポートに見覚えのない送信元が表示されても、それだけで設定に問題があるとは限りません。
なりすましメールが検出されている可能性もあるため、送信元の情報や認証結果を確認して判断してください。

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

正規の送信元の認証状況を確認できたら、隔離ポリシーへの移行を検討します。

ステップA：テストモードで確認する

v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com
t=yを設定して、隔離ポリシーをテストします。
一定期間、集約レポートや実際のメール配信状況を確認してください。
特に、以下の点を確認します。
  • 正規メールのDMARC認証が成功しているか
  • 認証に失敗している送信元がないか
  • メールの転送やメーリングリストに影響がないか
  • 正規メールが迷惑メールに振り分けられていないか
ステップB：隔離ポリシーを適用する
問題がないことを確認できたら、t=yを削除します。

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
これにより、DMARC認証に失敗したメールの隔離を受信側に要求します。
適用後も継続的にレポートを確認してください。
正規メールへの影響が確認された場合は、原因を調査し、必要に応じてポリシーを見直します。
BIMIに関する注意事項
BIMIを利用してブランドロゴを表示する場合、メールプロバイダごとに定められた要件を満たす必要があります。
DMARCの強制適用ポリシーは、その重要な要件の一つです。
ただし、p=quarantineまたはp=rejectを設定するだけで、必ずロゴが表示されるわけではありません。

フェーズ3：拒否（p=reject）

隔離ポリシーで十分な検証を行い、正規メールへの影響がないことを確認できた場合は、拒否ポリシーへの移行を検討します。

ステップA：テストモードで確認する

v=DMARC1; p=reject; t=y; rua=mailto:dmarc@example.com
t=yを設定し、拒否ポリシーのテストを行います。
RFC 9989では、この場合に隔離相当の処理を行うことが想定されています。
ただし、実際の取り扱いは受信側の判断にも左右されます。
ステップB：拒否ポリシーを適用する
問題がないことを確認できたら、テストモードを解除します。

v=DMARC1; p=reject; rua=mailto:dmarc@example.com
これにより、DMARC認証に失敗したメールの拒否を受信側に要求します。
ただし、拒否ポリシーを公開しても、すべての受信側が必ずメールを拒否するわけではありません。
受信側は、転送やメーリングリストなどの状況を考慮して、異なる処理を行う場合があります。
ポリシー選択時の注意点
一般ユーザが日常的にメールを送信し、外部のメーリングリストなどを利用するドメインでは、p=rejectによって正規メールの配送に影響が出る可能性があります。
RFC 9989でも、このような環境では拒否ポリシーを慎重に扱うよう求めています。
一方、送信元を厳密に管理できる専用ドメインでは、拒否ポリシーが適している場合があります。
いずれの場合も、実際のメール運用に合わせて判断してください。

DMARC設定でよくある問題と解決方法

問題1：「No DMARC Record Found」と表示される

考えられる原因
  • DNSレコードがまだ反映されていない
  • ホスト名が間違っている
  • TXTレコードの登録先が間違っている
  • DNS設定が正しく保存されていない
解決方法
  1. DNS管理画面でTXTレコードを確認します。
  2. ホスト名が_dmarcになっているか確認します。
  3. ドメイン名が重複していないか確認します。
  4. DNS Propagation Checkerで公開状況を確認します。
  5. DMARCチェッカーで再度検証します。

問題2：SPFとDKIMのアライメントが成立しない

考えられる原因
From:ヘッダーのドメインと、SPFまたはDKIMで認証されたドメインが一致していない可能性があります。
例は以下のとおりです。
  • From：from@example.com
  • SPF認証ドメイン：mail.otherdomain.com
  • DKIM署名ドメイン：newsletter.anotherdomain.com
この場合、いずれの認証ドメインもexample.comとアライメントしていないため、DMARC認証に失敗します。
解決方法
  • adkim=rとaspf=rの緩和モードを使用しているか確認します。
  • DKIM署名に使用されているドメインを確認します。
  • SPFで認証されているReturn-Pathドメインを確認します。
  • 必要に応じて、メール配信サービスの独自ドメイン設定を変更します。
  • 認証結果を再確認します。
なお、SPFレコードに送信元IPアドレスが登録されていても、Return-Pathドメインがアライメントしていなければ、DMARCのSPFアライメントには合格しません。

問題3：サードパーティのメール送信元で認証に失敗する

考えられる原因
メール配信サービスやCRMで、SPFまたはDKIMの設定が適切に行われていない可能性があります。
SPFに問題がある場合
  1. 利用しているサービスの公式ドキュメントを確認します。
  2. 必要なSPF設定を確認します。
  3. 既存のSPFレコードに適切に統合します。
  4. SPFチェッカーで検証します。

v=spf1 include:sendgrid.net include:mailchimp.com ~all
SPFレコードの例は上記のとおりです。
実際には、利用サービスが指定する値を使用してください。
DKIMに問題がある場合
  1. メール配信サービスで独自ドメインのDKIM署名を有効にします。
  2. 指定されたDNSレコードを公開します。
  3. DKIMチェッカーで確認します。
  4. 実際に送信したメールの認証結果を確認します。

問題4：SPFレコードが複数ある、またはDNSルックアップ回数が10回を超えている

SPFレコードが複数ある場合
同じドメインに複数のSPFレコードを公開すると、SPFの評価でpermerrorが発生します。
そのため、必要な設定を1つのレコードに統合してください。

統合前 統合後
v=spf1 include:sendgrid.net ~all
v=spf1 include:mailchimp.com ~all		 v=spf1 include:sendgrid.net include:mailchimp.com ~all
DNSルックアップ回数が10回を超えている場合
SPFでは、評価時にDNSルックアップ回数の上限を超えるとpermerrorが発生します。
対処方法としては、不要な設定の削除、送信サービスの整理、SPFレコードの最適化などがあります。
PowerDMARCのホスト型SPFなどの管理機能を利用する方法もあります。
ただし、includeを固定IPアドレスに置き換える場合は、送信サービス側のIPアドレス変更に対応できるか注意が必要です。

問題5：p=quarantineへの移行後、正規メールが迷惑メールに振り分けられる

考えられる原因
正規の送信元でDMARC認証に失敗している可能性があります。
解決方法
  1. DMARC集約レポートを確認します。
  2. 認証に失敗している正規の送信元を特定します。
  3. SPFまたはDKIMの設定とアライメントを確認します。
  4. 必要に応じてポリシーを一時的に緩和します。
  5. 問題を修正した後、再度ポリシーの強化を検討します。

なお、迷惑メールへの振り分けはDMARC以外の要因でも発生します。
認証結果だけでなく、送信者レピュテーションやメール内容なども確認してください。

問題6：DMARCレコードに構文エラーがある

考えられる原因
  • タグ名の入力ミス
  • セミコロンの欠落
  • 値の指定ミス
  • TXTレコードの登録形式の誤り
  • サポートされていないタグの使用
解決方法
  1. PowerDMARCのDMARC Checkerで構文を確認します。
  2. エラーがある場合は、タグと値を修正します。
  3. 必要に応じてDMARC生成でレコードを再作成します。
  4. DNSに登録し直します。
  5. 再度検証します。

まとめ

DMARCは、ドメインのなりすましやフィッシング攻撃への対策を強化するための重要な仕組みです。
また、主要なメールプロバイダによる認証要件への対応にも役立ちます。
DMARCを安全に導入するには、まず正規のメール送信元を把握し、SPFとDKIMの設定を確認することが重要です。

そのうえでp=noneからモニタリングを開始し、認証レポートを分析しながら、適切なポリシーへ段階的に移行してください。
なお、p=rejectがすべてのメール環境に適しているわけではありません。
転送やメーリングリストの利用状況なども考慮し、組織に適したポリシーを選択することが重要です。

PowerDMARCのDMARC管理プラットフォームを活用すると、認証レポートの分析やポリシー管理を効率化できます。
DMARCの導入や運用を効率的に進めたい場合は、PowerDMARCの無料トライアルやデモをご検討ください。

よくある質問（FAQ）

DMARCの設定にはどのくらい時間がかかりますか？
DMARCレコードの作成とDNSへの登録は、設定内容が決まっていれば短時間で完了します。
ただし、DNSの反映にかかる時間は環境によって異なります。
また、DMARCポリシーの強化には、正規のメール送信元の確認や認証レポートの分析が必要です。
送信環境によっては、数週間から数か月かかる場合もあります。
DMARCの設定はメール到達性に影響しますか？
DMARCの設定内容によっては、メール到達性に影響する場合があります。
p=noneでは、DMARCポリシーによる隔離や拒否を要求しません。

一方、p=quarantineやp=rejectでは、DMARC認証に失敗したメールが隔離または拒否される可能性があります。
そのため、ポリシーを強化する前に、正規メールの認証状況を確認することが重要です。
適切なメール認証は、なりすまし対策や送信元の信頼性向上に役立ちますが、受信トレイへの到達を保証するものではありません。
複数のドメインにDMARCを設定するにはどうすればよいですか？
複数の独立したドメインにDMARCを設定する場合は、それぞれのドメインに対応するDMARCレコードを公開します。
例えば、次のように設定します。
  • ドメイン1：_dmarc.example.com
  • ドメイン2：_dmarc.example.org
各ドメインの送信環境に応じて、適切なポリシーとレポート送信先を指定してください。
なお、サブドメインについては、組織ドメインのDMARCポリシーを継承できる場合があります。
多数のドメインを管理する場合は、PowerDMARCのようなDMARC管理プラットフォームを利用することで、認証状況の確認やポリシー管理を効率化できます。
DMARCアライメントとは何ですか？
DMARCアライメントとは、メールのFrom:ヘッダーに記載されたドメインと、SPFまたはDKIMで認証されたドメインとの一致を確認する仕組みです。
アライメントには、緩和モードと厳格モードがあります。
  • 緩和モード：同じ組織ドメインに属していれば、アライメントが成立します。
  • 厳格モード：ドメインが完全に一致する必要があります。
デフォルトでは、SPFとDKIMの両方で緩和モードが使用されます。
DMARCに合格するには、原則としてSPFまたはDKIMのいずれかで認証に成功し、アライメントが成立する必要があります。