SRSの仕組みとメール転送時の認証の限界

contact@your-agency.com → you@gmail.comという転送を設定し、テストでは正常に届きました。ところが二週間後、企業の取引先から送られた契約書が迷惑メールにも見当たりません。ログには550 5.7.1 Unauthenticated email、あるいは550 5.7.520 Access deniedという記録があります。後者はMicrosoft 365からの外部転送を組織のポリシーが禁止している場合などに発生します。前者だけでは原因を特定できません。SMTPで拒否されても、その通知が利用者に見えるとは限りません。

転送に伴うSPFの問題に対処する方法の一つが、適切に設定された送信者書き換え方式SRSです。転送時には、元のエンベロープ送信者のドメインが中継サーバーを許可していないため、SPFが失敗する場合があります。2026年のGoogleとYahooの送信者要件は認証の重要性を示していますが、すべての送信者にDMARCのp=rejectを求めるものではありません（Googleのメール送信者ガイドライン）。SPFの失敗だけでDMARCの失敗や無通知の破棄が決まるわけでもありません。本記事では、SRSの仕組みと限界、併せて検討したい対策を説明します。

転送全体の概要は、メール転送の設定とよくある問題の対処方法をご覧ください。

送信者書き換え方式（SRS）とは

SRSはSMTPエンベロープの送信者を変更し、転送によるSPFの問題に対処する方式です。転送サーバーは、元のエンベロープアドレス（MAIL FROM）を転送用ドメインのアドレスに書き換えます。受信サーバーはそのドメインについてSPFを確認します。DNSレコードが適切で、送信サーバーが許可されていれば、SPFは成功する可能性があります。エンベロープアドレスは通常のメール画面には表示されませんが、メールの完全なヘッダーのReturn-Pathで確認できます。書き換えない場合、許可されていない中継サーバーから元のドメインを名乗って送信することになり、SPFが失敗する可能性があります。ただし、それだけでなりすましやDMARCの失敗が確定するわけではありません。

メールの送信者を示す二つの層

転送時の認証を理解するには、エンベロープとメッセージヘッダーを区別する必要があります。SPFはエンベロープ側の送信者ドメインを検証します。DMARCは、表示される送信者ドメインと、SPFまたはDKIMで認証されたドメインの整合性を確認します。転送はこの関係を変えることがあります。

エンベロープは配送や配信エラーの返送に使われ、SPFはそのドメインを検証します。メールソフトに表示される送信者はヘッダー側にあり、DMARCの整合性確認の基準となります。転送で新しいSMTP接続が作られるとSPFに問題が生じることがありますが、すべての認証が必ず失敗するわけではありません。整合性の取れた有効なDKIMが残れば、DMARCは成功できます。

新しいSMTP接続がSPFに影響する理由

転送サーバーは宛先へ新しいSMTP接続を開きます。エンベロープ送信者がalice@bank.comのままでも、接続元IPは転送サーバーのものになります。SPFはそのIPをbank.comのレコードと照合します。許可されていなければ失敗します。bank.comがDMARC p=rejectを公開しており、整合性の取れた有効なDKIMもない場合、受信側は拒否することがあります。拒否は中継サーバーに通知され、配信エラーが返される場合もあるため、常に無通知で消えるとは限りません。

これは単純な設定ミスとは限りません。元のエンベロープ送信者を維持したまま配送経路を増やすことで生じ得る問題です。ただし、実際の経路とSPFの許可設定によって結果は変わり、すべての転送に同じように発生するわけではありません。

SRSによるエンベロープの書き換え

SRSは、新しいSMTP接続を始める前に、エンベロープのMAIL FROMを転送用ドメインのアドレスに変更します。受信者に表示されるFrom:ヘッダーは、この処理のために変更する必要はありません。

# WITHOUT SRS - SPF fails downstream
Return-Path: <alice@bank.com>
Received-SPF: fail (IP not authorized for bank.com)

# WITH SRS - SPF passes on your domain
Return-Path: <SRS0=4fac=PM=bank.com=alice@your-domain.com>
Received-SPF: pass (IP authorized for your-domain.com)

この例では、受信サーバーがyour-domain.comのSPFを確認します。そのドメインが実際の送信IPを許可しているため、検証は成功します。受信者には通常どおりFrom: alice@bank.comが表示されます。SRSは個別のSPF検証に対処しますが、元の表示送信者ドメインとの整合性までは回復しません。

SRSアドレスの各部分を読み解く

Return-Path内のSRSアドレスはランダムに見えても、各部分に役割があります。構造を理解すると、書き換えが実行されているか確認し、不具合を調べやすくなります。詳細は実装によって異なります。

例：SRS0=4fac=PM=bank.com=alice@your-domain.com

SRSはSPFのドメイン整合性を回復しない

SRSでSPFの検証が成功しても、元の表示送信者とのSPFの整合性は回復しません。DMARCには、整合性の取れたSPF、または整合性の取れた有効なDKIMが必要です。そのため、SRSを正しく設定しても認証が失敗する場合があります。

DMARCでは、SPFまたはDKIMで認証されたドメインが、表示されるFrom:のドメインと適用される規則に従って整合している必要があります。このSRSの例では：

• SPF検証：PASS - IPはエンベロープドメインyour-domain.comで許可されている
• SPFの整合性：FAIL - エンベロープのyour-domain.com ≠ ヘッダーのbank.com

この場合、DMARCの成功には整合性の取れた有効なDKIMが必要です。署名の有効性は本文だけでなく、署名対象のヘッダーや正規化方式にも左右されます。「External Email」の警告、末尾のウイルス検査通知、8-bitから7-bitへのMIME変換などは、署名対象の部分を変更するとDKIMを無効にする可能性があります。

SPFの整合性がなく、必要なDKIMも無効になると、DMARCは失敗します。SRSの書き換え自体が正しくても、送信者と受信側のポリシーに応じて拒否されることがあります。

SRSを補完するARC

ARC（Authenticated Received Chain、RFC 8617）はSRSを補完できます。SRSがエンベロープを変更するのに対し、ARCは中継サーバーが実際に確認した認証結果を署名付きの連鎖として記録します。次の受信サーバーはその情報を判断材料にできますが、ARCがメールの安全性を認定するわけではありません。

ARCはARC-Authentication-Results、ARC-Message-Signature、ARC-Sealの三つのヘッダーを追加します。これにより、それ以前の認証結果を中継後も参照できます。ただしメッセージ署名は本文にも依存し、署名後の変更すべてに耐えられるわけではありません。ARCがDMARCのドメイン整合性を修復することもありません。

注意点：ARCの署名者を信頼するか、その結果をどう扱うかは受信側が決めます。Microsoft 365では、必要であり現在のテナントでサポートされている場合、権限を持つ管理者がPowerShell（Set-ArcConfig）で信頼する署名者を設定できます。すべての環境で手動登録が必要なわけではありません。Gmail側の信頼判断を手動で強制することもできません。

本番環境では、SRSで転送後のSPFを扱い、ARCで以前の認証結果を伝える構成を検討できます。ただし、両方が常に必要なわけではなく、組み合わせてもすべての主要プロバイダーへの配送を保証するものではありません。

SRSの問題を調べるチェックリスト

転送メールが届かない場合は、次の手順でSRSの問題と、その手前で起きた認証エラーやポリシーによるブロックを切り分けます。

1. Return-Pathヘッダーを確認する

外部アカウントから転送経路を通してテストし、最終宛先で元のヘッダーを確認します。以下は結果の例であり、必ずこのようになるとは限りません。

# SRS inactive - SPF will fail
Return-Path: <original-sender@external.com>
Authentication-Results: spf=fail (IP not authorized for external.com)

# SRS active - SPF passes on your domain
Return-Path: <SRS0=xxxx=yy=external.com=sender@your-domain.com>
Authentication-Results: spf=pass (IP authorized for your-domain.com)

2. Microsoft 365の送信側ブロックを確認する

Microsoft 365からの外部転送がテナントのポリシーで禁止されている場合、メールはテナントを出る前にブロックされます。受信サーバーのSRSでは解決できません。

550 5.7.520 Access denied, Your organization does not allow external forwarding.

権限を持つ管理者がDefenderポータルの送信スパムフィルターポリシーを確認してください。変更は組織の承認とセキュリティ方針に従って行い、別の経路で制限を回避しないでください。受信側のSRSはこの送信ポリシーを変更しません。

3. 配送ループを確認する

AからBへ、BからAへ転送する設定があると、規則や保護機能によってはループが発生します。ログで次のような記録を探してください：

554 5.4.14 Hop count exceeded
5.4.6 Routing loop detected

転送の代わりに独立したメールボックスを使う

postsrsdの設定、HMAC鍵の管理、DMARCの整合性エラーの調査は、メールボックス単位の費用を抑えるために業務メールを個人の受信箱へ転送するときの管理負担です。SRSはその構成の一部の問題に対処します。直接受信するメールボックスなら追加の転送段階をなくせますが、適切な認証設定と運用は引き続き必要です。

contact@client-domain.comをGmailに転送してSRSを管理する代わりに、contact@client-domain.comをTrekMailのIMAPメールボックスとして運用できます。対応するIMAPクライアントや連携機能を使えば、対応するGmail環境からアクセスする選択肢もあります。配送先はホストされたメールボックスとなり、追加の転送やそのためのエンベロープ書き換えは不要です。ただし、認証や配送のリスクがすべてなくなるわけではありません。ドメインメールをGmailに転送するガイドや、エイリアスとメールボックスの比較で違いを確認してください。

複数の顧客ドメインを管理する場合、TrekMailで個別のメールボックスを用意すると、各サーバーのSRSを保守するより管理を集約しやすくなります。利用できる分離機能や設定時間はプランと構成によって異なり、完全な安全性を保証するものではありません。複数ドメインのメールホスティングでは、拡張時の管理方法を説明しています。

紹介しているTrekMailの提供条件は月額$3.50から、無料試用は14日間です。現在の料金、条件、機能を確認してください。独立したメールボックスを設定し、直接ホスティングが業務に合うか検討しましょう。