DMARC 設定：DNS とポリシー検証

DMARC 設定は、独自ドメインのメールを運用する際の基本作業です。ドメイン認証を確認し、検証に失敗したメールについて受信側に処理を要求します。一部のドメインなりすましを抑える助けになりますが、配信を保証するものではありません。

メールボックスがひとつでも、多数の顧客ドメインを管理していても重要です。全体の構成を検討中なら、先に小規模事業者向けのビジネスメールを確認し、その後に DNS 設定を整えましょう。

手順自体は難しくありません。ただし、SPF、DKIM、転送、外部の送信サービスが混在すると、調整不足が業務メールに影響します。ここでは最初のレコード、主要なタグ、ポリシーを強める条件、よくある設定ミスを説明します。

DMARC 設定で確認すること

_dmarc.yourdomain.com に TXT レコードを公開し、DMARC に失敗したメールの希望する処理を受信サーバーに伝えます。SPF または DKIM の少なくとも一方が成功し、その認証ドメインが表示上の From ドメインとのアライメントを満たす必要があります。

DMARC は SPF や DKIM の代わりにはなりません。RFC 7489 によれば、どちらかが認証成功と From ドメインとのアライメントを同時に満たせば、DMARC は成功します。認証成功だけ、またはアライメントだけでは足りません。

Google のメール送信者向けガイドラインにも認証とアライメントの要件があります。一般の送信者と一括送信者では要件が異なるため、実際の送信に適用される条件を確認してください。

つまり DMARC は、送信ドメインに対応する認証を確認し、失敗時の処理を要求する仕組みです。個人の身元や本文の安全性を証明するものではなく、受信とフィルタリングの最終判断は受信側にあります。

最初に公開する DNS レコード

送信経路をまだ十分に検証していない場合は、p=none で監視から始める方法があります。入手できたレポートを分析し、正規の送信システムを洗い出して、重要なメールをテストします。早すぎる reject は、パスワード再設定、請求書、問い合わせフォームなどに影響する可能性があります。

次はホスト名 _dmarc に置く例です。厳密なアライメントは任意の選択であり、すべての環境に適した初期設定とは限りません。

v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100

完全一致が送信構成に合わない場合は、adkim=s と aspf=s を緩和モードに変更できます。次のレコードは代替例です。前のレコードと同時には公開しません。

v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100

緩和アライメントは多くの構成で利用できますが、同じ組織ドメインを持つことが条件です。該当するサブドメインを扱えるのであって、任意の親子ドメイン関係が一致するとみなされるわけではありません。

TrekMail ではドメインの DNS レコードを確認できる場合があります。関連資料は必須の DNS レコード、ドメインの追加、DNS ステータスの確認です。資料にある p=quarantine の例は、未検証の稼働中ドメインで直ちに制限を要求する勧めではありません。まず監視とテストで影響を確認しましょう。

重要な DMARC タグ

最初はポリシー、レポートの宛先、アライメントに集中します。正規の送信システムの結果を確認してから、実際のメール運用に合わせて他の設定を調整してください。

タグ	役割	設定の考え方
`v`	プロトコルのバージョン	`DMARC1`
`p`	ドメインのポリシー	まず `none`、検証後に `quarantine`、必要に応じて `reject`
`rua`	集計レポートの宛先	受信でき、内容を分析するアドレス
`adkim`	DKIM のアライメント方式	`r` または `s`
`aspf`	SPF のアライメント方式	`r` または `s`
`pct`	DMARC 失敗メールに制限ポリシーを要求する割合	`100`。受信側の実際の動作も確認
`sp`	サブドメインに継承されるポリシー	異なる扱いが必要な場合に設定

特に、p による処理要求と rua によるフィードバックを理解しておきましょう。レポートは対応する受信側からのみ届き、送信元を網羅する一覧にはなりません。外部の宛先には宛先ドメインの DNS 承認が必要な場合があり、プライバシーとアクセス管理も確認します。

pct は RFC 7489 で段階的な適用に使うタグとして説明されています。ただし、どの受信側でも同じように抽出する保証はありません。100 は対象の失敗メール全体への要求ですが、none のままなら制限を要求していることにはなりません。

DMARC 設定の手順

SPF と DKIM を確認し、監視ポリシーを公開してから、レポートと実際のテスト結果を調べます。業務上の送信経路を十分に検証したうえで、ポリシーを強めます。

自社の From ドメインで送信するサービスをすべて列挙します。メールホスト、CRM、請求、サポート、フォーム、マーケティングなどが対象です。
実際のエンベロープ送信者ドメインの SPF を確認します。サービスの指示に従って実際に許可する送信元だけを適切な単一レコードに反映し、入れ子の評価も含めて DNS を必要とするメカニズムと修飾子の上限に注意します。
対応する送信サービスで DKIM を有効にし、アライメントを確認します。転送後も検証を成功させるには、署名対象のデータが保持される必要があります。
p=none の初期ポリシーを公開します。
例えば 2 から 4 週間レポートを分析し、低頻度の送信や月次、四半期の重要な処理は別途テストします。
正規のメールが認証成功とアライメントを継続的に満たすと確認できたら、p=quarantine を検討します。
重要な送信元と残る失敗を確認してから、p=reject を検討します。

DNS の確認に使えるコマンド例です。

dig TXT _dmarc.example.com +short

dig TXT example.com +short

dig TXT dkim._domainkey.example.com +short

次は構造を示す例です。SPF の include は実際に許可する送信元に合わせ、DKIM のセレクターと完全な公開鍵は署名を行うシステムから取得します。省略された鍵は実運用に使えません。

; SPF
example.com.  IN TXT  "v=spf1 include:spf.trekmail.net include:_spf.google.com -all"

; DKIM
dkim._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

; DMARC
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100"

新規に構築する場合は独自ドメインメールの作成も参考になります。ホストを変更する場合、TrekMail の IMAP 移行の概要は既存メールの取り込みを説明しています。IMAP はメールをコピーし、DMARC は送信メールのドメイン認証を確認します。MX や送信システムの切り替え計画は別に必要です。

DMARC が成功する場合と失敗する場合

SPF または DKIM の少なくとも一方が認証成功と From ドメインとのアライメントを満たせば、DMARC は成功します。そのような結果がなければ、別のドメインで認証に成功していても DMARC は失敗する可能性があります。

主な組み合わせは次のとおりです。

SPF	DKIM	成功した認証はアライメントを満たすか	DMARC の結果
Pass	Fail	はい	Pass
Fail	Pass	はい	Pass
Pass	Pass	いいえ	Fail
Fail	Fail	いいえ	Fail

転送は典型的な例です。転送サーバーが元のエンベロープドメインの SPF で許可されていなければ、SPF が失敗することがあります。DKIM は、正規化規則のもとで署名対象が保持されていれば成功を維持できます。そのため、検証済みでアライメントを満たす署名が重要です。

billing@example.com から送ったメールを顧客が Gmail に転送します。SPF が失敗しても、d=example.com の署名が検証に成功し、From ドメインとのアライメントを満たしていれば、DMARC 検証に合格します。

SPF 失敗は状況と合わせて調べましょう。転送後の DKIM が検証に成功してアライメントを満たせば DMARC の成功を支えますが、すべての SPF 失敗を無条件に無視してよいわけではありません。

転送を使う場合はメール転送の設定も確認してください。SRS は新しいエンベロープアドレスでの SPF 成功を助け、ARC は以前の認証結果を伝えます。ただし、元の From とのアライメントや特定の配信結果を保証するものではありません。

none から quarantine、reject へ進める

段階的な導入なら、厳しい処理を要求する前に問題を調べられます。各段階で正規のメールの設定不備が影響する可能性があり、最終的な扱いは受信側が決めます。

各ポリシーの意味は次のとおりです。

p=none：DMARC による制限を要求しません。ただし受信側のフィルターは適用され得ます。
p=quarantine：失敗メールを疑わしいものとして扱うよう要求します。迷惑メール扱いなどが考えられます。
p=reject：失敗メールの受信拒否を要求します。SMTP 段階で処理されることがあります。

以下は順番に使う代替レコードです。同時に公開せず、現在の段階に合うものを選びます。

; Phase 1
v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100

; Phase 2
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100

; Phase 3
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100

サブドメインを異なる扱いにする場合は sp= を設定できます。RFC 7489 では、サブドメイン自身に適用可能なレコードがなければ組織ドメインから継承し、sp がなければ主ポリシーを使うと説明されています。送信をサブドメインごとに分ける場合は、この関係を確認してください。

よくある DMARC 設定ミス

原因は SPF の許可漏れ、DKIM の不備、DNS 名の間違い、外部サービスの From アライメントなどであることが少なくありません。DMARC ポリシーだけでなく、実際の原因を修正します。

設定ミス	起こり得る影響	修正方法
DKIM を検証せず制限を要求する	転送メールに別の認証成功とアライメントの経路がなければ失敗する可能性	制限前に DKIM を有効化してテストする
複数の SPF レコードを公開する	SPF が PermError を返す	整合性を確認した単一の SPF レコードにする
DMARC のホスト名が違う	必要なレコードが見つからない	ドメインのルートではなく `_dmarc` に公開する
早すぎる reject	正規のメールが拒否される可能性	`p=none` で監視とテストから始める
アライメントを確認しない	認証が成功しても DMARC は失敗し得る	成功した認証を From に合わせる
レポートの宛先がない	このフィードバックが得られない	受信できる `rua` アドレスを設定して分析する

エイリアスを外部サービスから送る際、サービス自身のドメインでのみ署名されることがあります。SPF にも成功とアライメントを満たす結果がなければ、DKIM が成功しても DMARC は失敗し得ます。選択にはドメインメールのエイリアスとメールボックスの比較が参考になります。

TrekMail の DNS 検査は、想定されたレコードの競合を見つける助けになります。警告が出たら DNS ステータスを確認し、実際のメールもテストしてください。画面の正常表示だけでは全送信経路の認証確認にはなりません。

TrekMail とメール管理の集約

複数のホスト、転送ルール、三つの SMTP サービスがあると調整が増えます。TrekMail ではドメイン、メールボックス、DNS 検査、転送、移行を同じ管理画面にまとめられる場合があります。

分散管理の例	TrekMail で可能な運用
個別のドメインツールでユーザー単位に課金	リソース上限のある定額マルチドメインホスティング
メールボックスごとに保存容量を分ける	プランに応じた共有容量。他社でも共有方式を提供する場合がある
DNS を手作業で確認する	DNS 検査と設定ウィザード
移行の調整が複雑になる	計画した切り替えの一部としてのサーバー側 IMAP 取り込み
未検証の転送が原因調査を難しくする	認証を考慮した転送ツール

個人の運用者にも代理店にも、共通の手順は役立ちます。五十の顧客ドメインを管理するなら特に重要ですが、一定の節約額を保証するものではありません。

Starter の価格目安は月額 $3.50 からです。Nano にはカード不要の無料オプションがあり、独自 SMTP を使って最大 10 ドメインを扱えます。該当する有料プランには管理された SMTP が含まれ、提供される 14 日間の試用にはクレジットカードが必要です。最新の価格、機能、上限、条件は TrekMail の料金で確認してください。