メール転送がDMARCを破壊する理由

メール転送は、DMARC認証の失敗を引き起こす最も一般的な正当な活動の一つです。メールボックスが受信メッセージを自動的に別の宛先に転送する場合—例えば、個人のGmailアドレスから職場アカウントへの転送や、オフィス管理者が部門メンバーにメッセージを転送する場合—元の送信者がすべてを正しく設定していても、転送されたメッセージがDMARCチェックに失敗する可能性があります。

この認証の破綻は、DMARCが送信インフラストラクチャ、メッセージヘッダー、ドメインアライメントが配信中に変更されないことを期待しているために発生します。転送はその前提を破ります。その結果、転送サーバーが最終受信者にメッセージをリレーする際、認証済みドメインからの正当なメッセージが拒否、隔離、またはフラグ付けされる可能性があります。

転送がDMARCを破壊する理由、転送プロセス中に何が失敗するか、転送に安全なポリシーを実装する方法を理解することで、組織は正当なビジネスコミュニケーションをブロックすることなく、なりすまし防止保護を実施できます。

I. メール転送がDMARC失敗を引き起こす理由

メール転送の5段階のプロセスを示すフローチャート。転送サーバーが送信元ドメインのSPFレコードに登録されていない場合に、SPF認証が失敗する仕組みを説明しています。

DMARCアライメントでは、SPFまたはDKIMのいずれかが認証に合格し、かつFrom:ヘッダーのドメインと整合している必要があります。転送が発生すると、両方のアライメントメカニズムが失敗する可能性があります。

転送中のSPF失敗

SPFは、エンベロープMAIL FROMアドレスに記載されているドメインに対して送信サーバーを認証します。メッセージが転送されると、転送サーバーが新しい送信サーバーになります。元のSPFレコードは転送サーバーのIPアドレスを認可していないため、最終宛先でSPF認証が失敗します。

フローの例:

[email protected]が[email protected]にメールを送信
[email protected]がメッセージを[email protected]に転送
転送サーバー(office.net)がpersonal.comにメッセージを配信
personal.comが転送サーバーのIPに対してcompany.comのSPFをチェック
転送サーバーがcompany.comのSPFレコードに含まれていない
SPFが失敗

エンベロープMAIL FROMは依然としてcompany.comを参照していますが、送信IPは現在office.netに属しています。SPFルックアップはfailまたはsoftfailを返します。

コンテンツ変更時のDKIM失敗

DKIMは暗号署名を使用してメッセージヘッダーと本文に署名します。転送サーバーがメッセージを変更する場合—フッターの追加、件名の変更、MIME構造の変更など—DKIM署名の検証が失敗します。

DKIMを破壊する一般的な転送変更:

メッセージ本文への転送通知や免責事項の追加
件名への[Fwd:]や[External]の追加
HTMLからプレーンテキストへの変換またはMIME境界の変更
添付ファイルの削除またはエンコーディングの変更

わずかな変更でも署名が無効になります。DKIMが失敗すると、転送されたメッセージは認証証明を失います。

DKIMが合格してもDMARCアライメントが失敗

転送サーバーがメッセージを変更せず、DKIM検証が成功した場合でも、アライメント要件によりDMARCが失敗する可能性があります。

DMARCでは、From:ヘッダーのドメインがSPFエンベロープ送信者のドメイン(緩和または厳格なアライメント)またはDKIM署名のドメイン(緩和または厳格なアライメント)と一致する必要があります。SPFが失敗し、DKIMが合格しても異なるドメインを使用している場合(転送サーバーが独自のドメインで署名するなど)、DMARCアライメントが失敗します。

これは一般的に以下の場合に発生します:

元のDKIM署名は有効だが、From:ドメインがDKIM署名ドメインと異なる
転送サーバーが独自のDKIM署名を追加するが、元のFrom:ドメインと整合しない
SPFが失敗し、整合したDKIM署名が存在しない

II. 何が失敗し、いつ、どの程度明示的か

メール転送時に発生する4つの認証失敗シナリオを比較した表。各シナリオにおけるSPF、DKIM、DMARCの認証結果と、メールの到達率への影響を示しています。

転送の失敗は、元の送信者と転送ユーザーにとってしばしば目に見えません。メッセージは明確なフィードバックなしに拒否または隔離される可能性があります。

失敗条件

条件	SPF結果	DKIM結果	DMARC結果	影響
転送サーバーがSPFに含まれない	失敗	合格(未変更)	DKIMが整合すれば合格	配信
転送サーバーがSPFに含まれない	失敗	失敗(変更済み)	失敗	拒否または隔離
転送サーバーがSPFに含まれない	失敗	合格(不整合)	失敗	拒否または隔離
転送サーバーがフッターを追加	失敗	失敗(署名破損)	失敗	拒否または隔離

失敗が目に見えない場合

転送ユーザーはバウンスや失敗通知を受け取らない
元の送信者はメッセージが転送メールボックスに正常に到達したため、配信失敗を確認できない
最終宛先は転送ユーザーに通知せずにメッセージを拒否
DMARC集計レポートは認証失敗を示すが、元の送信者は失敗を転送と関連付けられない可能性がある

失敗が明示的な場合

転送ユーザーが特定の送信者からのメッセージが最終宛先に到達しなくなったことに気付く
最終メールボックスプロバイダーが転送メールボックスに拒否通知を送信
最終宛先が失敗通知を生成した場合、元の送信者がバウンスを受け取る(稀)

III. 組織が転送によるDMARC破壊を発見する方法

ほとんどの組織は、p=noneからp=quarantineまたはp=rejectに移行した後に転送の問題を発見します。以前は問題なく配信されていたメッセージが、突然転送先に到達しなくなります。

一般的な発見経路:

従業員が顧客、ベンダー、パートナーからの転送メッセージが届かなくなったと報告
営業チームがCRMシステムへの自動転送が失敗していることに気付く
チケットシステムから個人メールへのヘルプデスク転送が機能しなくなる
企業アカウントから個人デバイスへのメール転送を使用する役員がメッセージを失う

DMARC集計レポートは転送サーバーのIPアドレスからの認証失敗を示しますが、レポートは転送が原因であることを明示的に識別しません。レポートの分析には、失敗ソースと既知の転送設定を関連付ける必要があります。

IV. 転送に安全なDMARCポリシーの実装方法

組織はサードパーティの転送サーバーがメッセージを処理する方法を制御できません。ただし、DMARCポリシーを調整し、失敗パターンを監視し、転送の代替手段についてユーザーを教育することができます。

パーセンテージではなくメールストリームごとに段階的に実施

pct=を使用してDMARCを段階的に実施するのではなく、ドメイン、サブドメイン、送信者グループ、メールストリームの成熟度ごとに段階的に実施します。金融取引、アカウント通知、役員コミュニケーションに使用される高価値ドメインにはp=rejectを適用します。代替ソリューションが実装されるまで、既知の転送パターンがあるドメインにはp=quarantineまたはp=noneを適用します。

主要戦略としてパーセンテージベースのロールアウトに依存することは避けてください。現在のDMARC対応プログラムは、ドメイン、サブドメイン、送信者グループ、ビジネス機能ごとに段階的に実施すべきです。

転送の多いメールストリームにサブドメインを使用

ニュースレター、自動レポート、内部通知など、特定のメールストリームが頻繁に転送される場合は、より制限の少ないDMARCポリシーを持つサブドメインから送信します。これにより、転送の失敗が高価値のトランザクションメールから分離されます。

例:

company.com → p=reject (トランザクション、アカウントセキュリティ)
reports.company.com → p=none (自動レポート、ニュースレター)

このアプローチは、転送されるメールストリームの通過を許可しながら、プライマリドメインでのなりすまし防止保護を維持します。

ユーザーに転送の代替手段を教育

転送は利便性のためによく使用されますが、代替手段によりDMARCアライメント失敗が減少します:

転送の代わりにネイティブIMAPまたはPOPアクセスを使用。ほとんどのメールクライアントは複数アカウント管理をサポートしています。
メール委任を使用(Gmailの「アカウントへのアクセスを許可」やMicrosoft 365の「代理送信」など)して、転送せずに複数のメールボックスを管理。
外部アドレスへの転送の代わりに同じドメイン内のメールエイリアスを使用。
個別の転送ルールの代わりに配布リストまたは共有メールボックスを使用してチームベースのメールルーティングを実施。

転送パターンについて集計レポートを監視

DMARC集計レポートには、送信元IPアドレス、認証結果、メッセージ数が含まれます。転送の失敗は通常以下を示します:

既知の転送プロバイダー(Google Workspace、Microsoft 365、メールホスティングプロバイダー)に属するIPアドレスからのSPF失敗
メッセージが変更されたかどうかに応じてDKIMの合格または失敗
DKIMが合格しても整合しない場合のアライメント失敗

これらのパターンを確認することで、どの転送先が失敗を引き起こすか、ボリュームがポリシー調整を正当化するかを特定できます。

管理されたSkysnagデプロイメントでは、Skysnagが生成するレポート宛先を使用してください。以下は手動の例のみです:

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100; fo=1

従来の静的レコードも機能しますが、レポートが積極的に受信、解析、分析され、対処される場合のみです。Skysnag Protectは自動的にDMARCレポートを集計・分析し、転送パターンを表面化し、影響を受ける送信者を特定します。

ARC(Authenticated Received Chain)サポートを検討

ARCは、転送システムを含む中間サーバー全体で認証結果を保持するために設計されたプロトコルです。メッセージがARCをサポートする転送サーバーを通過すると、サーバーは元の認証結果を記録するARCヘッダーセットを追加します。最終宛先はARCチェーンを評価して、メッセージが転送前に認証されたかどうかを判断できます。

ARC単独では転送の失敗を解決しません。最終受信サーバーがARCヘッダーを尊重し、転送サーバーがARCを正しく実装する必要があります。2026年現在、主要メールボックスプロバイダー間でARCサポートが増加していますが、普遍的に展開されているわけではありません。

組織は、転送サーバーまたは最終宛先がARCをサポートするかどうかを制御できません。ただし、DMARCフォレンジックレポートのARC関連ヘッダーを監視することで、転送システムが認証を保持しようとしているかどうかを特定できます。

V. ポリシー調整後に問題が発生する可能性

転送に対応するためにDMARCポリシーを調整すると、新たなリスクが生じます。

プライマリドメインでのポリシー弱体化

転送の失敗を防ぐためにプライマリドメインのDMARC実施を緩和すると、なりすまし防止保護が低下します。攻撃者は弱体化したポリシーを悪用して、ドメインから未認証のメールを送信できます。

失敗の例:

company.comが転送メッセージを許可するためにp=rejectからp=quarantineに変更
攻撃者が[email protected]をなりすましてフィッシングメールを送信
なりすましメッセージはDMARCに失敗するが、拒否ではなく隔離される
一部の受信者が隔離からメッセージを取得し、フィッシング攻撃の被害に遭う

サブドメインポリシーの不整合

転送の多いメールストリームにサブドメインを使用することは、サブドメインのDMARCポリシーが明示的に設定されている場合のみ機能します。サブドメインがsp=タグを通じて親ドメインのp=rejectポリシーを継承する場合、転送の失敗が持続します。

失敗の例:

company.com → p=reject; sp=reject
転送メール用にreports.company.comが作成される
reports.company.comが親ドメインからp=rejectを継承
転送メッセージは依然としてDMARCに失敗し、拒否される

異なる実施ニーズを持つサブドメインには、常に個別のDMARCレコードを公開してください。

ユーザー教育のギャップ

転送の代替手段を推奨しても、ユーザーの採用が保証されるわけではありません。代替手段が明確に伝達、文書化、またはITによってサポートされていない場合、従業員は転送ルールを使い続ける可能性があります。

失敗の例:

ITがメール転送がDMARC失敗を引き起こすことを発表し、IMAPアクセスを推奨
従業員がIMAPの設定方法を理解していない、またはモバイルデバイス管理ポリシーが不足
従業員がメール転送を継続し、ベンダーや顧客からのメッセージが欠落していると報告
ITが根本的な行動に対処せずに個別のケースを手動でトラブルシューティング

転送の代替手段には、ユーザートレーニング、明確な文書化、成功するためのITサポートが必要です。

VI. Skysnag Protectが転送の失敗を特定し対処する方法

Skysnag ProtectはDMARCレポートを集計し、転送関連の認証失敗を特定し、正当なメールストリームが転送によって影響を受けているパターンを表面化します。

Skysnag Protect:

既知の転送サービスに属する送信元IPアドレスを特定し、それらのアドレスからのDMARC失敗を強調表示
転送中にSPF、DKIM、またはその両方が失敗したかどうかを示す
転送ソースからのメッセージボリュームを追跡し、ポリシー調整の優先順位付けを支援
どの送信者とメールストリームが転送によって最も影響を受けているかを可視化
ITチームがユーザーに転送の代替手段を教育し、採用を監視するのに役立つレポートを生成

Skysnag Protectを使用して、正当な送信者を特定し、未承認のソースを検出し、ビジネスクリティカルな転送メッセージをブロックせずに実施に移行します。でDMARC監視を開始してください。

VII. 重要なポイント

メール転送は、転送サーバーが元の送信者のSPFレコードによって認可されていない場合にSPFが失敗するため、DMARCを破壊します。
転送サーバーがメッセージ本文、件名、MIME構造を変更すると、DKIMが失敗する可能性があります。
DKIMが合格しても、From:ドメインがSPFまたはDKIM署名ドメインと一致しない場合、DMARCアライメントが失敗する可能性があります。
転送の失敗は、元の送信者と転送ユーザーにとってしばしば目に見えません。最終宛先は明確なフィードバックなしにメッセージを拒否または隔離します。
組織は、パーセンテージではなくドメインとメールストリームごとにDMARC実施を段階的に行うべきです。転送の多いメールストリームにはサブドメインを使用します。
ユーザーに転送の代替手段を教育:IMAPアクセス、メール委任、エイリアス、共有メールボックス。
DMARC集計レポートを監視して転送パターンを特定し、影響を定量化します。
Skysnag Protectは転送関連の失敗を表面化し、影響を受けるメールストリームを追跡し、なりすまし防止保護を弱めることなくポリシー調整の優先順位付けを支援します。