DMARC の設定方法：送信元とアライメントを確認

DMARC の設定方法を調べているなら、最初から p=reject に進まないことが大切です。監視から始め、実際の送信元ごとに SPF または DKIM の認証成功と From アライメントを確認してから、段階的にポリシーを強めます。請求書、パスワード再設定、見落としていた SaaS のメールへの影響を抑えながら、ドメインなりすましを制限する助けになります。

実際の構成は複雑です。メールボックスは Microsoft 365、請求書は外部アプリ、マーケティングは別のプラットフォームから送り、倉庫の複合機もスキャンをメール送信しているかもしれません。送信元を見落とすと、制限ポリシーが業務の障害につながります。ドメインメールの構築には自分のドメインでメールを設定する方法と、全体を説明するビジネスメールのガイドも役立ちます。

ここでは運用の順序に沿って、監視、検証可能な結果の収集、アライメントの修正、制限の要求を説明します。レコードの公開だけで確認作業が済むわけではありません。

DMARC が実際に行うこと

DMARC は、自社ドメインを名乗るメールがアライメントを満たす認証に失敗した場合、受信サーバーに希望する処理を伝える DNS ポリシーです。SPF と DKIM を利用し、少なくとも一方が認証に成功して表示上の From ドメインとのアライメントを満たせば、DMARC は成功します。

DMARC は Domain-based Message Authentication, Reporting, and Conformance の略です。認証失敗時のポリシーを公開し、レポートを要求できます。基本仕様は RFC 7489 です。認証成功は本文の安全性や配信の保証ではありません。

設定では次の関係を理解しておきましょう。

• SPF に成功しても From とのアライメントを満たさない場合があります。その場合でも、DKIM が認証成功とアライメントを満たせば DMARC は成功します。
• DKIM の認証成功だけでも足りません。ただし SPF が成功し、From とのアライメントを満たせば、DMARC は成功できます。
• SPF または DKIM のどちらかが認証成功とアライメントを同時に満たせば、DMARC は成功します。

Google が説明する一括送信者の要件には SPF、DKIM、最低限 p=none を指定した DMARC レコードがあります。対象の送信者は SPF または DKIM による From アライメントも必要です。最新の適用条件は Google の送信者ガイドラインに関する FAQを確認してください。

DMARC を設定する前の確認

まず送信構成を確認します。SPF の不備、DKIM の未設定、別のドメインによる署名は、制限を要求した際に正規のメールへ影響する可能性があります。監視ポリシーが認証エラーを作るのではなく、既存の不備を把握する手掛かりになります。

最初に三つの項目を確認しましょう。

1. SPF：実際のエンベロープ送信者ドメインに適切な単一レコードを設定します。10 の上限は、入れ子の評価を含めて DNS を必要とするメカニズムと修飾子を数えるもので、すべての DNS 問い合わせ数ではありません。
2. DKIM：対応する送信元で有効化して検証します。プロバイダーが適切に対応している場合は、2048 ビットの鍵を使用します。
3. 送信元一覧：メール基盤、CRM、請求、サポート、フォーム、スキャナー、マーケティングなど、自社の From を使うシステムをすべて列挙します。

TrekMail のドメインでは、必須の DNS レコードとドメインの追加が基本資料です。DNS 検査は不足や重複を見つける助けになりますが、実際のメール認証は別にテストする必要があります。

請求アプリが billing@yourdomain.com で送信しても、署名ドメインと Return-Path が提供元のものなら、SPF と DKIM は提供元について成功するだけかもしれません。自社の From とのアライメントを満たす成功結果がなければ、DMARC は失敗します。

制限を要求した後に発覚する問題には、こうしたアライメントの不一致があります。

ステップ 1：監視用の DMARC レコードを公開する

送信経路を十分に検証していない場合は、監視から始められます。p=none は DMARC による隔離や拒否を要求しません。入手できたレポートは調査に役立ちますが、提供は保証されず、受信側のフィルターは引き続き適用され得ます。

_dmarc.yourdomain.com に次の値の TXT レコードを作成します。

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

同じレコードをゾーンファイル形式で示した例です。追加レコードとしては公開しません。

_dmarc  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

これは RFC 7489 の例の基本形に沿っています。レポートには、個人の受信箱ではなく管理する専用アドレスやエイリアスを使います。集計レポートは XML で、短期間に増える場合があります。アクセス権と、外部宛先で必要になり得る宛先側の DNS 承認も確認してください。

実際に DNS を管理するサービスで公開し、他の認証経路も検証します。TrekMail のメールが迷惑メールに入る場合の FAQは、転送による通常の変化と、追加調査が必要な問題を整理する際にも役立ちます。

ステップ 2：レポートを分析して送信元を確認する

分析を省略しないでください。レポートは送信元や不備の手掛かりを示しますが、すべてのメールを網羅せず、それだけで正規の送信と悪用を確実に分類することもできません。

レポートには次のような情報が含まれます。

• 報告する受信側が観測した送信元 IP
• SPF の認証結果
• DKIM の認証結果
• From ドメインとのアライメント結果
• 受信側が報告した処理

調査では、まず二つの分類が役立ちます。

既知の正規システムでアライメントが失敗していれば修正します。未知の送信元は特定が先です。悪用の可能性だけでなく、転送や共有送信サービスも考えられます。また、認証成功だけでは内容の安全性は分かりません。

次の表は例であり、プロバイダーの固定的な初期動作ではありません。

多数のドメインでは、新しい SaaS ごとに送信設定が増えます。共通の運用手順を検討する際はマルチドメインメールホスティングが参考になります。ただし、問い合わせ削減の幅を保証するものではありません。

ステップ 3：認証だけでなくアライメントを修正する

必要なのは、SPF または DKIM の少なくとも一方が認証成功とアライメントを満たすことです。緩和モードでは認証ドメインと表示上の From が同じ組織ドメインを持つ必要があり、厳密モードでは完全一致が必要です。

RFC 7489 は RFC5322.From のドメインを基準に緩和アライメントを定義しています。Google の FAQ でも、DMARC には SPF または DKIM のどちらかが成功してアライメントを満たせばよいと説明されています。両認証方式の設定は適用される送信要件に従います。

よくある修正は次のとおりです。

• マーケティング基盤では、自社ドメインの DKIM 署名を設定して検証します。
• バウンス処理では、対応していれば独自 Return-Path やブランド用のバウンスドメインを設定します。
• Microsoft 365 では、制限を要求する前に独自ドメインの DKIM を有効化してテストします。
• TrekMail の管理された送信では、実際の送信経路に表示された SPF と DKIM のレコードを正確に公開します。

管理画面を集約しても、適切な DNS 設定は必要です。TrekMail は設定用のレコードを示し、プランに応じて管理された SMTP や Nano での独自 SMTP を利用できる場合があります。メールボックスと送信サービスは別々に検証してください。

Nano では自分の SMTP プロバイダーから送信し、該当する有料プランには管理された SMTP が含まれます。TrekMail の価格目安は月額 $3.50 からで、有料プランの 14 日間試用も提供されています。Nano にはカード不要の無料オプションがあります。最新の機能と条件は TrekMail の料金を確認してください。

ステップ 4：Quarantine を中間段階として検討する

監視とテストの後、Quarantine を検討できます。ただし、すでに制限的な処理を要求するポリシーです。失敗メールを疑わしいものとして扱うよう求めますが、特定の迷惑メールフォルダーへの保存や復旧は保証されません。低頻度の正規送信も確認が必要です。

進められると判断したら、以前のレコードを次に置き換えます。

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

Reject の前に Quarantine を検討する理由は何でしょうか。

• ドメイン認証に失敗したメールへの制限を要求できる。
• 受信側によっては、拒否よりも取り消しやすい扱いになる可能性がある。
• さらに結果を観察できる。ただし正規のメールへのリスクは残る。

期間は送信周期によって異なります。数週間は計画上の目安になり、30 日も一例にすぎません。まれに送る重要なメールや四半期の処理は、個別テストや長い観察が必要です。

この段階で、未記録の WordPress プラグイン、CRM のテスト環境、古い複合機、月次で送る業者などが見つかることがあります。Quarantine はその検証の代わりにも、損失のない緩衝策にもなりません。

ステップ 5：結果を確認して Reject を検討する

p=reject は、失敗メールを疑わしいと扱うだけでなく、受信拒否を要求します。直接のドメインなりすましを制限する助けになりますが、最終判断には受信側のローカルルールが影響します。

次のレコードは以前のポリシーを置き換えるもので、追加公開はしません。

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

RFC 7489 は p=reject による DMARC 失敗時の拒否要求を説明しています。受信側はローカルな例外を適用でき、あらゆる詐欺の防止や本文の安全性は保証されません。

移行前に少なくとも次を確認します。

• 主なメールサービスの送信が認証成功とアライメントを満たす
• マーケティングとトランザクションメールも認証成功とアライメントを満たす
• 数週間の利用可能なレポートを分析し、低頻度の重要な処理もテストした
• 残る失敗について理由を説明できる

移行後もレポートと実際のメールを確認します。新サービスや送信設定の変更にも、同じ検証手順を適用してください。

メールに影響するよくある設定ミス

見落とした送信元、重複した SPF、未設定の DKIM、修正していない提供元の認証ドメインは、厳しいポリシーで問題になる可能性があります。DMARC 要求だけでなく、実際の送信構成を調べましょう。

• DKIM を有効化してテストする前に制限を要求する
• 整合性を確認した単一レコードではなく複数の SPF を公開する
• SPF pass を DMARC pass と同じだと考える
• 少量しか送らない業者を見落とす
• 検証せずに直接 p=reject に進む
• 管理していない受信箱にレポートを送る

転送で SPF が失敗しても、有効でアライメントを満たす DKIM 署名が残れば DMARC は成功します。そのためには、正規化規則のもとで署名対象のデータが保持される必要があります。運用全体についてはメールエイリアスの転送と安全なビジネスメールも参考になります。

DMARC 設定の短いチェックリスト

次の一覧は段階的な流れをまとめたものです。実際の送信元と業務周期に合わせて調整します。

1. 自社の From を使う全システムを洗い出す。
2. 実際のエンベロープドメインに有効な単一 SPF を設定する。
3. 対応する送信基盤で DKIM を有効化して検証する。
4. v=DMARC1; p=none; rua=mailto:... を公開する。
5. レポートを既知の送信元と照合し、未知の通信を調べる。
6. 正規の送信元ごとに認証成功とアライメントを確認する。
7. テスト後に p=quarantine を検討する。
8. レポートと重要なメールを再確認する。
9. 結果を把握した後に p=reject を検討する。

まとめ：DMARC を検証しながら設定する

実用的な流れは p=none から始め、レポートを送信元一覧と照合して SPF と DKIM のアライメントを修正することです。テスト後に p=quarantine、その後に p=reject を検討できます。設定ミスのリスクを抑える手順ですが、配信や完全ななりすまし防止を保証しません。

多数のドメインには共通の管理ツールが役立ちます。TrekMail はプランに応じて独自ドメイン、IMAP メールボックス、キャッチオール、転送、移行、独自または管理された SMTP を提供できます。IMAP 移行は既存メールをコピーするもので、MX、アプリ、送信の全面的な切り替えは別に計画します。定額プランにも上限があり、DMARC の適切な設定は必要です。

これが運用を重視したDMARC の設定方法です。まず検証し、根拠を確認してからポリシーを強め、レポートと実際のメールテストを継続して照合しましょう。