DMARC レコード作成と検証

DMARC レコードの作成を考えるきっかけは、なりすましメール、Gmail の警告、プロバイダーからの DNS 変更依頼などです。SPF と DKIM の結果がメールごとに違う場合もあります。構築中なら、まずビジネスメールのガイドでドメイン、メールボックス、DNS の関係を整理しましょう。

レコードが存在しても適切な設定とは限りません。ホスト名の誤り、不適切なポリシー、届かないレポート、アライメント不足は、すぐには気づかない場合があります。公開だけでなりすましや正規メールの配信問題が解決するわけではありません。

ここでは主要なタグ、_dmarc.yourdomain.com への公開、検証後に監視から制限要求へ進める手順を説明します。

DMARC レコードとして公開する内容

_dmarc.yourdomain.com に、v=DMARC1 で始まり、p=none、p=quarantine、p=reject などの有効なポリシーを含む TXT を公開します。SPF と DKIM のどちらも認証成功と From アライメントを同時に満たさなければ、DMARC は受信側に処理を要求します。

最小の有効な例です。

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none;

これは DMARC による制限を要求しません。ただしレポート宛先がないため、レポートも要求しません。受信側のローカルフィルターは引き続き適用され得ます。

集計レポートを指定した例です。

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100

次は送信を検証してから検討する代替ポリシーです。前のレコードと同時には公開しません。

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100

RFC 7489 では v が先頭にあり、p が含まれる必要があります。無効なレコードはポリシー処理を妨げる場合があります。仕様の詳細は RFC 7489 にあります。

DNS のどこに公開するか

ドメインのルートではなく、ホスト _dmarc に公開します。example.com なら完全な検索先は _dmarc.example.com です。別の場所に置いても、その検索では必要なポリシーが見つかりません。

よくある間違いは @ に公開したり、短い名前を求める画面に _dmarc.example.com を入力したりすることです。_dmarc だけが必要なのか完全な名前が必要なのかは、DNS プロバイダーの入力規則で確認してください。

公開後は管理画面以外からも検索します。

dig txt _dmarc.example.com +short
nslookup -q=txt _dmarc.example.com

v=DMARC1 で始まる有効な DMARC ポリシーレコードが必要です。同じ TXT レコード内の複数の文字列は、複数のポリシーレコードとは異なります。他の TXT 内容も区別して判断します。

TrekMail ではドメインを追加して必要な値を取得し、DNS 検索結果を確認できます。関連資料はドメインの追加、必須の DNS レコード、DNS ステータスの確認です。実際の送信経路はメールでもテストします。

レコード作成時の主要タグ

まず必須の v と p、レポート用の適切な rua を設定します。他のアライメントやレポート設定は、具体的な運用目的に合わせて追加しましょう。

タグ	必須	役割	設定の考え方
`v`	はい	バージョン識別子	`DMARC1` を先頭に置く
`p`	はい	DMARC 失敗時の処理要求	`none` で監視し、検証後に `quarantine`、必要なら `reject`
`rua`	いいえ	集計レポートの宛先	受信可能で、管理とアクセス制限を行う宛先
`ruf`	いいえ	失敗レポートの宛先	任意。対応は限定的で、機微な内容を含み得る
`adkim`	いいえ	DKIM アライメント	`r` が既定値。送信要件も確認する
`aspf`	いいえ	SPF アライメント	`r`、または目的を明確にして検証した `s`
`pct`	いいえ	失敗メールに制限を要求する割合	`100`、または計画した段階的適用。受信側の動作は異なり得る
`sp`	いいえ	サブドメインの継承ポリシー	別の扱いが必要な場合に確認し、サブドメイン自身の適用可能なレコードも考慮する

有効なレコードに p=none だけがあり rua がなければ、集計レポートは要求されません。他のログは手掛かりになりますが、このフィードバックを自動的に代替するものではありません。

適切なポリシーを選ぶ

未検証の送信経路があるなら p=none から始められます。レポート、送信元一覧、メールテストを確認して p=quarantine を検討します。p=reject は重要な送信元や低頻度の正規送信を検証してから判断します。未知の IP だけでは不正な送信の証明になりません。

ポリシー	受信側への要求	利用を検討する場面	主なリスク
`p=none`	DMARC による制限を要求しない	導入時の監視	このポリシーは追加の制限を要求しない
`p=quarantine`	失敗メールを疑わしいものとして扱う	送信の検証後	正規の例外的な送信に影響し得る。復旧は保証されない
`p=reject`	失敗メールの受信拒否を要求する	検証済みの構成	設定不備のある正規メールが拒否され得る

Google が説明する一括送信者の要件には SPF と DKIM、および成功した少なくとも一方による From アライメントがあります。将来の変更を現行要件とみなさず、Google の送信者 FAQで適用条件を確認しましょう。

認証の有効化だけでは十分ではありません。CRM が自社の From を使っても、署名とバウンスが提供元のドメインなら、別の成功したアライメント経路がない限り DMARC は失敗し得ます。

DMARC レコードを段階的に作成する

送信元を整理し、監視ポリシーを公開して、レポート、ログ、実際のテストを確認します。レポートに問題が見えないだけでは、低頻度の重要な処理まで確認したことにはなりません。

Google Workspace、Microsoft 365、サポート、CRM、フォーム、請求、ニュースレターなど全サービスを列挙する。
実際の送信経路の SPF と DKIM を検証する。DMARC は代替しない。SPF の上限は DNS を必要とするメカニズムと修飾子を入れ子も含めて数えるもので、全問い合わせ数ではない。
dmarc@yourdomain.com などの管理する宛先やレポートサービスを用意する。プライバシーと、外部宛先で必要になる DNS 承認を確認する。
送信を十分に検証していなければ p=none から始める。
利用可能なレポートを一覧、ログ、テストと照合する。
認証の不備を修正し、認証ドメインと From のアライメントを確認する。
検証後に p=quarantine を検討する。
残る失敗と低頻度の処理を確認してから p=reject を検討する。

次は 2026 年の設定を検討する際の監視例です。実環境に合わせて変更してください。

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100

転送を使うならドメインメールを Gmail に転送する方法も参考になります。SPF は新しいサーバーで失敗し得ます。署名対象が正規化規則のもとで保持され、有効な DKIM がアライメントを満たせば DMARC 検証に合格します。ARC は受信側の例外判断を助けることがありますが、DMARC 失敗を本来の検証成功に変えるものではありません。

レコード作成時によくある間違い

ホスト名の誤り、複数のポリシー、届かないレポート、未検証の SPF や DKIM はよくある原因です。外部から公開結果を確認し、実際の送信もテストします。

特に次の間違いに注意してください。

1. _dmarc ではなくルートに公開する。
@ のレコードは必要な検索場所にありません。

2. 複数の DMARC ポリシーレコードを公開する。
RFC 7489 は複数のポリシーがある場合の処理停止を説明しています。同一 TXT 内の複数文字列とは別です。

3. 最初から p=reject を使う。
見落としたサービスの再設定メール、請求書、サポート返信が、受信側の拒否によって届かなくなる可能性があります。

4. 届かない宛先を rua に設定する。
その宛先ではレポートを受信できません。ただし宛先が有効でも、レポートがないことはすべての受信側が送った証拠にはなりません。

5. DMARC が転送を修復すると考える。
認証成功とアライメントを満たす SPF または DKIM が必要です。転送で SPF が失敗した場合、DKIM は署名が有効でアライメントを満たすときだけ助けになります。

注文確認、サポート、マーケティングを別々の SMTP から送り、全経路の検証前に p=reject を公開します。一部は成功しても他のメールは拒否される可能性があります。不十分な確認が顧客に影響します。

全体の構築は独自ドメインでメールを作成する方法が参考になります。DNS とメールボックスを SPF、DKIM、DMARC と合わせて説明しています。

多数のドメインで DMARC を管理する

表計算、別々のレジストラーログイン、古い TXT 値は一貫した管理を難しくします。共通の画面と検証可能な設定は助けになりますが、実際の DNS 管理者と送信経路を考慮する必要があります。

分散した管理	TrekMail で可能な運用
各レジストラー画面で DNS を照合する	共通の画面でマルチドメインメールを管理する
TXT を手動比較してキャッシュ更新を推測する	DNS 検索と検出した競合を確認する。反映時間は保証されない
別々のツールで SPF、DKIM、DMARC を管理する	DNS の作業を集約する
少人数のドメインでもユーザー単位で課金される	月額 $3.50 からを目安とする定額プランを検討する。プラン上限あり

TrekMail はプランに応じて、複数ドメイン、共有容量、IMAP メールボックス、移行、キャッチオール、転送、独自または管理された SMTP をまとめられます。Nano には独自 SMTP で最大 10 ドメインを扱える無料オプションがあります。有料プランの価格目安は月額 $3.50 からです。最新条件は TrekMail の料金で確認してください。

共通の画面は、五つの提供元と二十のブラウザータブを行き来する手間を減らす助けになります。ただし、全経路の認証検証や MX、アプリの切り替え計画は別に必要です。IMAP 取り込みは既存メールをコピーします。