SRS：送信者書き換えと転送の確認

メール転送を設定し、テストも成功しました。ところが二週間後、顧客からの契約メールが届きません。スパムにもなく、配信不能通知も見当たりません。ログには550 5.7.1 Unauthenticated email from domain.comとあります。

このエラーには複数の認証上の原因が考えられます。SRSの未設定や設定不備も確認すべき候補ですが、このコードだけでは判断できません。転送では、別ドメインのエンベロープ送信者を持つメールを、サーバーが自身のIPから送る場合があります。Sender Rewriting Scheme、略してSRSは、そのSMTPエンベロープを書き換える仕組みです。2026年でも、SRSだけで問題がすべて解決するわけではありません。役割と限界の両方を理解する必要があります。

このガイドでは、SRSの動作、問題が起きる場面、転送構成に必要な要素を説明します。MXの誤り、キャッチオールの設定不備、DNS変更による経路の障害など、より広い配信問題を調べている場合は、先にメール転送の設定とトラブル対処ガイドを参照してください。

転送でSPFが失敗する場合

転送サーバーが自分のIPから送信し、元のエンベロープ送信者を維持していて、そのドメインが転送IPを許可していなければSPFは失敗する可能性があります。DMARCのp=rejectが設定され、有効でアラインメントを満たすDKIMもなければ、受信側は拒否する場合があります。SMTP拒否は元の送信者への配信不能通知につながることもありますが、自分の受信箱には通知が出ないこともあります。

メールは一つの連続した接続を通るわけではありません。中継ごとに新しいTCP接続を行うSMTP接続の連なりです。次は失敗する構成の例です。

1. alice@client.comがcontact@your-agency.comに送信します
2. 自分のサーバーが受信します。この例ではAliceの送信IPはclient.comのSPFで許可されています
3. 自分のサーバーがGmailへの新しいSMTP接続を開いて転送します
4. Gmailが見る接続元は自分のサーバーのIPです
5. エンベロープ送信者はalice@client.comのままです
6. Gmailがclient.comのSPFを確認しますが、転送IPは許可されていません
7. SPFは失敗します。client.comがp=rejectを使い、有効でアラインメントを満たすDKIMもなければ、Gmailは拒否する場合があります

SPF仕様のRFC 7208も、転送で生じる問題に触れています。元のドメインが中継サーバーを許可すると想定するだけでは不十分です。エンベロープの書き換えは、新しい経路でのSPF確認を支える方法の一つです。

二つの送信者情報：エンベロープとヘッダー

メールには二つの送信者情報があります。エンベロープ送信者（RFC 5321、MAIL FROM、P1）はSPFと配信不能通知の経路に使われます。サーバーが利用する情報ですが、利用者も完全なヘッダーのReturn-Pathで確認できます。ヘッダーのFrom（RFC 5322、P2）はGmailやOutlookに表示される送信者です。転送では、エンベロープ送信者のSPF許可が新しい送信サーバーに対応していない場合があります。SRSが変更するのはこの部分であり、表示上のFromではありません。

転送後も表示上のFromはalice@client.comのままの場合があります。サーバーは新しいSMTPトランザクションを作り、SPFはその段階のIPに対してエンベロープ送信者を評価します。問題は新しいIPの許可がないことであり、二つの送信者情報が異なること自体ではありません。

SRSが実際に行うこと

SRSは、転送サーバーが新しいSMTP接続を開く前にエンベロープ送信者（P1）を書き換えます。表示上のFromは変えません。転送サーバーを許可するドメインをエンベロープに使うことで、表示される送信者を維持したままSPFが通る可能性があります。元のFromドメインとのDMARCアラインメントは保証しません。

郵便で例えると：SRSがない場合、Aliceの手紙を受け取り、新しい袋に入れても返送先はAliceのままです。運ぶ人と返送先の情報が違う、というSPF問題の例えであり、偽造の証明ではありません。SRSでは返送先を自分にします。袋が返ってきたら自分が受け取り、Aliceへ返送を引き継げます。

SRSアドレスの構成を読む

SRSは転送前にエンベロープ送信者を符号化した文字列にします。書き換え先ドメインは実際の経路を許可する必要があります。文字列には、配信不能通知の確認に使う認証コード、有効期間を制限する時刻情報、通知を戻すための元の送信者アドレスが含まれます。意味のない文字ではなく構造化された情報であり、保護の強さは実装次第です。

SRSで書き換えたアドレスの例です。

SRS0=4fac=PM=client.com=alice@your-agency.com

• SRS0：最初の転送。さらに転送する場合のSRS1はアドレスの増大を抑えますが、無限に中継できる保証ではありません
• 4fac：この例ではHMAC-SHA1の認証コードを表します。方式や長さは実装によって異なります。無効なコードの通知を拒否し、無関係な第三者へ配信不能通知を送るバックスキャッターの悪用を抑える助けになります
• PM：時刻情報。7-21日の期間は設定可能な一例であり、共通の固定値ではありません。期限は古いアドレスの利用を制限しますが、リプレイ攻撃をすべて防ぐわけではありません
• client.com=alice：符号化された元の送信者。配信不能通知を元のアドレスへ戻すために使います

SRSを検討すべき場面

元のエンベロープ送信者を維持してドメイン間で転送し、元のSPFが中継サーバーを許可しない場合にSRSが役立ちます。複数ドメインの転送構成では、すべての送信者のポリシーと常に互換性があると想定せず、この点と認証経路全体を確認してください。

独自ドメインから個人用Gmailへ。cool-startup.comを所有し、founder@gmail.comへ転送する場合です。SRS書き換えとサーバーのSPF許可を確認します。書き換えがないと厳格なDMARCの送信者などでSPFが失敗する可能性がありますが、有効でアラインメントを満たすDKIMがあればDMARCは通る場合があります。

共通メール基盤を持つMSPや代理店。200の顧客ドメインをホストし、顧客がComcast、AT&T、Outlookなどへ転送する場合です。再送されるスパムはIP評価に影響する可能性があります。数週間でSpamhausに登録されることは想定されるリスクであり、必然的な結果ではありません。SRSだけでスパムや評価の問題は解決しません。

送信コネクタを使うMicrosoft 365。M365のSRS動作は経路と対応するコネクタの種類によって異なります。利用するバージョンと構成でSenderRewritingEnabledが使えるか確認し、設定は適切な権限と承認のもとで変更してください。送信スパムポリシーも確認します。外部転送の5.7.520はポリシー制限を示し、必ずしもSRSの障害ではありません。

SRSだけでは不十分な理由

SRSは書き換え先ドメインのSPFを通せる場合がありますが、元のFromとのDMARCアラインメントは自動的に回復しません。DMARCではSPFかDKIMの少なくとも一方が成功し、その認証ドメインが表示上のFromドメインとアラインメントを満たす必要があります。SRSが別ドメインを使う場合、SPFは成功してもアラインメントを満たさず、DMARCが転送後も有効な、アラインメントを満たすDKIMに依存することがあります。

転送時の変更によってDKIMが無効になる場合があります。

• 署名された件名に[EXTERNAL]を追加すると、DKIMが無効になる場合があります
• ウイルス検査の通知や配信解除リンクなどを末尾に追加すると、署名対象の本文が変わり、DKIMが無効になる場合があります
• MIMEを8-bitから7-bitへ変換するなどの変更は、署名対象と正規化の方式によってDKIMを無効にする場合があります

SPFがアラインメントを満たさず、変更によってアラインメントを満たすDKIMも無効になれば、DMARCは失敗します。拒否を含む最終的な処理は受信側のポリシー次第です。

ARC（Authenticated Received Chain、RFC 8617）は追加の判断材料を提供できます。転送前に観測した結果を封印し、三つのヘッダーを加えます。

• ARC-Authentication-Results：観測したSPF、DKIM、DMARCの結果を記録します。すべて成功しているとは限りません
• ARC-Message-Signature：署名時点の状態にあるメッセージの一部を署名します。受信直後の状態とは限りません
• ARC-Seal：封印を行うサーバーをチェーンに結び付ける暗号学的な署名です

GmailはSPFやDKIMでDMARCが通らない場合にARCを考慮することがあります。封印を行うサーバーとチェーンを信頼すれば、判断に使う場合があります。その信頼を強制することはできず、長期間の評価蓄積で必ず得られるとも限りません。受信側が決定します。

SRSの動作を確認する方法

外部アカウントから転送対象アドレスへテストメールを送り、転送先で完全なヘッダーを確認します。Return-PathにSRSで書き換えた送信者か元のアドレスのどちらがあるかを確認し、実際の認証結果も調べてください。

手順1：転送先でReturn-Pathを確認

# SRS inactive - SPF is almost certainly failing:
Return-Path: <original-sender@protonmail.com>

# SRS active:
Return-Path: <SRS0=xxxx=yy=protonmail.com=sender@your-domain.com>

手順2：SRSドメインのDNSを確認

# Check SPF on your forwarding domain:
dig TXT your-domain.com | grep spf

# Check MX - bounces need a place to go:
dig MX your-domain.com

書き換え先ドメインはSPFで送信を許可し、配信不能通知を受け取れる経路を持つ必要があります。適切なMXは一般に有用ですが、MXがないと必ず到達不能になるわけではありません。場合によってSMTPはAやAAAAを暗黙に使えます。レコードの有無だけでなく、実際の到達性とサーバーの応答を確認してください。

手順3：Linuxのメールログを確認

grep "srs_forward" /var/log/mail.log

hash mismatchやtimestamp expiredには、共有シークレットの不一致、鍵のローテーション、通常の遅延、データ破損、不正利用などの原因が考えられ、攻撃の証明にはなりません。PostfixにはPostSRSdなどのSRS機能を統合する必要があります。方法はバージョンと設定によって異なります。対応する構成ではローカルドメインのSRS_EXCLUDE_DOMAINSを検討し、経路をテストしてください。除外がないだけで必ずループになるわけではありません。

よりシンプルな代替：転送をやめる

SRSは送信サーバーが変わる際のエンベロープ送信者を管理します。自分のドメインに実際のメールボックスを用意してIMAPでアクセスすれば、追加の転送とそれに伴うSPF問題を避けられる場合があります。ただしエンドツーエンド認証を保証せず、すべてのDKIM、DMARC、アクセスの問題も解消しません。正しい設定は必要です。

転送が使われる背景には、月に五通しか届かないメールボックスに利用者ごとの料金を払いたくない、という事情もあります。SRSは技術的な要請だけでなく、費用を理由とした選択を支えている場合があります。

説明されているTrekMailの料金モデルは月額$3.50からで、複数ドメインと共用ストレージを定額で扱い、適用上限内ではユーザー単位の料金ではありません。sales@yourdomain.comを実際のIMAPメールボックスとして使い、Outlookや対応するGmail連携からアクセスできます。その転送構成は避けられますが、すべての認証リスクがなくなるわけではありません。現在の料金、機能、互換性を確認してください。

複数顧客の構成については、複数ドメインのメールホスティングのガイドで、数十のドメインを整理して管理負担を抑える方法を扱っています。メールボックスと旧来の転送を併用する場合は、メールエイリアス転送のガイドで、転送経路のSRSを確認してください。

転送を続ける場合もメールボックスに移る場合も、SRSの役割を理解して動作を確認し、対応している場合はARCを検討してください。不十分な転送設定は正当なメールの未着につながります。単なる技術の話ではなく、業務上のリスクです。

ここで紹介する条件では、無料TrekMailアカウントはカード不要で試用期限もありません。現在の条件を確認し、転送の複雑さを避けて複数ドメインのメールを試してください。