DMARC ポリシー: 段階的な適用と確認

DMARC ポリシーは、自分の From ドメインを使うメールが DMARC に失敗したときの扱いを受信側に伝えます。最終的な判断は受信側のルールによります。早すぎる適用は請求書、サポート返信、転送メールにも影響しますが、丁寧な設定はドメインの直接的ななりすましを抑えるのに役立ちます。全体像はビジネスメールのガイドをご覧ください。

問題はプロトコルの複雑さより、実際の送信元の確認不足で起こりがちです。p=none のまま結果を見ないか、正規の送信元で認証とアライメントを確認する前に p=reject を設定すると、必要なメールも拒否される場合があります。

実用的な進め方は、p=none で実際の送信元を把握し、認証成功とアライメントを確認してから p=quarantine を検討することです。残る失敗を調査した後で p=reject を検討します。失敗がすべてなりすましとは限らず、移行時期は運用に合わせます。

DMARC ポリシーとは

DMARC ポリシーは、From に自分のドメインを使いながら DMARC に失敗するメールへの処理要求です。選択肢は none、quarantine、reject です。正規の送信元で SPF または DKIM が成功し、アライメントを満たしているかが重要です。

受信側は SPF と DKIM を検証し、表示上の From ドメインとのアライメントも確認します。少なくとも一つの方式で認証成功とアライメントがそろう必要があります。

SPF が成功しアライメントを満たせば、DMARC は成功します。

DKIM が成功しアライメントを満たせば、DMARC は成功します。

成功したアライメント付き経路がなければ、受信側が DMARC ポリシーを考慮します。

ポリシー	レコード	受信側に求める処理	用途
None	`p=none`	DMARC による制限は求めず、レポートを要求	送信元の把握と監視
Quarantine	`p=quarantine`	疑わしいメールとして扱う、例えば迷惑メールへ	段階的な制限
Reject	`p=reject`	受信拒否を要求、通常は SMTP での処理	より厳格な制限

最初に選ぶ DMARC ポリシー

すべての送信元で認証成功とアライメントを確認していなければ、p=none から始める方法があります。制限を要求する前に、実際のトラフィックを観察します。

初期レコードの例です。

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

このモード自体はなりすましの拒否を求めません。レポートを送る受信側から状況を把握できますが、すべての受信側が報告するわけではありません。送信システムが想定より多い場合もあります。

見落としやすい送信元です。

請求書を送る会計ソフト。
採用通知を送る人事や採用ツール。
キャンペーンを送る CRM やマーケティングサービス。
主要ドメインから返信するヘルプデスク。
次の送信地点で SPF に影響するユーザーの転送ルール。

観察を省くと、実際の業務メールに制限がかかる場合があります。DNS の構文だけでなく送信経路を確認してください。

一括送信者には DMARC レコードも重要な送信要件に含まれます。Google はドメイン認証とアライメントを扱っています。ここで説明するプロトコルは RFC 7489 に記載されています。

none のまま観察する期間

none で二週間から四週間の観察を出発点にできますが、すべての送信周期を含むとは限りません。月次やまれな処理には、長い観察期間や個別テストが必要な場合があります。

三日間では月次請求書、四半期の通知、まれにパスワード再設定を送る古いアプリを見逃しがちです。

次の流れを含めます。

通常の業務メール。
マーケティング送信。
請求サイクル。
サポートのエスカレーション。
転送メール。
外部サービスの自動処理。

取得できた集計レポートを調べ、既知の正規送信元、疑わしい送信元、まだ原因が分からない失敗を分けます。報告は網羅的とは限らず、失敗がすべて偽装とは限りません。

例: ニュースレターサービスが自分のサービスドメインで署名し、SPF もアライメントを満たさないサービスドメインで成功しています。成功したアライメント付き経路がないため DMARC は失敗します。Reject より先にアライメントを直します。

TrekMail の DNS 設定は必要なレコードを示し、検証を支援します。ただし、すべての送信元の把握を代替するものではありません。ドメインの追加と必要な DNS レコードをご覧ください。

転送で DMARC に影響が出る理由

転送で送信サーバーが変わると、元の SPF が失敗する場合があります。成功したアライメント付き DKIM が重要な理由です。ポリシー自体は検証を変えず、成功したアライメント付き経路がなければ DMARC が失敗する場合があります。

経験のある管理者も、この違いを理解する必要があります。

メールには複数の送信者識別情報があります。利用者に見えるのは From で、エンベロープ送信者はバウンス処理に使われます。SPF はそのドメインと送信 IP を確認し、DMARC は認証済みドメインと表示上の From のアライメントを確認します。

転送後の IP は元の SPF の許可に含まれない場合があります。DKIM は、署名対象の内容が正規化ルール上維持されれば成功できます。

そのため、両方が成り立ちます。

転送後に SPF が失敗する。
DKIM が成功しアライメントを満たすため、DMARC は成功する。

転送が重要な業務では、制限を適用する前に実際の経路と正規送信元の成功したアライメント付き DKIM をテストします。Gmail はドメインのメールを Gmail に転送する、一般的な問題はメール転送の設定が参考になります。

ARC は中間システムやメーリングリストを通じて認証の文脈を伝えますが、自分のアライメントの代わりではありません。情報の採用は受信側が判断します。プロトコルは RFC 8617 にあります。

quarantine に移行する時期

レポートと個別テストで、正規の送信元の SPF または DKIM が成功しアライメントを満たすと確認してから、quarantine を検討します。疑わしい扱いを求めますが、迷惑メールフォルダーへの保存や回収できることは保証しません。

レコードの例です。

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

見落とした送信元が迷惑メール判定などで分かる場合があります。ただし受信側は別の処理を選ぶ場合もあり、自分でも確認とフィードバック収集が必要です。

対応手順の例です。

利用者がメールの不足を報告する。
送信元、認証、アライメントを調べる。
SPF、DKIM、または両方を直す。
Reject を検討する前に再テストする。

pct=25 や pct=50 で段階的に進めるチームもあります。受信側の対応や処理は異なり、比率どおりの適用は保証されません。100% への移行にも十分な検証が必要です。

適切に設定された TrekMail の管理型 SMTP は、ドメインで署名できます。実際のヘッダーとアライメントを確認してください。転送後に SPF が失敗しても DKIM が成功するケースはメールが迷惑メールになる場合で説明されています。

reject に移行する時期

正規の送信元を確認し、残る失敗を調査した後で reject を検討します。DMARC 失敗メールの受信拒否を求めるもので、受信側すべてに同じ処理を保証するものではありません。

レコードの例です。

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

準備ができれば、多くのドメインで検討できる目標です。

期待できる役割は次のとおりです。

保護対象ドメインの直接的ななりすましを抑える。
一部のフィッシングや送信者ドメインの悪用を難しくする。
認証失敗時に望む扱いを明示する。
広いブランド保護策の一部になる。

Google の FAQ は DMARC 関連の 4.7.31、アライメントの 4.7.32 など、拒否や制限を説明しています。バウンスには 5.7.26 とドメインポリシーが記載される場合もあります。全文を確認し、Google のメール送信者ガイドライン FAQと照合します。

注意点として、古い会計 SaaS に成功したアライメント付き経路がなければ、請求書が拒否される場合があります。事前に確認し、障害時の対応を計画してください。

DNS に公開する DMARC ポリシーレコード

ポリシーは _dmarc.yourdomain.com に TXT として公開します。その名前に公開する DMARC ポリシーレコードは一つにします。矛盾する複数レコードは処理を妨げる場合があります。

次は選択肢ごとの例であり、同時に公開するものではありません。

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
_dmarc.example.com  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
_dmarc.example.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

TrekMail の DNS 設定では通常、MX、SPF、DKIM、DMARC をまとめて扱います。次は構造の例であり、直ちに Quarantine を適用する指示ではありません。SPF と DKIM も実際の送信サービスに合わせます。

@                MX   10 mail.trekmail.net.
@                TXT  "v=spf1 include:spf.trekmail.net -all"
dkim._domainkey  TXT  "<unique value from dashboard>"
_dmarc           TXT  "v=DMARC1; p=quarantine;"

SPF を重複公開せず、DKIM 値を推測しないでください。古い MX の要否も確認します。持ち込み送信サービスでは、その指示に合わせて SPF と DKIM を設定し、アライメントを検証します。持ち込み SMTP（BYO）をご覧ください。

よくある DMARC ポリシーの間違い

分析しないままの p=none、早すぎる制限、SPF だけへの依存、サブドメインの見落としが典型例です。影響は実際の業務構成によります。

次の点に注意します。

none のまま分析も計画もしない。レポート自体は DMARC の制限を実行しません。
SPF の正常表示だけで DKIM アライメントを省く。転送で SPF への依存が明らかになる場合があります。
サブドメインの継承を忘れる。別のポリシーには sp= を使います。
SPF の制限を無視する。評価される DNS を伴う項目が 10 を超えると PermError になる場合があり、単純な全 DNS 照会数ではありません。
自分のドメインで送るサービスの署名方法を検証しない。

サブドメインの扱いを変える例です。

v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@yourdomain.com

主ドメインは Reject を求め、継承するサブドメインは None になります。選んだ一つのテスト用サブドメインだけの設定ではありません。個別の DMARC レコードがあれば、継承するポリシーを上書きできます。

TrekMail が DMARC 設定を支援する部分

TrekMail は複数ドメインの管理画面で DNS 確認、送信設定、共有ストレージを扱います。管理の分散を減らせる可能性はありますが、外部送信元の確認や十分な DMARC 観察を代替するものではありません。

価格の目安として、Starter は月額 $3.50 からで管理型 SMTP を提供し、Nano は持ち込み SMTP の無料プランとして案内されています。IMAP メールボックス、独自ドメイン、キャッチオール、転送、移行、API の利用条件は最新のプランと前提条件によります。選択前に価格と機能をご確認ください。

DMARC では、ドメインを使って送るすべてのシステムの把握が重要です。TXT の公開だけでは解決できません。

プランと設定に応じて、次のように運用できます。