DMARC の失敗は、設定が終わったと思った後に問い合わせとして届くことがあります。SPF は公開済みで、DKIM も有効です。DMARC ポリシーもようやく p=quarantine または p=reject にしました。ところが、正規のメールが転送されると届かなくなります。なりすましや迷惑メールとは限らず、構成が十分に考慮していなかった経路を通った可能性があります。
これが転送時のDMARC 失敗でよく見られる問題です。メール自体は正規のものでも、転送区間が配送状況や内容を変えると、受信側で十分な認証結果を得られなくなります。SPF と DKIM を設定画面のチェック項目としてしか捉えていないと、原因が偶然に見えます。しかし、多くの場合は追跡できるパターンがあり、それに沿って原因を調べられます。
基本構成を先に整えるなら、ビジネスメールから始めてください。すでに転送を使っている場合は、メール転送も参考になります。
DMARC の失敗が意味すること
DMARC の失敗とは、表示される From ドメインにアラインした SPF の成功も、有効でアラインした DKIM 署名も得られなかった状態です。認証が成功するだけでは不十分で、認証済みドメインと受信者に見えるドメインの関係も評価されます。
DMARC は SPF と DKIM を基に動作します。歴史的な仕様であるRFC 7489に記された基本原則では、以下のどちらかが成立すれば成功します：
- SPF が成功し、Header From ドメインにアラインしている。
- DKIM が成功し、Header From ドメインにアラインしている。
説明は単純ですが、運用では次の異なる考え方を混同するとDMARC の失敗につながります：
- 認証：SPF または DKIM が成功したか。
- アラインメント：成功したドメインが Header From ドメインに対応しているか。
- 転送後の維持：署名対象データの有効性が保たれたか。
SPF が成功してもDMARC は失敗することがあります。DKIM が成功してもDMARC は失敗することがあります。成功した認証ドメインがアラインしていなければ、DMARC に必要な条件を満たしません。
転送が DMARC の失敗につながる理由
転送は経路を変え、ときには内容も変えるため、DMARC の失敗を招くことがあります。SPF は接続元に依存し、DKIM は署名対象データに依存します。転送で片方が失敗し、不適切な変更で両方が影響を受ける場合があります。
よくある経路は次のとおりです：
- 送信者が
sender.comからメールを送る。 - 途中のメールボックスまたはゲートウェイが受信する。
- そのシステムが Gmail、Outlook、その他の宛先へ自動転送する。
最終受信側が SMTP クライアントとして見るのは、元の送信 IP ではなく、転送サーバーの IP になります。
ここにDMARC 失敗の原因があるかもしれません。
SPF が先に失敗する場合
SPF はRFC 7208で定義され、接続 IP がエンベロープドメインの送信元として許可されているかを確認します。
転送後は元の送信サーバーではなく転送サーバーが接続するため、SPF が失敗することがあります。SRS はエンベロープ送信者を書き換え、新しいドメインの SPF を成功させられる場合がありますが、元の From との DMARC アラインメントを自動で復元するわけではありません。
元の経路：
sender.comが IP A から送信し、SPF が成功する。
転送後の経路：中継者が IP B から転送する。受信側は IP B をsender.comに対して確認し、その IP が許可されていなければ SPF が失敗する。
SPF の失敗だけでDMARC の失敗が決まるわけではありません。アラインした DKIM が有効なら DMARC は成功できます。そのため、適切な DKIM 設定が重要です。
DKIM が認証結果を維持する場合
RFC 6376で定義される DKIM は、選択されたヘッダーと本文に署名します。転送 IP は署名の検証に関係しません。このため、SPF が失敗しても DKIM によって DMARC の成功を維持できる場合があります。
ただし、次の条件が必要です：
- 転送後も署名が有効である。
d=ドメインが表示される From ドメインにアラインしている。
どちらかが欠け、ほかにアラインした成功結果がなければ、DMARC は失敗します。
転送システムは小さく見えても署名に影響する変更を加えることがあります：
- 件名に
[EXTERNAL]を追加する - 免責事項や法的なフッターを付ける
- MIME 境界を書き換える
- 改行や空白を変える
Relaxed 正規化が許容する変更もありますが、すべてではありません。ゲートウェイが署名を無効にする場合もあります。転送メールのDMARC 失敗は実装に起因する可能性があるものの、失敗だけではなりすましの有無を証明できません。
転送なしでも起こるアラインメントの問題
DMARC の失敗に転送は必須ではありません。SaaS の送信サービスが、企業の From にアラインしない自社ドメインで認証している場合にも起こります。メールは正規でも、認証ドメインの関係が適切でない状態です。
この違いは運用で見落とされがちです。
例：
- From：
billing@yourcompany.com - Return-Path：
bounce.vendor-mail.com - DKIM：
d=vendor-mail.com
vendor-mail.com の SPF が成功し、vendor-mail.com の DKIM も成功するかもしれません。それでも DMARC は失敗します。ほかの成功した認証ドメインが yourcompany.com にアラインしていない場合です。
対策は独自ドメインの認証を適切に設定することです。アラインした DKIM は転送時に特に役立ちます。直接配送ではアラインした SPF だけで DMARC が成功する場合もあります。
エイリアスを多用する構成を見直すなら、ドメインメールのエイリアスとメールボックスを読み、隠れた転送経路や担当を整理してください。
ヘッダーから DMARC の失敗を調べる
多くのDMARC 失敗は、推測するよりヘッダーを読むほうが早く原因を絞れます。信頼できる受信システムが付加した Authentication-Results から始め、SPF、DKIM、アラインメントのドメインを比較します。任意の同名ヘッダーをそのまま信用してはいけません。
受信者に完全なヘッダーを依頼します。例えば、次の結果です：
Authentication-Results: mx.google.com;
spf=fail smtp.mailfrom=sender.com;
dkim=pass header.i=@sender.com header.s=mail;
dmarc=pass header.from=sender.comこれは、転送で SPF が失敗した一方、DKIM が維持された場合と整合します。DMARC は成功していますが、ほかの配送問題まで否定する結果ではありません。
次の結果では追加調査が必要です：
Authentication-Results: mx.google.com;
spf=fail smtp.mailfrom=sender.com;
dkim=fail header.i=@sender.com;
dmarc=fail header.from=sender.com転送後の典型的なDMARC 失敗かもしれません。経路変更が SPF に影響し、内容変更や元から無効な署名が DKIM に影響した可能性があります。ただし、この結果だけですべての原因は確定しません。
| ヘッダー結果 | 考えられる意味 | 対応 |
|---|---|---|
spf=fail、dkim=pass、dmarc=pass | 一般的な転送動作と整合する | 監視を続け、ほかの症状があれば経路を確認する。 |
spf=fail、dkim=fail、dmarc=fail | 転送による内容変更、または別の DKIM 問題 | 署名、正規化、実際の変更を確認する。 |
dkim=pass だが d= ドメインが非アライン | ESP またはリレーのアラインメント問題の可能性 | アラインした DKIM と、ほかの成功した認証ドメインを確認する。 |
spf=permerror | SPF が複雑すぎる、または構文が不正な可能性 | 原因を調べ、不要な include を削除する。フラット化では IP 変更の継続管理が必要。 |
arc=pass | ARC チェーンの暗号学的検証が成功 | 中継者への信頼と受信側ポリシーを確認する。DMARC の成功とは限らない。 |
転送メールの DMARC 失敗を減らす方法
利用者の転送を止めることはできません。DMARC の失敗を減らすには、転送を考慮した設計が適しています。アラインした DKIM、管理しやすい SPF、署名対象データをできるだけ維持する経路を整えます。
1. 各送信経路に DKIM を設定する
正規メールが転送後も認証を維持できるようにするには、アラインした DKIM が重要です。ニュースレターやサポートだけでなく、管理できるすべての送信経路を署名対象にします。
署名ドメインは可視の From にアラインする必要があります。yourdomain.com なら yourdomain.com、または relaxed アラインメントで条件を満たすサブドメインが使えます。厳密なアラインメントでは完全一致が必要です。
TrekMail の DNS 設定は必要な DNS レコードから確認できます。黄色や赤色の状態は調査してください。緑色でもすべての転送ケースの成功は保証されません。
2. DKIM の relaxed 正規化を検討する
Simple 正規化は小さな書式変更に敏感で、DMARC の失敗につながる場合があります。Relaxed は規定された空白やヘッダーの正規化を許容しますが、任意の内容変更に耐えるものではありません。
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail;
c=relaxed/relaxed; h=from:to:subject:date:message-id; ...本文に長いフッターを追加すれば、通常はこの設定でも署名が無効になります。許容範囲は標準で定められた正規化に限られます。
3. 外部サービスのドメイン認証を確認する
CRM、ヘルプデスク、配信ツールが d=vendor.com で署名していても、それだけで不備と決めず、アラインメントとほかの署名を確認します。アラインした DKIM がないと、転送で残る SPF 経路も失われ、DMARC が失敗する場合があります。適切な独自 DKIM と、必要に応じて独自 Return-Path を設定してください。DMARC に両方の同時成功は必須ではありません。
4. SPF を評価可能な構成に保つ
SPF は転送だけでなく、過密な設定でも失敗します。RFC 7208 は、SPF 評価で DNS 参照を必要とする対象メカニズムと修飾子の数を 10 に制限し、入れ子も含めます。上限に達しただけではなく超えた場合に permerror が生じ、SPF を DMARC の成功経路として使えなくなる可能性があります。
dig +short TXT example.com
dig +short TXT _dmarc.example.comGoogle、Microsoft、Mailgun、SendGrid、Zendesk と三つの古いホストが同じ SPF に入っているなら、現在必要な送信元を確認します。適切なサブドメインへの分離も選択肢ですが、実際のエンベロープドメインと対応させる必要があります。
5. SRS と ARC の限界も理解する
SRS は転送時にエンベロープ送信者を書き換え、新しい認証ドメインで SPF を成功させられる場合がありますが、元の DMARC アラインメントは自動で戻りません。ARC は上流の認証結果を検証可能なチェーンで伝えます。最終受信側が中継者を信頼するか、ポリシー例外を適用するかを判断します。いずれも適切な DKIM の代替ではありません。
Google の間接配送に関する案内では、転送と直接送信を区別し、転送サービスに ARC ヘッダーを推奨しています。DMARC アラインメントが一般に免除されるという意味ではありません。2025 年と 2026 年のそれぞれで、最新の事業者ルールと実際の結果を確認してください。
転送するメールボックスが多い場合は基盤の設計が重要です。現行ドキュメントでは TrekMail はメールボックス転送と DNS 設定案内を提供しています。Bring Your Own SMTPの案内で外部送信経路とアラインメント条件を確認できます。
多数のドメインを扱う従来型と整理された運用
従来のDMARC 失敗対応では、ツールを追加し続け、どのシステムが署名するか不明になることがあります。整理された運用ではメールボックスの保管、配送、DNS 状態を明確に分け、原因を調査できるようにします。
| 従来型 | 整理された運用 |
|---|---|
| ユーザー課金がエイリアスや転送の多用を促す場合がある | 複数ドメインの定額プランなら、利用状況によって実メールボックスの費用を抑えられる |
| 過去の全サービスを巨大な SPF にまとめる | 送信元を点検し、不要な include を減らし、適切なサブドメインを使う |
| ESP が非アラインの事業者ドメインで署名する | 各正規送信経路でアラインした認証を確認する |
| ユーザーの苦情まで状態が見えない | DNS チェックが一部の設定不備の早期発見に役立つ |
| 移行がエクスポートと不明確な手順に依存する | IMAP でデータをコピーし、DNS と送信認証は別に切り替える |
TrekMail は現行プランに応じて複数ドメインのメールボックス、共有ストレージ、マネージド SMTP または自選事業者による送信を提供できます。費用と適性は利用状況によります。複数ドメインのメールホスティングと、移行に関するimapsyncも比較してください。
DMARC 失敗の問い合わせを受けたら
DMARC の失敗が届いても、反射的に reject から none へ戻さないでください。転送、無効な DKIM、非アラインのどれが原因かを先に確認します。ポリシー変更には送信元一覧、テスト、監視、合意したロールバック計画が必要です。
- 受信者から完全なヘッダーを入手する。
- SPF が失敗した接続 IP が既知の転送サーバーかを確認する。
- DKIM 結果と署名した
d=ドメインを見る。 - 署名ドメインと可視の From のアラインメントを調べる。
- 信頼できる中継者を通った場合は
arc=passを探し、その受信者での意味を評価する。 - SPF の参照数、古い include、構文を確認する。
TrekMail ではレコード確認にドメインの追加が役立ちます。明確なバウンスがなくメールが届かない場合は、メールを受信できないも確認してください。
まとめ：DMARC の失敗は順序立てて調べられる
繰り返すDMARC の失敗は、メールが修復不能という証拠ではありません。SPF への過度な依存、非アラインまたは変更に弱い DKIM、転送チェーンの書き換えが原因かもしれません。許可されていない送信元も考慮します。
基本対策は地道です。アラインしたドメインで署名し、DKIM の有効性を維持し、SPF を管理し、転送をテストします。実際の送信経路と利用可能なレポートを調べ、報告範囲の不足も考慮してください。
TrekMail は現行プランに応じて、複数ドメインのメールボックス、共有ストレージ、IMAP 移行、catch-all、柔軟な送信手段を提供します。本文の条件では有料プランは年払いで月額 $3.50 からで、14 日間の無料試用が用意される場合があります。Nano は無料でカード不要として提供される場合があります。IMAP はメールボックスデータをコピーし、DNS や評判は移しません。試用条件やカード要否を含め、料金またはTrekMailで最新条件を確認してください。
要するに、転送がある環境ではDMARC の失敗は重要なテストケースです。成功するテストは構成の堅牢性を高める助けになりますが、すべての経路での DMARC 成功や、すべての受信者への配送を保証しません。
