ドメインメール転送: SRS、ARCと障害診断

ドメインのメール転送は、単にメールを次へ渡す処理ではありません。サーバーが転送先へ新たな SMTP 接続を開始します。エンベロープに元の送信者が残っていると、新しい経路で認証の問題が起こる場合があります。配信不能通知は元の送信者やログで確認できても、自分の受信箱には届かないことがあります。

適切な認証設定がない転送では、Gmail で迷惑メールに分類されたり拒否されたり、Yahoo から 550 の拒否を受けたり、Microsoft 365 のポリシーで阻止されたりする可能性があります。未着という事実だけでは、どこで失敗したかは分かりません。

このガイドでは、2026 年の転送に使える三つの考え方、主要プロバイダーの代表的なエラーコード、十分以内に実施できる診断項目を紹介します。設定全体の手順は、メール転送の設定と修復の完全ガイドをご覧ください。

ドメインのメール転送で SPF が失敗する理由

転送時は自分のサーバーが新しい SMTP 送信元になりますが、Return-Path、つまりエンベロープ送信者は元のドメインを示したままの場合があります。転送先がその SPF レコードを調べ、自分の IP が許可されていなければ SPF は失敗し得ます。DMARC が p=reject の場合、元の From ドメインと整合する有効な DKIM もなければ、拒否される可能性があります。

典型的な失敗の流れは次のとおりです。

1. alice@bank.com が info@yourdomain.com に送信します。銀行の SPF レコードは銀行自身のメールサーバーを許可しています。
2. 自分のサーバーが you@gmail.com へ転送します。Gmail に見えるのは自分のサーバーの IP ですが、Return-Path は bank.com のままです。
3. 自分の IP は bank.com の SPF レコードに含まれないため、SPF が失敗する可能性があります。
4. サーバーがスキャン通知の追記や件名タグなどで署名対象のデータを変更すると、DKIM も失敗し得ます。整合する SPF も DKIM もなければ DMARC は失敗しますが、最終的な処理は受信側のポリシー次第です。

配信不能通知は元の送信者へ届いたり、ログに記録されたりする場合があります。転送先の受信箱で確認できるとは限りません。

キャッチオール経由の転送は問題を増幅する場合があります。転送された迷惑メールが自分の転送 IP と関連付けられるためです。Gmail でその IP の評価が低下し、正当なメールまで迷惑メール扱いや拒否になる可能性があります。ただし、すべてのメールが同じ経過をたどるわけではありません。

転送そのものが用途に適しているかを判断するには、設定前にメールエイリアス転送の利点と制約を確認してください。

ドメインのメール転送を安全にする 3 つの方法

この三つの方法は、それぞれ異なる問題に対処します。必要な組み合わせは経路や受信システムによって異なり、すべてを必ず導入する必要があるわけではありません。特に、元の有効な DKIM 署名が整合したまま残れば、転送後も DMARC に合格できます。

1. Sender Rewriting Scheme（SRS）

SRS は、転送前にエンベロープ送信者を転送サーバーのドメインのアドレスへ書き換えます。転送先はそのドメインの SPF を検査し、正しく許可されていれば合格できます。符号化されたアドレスによって元の送信者へ配信不能通知を戻せますが、SRS の復元処理が正しく設定されている必要があります。

SRS 適用前：

MAIL FROM: <alice@bank.com>

SRS 適用後：

MAIL FROM: <SRS0=hash=TT=bank.com=alice@forwarder.com>

制約は、SRS でエンベロープの SPF を改善しても、元の From ドメインとの DMARC 整合性は得られないことです。残された整合する DKIM によって DMARC に合格することはできます。その DKIM も失敗した場合、SRS だけでは整合する認証の代わりになりません。

2. Authenticated Received Chain（ARC）

ARC（RFC 8617）は、中継システムが記録した認証履歴を保護します。転送サーバーは三つのヘッダーを追加し、その観測結果とメールの状態を暗号学的に保護します。ただし、すべての記録の正しさや受信側の信頼を保証するものではありません。

ARC-Authentication-Results: i=1; forwarder.com; spf=pass; dkim=pass; dmarc=pass
ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.com; ...
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=forwarder.com; ...

Google や Microsoft は、信頼する中継システムの ARC 結果を考慮する場合があります。最終ホップで DMARC が失敗しても、その履歴がローカルな配信判断に影響する可能性があります。しかし、有効な ARC チェーンが受信を強制するわけではありません。

注意点は、信頼を決めるのは受信側だということです。新しい署名ドメインや IP が自動的に信頼されるわけではなく、良好な評価だけでも ARC への信頼は保証されません。

3. 内容を変更しない中継：DKIM の維持

SRS や ARC がない場合でも、元の DKIM 署名を維持することは重要です。フッターの挿入、件名の書き換え、スキャナーによる内容変更を避けてください。DKIM は正規化された本文と指定されたヘッダーを署名します。署名対象の変更は署名を壊し得ますが、あらゆるバイト変更が失敗を招くわけではありません。正規化方式によっては空白の一部の変更が検証に影響せず、署名対象外のヘッダーはその署名で直接保護されません。

原因を見つけにくい転送障害は、メールの変更で起こることがあります。例えば、スキャナーが MailGuard による検査通知を本文に追加しても、送信ログに明確なエラーが出ない場合があります。メールを確認できれば、受信側の Authentication-Results にある dkim=fail (body hash did not verify) が署名対象の本文変更を示す手掛かりになります。

内容を維持する転送は、有効で整合する DKIM が経路全体で残る場合に役立ちます。新しいホップで SPF が失敗し、DKIM も無効になれば、DMARC に使える整合する認証がなくなります。ARC や受信側のローカルポリシーは別途考慮される場合があります。

主要プロバイダーによる転送障害の扱い

Microsoft、Google、Yahoo は、認証、評価、転送ポリシーを異なる形で扱う場合があります。Microsoft はポリシーで自動外部転送を止められ、Gmail は分類を変更し、Yahoo は例えば 550 の拒否を返すことがあります。エラーの全文と発生した中継点によって、調査の出発点が決まります。

Microsoft 365（Exchange Online）

Defender の送信スパム対策ポリシーで、テナントの自動外部転送が禁止される場合があります。その場合、外部の転送先が評価する前に送信が止まります。対象メールボックスに実際に適用されているポリシーを確認してください。

5.7.520 を含む通知は、転送先ではなく元の送信者へ届く場合があります。受信箱の未着だけで原因を断定せず、メッセージ追跡と通知全文を確認してください。

Google Workspace / Gmail

明示的な拒否の例は、550-5.7.1 Unauthenticated email from domain.com is not accepted due to domain's DMARC policy です。p=reject で整合する認証がない場合に起こり得ます。元の整合する DKIM が残れば転送後も DMARC に合格でき、SRS 単独ではその整合性を回復しません。

評価の低下もリスクです。キャッチオールで転送される迷惑メールが、数日から数週間で転送 IP の評価を下げる場合があります。正当なメールも迷惑メール扱いや拒否になる可能性がありますが、共通のエラーコードや必ず起こる無通知の消失があるわけではありません。

Yahoo / AOL

Yahoo への認証不十分な転送は、550 の拒否を招く場合があります。件名が署名されていれば、[FWD] や [External] の追加で DKIM が失敗する可能性があります。整合する SPF も失敗していれば DMARC のリスクは高まりますが、そのようなメールの 100% が必ず拒否されるわけではありません。残された署名と受信側のポリシーも確認が必要です。

転送の診断チェックリスト

ドメインのメール転送に失敗したら、設定を変更する前に次の順で確認してください。

1. Authentication-Results ヘッダーを読む。Gmail の「メッセージのソースを表示」や Outlook のメールソースで確認します。

   Authentication-Results: mx.google.com;
     spf=fail (domain of bank.com does not designate 198.51.100.1 as permitted)
     dkim=fail (body hash did not verify)
     dmarc=fail (p=REJECT)

   spf=fail → エンベロープのドメイン、送信 IP、SRS 設定を確認する。
   dkim=fail (body hash) → 署名対象の本文と経路上の変更を確認する。
   両方失敗 → 整合性、他の DKIM 署名、ARC、受信側のポリシーも確認する。この結果だけで拒否が保証されるわけではない。
2. ルーティングループを確認する。5.4.14 Hop count exceeded はホップ数の上限超過を示し、上流への再転送がよくある原因です。経路全体を書き出してください。A→B→C→A は典型例です。
3. Reply-To の動作を試す。転送メールに返信します。クライアントは通常 Reply-To があれば優先し、なければ From を使います。転送サーバー宛てになる場合は、両方のヘッダーとクライアント設定を確認してください。
4. メールに触れるすべての処理を確認する。迷惑メールフィルター、ウイルススキャナー、メーリングリスト、フィッシング対策は署名対象を変更する場合があります。経路全体を調べてください。すべての変更が DKIM を壊すわけではなく、ログに原因が明示されない場合もあります。
5. キャッチオールの転送量を確認する。転送 IP 経由の迷惑メールが多いと、個別メールが認証に合格していても、長期的に Gmail の配信へ悪影響が出る可能性があります。

転送とアドレス別の専用ルーティングで迷っている場合は、ドメインのメールエイリアスとメールボックスを比較してください。目的が異なり、起こり得る障害も変わります。

TrekMail の転送インフラの扱い

自分で運用する Postfix では、SRS 用の postsrsd、ARC 用の OpenARC、RSA 鍵のローテーション、内容を維持する転送経路が必要になる場合があります。この四つの領域は独立して障害を起こし得ます。必要な構成はアーキテクチャ次第であり、外から同じ症状に見えても個別の確認が必要です。

ARC と DKIM は処理順序にも注意が必要です。転送サーバーの追加 DKIM 署名は、そのサーバーのドメインを認証できますが、ARC の一般的な必須条件ではなく、元の From に対する DMARC 整合性も自動的には回復しません。元の有効な署名を残し、ARC の結果と追加 DKIM を分けて調べてください。追加署名の不足だけで、あらゆる配信障害を説明することはできません。

現在の TrekMail が対象経路で OpenARC、追加 DKIM 署名、自動 SRS を使うかどうかは、最新の設定と実際に受信したヘッダーで確認してください。転送経路ではフッターや件名タグを追加せず、内容を維持することが重要です。転送先はメールボックスの転送設定で指定し、現在のプランで使える機能も確認してください。

ここに示すプラン条件は、申し込み前に最新情報を確認してください。転送は Pro（月額 $10）と Agency（月額 $23.25）、両方に14 日間の無料トライアルがあり、開始にはクレジットカードが必要とされています。Nano（$0、10 ドメイン、SMTP 持ち込み）と Starter（月額 $3.50、50 ドメイン）にはここでは転送が含まれていません。trekmail.net/pricing の最新プラン比較が基準です。

まとめ

2026 年の信頼できるドメインのメール転送には、エンベロープを扱う SRS、認証履歴を保護する ARC、元の DKIM を維持する経路の適切な組み合わせが重要です。どの構成でも全要素が必須というわけではありません。転送サーバーの新しい DKIM 署名は元の DMARC 整合性の代わりにならず、配信も保証しません。

調査は Authentication-Results ヘッダーから始めてください。これはそのヘッダーを生成したノードの検査結果です。メッセージ追跡や SMTP ログと組み合わせることで原因を絞れます。

Postfix を自分で管理したくない場合は、TrekMail で独自ドメインのメールを設定する方法を参考にしてください。約 15 分は目安であり、現在の構成で利用できる SRS、ARC、DKIM の機能も確認が必要です。