SRS転送とPostfixの実践的な設定ガイド

メール転送は、宛先を指定するだけで済むように見えます。しかしSRSによる転送（Sender Rewriting Scheme）を使わない経路では、SPFが失敗する場合があります。bank.comが転送用アドレスに送り、サーバーが元のエンベロープ送信者を維持して中継すると、接続元IPは中継サーバーのものになります。bank.comがそのIPを許可していなければSPFは失敗します。DMARCがp=rejectで、整合性の取れた有効なDKIMもなければ、受信側が拒否することがあります。ただし、SMTP拒否は配信エラーとして返される場合もあり、常に無通知で削除されるわけではありません。

本記事はSRSの実際の設定を扱います。全体像はメール転送の設定と配信問題の総合ガイドをご覧ください。ここでは構成、アドレス書き換え、Postfixとの連携、ARCの補完的な役割を説明します。ARCもDMARCの成功を保証するものではありません。

SRSによる転送が行うこと

SRSは中継時にエンベロープ送信者を、元のドメインから管理下のドメインへ変更します。そのドメインのSPFが中継サーバーのIPを許可していれば、宛先でSPFが成功できます。メールソフトに表示されるFromヘッダーは、この書き換えでは変更しません。

SRSなしで元のエンベロープ送信者を維持すると、SPFに問題が生じることがあります。SRSはその問題に対処しますが、元のFromとの整合性やすべての認証を自動的に維持しません。必要性は実際の経路と許可設定によります。

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

SRSを設定するには、二つのアドレスフィールドを区別する必要があります。SPFが確認するエンベロープ送信者は、転送で接続元IPが変わってもそのまま残ることがあります。

• エンベロープ送信者（RFC 5321 MAIL FROM）：メールサーバーが配信エラーの返送に使うアドレスです。SPFは、接続元IPがこのドメインからの送信を許可されているか確認します。
• Fromヘッダー（RFC 5322 From）：メールソフトに表示されるアドレスです。DMARCはSPFまたはDKIMで認証したドメインとの整合性を確認します。SRSは意図的にこのフィールドを維持します。

次の例では、中継サーバーが元のドメインでは許可されず、SRS用ドメインでは許可されているとします。

SRSは管理下のドメインをエンベロープに使い、そのSPFでサーバーを許可できるようにします。成功しても、他の検証や配送判断は残ります。書き換えたアドレスは通常の画面には出ませんが、元のヘッダーのReturn-Pathで確認できます。

SRSアドレスの各部分の意味

書き換えたアドレスは複雑に見えても、各部分に役割があります。構造を理解すると、配信エラーや複数の中継を含む経路を調べやすくなります。

最初の書き換え（SRS0）の形式は次のとおりです。

SRS0=Hash=Timestamp=OriginDomain=OriginLocalPart@AnchorDomain

構成要素：

• Hash：ローカルで管理する共有シークレットから生成する、切り詰めたHMACです。SHA1は一部の実装で使われるアルゴリズムの例です。SRSの偽造された返送先を検出する助けとなります。検証がなければ、もっともらしいSRS0アドレスを使ったエラー通知の悪用が起こり得ますが、HMACもすべての攻撃を防ぐわけではありません。
• Timestamp：base32で表す時刻情報で、この例の有効期間は7-21日です。形式と期間は実装や設定によって異なります。期限切れの拒否は古いアドレスの悪用を抑えますが、再利用攻撃への完全な防御ではありません。
• Origin：配信エラー時に元の送信者を復元するための情報です。サーバーが通知を受け、逆変換して元の送信者へ返します。
• AnchorDomain：管理下のドメインです。SPFによる送信許可と到達可能な返送経路が必要です。通常はMXを使いますが、MXがなければ条件に応じて暗黙のA/AAAAへのフォールバックが適用されることもあります。

次の転送では、対応する実装でSRS0をSRS1へ変換します。

SRS1=NewHash=PreviousAnchorDomain==SRS0_Suffix@NewAnchorDomain

SRS1はアドレスの増大を抑えますが、ローカル部が64文字以内というRFC 5321の制限は引き続き確認してください。複数中継での失敗には、長さ以外の原因もあります。

Postfixとの連携：PostSRSdの設定

PostSRSdはLinuxとPostfixで利用できるSRS実装の一つです。Postfixはcanonical mapを通じて書き換えたアドレスを取得します。以下は概念的な例です。変更前に、導入したバージョンの構文、パス、権限と文書を確認してください。

手順1：基準ドメインを準備する

設定ファイルを変更する前に、書き換え後のエンベロープに使うドメインを準備します。確認項目：

• MXレコード：配信エラーが届く有効な経路を確保します。MX、またはRFC 5321に従って適用できる暗黙のA/AAAAフォールバックを確認してください。返送経路が到達不能だと通知が失われる可能性があります。
• SPFレコード：受信側はこのドメインについて中継元IPを検証します。書き換え自体はIPを許可しないので、レコードと実際の検証結果を確認します。
• 評判：迷惑メールの転送はサーバーや基準ドメインの評価を損なう可能性があります。ブロックリストへの登録は必然ではありませんが、転送トラフィックの管理は必要です。

# Verify SPF record exists for your anchor domain
dig relay.yourdomain.com TXT +short
# Expected output - must include your server IP:
"v=spf1 ip4:203.0.113.10 -all"

# Check MX records exist for bounce delivery
dig relay.yourdomain.com MX +short

手順2：PostSRSdを設定する

パッケージとバージョンによって、設定は/etc/default/postsrsd（Debian/Ubuntu）または/etc/postsrsd/postsrsd.confにあります。以下は共通の構文ではありません。除外リストの対応状況と意味も確認してください。

# Domain that appears in SRS-rewritten envelope senders
SRS_DOMAIN=relay.yourdomain.com

# Secret key path
# In a multi-server cluster, this file MUST be identical on all nodes.
# If nodes have different secrets, they can't validate each other's bounces.
SRS_SECRET=/etc/postsrsd.secret

# Exclusion list - critical config, don't skip this
# Without it, Postfix rewrites local-to-external mail too,
# causing routing confusion and potential delivery loops.
SRS_EXCLUDE_DOMAINS=yourdomain.com,client-one.com,client-two.com

共有シークレットの新規作成は、承認された管理計画に従って必要な場合だけ行います。注意：以下の出力リダイレクトは既存ファイルを上書きします。現在のシークレットを安全にバックアップし、ローテーションと配送中のエラー通知の検証を計画してください。所有者とアクセス権も確認し、本番環境でそのまま実行しないでください。

openssl rand -base64 32 > /etc/postsrsd.secret
chmod 600 /etc/postsrsd.secret

手順3：Postfixと連携する

/etc/postfix/main.cfの設定を確認します。例ではPostSRSd 2.xのソケットマップと1.xのTCPを区別しています。実際の構文、ソケットの場所とアクセス権を導入環境に合わせて検証してください。

# PostSRSd 2.x - modern installs (unix socket maps)
sender_canonical_maps = socketmap:unix:srs:forward
sender_canonical_classes = envelope_sender
recipient_canonical_maps = socketmap:unix:srs:reverse
recipient_canonical_classes = envelope_recipient

# PostSRSd 1.x - legacy installs (TCP)
# sender_canonical_maps = tcp:localhost:10001
# sender_canonical_classes = envelope_sender
# recipient_canonical_maps = tcp:localhost:10002
# recipient_canonical_classes = envelope_recipient

設定を検証した後、運用手順に従ってサービスの再起動を計画します。

systemctl restart postsrsd
systemctl restart postfix

SRSだけでは解決しない問題とARC

SRSでSPFが成功しても、DMARCのドメイン整合性は回復しません。DMARCではFromのドメインがSPFの認証ドメイン、または有効なDKIMの署名ドメインと整合する必要があります。この例ではSPFがrelay.yourdomain.comを認証し、client.comとは整合しません。そのためDMARCの成功には整合性の取れた有効なDKIMが必要です。

転送で署名対象が変更され、正規化後も差分が残ると、DKIMが無効になることがあります。Subjectへの「External Sender」の追加、本文の配信停止案内、MIME境界の変更などが例です。すべての変更が必ず署名を壊すわけではありません。DKIMが無効でSPFも整合しなければ、DMARCが失敗し、受信側がポリシーに従って拒否することがあります。

RFC 8617のARC（Authenticated Received Chain）は、実際に観察した認証結果を署名付きの連鎖で伝えます。署名者を信頼する受信側は、DMARC失敗時でもその情報を受信判断に使えます。ただしARCは整合性を修復せず、配送を強制しません。

ARCが追加する三つのヘッダー：

• ARC-Authentication-Results：サーバーが観察し記録した認証結果
• ARC-Message-Signature：処理中の署名時点のヘッダーと本文の署名
• ARC-Seal：中継間で連鎖の各要素を結び付けるシール

SRSはエンベロープを扱い、ARCは認証の経緯を伝えます。GoogleやMicrosoftのような厳格な受信側では補完的に使えますが、常に両方が必要とは限らず、組み合わせても十分とは限りません。SPFが整合せず、整合した有効なDKIMもなければ、SRSだけではDMARCを通過できません。

SPFの正式な仕様はRFC 7208です。

導入前に知っておきたいプロバイダー固有の問題

SRSとARCが適切でも、提供側のポリシーによって経路がブロックされる場合があります。すべてが認証や自分の設定の問題ではありません。本番利用前に現在の条件を確認してください。

M365の550 5.7.520をSRSの問題として調べると時間を浪費します。外部転送の禁止を示す場合は、宛先ではなく、メールが出る元のテナントのポリシーです。送信元の権限ある管理者がDefenderで許可を検討してください。セキュリティ制限を迂回してはいけません。

SRSの動作を確認する

本番利用前に経路をテストし、元のヘッダーを確認します。SRSのReturn-Pathは経路内の書き換えを示しますが、認証とエラー返送も確認してください。元のアドレスのままなら、除外、別経路、連携不備なども考えられ、PostSRSdの停止とは断定できません。

1. Return-Pathを確認する

ProtonMailなどの外部アカウントから転送用アドレスへテストします。宛先でメッセージのソースを開き、Return-Pathを探します。

• Return-Path: <SRS0=...@yourdomain.com> → SRSの書き換えがある。SPF結果と逆変換も確認する
• Return-Path: <alice@protonmail.com> → この経路では書き換えが見えない。除外と連携、別経路を確認する

2. 基準ドメインのDNSを確認する

# SPF record must cover your server IP
dig relay.yourdomain.com TXT +short

# MX record must exist so bounces can arrive
dig relay.yourdomain.com MX +short

3. Postfixのログを確認する

grep -E "srs_forward|canonical" /var/log/mail.log | tail -50

SRSへの問い合わせと書き換えたアドレスの応答を確認します。接続拒否はサービス停止だけでなく、ソケット、設定、ネットワーク制限などでも起こります。確認方法の一つがsystemctl status postsrsdです。

4. 接続とTLSを確認する

SRS、ネットワーク、TLSの障害は似た症状を示すことがあります。SMTPへの到達とTLSの交渉を別々に確認します。

openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp

タイムアウトはネットワーク、ポート制限、サーバーへの到達不能などでも起こります。交渉失敗はSRSとは別のTLS問題を示す場合がありますが、タイムアウトだけで原因は特定できません。

転送をやめて直接ホスティングを選ぶとき

SRS、ARC、基準ドメイン、共有シークレット、除外リスト、評判の管理には作業が伴います。他社のメールボックス単位の費用を避けるため、sales@を個人の受信箱へ転送する構成もあります。この例では一人あたり月額$6を節約します。一つのアドレスでは合理的でも、十個になると管理費用が上回るかもしれません。

エイリアス転送の利点と制約では、転送が役立つ場面と複雑化する場面を比較します。エイリアスとメールボックスの選択ガイドはアドレス構成の判断に役立ちます。

紹介するProプラン（月額$10）は100ドメインと50GBの共有容量を提供します。現在の料金と上限を確認してください。sales@、support@、info@をIMAPメールボックスとして、説明した料金体系では利用者単位の課金なしで運用でき、その外部転送経路を保守する必要はありません。容量は各メールボックス専用ではなく、メッセージの保存は設定や運用にも左右されます。

複数ドメインを一か所へ集約するなど転送が必要な場合、紹介するProとAgencyの条件にはSRSとOpenARCのサーバー側管理があります。宛先を設定する前に現在の対応を確認してください。配送は保証されません。独自SMTPを使うNanoが管理付き転送を自動的に利用できるわけでもありません。自社の送信基盤へSRSを実装する場合は、上記のPostSRSd例のように互換性と設定を検証する必要があります。

Gmailへの経路は、ドメインメールをGmailへ転送するガイドで固有の問題と確認手順を説明しています。

要点

SRSによる転送は、サーバーを許可するドメインでSPFを検証できるようエンベロープ送信者を変更します。変更しないとSPFが失敗することがありますが、全メールで必ず失敗するわけではありません。PostSRSdはPostfix連携の一例です。有効な返送経路、SPF、共有シークレット、対応する除外設定、main.cfのcanonical mapをバージョンに合わせて準備します。DKIMが無効になる経路ではARCによる追加情報も検討できますが、整合性や配送の保証ではありません。

変更後は毎回、元のヘッダーを確認します。管理負担がライセンスの節約を上回るなら、直接ホストするメールボックスを検討してください。TrekMailのプランでは、紹介するNanoはカード不要ですが、有効化と機能は現在の条件によります。Proでは対応する経路のSRSとARC管理により技術作業の一部を任せられる場合があります。