みなさん、こんにちは。
「独自ドメイン宛のメールを自分のGmailへ自動転送（Forward）しているけれど、特定の相手からのメールだけ遅配したり、迷惑メールに入ってしまう…」
そんな不可解な現象に最近遭遇しました。
以前の記事で、サーバーのリピュテーション（信用度）リスクによって自動転送が失敗する可能性については調査済みで、それなりに覚悟はしていたんです。
ですが、今回の問題はリピュテーションではありませんでした。
ヘッダーログを詳しく解析してみたところ、「送信元のDMARCポリシー（p=REJECT）」と「Microsoft 365（Outlook）独自のヘッダー構造＋転送サーバーによるDKIM破壊」が複雑に絡み合った、まさに現代ならではのメール認証トラブルだと分かりました。
本記事では、実際に発生した事例をもとに、そのメカニズムと解決策を共有します。
今回起きたトラブルの概要
- 現象
- 独自ドメイン宛のメールをレンタルサーバーの自動転送機能でGmailへ転送していたところ、特定企業（A社）の担当者さんが手動送信したメールが約12時間遅配し、DMARC検証で「FAIL」し、迷惑メールに振り分けられていた。
- 不思議な点
- A社からの「システム自動配信メール」は問題なくDMARC PASSしてすぐに届く。
- 他社からの転送メールも問題なく届く。
- Gmailの表示上は
SPF: PASSDKIM: PASSとなっているのに、なぜかDMARC: FAILになる。
単体ではPASSしているのになぜDMARCで落ちるのか？ ログを読み解くと、3つの要因が見えてきました。
なぜ起きたのか？ 3つの技術的要因
1. DMARC「アライメント（ドメイン一致）」の罠
画面上で SPF: PASS や DKIM: PASS と表示されていても安心はできません。
転送サーバーを経由すると、転送サーバー自身のドメイン（forward-server.net）でSPFチェックが通ったり、転送サーバー自身が新たなDKIM署名を付与してPASSになることがあります。
ですが、DMARC認証を突破するためには「メール本文上の差出人（Header From）」と「認証に使われたドメイン」が一致（アライメント）していることが絶対条件です。
- 差出人（Header From）:
a-company.com - 認証成功ドメイン:
forward-server.net（転送サーバー）
いくら転送サーバー側のSPFやDKIM単体がPASSしていても、差出人ドメインと一致しないため、DMARC判定としては容赦なく「FAIL」となってしまいます。
つまり、転送環境でDMARCを通すには、送信元（A社）が付与したオリジナルのDKIM署名（d=a-company.com）が壊れずにそのままGmailまで届くことが必須なのです。
2. 「システムメール」と「社員のOutlook」での挙動の違い
ここで「なぜシステムメールは届いて、担当者のメールだけ遅れたのか？」という疑問が出てきます。実は、メールの構造に違いがありました。
- システム自動配信メール
ヘッダーや本文の構造がシンプルなため、転送サーバーを経由しても送信元（A社）のオリジナルDKIM署名が壊れず、DMARC PASSとなった。 - 社員のOutlook（Microsoft 365）メール
スレッド情報や複雑なHTML、改行コードの変換などが挟まるため、転送サーバーを経由した際のわずかな書き換えで、送信元のオリジナルDKIM署名が破損（dkim=fail）してしまった。
3. 送信元の厳格なDMARCポリシー（p=REJECT）
DMARCがFAILした際、受信側（Gmail）がそのメールをどう扱うかは、送信元が公開しているポリシー（p=）によって決まります。セキュリティ意識の高いA社のような大手企業は、p=REJECT（失敗時は拒否または隔離）を設定しています。
その結果、以下のような流れで遅配が発生しました。
- SPF判定（単体PASS、アライメントNG）
転送サーバーによりEnvelope Fromが書き換えられたため、転送サーバーとしてのSPFチェック自体は「PASS」になります。しかし、差出人（Header From）のドメインと異なるため、DMARC用のアライメントとしては無効化されます。 - DKIM判定（転送側PASS、送信元FAIL）
転送サーバーが付与したDKIM署名は「PASS」になりますが、これも差出人ドメインと異なるためDMARCには使えません。肝心な送信元が付与したオリジナルのDKIM署名は、Outlook特有のヘッダー構造と転送時の微小な改変により破壊され「FAIL」となりました。 - DMARC判定
差出人ドメインでの認証（SPFアライメント・送信元DKIM）が全滅し、DMARC: FAIL と決定。 p=REJECT発動
Gmail側で一時拒否（リトライ要求）となり、サーバー間での再送ループを経て、約半日〜1日遅れでなんとか届いた。
自動転送（Forwarding）運用の限界
「これまでは普通に転送できていたのに…」と思いましたが、近年のメールセキュリティ強化に伴い、環境は激変していたのです。
- Google、Yahoo、Microsoftなどの主要インフラによる送信ドメイン認証の厳格化
- 大手企業を中心とした
p=REJECTやp=QUARANTINEへの移行 - 送信元が設定したDMARCポリシーやメーラーの挙動は、受信側ではコントロール不能
もはや「レンタルサーバー等での自動転送」という構成自体が、大事なビジネスメールの遅配や不達を引き起こすハイリスクな運用になってきています。
さらに、Gmail側でも他社メールアドレスを送信元にするSMTP機能の廃止予定がアナウンスされるなど、Gmailをハブにした独自ドメイン運用は日ごとに困難になっています。
私の場合の解決策 – Zoho Mailへの移行
この問題を根本から解決するため、私はGmail運用を見直すことにしました。
Gmail側で「迷惑メールにしない」フィルタをかける方法も検討しましたが、あくまで一時的な応急処置に過ぎないため、採用を断念しました。
Google Workspaceへの移行も本格検討しましたが、最終的には「Zoho Mail」を利用して独自ドメインメールを直接送受信する運用に切り替えることにしました。
- 受信: POP3
- 送信: SMTP
構成としてはThunderbirdなどのメーラーを使う感覚と一緒です。Zoho Mailが直接独自ドメインのメールを送受信してくれるため、中間で転送サーバーを挟みません。Google Workspaceと異なり、メーラー感覚で使えるのが決め手となりました。以前一度試用していたこともあり、設定自体はすんなり行うことができました。
これにより、転送処理によるヘッダー改変やDKIM署名の破壊（DMARC崩れ）を回避できるようになり、転送失敗による大幅な遅配や不達の不安から解放されました。（※Zoho MailのPOP3取得間隔によるタイムラグは発生しますが、メールが失われたりREJECTされるリスクは解消できます）
2025年10月に発表されたPOPフェッチ廃止から始まったGmailショックですが、ようやく終着を迎えた？はずです。
自動転送の終わり…
GmailのPOPフェッチ廃止後にGoogleでさえ代替案として提示している「他社メールのGmailへの自動転送」ですが、現代の厳格なセキュリティ環境下ではそろそろ限界を迎えているようです。
もし「最近メールの届きが悪いな…」と感じている方がいたら、ぜひメールヘッダーの解析や、直接受信できる専用メールサーバー（Google Workspace、Microsoft 365、Zoho Mailなど）への移行を検討してみてください。
今回のような検証、「うちの環境ではどうなんだろう？」と気になった方はいませんか。
ビューローみかみでは、構想段階の壁打ちからPoC・実装・現場導入まで、現場で「使い続けられる」ものづくりを支援しています。
技術顧問サービスでは、本記事のような技術的な質問・検証にも継続的にお答えしています。「相談したら契約」ということはありません。システムを作らない判断も含めて、率直にお話しします。
▶ 技術顧問サービスの詳細はこちら
気になることがあればお気軽にご相談ください。
本日も最後までお読みいただきありがとうございました。
それでは、よいメールライフを！
