转发邮件看起来很简单：设置重定向就完成了。但如果没有使用 SRS 转发（Sender Rewriting Scheme），SPF 可能失败。例如 bank.com 向你服务器上的转发地址发信，服务器再从自己的 IP 中继。如果信封发件人保留 bank.com，而该 IP 未获授权，SPF 就会失败。如果也没有有效且对齐的 DKIM，域名又发布了 p=reject，接收方可能拒收。这不一定悄无声息：提交邮件的服务器可能收到 SMTP 错误并生成未投递通知。
本文是 SRS 转发的操作指南。邮件转发设置与故障模式完整指南提供整体介绍。这里重点讨论架构、地址重写语法、Postfix 集成，以及作为额外认证上下文的 ARC，而不是把它们视为 DMARC 通过或投递成功的保证。
SRS 转发实际做了什么
SRS 会在服务器中继邮件时重写信封发件人，用你控制的域名替代原始域名。如果新域名正确授权转发服务器 IP，SPF 就可能通过。客户端显示的标头 From 保持不变。重写不保证与该 From 对齐，也不保证接收方接受邮件。
没有 SRS 时，如果新 IP 未获授权，转发邮件可能无法通过 SPF。SRS 让信封身份适应新路径，但仍需检查 DNS、DKIM、DMARC 对齐和接收方策略。它不会消除所有认证风险。
邮件身份的两层结构
正确配置 SRS 需要区分以下两个字段。SPF 检查信封域名，而 DMARC 将可见 From 作为对齐参照。
- 信封发件人（RFC 5321 MAIL FROM）：邮件传输代理用于退信路由的返回地址。SPF 检查连接 IP 是否获准为该域名发信。用户也可以在原始标头的 Return-Path 中查看它。
- 标头 From（RFC 5322 From）：客户端显示的地址。DMARC 要求 SPF 或 DKIM 至少有一条有效路径与其域名对齐。SRS 不修改这个字段。
以下示例假设 SRS 前 IP 未获授权，之后已正确授权：
| 跳转 | 连接 IP | 信封发件人 | 示例 SPF 结果 |
|---|---|---|---|
| 1：Alice → 你的服务器 | Alice 的服务器 | alice@client.com | PASS |
| 2：你的服务器 → Gmail（无 SRS） | 你的服务器 | alice@client.com（不变） | FAIL |
| 2：你的服务器 → Gmail（有 SRS） | 你的服务器 | SRS0=Hash=Time=client.com=alice@yourdomain.com | PASS |
SRS 将自有域名写入信封发件人。其 SPF 必须授权实际发送路径，检查才可能通过。这并不要求接收方一定投递。重写地址通常不会作为发件人显示在界面中，但仍可在原始标头里查看。
SRS 转发语法：各字段的含义
重写地址看起来复杂，但每个字段都有用途。理解它有助于排查退信日志和多跳投递链。
首次 SRS 转发重写（SRS0）如下：
SRS0=Hash=Timestamp=OriginDomain=OriginLocalPart@AnchorDomain各组件：
- Hash：使用本地密钥生成的截断 HMAC 认证码，SHA1 是某些实现采用的算法示例。它验证 SRS0 退信地址并增加伪造难度，但不能消除所有未投递通知滥用风险。
- Timestamp：时间戳，例如使用 base32 编码，有效期为 7 至 21 天。格式和期限取决于实现及配置。拒绝过期地址可以限制部分重复使用风险，但不能阻止所有重放攻击。
- Origin：发生退信时重建原发件人所需的数据。服务器收到未投递通知后，反向解析重写地址，再将通知送到原发件人。
- AnchorDomain：你控制的域名。它需要授权发送服务器的 SPF，以及可接收退信的有效路径，通常通过 MX；在某些情况下，SMTP 可通过隐式 MX 使用 A 或 AAAA。
继续转发时，实现可能把 SRS0 换成 SRS1：
SRS1=NewHash=PreviousAnchorDomain==SRS0_Suffix@NewAnchorDomainSRS1 有助于限制本地部分增长，但仍需检查 64 字符限制（RFC 5321）。排查多跳链故障时，应同时检查长度、认证、有效期、路由和日志；地址长度并非唯一原因。
Postfix 集成：配置 PostSRSd
PostSRSd 是 Linux 与 Postfix 的一种 SRS 集成选择。Postfix 可通过地址重写映射查询该服务，传入信封地址并取得转换结果。以下内容为配置示例：适配前请核实版本、软件包和路径，不要在未审查自身配置时执行命令。
步骤 1：重写域名的前置条件
修改文件前，先准备将出现在重写信封发件人中的域名。需要检查：
- MX 记录：域名应接收未投递通知并正确送回原发件人。通常使用显式 MX，但在某些条件下 SMTP 也允许通过 A 或 AAAA 使用隐式 MX。应按 RFC 5321 检查实际返回路径。
- SPF 记录：接收方根据此域名检查服务器 IP。如果 IP 未获授权或记录有误，SRS 不保证 SPF 通过。
- 信誉：中继垃圾邮件可能影响服务器与重写域名，并增加进入阻止名单的风险。这并非必然，SRS 也不能替代过滤。
# 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 的 Unix 套接字映射，以及 1.x 的 TCP 映射。语法、套接字路径和 Postfix 访问方式取决于安装，请查阅对应版本文档：
# 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 postfixSRS 还不够：ARC 的作用
SRS 可能让新域名的 SPF 通过，但不能单独建立与原始 From 的 DMARC 对齐。DMARC 要求 SPF 或 DKIM 至少有一条有效路径与该 From 对齐。如果 SPF 认证的是 relay.yourdomain.com 而非 client.com，在此示例中就不对齐。此时 DMARC 可能依赖有效且对齐的 DKIM。
转发修改可能在影响已签名部分并改变规范化后的内容时使 DKIM 失效。在主题中加入“外部发件人”前缀、附加退订页脚或修改 MIME，并不一定使所有签名失效，结果取决于签名范围。如果对齐的 DKIM 失效，SPF 又不对齐，DMARC 就会失败，接收方再执行自身策略。
ARC（Authenticated Received Chain）在 RFC 8617 中定义，可以传递实际观察到的认证结果。信任 ARC 签名方和链的接收方，可能在 DMARC 失败时参考这些信息。ARC 不会修复对齐，也不保证投递成功。
一个 ARC 实例会添加三个标头：
ARC-Authentication-Results：服务器观察到的认证检查结果ARC-Message-Signature：对创建 ARC 签名时部分标头与正文内容的签名ARC-Seal：将当前实例与各跳 ARC 链连接起来的密码学关联
SRS 调整信封发件人，ARC 提供认证上下文。它们可在严格策略下互补，但并非总是投递所必需，也不足以保证成功。如果 DKIM 失败且 SPF 不对齐，单独使用 SRS 不会让 DMARC 通过。
SRS 针对的 SPF 转发问题，其规范性参考为 RFC 7208。
部署前应了解的服务商特定问题
即使 SRS 与 ARC 正确配置，服务商仍可能按策略阻止转发，与认证结果无关。应先检查策略范围及所属环境，再判断是否为配置问题。
| 服务商 | 错误或行为 | 可能原因 | 处理方式 |
|---|---|---|---|
| Microsoft 365 | 550 5.7.520 Access denied | 源环境的 M365 策略限制出站外部转发，以降低数据泄露风险 | 获授权管理员在 Defender 中检查出站垃圾邮件策略，只允许经批准且具备适当控制的路径 |
| Microsoft 365 | 554 5.4.14 Hop count exceeded | 可能存在路由循环，例如 catch-all 转到外部后又返回 | 审查 catch-all 和路由，在源头解除循环 |
| Gmail / Workspace | 邮件未到达；可能没有 NDR | 循环检测可能导致拒收或丢弃，是否通知取决于路径和系统 | 具有获授权的 Workspace 访问权限时，检查 Google Admin 中可用的投递工具，并修复路由 |
| Gmail / Workspace | 高发送量审查 | 每天 >5,000 封转发邮件的示例，不代表所有流量都会自动被归为批量发件人；应核实当前判定标准 | 评估大规模转发架构和实际适用的要求 |
定位正确策略可以减少排查 M365 550 5.7.520 的时间：它通常涉及源环境的出站转发，而不是要在目标租户中修改的策略。SRS 和 ARC 不能解除这一限制。Defender 中的审查和更改应由获授权管理员按安全策略执行。
验证 SRS 转发是否工作
用于生产前，应发送测试邮件并在接收端查看原始标头。Return-Path 中的 SRS 地址说明这封邮件存在可见重写，不代表投递获得保证。保留原地址可能是排除规则、未调用 SRS 的路径或集成问题，不能单独证明服务没有运行。
1. 检查 Return-Path 标头
从外部账户（例如 ProtonMail）向转发地址发送测试。查看原始邮件中的 Return-Path，并检查认证结果：
Return-Path: <SRS0=...@yourdomain.com>→ 可以看到 SRS 重写，仍需确认认证结果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 +short3. 检查 Postfix 日志
grep -E "srs_forward|canonical" /var/log/mail.log | tail -50查找向 SRS 服务发出的查询和返回的重写地址。连接被拒绝可能源于服务停止、套接字或端口配置错误、权限或网络规则。systemctl status postsrsd 有助于检查服务，但不能排除其他原因。
4. 测试连接与 TLS
SRS 故障和连接故障可能表现相似。以下测试有助于区分 SMTP 连通性与 TLS 协商：
openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp超时可能由网络、端口或过滤造成，不一定是 TLS 问题。协商失败时应查看具体响应，并与 SRS 地址重写问题分开调查。
何时停止转发，改用托管邮箱
SRS、ARC、重写域名、密钥、排除规则和信誉都需要维护。有时选择这种架构是为了避免按邮箱付费。例如，把 sales@ 转到个人邮箱，可以在某个成本示例中省去每月 $6 的席位费用。一个地址可能划算，管理十个时却可能增加维护成本。
邮件别名与转发取舍指南比较哪些场景适合转发，以及哪些场景会累积问题。别名与邮箱选择指南帮助确定基础地址结构。
| 原方式：转发 | 替代方式：按套餐托管在 TrekMail | |
|---|---|---|
| SPF 检查 | 可能需要 SRS 集成和重写域名配置 | 按配置提供服务器管理；直接投递可避免该跳转 |
| DMARC | 对齐的 DKIM 可能足够；ARC 提供上下文 | 在支持的配置中使用 OpenARC，但不保证 DMARC 通过 |
| 退信处理 | 重写域名需要可用的通知接收路径 | 按路径和套餐由 TrekMail 基础设施处理 |
| 持续运维 | 密钥轮换、排除规则更新和信誉监测 | 减少转发维护，但仍需检查配置与访问控制 |
| 存储模式 | 取决于目标服务商，其也可能提供共享存储 | 在套餐限制内供各邮箱共享存储 |
所述 Pro 方案（每月 $10）包含 100 个域名和 50GB 共享存储。你可以将 sales@、support@ 和 info@ 托管为真实 IMAP 邮箱，在套餐限制内不按用户收费，并避免这些转发链。请核实当前条件：直接投递不保证接收成功或无限期保存。
如果仍需转发，例如把多个域名集中到一个目的地，所述 Pro 和 Agency 配置包括服务器端的 SRS 重写及 OpenARC 签名。请确认当前可用性和要求，它们不保证投递成功。Nano 使用自有 SMTP，并不自动获得转发权限；如果外部出站基础设施支持这条路径，应在那里集成 SRS，并按版本适配 PostSRSd 或其他方案。
有关转向 Gmail 的具体路径，域名邮件转发到 Gmail 指南详细介绍可能故障和验证步骤。
简要总结
SRS 转发重写信封发件人，让 SPF 检查授权实际连接 IP 的域名。这可能使 SPF 通过，但不保证 DMARC 通过。PostSRSd 是 Postfix 的一种集成选择：应验证域名和退信路径、SPF、密钥、排除规则，以及 main.cf 中兼容的映射。当 DKIM 失效且 SPF 不对齐时，可评估 ARC 能否为接收方提供有用上下文。
每次配置变更后，都应检查原始标头、认证和退信。如果维护成本超过省下的许可费用，可考虑直接投递的邮箱。查看 TrekMail 套餐：所述 Nano 条件无需信用卡，但激活和功能受当前前置条件与限制影响。Pro 在支持的配置中提供托管 SRS 和 ARC。
