2026 年には適切なDMARC レコードがメール構成の重要な部分です。Google と Yahoo は対象送信者に認証要件を求め、Microsoft も独自の規則を適用します。欠落は拒否や振り分けに影響する場合がありますが、すべてのメールが自動で使えなくなるわけではありません。
DMARC レコード (Domain-based Message Authentication, Reporting, and Conformance) は DNS TXT の方針です。表示上の From ドメインに有効で整合した認証がないメールの扱いを要求します。受信側の判断とフィルターは残り、内容検査を置き換えません。
一人の創業者では投資家へのメールにリスクが生じ、500 ドメインを管理する MSP では QuickBooks の請求書が見つからない問い合わせになる場合があります。規則は規模だけでなく送信種別と受信側によります。認証はリスクを減らしますが、到達を保証しません。
本ガイドはDMARC レコードの仕組み、失敗と、必要に応じた p=rejectへの計画的な移行を説明します。採用は送信元の一覧とテストから決めるもので、無停止の保証ではありません。
DMARC レコードの役割
DMARC レコードは認証と方針の層で、独立した迷惑メール検査ではありません。「自分の表示ドメインを使うメールに有効で整合した認証がなければ、どの扱いを受信側へ求めるか」を公開します。
会場に例えると、SPF はエンベロープドメインの許可 IP を確認し、DKIM は署名対象の封印、DMARC は表示ドメインとの関係と扱いの要求を担当します。DMARC がなくても受信側は独自に判断し、すべてを通すわけではありません。
DMARC レコードがないと Gmail や Outlook は公開された DMARC 要求を得られませんが、他の規則は残ります。公開名は対応する From ドメインの _dmarc です。同名の複数 DMARC 方針は無効ですが、別の TXT 内容はそれだけで禁止されません。明確な要求であり、全受信者への強制命令ではありません。
三つの方針と p=タグ
p=は DMARC 失敗時に求める方針です。整合、サブドメイン、レポート先などの他の項目も設定と監視に重要です。
| 方針 | 受信側への要求 | リスク | 用途 |
|---|---|---|---|
p=none |
DMARC に基づく隔離や拒否を求めない。 | 追加で求める DMARC 処置はゼロだが、全リスクがゼロではない。 | 別途設定したレポートで監視。ローカルな振り分けや拒否は可能。 |
p=quarantine |
失敗メールの隔離や迷惑メール扱いを求める。 | 正当な送信元と受信側規則による。 | 一覧、テスト、戻す手順を準備した後の移行段階になり得る。 |
p=reject |
DMARC 失敗の拒否を求める。 | 誤設定で正当なメールが影響を受ける場合がある。 | 直接のドメイン詐称を抑える助け。全フィッシング防止や到達の保証ではない。 |
p=rejectは準備後の目標になり得ますが、全環境で即採用すべきではありません。急な変更で会計ソフトの請求書を一週間調べることになるかもしれません。これは危険性の例で、多くの組織について実証した統計ではありません。
無条件に切り替えず、以下を実際の経路に合わせて使ってください。
SPF、DKIM、DMARC の関係
DMARC は SPF と DKIM を使い、少なくとも一つの検証が成功し、ドメインが整合している必要があります。許可する送信元の一覧が不完全だったり署名に問題があったりすると、厳しい方針で正当なメールに影響する場合があります。ただし、両方の同時成功は必須ではありません。
三つの役割は次のとおりです。
SPF (Sender Policy Framework)
役割：実際に検査する MAIL FROM ドメイン、該当する場合は HELO に対して IP を許可します。接続 IP を照合し、表示上の From を直接検査しません。
制約：転送で元のエンベロープが残り、新 IP が許可されていなければ失敗する場合があります。全転送で必ず失敗するわけではありません。
手順はSPF 設定、基礎はメールの SPF レコードを確認します。DNS 参照を要する該当メカニズムと修飾子の評価上限はSPF 参照上限の改善を参照してください。
DKIM (DomainKeys Identified Mail)
役割：選択したヘッダーと対象本文を正規化規則で署名し、署名はヘッダーに入れます。受信側は DNS 公開鍵で検証します。
強み：署名対象が保たれ、他の検証条件も満たされれば転送後も成功する場合があります。本文が変わらないだけでは保証されず、ヘッダーや鍵も確認が必要です。DMARC の成功にはドメインの整合も必要になります。
DMARC の方針
規則：成功した SPF または任意の有効な DKIM 署名が、表示 From ドメインと整合していれば成功します。両方を管理するのは有用ですが、どちらか一つの検証が成功し、ドメインが整合していれば十分です。
詳しくはSPF、DKIM、DMARC の設定順序を参照してください。
整合を理解する
経験のある管理者も整合を見落とす場合があります。SPF と DKIM が別々に成功し、正しい DMARC を DNS に公開していても、DMARC が失敗する場合があります。どのドメインの検証が成功したのかが重要です。
まず二つの送信元アドレスを分けます。
- Header From：メール画面に表示されるアドレス、例えば
support@yourcompany.com。 - Envelope From (Return-Path)：バウンス処理用の技術的なアドレスで、外部送信者が管理する場合があります。DKIM には別途署名ドメインがあります。
DMARC は表示 From と、成功した SPF のドメインまたは有効な DKIM 署名のドメインの整合を求めます。Strict は完全一致、relaxed は対応する組織ドメインの一致を認めます。成功した検証のドメインが整合していなければ、個々の成功だけでは DMARC は通りません。
典型例：Mailchimp などのマーケティングツール
次はニュースレターの構成例です。
- Header From：
news@yourcompany.com - Return-Path：
mail12.mailchimp.comはバウンス用ホスト名の例で、完全なアドレスではない - DKIM 署名：
d=mailchimp.comで署名
個別の成功を仮定すると、次の結果になり得ます。
- SPF は
mailchimp.com配下の実際のエンベロープドメインを検査し、成功する場合がある。 - DKIM は署名ドメイン
mailchimp.comを検査し、成功する場合がある。 - DMARC は
yourcompany.comとmailchimp.comを照合する。この例では整合しない。 - 他に検証が成功し、ドメインが整合する手段がなければ、DMARC はFail.
つまり個別に SPF と DKIM が成功しても DMARC は失敗します。事業者の現在の既定構成を説明したものではありません。
対処：独自ドメイン認証
マーケティング、CRM、トランザクションサービスそれぞれの実ドメインを確認します。対応する独自ドメイン認証は整合を可能にする場合がありますが、両方を必ず同時に整合させる必要はありません。
- SPF 整合：
bounces.yourcompany.comなどを実際の MAIL FROM に使い、SPF が成功する必要があります。DNS 種別は事業者により、CNAME だけでは保証されません。Relaxed は組織ドメイン、strict は From との完全一致を確認します。 - DKIM 整合：現行の鍵を公開または委任し、事業者側で例えば
d=yourcompany.comとして署名を設定します。DNS 公開だけでは署名は変わりません。
100 顧客ドメインを事業者ごとに設定するのは負担になる場合があります。TrekMail の必須 DNS 設定は準備を助けますが、実値、外部 DNS 公開、実署名の確認は各対象名で必要です。全ポートフォリオを自動で設定するものではありません。
詳しくはDMARC 整合を参照してください。
段階的な導入
急いで p=rejectにすることも、監視計画なしに p=noneのままにすることも適切とは限りません。段階は判断を助けますが、全環境での期間や無停止を保証しません。
段階 1：監視方針を公開 (第 1-4 週)
追加の DMARC 処置を求めない構成から始められます。
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.comレポートを集め、送信元一覧も確認します。四週間は月次の給与、ニュースレターなどを含める場合がありますが、四半期請求や全送信元を保証しません。一週間では重要な経路を逃す場合があります。実周期に合わせ、能動的なテストを加えます。
段階 2：未登録の送信サービスを探す
下のレポート節のツールを使い、観測を三つに分けます。
- 許可され整合している：主プラットフォームと既知の業務送信元。予期しない失敗は強化前に修正する。
- 許可されているが整合しない：追加のマーケティングツール、ヘルプデスク、2022 年からの CRM など。正当な経路を設定してテストする。
- 潜在的な脅威：未知 IP は詐称だけでなく転送者や忘れたサービスかもしれない。文脈を確認し、
p=rejectが未知の全経路や全攻撃を必ず止めるとは考えない。
次へ進む前に、既知の正当な経路を適切に整合させ、監視と戻す手順を準備してください。
段階 3：管理された隔離テスト
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com隔離は失敗時の扱いを要求し、受信側が別の判断をすることもあります。レポート、テスト到達、問い合わせを能動的に確認します。被害の報告を待つ間に重要なメールが影響を受ける可能性があります。
旧 pct=は現行仕様から削除されましたが、古い実装は割合として処理する場合があります。pct=25はそこで 25% の失敗を扱う例です。段階 1 と 2 を終えたから即 100% が安全とは限りません。実際の受信側対応を確認し、適切な段階的手順と戻す方法を選びます。
段階 4：拒否を要求する
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com準備が十分なら p=rejectは保護する From ドメインの直接詐称を抑える助けになります。しかし類似ドメイン、表示名、侵害アカウントなどの全フィッシングを防がず、全受信側の拒否や Google の評価、受信トレイ入りを保証しません。
設定はDMARC の設定方法を参照し、各段階のレコード例は現行値と実送信元を検証してから使います。
転送、ARC、DKIM の役割
「通常は送れるのに、弁護士へ送ると戻る」。転送が原因の場合もありますが、十回中九回という主張は確認された一般統計ではありません。方針は扱いを求めるもので、診断の代わりではありません。
転送が SPF に及ぼす影響
contact@smallfirm.comへ送り、そのサーバーがpersonal@gmail.comに転送します。Gmail は smallfirm.comの接続を見ます。元のエンベロープを維持し、自社 SPF が smallfirm.comを許可しないなら、SPF が失敗する場合があります。
SPF だけが整合する手段だった場合、DMARC は失敗することがあります。必ずここで破棄されるわけではありませんが、経路を確認します。
DKIM が転送後も有効な条件
DKIM 署名はヘッダーにあり、選択したヘッダーと署名対象の本文部分を保護します。正規化後も有効で他の条件が満たされれば、Gmail は検証できます。ドメインが整合していれば SPF が失敗しても DMARC は成功する場合があります。件名を変えずフッターもないというだけでは保証されません。
そのため DKIM は多くの経路で重要で、該当する要件では必須です。SPF を補いますが、任意の変更後に成功するとは限りません。
中間で DKIM が変わる場合の ARC
メーリングリストや安全対策ゲートウェイの変更で、DKIM が失敗する場合があります。ARC (Authenticated Received Chain) は前の検証結果について署名された情報を伝えます。受信側の判断材料になっても、失敗した DMARC を自動で成功へ変えません。
Google と Microsoft は ARC を考慮する場合があります。チェーンの暗号学的な有効性と、中間サービスへの信頼は別です。通常は転送インフラが扱い、ヘッダーの存在や arc=pass だけで DMARC pass、受理、受信トレイ入りは保証されません。
詳しくはDMARC 失敗と転送を参照してください。
RUA と RUF：レポートの選択
有効な rua=の宛先を公開すると、対応する受信側に XML を求められます。全大手が全メールを報告するわけではありません。ツールは大量のファイルを見やすくしますが、XML を直接調べることも可能です。外部宛先には追加の認可が必要な場合があります。
RUA：集計レポート
タグ： rua=mailto:reports@yourdomain.com
RUA は観測結果をまとめ、通常は一日ごとに提供されますが、網羅性や期限は保証されません。例として IP 203.0.113.12 が 300 通送り、295 通が DMARC 成功、5 通が失敗したと示します。量、送信元、検証と処置を見られますが、検証結果だけでは最終的にどのフォルダーに入ったかは分かりません。
可視化にはdmarc.org のツール一覧や、現行提供に応じた Postmark、Valimail などを検討できます。既知 IP の失敗は調べます。未知や外国の IP だけで攻撃や p=rejectによる遮断を確定せず、項目と文脈を確認します。
DMARC レポートと DMARC RUA の記事で分析を深められます。
RUF：個別の失敗レポート
タグ： ruf=mailto:forensics@yourdomain.com
RUF は個別失敗の情報を含み、受信側によってヘッダーや一部内容がある場合があります。常に全メッセージのコピーではなく、全原因を確定できるとも限りません。
プライバシーを考慮します。従業員の機密情報が報告に入る可能性があり、宛先、権限、保存期間と処理を組織の要件に合わせます。自動的に違法という意味ではありません。
多くの受信側は RUF を提供せず、または内容を制限し、Gmail は対応していません。多くの運用では RUA が出発点になります。RUF は必要性とプライバシーを確認してから使い、役立つ情報と分析負担の比率は実際の運用に応じて判断してください。
DMARC RUF の記事は得られる情報と、必要かどうかの考え方を説明しています。
未知の失敗を無条件に無視しない
RUA には古い転送経路、詐称、忘れた正当なサービスも現れます。少量の未知 IP は攻撃の証明でも、無関係の証明でもありません。パターンを探し、低頻度でも重要な送信元を確認します。
p=reject を選ぶ時期
p=rejectは十分な準備後に適する場合があります。変更前に確認します。
- 30 日の監視は例：月次を含めても四半期の全経路は保証できません。一週間は短い場合があり、一覧と能動テストを加えます。
- 主経路が整合する：TrekMail、Google Workspace、Microsoft 365 が実経路で DMARC に成功し、SPF や DKIM だけの成功ではない。
- 外部サービスを確認した：マーケティング、トランザクションメール、CRM、ヘルプデスクが有効な整合手段を持ち、必要に応じて対応する独自ドメイン認証を設定する。
- マーケティングに確認した：新ツールを聞く。先週火曜からのサービスは一覧や不完全なレポートにまだない場合がある。
- サブドメイン方針を選んだ：より適切な独自方針がないとき、親方針が適用される場合がある。
sp=noneは監視段階の例：v=DMARC1; p=reject; sp=none; rua=mailto:reports@yourdomain.com。継承と一時的な保護の空白を確認し、実経路を調べてからsp=を強化する。
p=reject後も監視します。正当な経路の失敗が確認されたら、準備した一時的な戻す手順、例えば p=quarantineを検討し、権威 DNS とキャッシュを確認します。既に拒否されたメールは復元されず、即時反映や到達も保証しません。直接詐称を抑える価値はあっても、全体のメールドメイン評価の改善保証ではありません。
拒否方針の解説とDMARC 失敗の診断と改善も参照してください。
TrekMail で複数ドメインを管理する
一ドメインでも継続管理は必要です。一か月の監視と修正、強化の検討は例で、後の送信元変更には再確認が必要です。
数十から数百のドメインでは反復できる手順が必要です。初日から確認し、サービスを登録して、例えば月次の監視と変更時のテストを行います。
手動では各 DNS に入り、公開、キャッシュ確認、テストを繰り返します。50 ドメインの設定に午後の時間を費やすのは所要時間の一例で、500 ではツールが役立つ場合があります。自社管理が必ず拡張不能という意味ではありません。
TrekMail の現行必須 DNS レコード機能は、初期の監視方針などの案を作る助けになります。公開前に実値と一覧を確認します。DNS 状態の確認は概要を示す場合がありますが、実メールや全流量の証拠を置き換えません。
適切に設定した管理型 SMTPは独自ドメインで署名できる場合があります。現行説明に沿って DNS とセレクターを公開し、実際の整合を確認します。管理型や持ち込みの全経路が自動で設定されるとは限りません。
原文は Pro を月額 $8、100 ドメイン、各ドメイン 300 ユーザー、50GB 共用容量とし、一人 $6-12 と比較しています。過去の例であり、現在のプラン、機能、契約、上限によって費用は変わります。顧客が増えても常に追加費用なしとは言えません。
1,000+ ドメインには原文で Agency を示しています。適合性と費用は現行条件と必要機能で判断し、全料金を確認します。
DMARC レコードについてのまとめ
DMARC レコードを管理し、該当する規則を満たしてください。欠落はリスクですが、全受信側がすべての未認証メールを必ず拒否するという意味ではありません。
監視方針を公開し、実周期に沿って例えば一か月観測して正当な送信元を修正します。隔離と拒否は一覧、テスト、戻す手順の後の選択肢です。その後もレポートと経路を確認します。
同じ作業の繰り返しは負担を増やします。ある午後に自分のドメインを設定するというのは一例で、複数の顧客のドメインには追跡できる運用が必要です。TrekMail は現行機能で支援しても、全運用をなくすものではありません。
DMARC レコードに p=rejectを選ぶ前に、準備と経路を確認します。その上で費用と必要機能を比較し、他の製品を一律に高すぎると見なさないでください。
