AWS SES SendBounce发送退信邮件的DMARC合规问题

问题1：通过SendBounce接口发送的邮件是否存在可行方案实现DMARC合规？ #

原生直接调用SendBounce、使用根业务域作为发信From地址的场景下，没有可实现严格DMARC合规的方案，目前可落地的方案只有两类：

• 子域隔离方案（生产环境最稳妥的落地方式）：单独规划退信专用子域，例如bounce.email.com，为该子域单独配置v=DMARC1; p=none的DMARC记录，调用SendBounce时将From头设置为mailer-daemon@bounce.email.com。由于DMARC的子域策略查找优先级高于根域继承策略，该子域的退信不会触发根域p=quarantine/p=reject的拦截规则，可避免退信被丢入垃圾邮件或直接拒收。
• 替换接口实现完全合规：放弃使用SendBounce接口，改用常规的SendEmail/SendRawEmail接口自行构造符合RFC 3464标准的投递状态通知（退信），发信时配置自定义MAIL FROM域、开启对应发信域的DKIM签名，SES会自动为发信域添加DKIM签名，同时自定义MAIL FROM域可满足SPF对齐要求，最终实现DMARC完全合规。该方案的缺点是需要自行严格遵循退信格式规范，否则可能被收件方判定为伪造系统通知。

补充说明：SendBounce发信时强制使用空MAIL FROM:<>，此时SPF校验对象为SMTP会话的HELO域，而SES固定使用*.amazonses.com作为HELO标识，和用户自有发信域无法满足SPF对齐要求；加上接口固定只加d=amazonses.com的DKIM签名，DKIM对齐也无法满足，因此原生调用必然触发DMARC校验失败，用户侧没有配置项可以修改SES侧的这两个固定行为。

问题2：SES出于何种设计原因未给SendBounce发送的邮件添加对应From:头域名的DKIM签名？ #

核心是三个层面的设计考量，均符合邮件行业的通用规则和安全要求：

• 符合MTA系统邮件的身份惯例：SendBounce产生的邮件属于MTA层面自动生成的投递状态通知，RFC 5321明确要求这类系统通知必须使用空MAIL FROM，行业通用做法是由MTA使用自有域为这类系统邮件签名，代表邮件是MTA系统自动产生的，而非用户业务主动发送的常规邮件。
• 规避接口被滥用的安全风险：如果放开用户自定义From域的DKIM签名，攻击者可通过滥用SendBounce接口构造任意内容的邮件，绕过SES常规发信的内容校验、身份校验，发送带有用户合法域DKIM签名的钓鱼邮件、垃圾邮件，带来极高的安全风险。
• 明确责任边界：SendBounce的退信内容框架是SES侧自动组装生成的，并非用户完全可控的内容，使用SES自有域amazonses.com签名，代表该邮件的生成主体是SES服务侧；如果添加用户域的DKIM签名，相当于用户需要为SES自动生成的邮件内容承担身份背书责任，会出现责任边界模糊的问题。

内容的提问来源于stack exchange，提问作者mxxk