転送を設定し、contact@yourdomain.comのメールをGmailで受け取っています。一週間は問題なくても、その後、一部の顧客メールが届かず、不達通知もすぐには見つからないことがあります。ログには550 5.7.1 Unauthenticated emailや550 5.7.26 This message does not have authentication informationが記録されています。これらの応答には複数の原因があり、SRSによるメール転送はその一つに対応する仕組みです。転送サーバーは新しいSMTP接続を開きますが、エンベロープ送信者には元のドメインが残ります。新しいIPがSPFで許可されていなければ、検証が失敗する場合があります。DMARCがp=rejectで、整合するSPFもDKIMも成功しなければ、受信側のポリシーに応じて拒否されることがあります。SMTP拒否は不達通知につながる場合もあり、必ず黙って消えるわけではありません。
SRSを有効にしても、すべての問題は解決しません。正しく書き換えられていても、DMARCで必要なドメインの一致が満たされない場合があります。転送障害の原因と診断方法は、メール転送の設定と問題解決ガイドを参照してください。
SRSによるメール転送とは
SRSによるメール転送は、Sender Rewriting Schemeを使って、転送時にエンベロープ送信者を書き換える方式です。技術的な返信先に転送サービスのドメインを使い、そのドメインでSPFを検証できるようにします。成功するかはDNSと実際のIPの許可状況によります。受信者に表示されるFromは元のままです。SRSは暗号化でもヘッダーを隠す仕組みでもありません。エンベロープの情報は完全なヘッダーから読める場合があります。
Postfixではpostsrsdデーモンを使ったSRS連携が可能です。Microsoft 365や一部の管理型メールサービスも、ハイブリッド構成を含む特定の経路で対応しています。バージョン、コネクタ、設定を確認してください。SRSはSMTP転送とSPFの関係を補いますが、DMARCの要件をすべて解決するわけではありません。
転送で問題が起きる理由：新しいSMTPホップ
転送はSMTPホップを追加するため、新しいIPが許可されていなければSPFが失敗する場合があります。メールには異なる二つの送信者情報があります。Header From（RFC 5322）は表示される送信者で、例はFrom: alice@client.comです。Envelope Sender（RFC 5321、MAIL FROM）はSPF検証や不達通知のための技術的な返信先です。通常の画面には出なくても、完全なヘッダーで確認できる場合があります。
次は考えられる失敗の流れであり、すべての転送で必ず起きるものではありません。
- Aliceが
alice@client.comから送ります。SPFは送信サーバーを許可しており、転送サーバーへの到着時には成功します。 - 転送サーバーが
you@gmail.comへ新しいSMTP接続を開きます。接続元は転送サーバーのIPになります。 - エンベロープ送信者は
alice@client.comのままですが、この例ではclient.comのSPFが転送サーバーのIPを許可していません。 - Gmailが
client.comのSPFを確認し、接続元IPが許可されていないため失敗します。 client.comがp=rejectを公開し、整合するDKIMも成功せず、受信側が拒否を適用すれば、メールは拒否される場合があります。転送サーバーが応答を受けて不達通知を送ることもあります。
SRSがSPFの問題に対応する仕組み
SRSによるメール転送は、新しい送信の前にエンベロープ送信者を転送サービスのドメインへ書き換えます。受信側はそのドメインのSPFを検証します。現在のレコードが実際の送信IPを許可していれば、成功する可能性があります。Header Fromは変わりません。不達通知は転送サービスに戻り、サービスがSRSアドレスを検証して、設定に応じて元の送信者へ戻せます。
SRSの構文を読み解く
SRSでは、単純な返信先が認証コードを含む構造化されたアドレスになります。書き換えであり、暗号化ではありません。
SRS適用前：MAIL FROM: <alice@client.com>
SRS適用後：MAIL FROM: <SRS0=4fac=PM=client.com=alice@yourdomain.com>
| 要素 | 例 | 役割 |
|---|---|---|
SRS0 | 接頭辞 | 最初の書き換えを表します。次の転送では、実装に応じてSRS1を使います。 |
4fac | 認証コード | この例では、ローカルの秘密鍵を使うSHA1の短縮HMACです。不達通知の偽造リスクを抑えますが、すべての偽造を防ぐ保証はありません。 |
PM | 時刻情報 | この例では循環するBase32タイムスタンプです。期限により古いアドレスの再利用を制限しますが、設定に依存し、すべてのリプレイやバックスキャッターを防ぎません。 |
client.com | 元のドメイン | 不達通知の経路を復元するために元のドメインを保持します。 |
alice | 元のユーザー | 元の送信者アドレスのローカル部です。 |
@yourdomain.com | 書き換えドメイン | 転送サービスのドメインです。新しい送信に使うIPをSPFで許可する必要があります。 |
再転送（A → B → C）では、サービスがSRS1を使う場合があります。SRS0全体を繰り返し入れ子にするのではなく、アドレスの伸長を抑えます。詳細はハッシュとタイムスタンプだけではなく、実装によって異なります。ローカル部の64文字上限はRFC 5321の規定に沿って別途確認が必要です。SRSならどんなアドレスでも収まるわけではありません。
SRSだけでは不十分な理由：DMARCの問題
SRSによるメール転送を有効にしても、メールが迷惑メールになったり拒否されたりすることがあります。SRSでSPFを成功させても、DMARCで必要なドメインの一致が維持されるとは限りません。DMARCには、Header Fromと一致するドメインでSPFまたはDKIMが成功する必要があります。書き換え後にSPFが認証するのはyourdomain.comで、Header Fromはclient.comのままです。この例の別々のドメインは一致しません。ただし、relaxedモードでは、同じ組織ドメインに属する別のドメインも一致と見なされる場合があります。
SPFが整合しなくても、整合するDKIMが成功すればDMARCは成功できます。転送時の変更が署名を損なうかは、署名対象と正規化方式によります。
- 署名対象の件名に
[EXTERNAL]を付ける - 署名対象の本文にウイルス対策の注記や免責文を追加する
- 8-bitエンコーディングを7-bitに変換する
- MIMEの境界文字列を変更する
こうした変更がすべての署名を必ず壊すわけではありません。署名対象と正規化が結果を決めます。整合するSPFもDKIMも成功しなければ、DMARCは失敗します。その場合、SRSが正常に機能していても、受信側のポリシーに応じて振り分けや拒否が行われることがあります。
ARC（Authenticated Received Chain）の役割
ARC（RFC 8617）では、転送サービスが実際に観測した認証結果を記録できます。検証と署名の時点は処理経路によって異なります。次の三つのヘッダーを追加します。
- ARC-Authentication-Results: SPF、DKIM、DMARCの観測結果を、失敗も含めて記録します
- ARC-Message-Signature: 署名作成時点のヘッダーと本文に署名します。後から署名対象を変更すると、無効になる場合があります
- ARC-Seal: 新しいARCのセットを既存のチェーンに暗号学的に結び付けます
チェーンが有効で、受信側が署名したサービスを信頼すれば、DMARCが失敗しても受け入れる判断にARCを使える場合があります。ARCはドメインの一致そのものを変えず、到達も保証しません。Gmailは2019年から本番環境でARC署名を評価しています。
2026年の堅牢な構成では、SRSによる転送、DKIMの署名対象の保持、必要かつ対応している場合のARCを組み合わせられます。ただし、すべてが常に必要とも、それだけで十分とも限りません。元の認証と受信側の判断が重要です。
プラットフォーム別のSRS設定
手順はサービスによって異なります。Postfixは外部デーモンを使う構成があり、Microsoft 365は独自の転送ポリシーやコネクタを持ち、Google Workspaceには管理型の仕組みと制限があります。現在の設定を確認し、すべてが初期状態で無効または有効だと決めつけないでください。
自己管理LinuxのPostfix
PostfixのSRS連携の一例はpostsrsdです。次は対応するディストリビューションでの例であり、承認された変更の前に適合性を確認してください。
apt-get install postsrsd次は/etc/postfix/main.cfにpostsrsdのTCPマップを設定する旧来の例です。新しいバージョンでは別のソケットや構文が必要な場合があります。既存設定をバックアップし、現在のマップと統合してください。無条件で上書きしてはいけません。
sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient確認事項：対応するバージョンでは、SRS_EXCLUDE_DOMAINSを/etc/default/postsrsdに設定し、ローカルドメインを除外できます。設定項目とファイルの場所はバージョンに応じて確認し、経路、マップ、ソケット権限と併せてテストしてください。除外の誤りは自社メールの書き換えや経路障害につながる場合がありますが、必ずループになるわけではありません。
Microsoft 365
M365は特定の送信経路でSRSを処理します。特にハイブリッド構成や外部ゲートウェイへのコネクタでは、現在の動作を確認してください。550 5.7.520 Access denied, Your organization does not allow external forwardingは転送ポリシーの制限を示し、SRS障害を証明するものではありません。
この制限はセキュリティ上の確認が必要です。権限のある管理者がSecurity Center → Policies & Rules → Anti-spam → Outbound spam filter policyを確認し、承認した転送だけを許可してください。次のコマンドは設定例です。パラメーターはバージョンによって異なり、対応していない場合もあります。テナントとバージョンに適した手順を確認し、共通の指示として扱わないでください。
Set-OutboundConnector -Identity "Outbound to Gateway" -SenderRewritingEnabled $trueGoogle Workspace
Googleは管理型の転送機能を使います。Workspaceに限らない、考えられる問題には次があります。
- 送信量の制限：キャッチオールで迷惑メールを転送すると、割り当てを消費して制限される場合があります。アカウント停止の有無はポリシーや状況によります。
- ループ検出：ループを防ぐために一部のメールが破棄される場合があります。確認できる情報はログ、管理ツール、経路によって異なり、必ず記録がないわけではありません。
SRS転送の障害を調べる
完全なヘッダーは診断に役立ちます。ProtonMailからテストし、最終受信先のメールを確認してください。拒否された場合はヘッダーを取得できないこともあります。SMTPログ、追跡情報、完全な応答も使いましょう。すべての原因がヘッダーだけで分かるわけではありません。
確認1：Return-Path
SRS書き換えなしの例：Return-Path: <original@protonmail.com>
SRS書き換えありの例：Return-Path: <SRS0=xxxx=yy=protonmail.com=original@yourdomain.com>
元のReturn-Pathが残る原因には、デーモン停止や連携ミスだけでなく、除外やSRSを通らない経路もあります。経路とログを確認してから判断してください。
確認2：Authentication-Results
書き換えドメインに対するspf=passを確認します。dmarc=failなら、DKIMがない、署名が無効、または有効でも整合しない可能性があります。SPFも元のFromと整合しない場合があります。署名ドメインと本文・件名の変更を確認してください。
確認3：DNS
dig yourdomain.com TXT +short書き換えドメインのSPFが実際のIPを許可し、返信先が到達可能かを確認します。MXは重要ですが、ないことだけで受信不能とは断定できません。SMTPがAまたはAAAAによる暗黙のMXを使う場合もあります。レコードの有無だけでなく、経路と実際の応答を確認してください。
確認4：Postfixログ
grep "srs_forward" /var/log/mail.loghash mismatchやtimestamp expiredには、ノード間の鍵の違い、鍵の更新、時刻、期限、設定などの原因があります。古いアドレスの再利用やリプレイの可能性もありますが、応答だけで攻撃とは判断できません。バックスキャッターを特定の原因に結び付ける前に、周辺情報を確認してください。
SRS転送をやめたほうがよい場合
SRSによるメール転送は、中間ホップで生じる構造上の問題に対応します。SRS、DKIMの保持、ARCには追加の構成や確認が必要な場合があります。ユーザーライセンスの節約に見えても、管理時間を含めると差が縮むことがあります。比較結果は自社の環境によります。
二つの方式を比較しましょう。
| SRSによるメール転送 | ホスティングされたメールボックス（TrekMail） | |
|---|---|---|
| SPF認証ドメインの一致 | SRSドメインは元のFromと異なる場合があります | 実際の送信経路に合わせて設定と検証が必要です |
| DKIM | 署名対象の変更で失敗する場合があります | 対応するSMTPと設定に応じた署名です |
| DMARC | ドメインが一致するDKIMで成功可能。ARCは受信判断に影響し得ます | 認証とドメインの一致の確認が必要です |
| 設定の複雑さ | postsrsd連携、必要に応じたARC、署名対象の保持 | 対応する場合はドメイン設定ガイドを利用できます |
| ユーザー単位の費用 | 例ではライセンス$0に、診断と基盤の費用が加わります | プラン料金と制限内の共有容量 |
| 複数ドメイン | サーバー設定とドメイン別の確認 | 紹介する提供条件では最大1,000+ドメイン。プランによります |
TrekMailは、ユーザー単位ではなく、メールボックスとドメインで共有容量を使う定額プランを紹介しています。容量だけへの課金や無制限の利用を意味しません。代理店は通常のGmail転送と比較し、エイリアス転送の利点と制約も確認してください。エイリアスと実際のメールボックスの選択には、ドメインエイリアスとメールボックスの比較が役立ちます。
TrekMailのメールボックスで直接受信すれば、そのメールの転送ホップをなくせます。そのホップのためのSRSやARCは不要になりますが、送信認証は引き続き設定と検証が必要です。設定ガイドがあっても同様です。MXに指定されたサーバーが自動的に送信を許可されるわけではありません。SPF、DKIM、DMARCや外部SMTPは、経路、サービス、プランに依存します。
TrekMailを試す：紹介する提供条件では、Nanoはカード不要で、管理型SMTPを含むStarterには14日間の試用があり、料金は月額$3.50からです。現在の提供状況、利用資格、料金、条件を確認してください。
まとめ
SRSによるメール転送は2025-2026年の転送構成で役立つ手段ですが、普遍的な必須条件ではありません。書き換えがなければ新しいホップでSPFが失敗する場合があります。SRSでSPFが成功しても、認証ドメインがFromと整合しないことがあります。整合するDKIMが成功すればDMARCは成功でき、拒否は受信側のポリシーによります。
Postfixの連携例には、postsrsd、main.cfのマップ、バージョンに応じた除外があります。M365では管理される経路と転送ポリシーを確認し、承認がある場合だけ変更します。Google Workspaceでは、停止やログ欠落を決めつけず、割り当て、ループ検出、管理ツールを確認してください。
SRS、DKIM署名対象の保持、ARCは転送の管理に役立ちますが、常にすべて必要とは限らず、到達も保証しません。別の選択肢として、実際の受信先にメールボックスを置き、認証、アクセス、制限を確認する方法があります。
