DMARC レコード例は、SPF と DKIM のどちらも認証成功と From アライメントを満たさないメールについて、受信側に処理を要求する DNS TXT です。誤った設定は正規メールに影響し、期待するなりすまし対策にもつながらない場合があります。全体の構築にはビジネスメールのガイドと独自ドメインメールの作成方法も参考になります。
_dmarc.yourdomain.com に有効な単一ポリシーを公開します。送信が未検証なら監視から始め、送信元を確認してから隔離や拒否を検討します。TrekMail の必須 DNS レコードのガイドは基本構成を説明し、ここでは適切なDMARC レコード例の選び方を扱います。
DMARC レコードが実際に行うこと
DMARC の例はプロトコル、失敗メールの希望する処理、レポート宛先を示します。SPF と DKIM を置き換えるのではなく、その結果を使います。少なくとも一方が認証成功と表示上の From とのアライメントを同時に満たす必要があります。
DMARC による制限を要求せず、レポートを求める短い例です。
Host: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com各部分の意味は次のとおりです。
v=DMARC1は DMARC レコードを識別します。p=noneは隔離や拒否を要求しません。ただしローカルフィルターは適用され得ます。rua=mailto:dmarc@example.comは対応する受信側に XML 集計レポートを要求します。
他の設定はこの基本形に追加します。レポート宛先は管理し、アクセスを制限します。外部宛先は DNS 承認が必要な場合があります。
DMARC はポリシーであって、本文の安全性の証明ではありません。SPF と DKIM が認証結果を示し、DMARC は成功した認証が見える From ドメインに対応するかを確認します。
5 つの用途別 DMARC レコード例
共通のDMARC レコード例だけでは全環境に対応できません。以下は監視、段階的な制限、サブドメインやアライメント要件の違いに応じた代替案です。同時には公開しません。
監視のみ。実際の送信サービスや転送を把握する際に使います。
v=DMARC1; p=none; rua=mailto:dmarc@example.com疑わしいメールとしての処理を要求。正規送信を検証した後の中間段階として検討します。
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com拒否を要求。重要な送信元や低頻度の送信を確認してから判断します。
v=DMARC1; p=reject; rua=mailto:dmarc@example.com段階的な導入。失敗メールの一部に制限を要求します。受信側の動作は異なり得ます。
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.comサブドメインのポリシーと厳密なアライメント。検証した完全一致と異なる処理が必要な場合に使います。サブドメイン自身に適用可能なポリシーがない場合に、組織ドメインから継承します。
v=DMARC1; p=reject; sp=quarantine; adkim=s; aspf=s; rua=mailto:dmarc@example.com
| ポリシー | 検討する場面 | 役割 | リスク |
|---|---|---|---|
p=none | 送信元の把握 | DMARC 制限を要求しない | 追加の制限はなく、他のフィルターは適用される |
p=quarantine | 検証済みの送信 | 疑わしいメールとして処理を要求する | アライメント不足の正規メールに影響し得る |
p=reject | 十分にテストした構成 | DMARC 検証に失敗したメールの拒否を要求する | 設定不備で正規メールに影響し得る |
pct=25 | 計画した導入 | 失敗メールの一部への制限を要求する | 適用割合やリスク範囲は保証されない |
adkim=s; aspf=s | 完全一致が必要な環境 | 厳密なアライメントを確認する | 外部の送信設定の調整が増え得る |
正規の送信経路を検証済みなら、次のDMARC レコード例を次の段階として検討できます。ただし、どのドメインでも安全な初期設定というわけではありません。
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.comQuarantine はすでに制限を要求します。具体的な扱いは受信側が決め、特定の迷惑メールフォルダーや復旧は保証されません。
DNS に DMARC レコード例を公開する
DMARC レコードを公開するにはホスト _dmarc に適切なポリシーを設定して外部検索します。ルートに置いて _dmarc を使わないことや、複数のポリシーを作ることがよくある間違いです。同一 TXT 内の複数文字列とは区別してください。
次は検証後に Quarantine を導入する場合の例です。DNS プロバイダーの入力規則に合わせます。
Host: _dmarc
Type: TXT
TTL: 3600
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.comその後に検索します。TTL は世界中で一定時間内に更新される保証ではありません。
dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.comv=DMARC1 で始まる有効なポリシーを確認できれば、DNS 公開は確認できます。ただし全送信経路の認証検証にはなりません。
RFC 7489 では、複数の有効なポリシーや適用可能なレコードがない場合、そのポリシーを適用しません。管理画面の形式も確認します。_dmarc だけを求める画面も完全な名前を求める画面もあります。
TrekMail の必須 DNS レコードは MX、SPF、DKIM、DMARC の構成をまとめて説明しています。
メールに影響するよくある設定ミス
不適切なDMARC レコード例では、ホスト名、重複したポリシー、届かないレポート、早すぎる厳密アライメントが問題になります。転送後の SPF 失敗は、必ずしも DMARC 失敗ではありません。
特に次を確認しましょう。
- ルートドメインに公開する。ホストは
_dmarcであり@ではありません。 - 複数の DMARC ポリシーを公開する。検索場所には有効な単一ポリシーが必要です。
- 十分に検証せず
p=rejectを使う。見落とした CRM や請求サービスに影響し得ます。 - 転送問題を DMARC のせいにする。SPF が失敗しても、署名対象が保持され、有効な DKIM がアライメントを満たせば DMARC は成功します。ドメインメールの Gmail 転送とメールエイリアスの転送も参考になります。
- アライメントを確認しない。SPF が認証に成功しても From とのアライメントを満たさなければ、成功してアライメントを満たす DKIM がない場合に DMARC は失敗します。
- レポートを設定しない。
ruaがなければこのフィードバックは要求されません。他のログは手掛かりを示す場合があります。
対象となる送信者では、Google の要件により DMARC 不足やアライメント失敗で制限される場合があります。適用条件は公式の送信者 FAQを確認し、すべての送信量に一律適用しないでください。
TrekMail に適した DMARC レコード例
適したDMARC レコード例は送信経路によって異なります。該当する有料プランの管理された SMTP でも、正しい DNS とメールテストが必要です。独自 SMTP では実際のエンベロープドメインの SPF と、提供元の DKIM アライメントを確認します。
管理方法の例です。
| 構成 | 分散した管理 | 共通の作業 |
|---|---|---|
| 管理された送信 | メールホストと別の SMTP を接続する | TrekMail SMTP に正しい DNS を設定してアライメントを検証する |
| 独自 SMTP | 問題発生後に提供元の値を推測する | 実際の SPF と DKIM の要件を事前確認する |
| 複数ドメイン | 共通資料なしで個別に変更する | DNS テンプレートを調整してドメインごとに結果を監視する |
Managed TrekMail SMTP は該当する有料プランの送信を説明しています。現在の構成も確認してください。Bring Your Own SMTP では、実際のエンベロープドメインの SPF が送信プロバイダーを許可する必要があります。SPF が From とのアライメントを満たさなくても DKIM が成功してアライメントを満たせば、DMARC は成功します。
メールボックスとアプリの送信は別経路の場合があります。SES、SendGrid、Mailgun を使うアプリでは、適切なDMARC レコード例があっても、成功してアライメントを満たす認証がなければ失敗し得ます。
実務上は次を検討します。
- 共通の管理画面が必要なら、適した有料プランの管理された SMTP を比較する。
- 独自 SMTP では SPF、DKIM、DMARC をまとめてテストする。SPF の上限は DNS を必要とするメカニズムと修飾子を入れ子も含めて数える。
- 複数ドメインでは管理するレポート宛先と、環境に合う導入手順を記録する。
Starter の価格目安は月額 $3.50 からです。有料プランには 14 日間試用が提供され、Nano にはカード不要の無料オプションがあります。最新の定額プラン、上限、共有容量、IMAP 移行は TrekMail の料金で確認してください。
2026 年に DMARC レコードを段階的に導入する
2026 年も、DMARC レコード例は送信を確認してから段階的に導入します。直ちに Reject を使うと、忘れていた稼働中システムへのリスクが増えます。
- 監視から始めます。
v=DMARC1; p=none; rua=mailto:dmarc@example.com - まず例えば 7 から 14 日間レポートを分析し、請求、CRM、サポート、転送と照合します。低頻度の重要な処理には追加テスト、ログ、長い観察が必要です。
- 送信元ごとに認証成功とアライメントを検証します。合わない構成は修正し、必要なら管理された代替経路を計画します。
- 検証後に Quarantine を検討します。
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com - 残る失敗と重要なテストを確認して Reject を検討し、各段階で以前のレコードを置き換えます。
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
代理店やドメインのポートフォリオには、単発の修正より記録された手順が役立ちます。TrekMail はプランに応じて複数ドメイン管理、定額料金、共有容量、サーバー側 IMAP 取り込みをまとめられます。取り込みはメールをコピーし、MX やアプリの切り替え計画を代替しません。
適したDMARC レコード例は実際の送信元と希望するポリシーに合うものです。レポートは確認の一部にすぎません。アライメントを修正してから隔離や拒否を検討することでなりすましを制限できますが、配信や完全な保護は保証しません。
TrekMail はプランに応じてメールボックス、DNS ガイド、管理されたまたは独自 SMTP、複数ドメイン管理を提供できます。trekmail.net で比較する際は、定額プランのリソースと機能の上限も確認してください。
