[ 寄送服务指南 ]
验证通过 MailerSend 发送的电子邮件：配置和验证
验证实际的 MailerSend 域，发布当前的DKIM CNAME 及其Return-Path记录，然后测试应用程序路由，而不是依赖地址验证。
由EmailAuth研究团队提供 · 5 分钟阅读
[ 要点 ]
- 使用经过身份验证的客户端域而不是未对齐的发件人身份。
- 发布当前的DKIM CNAME 并跟踪注明日期的迁移通知。
- 验证实际的 API/ SMTP路由和不同的Return-Path 。
[ 外卖 ]
验证实际的 API/ SMTP路由和不同的Return-Path 。
[ 按角色 ]
这对您意味着什么
选择您的角色以执行后续实际步骤。
IT/邮件管理员
完成两键迁移
当前的 MailerSend 验证需要两个已颁发的DKIM CNAME。
后续步骤
- 公布两个经常账户发布的目标。
- 通过支持的转换保留旧记录。
- 在收到的邮件上测试Return-Path和DKIM 。
CISO / SecOps
保持客户权限分开
验证一个地址并不验证客户端域。
后续步骤
- 查看域与身份决策。
- 保留现有的域范围DMARC策略。
- 将DNS和应用程序更改限制在批准的范围内。
创始人/非技术人员
保护事务工作流程
域更改可能会影响客户访问和付款通知。
后续步骤
- 列出每个关键应用程序的所有者。
- 选择经过身份验证的域以进行客户端对齐的发送。
- 部署前需要经过测试的恢复路线。
[ 常见问题解答 ]
常见问题
经过验证的发件人身份是否等同于经过身份验证的域？
MailerSend 表示发件人身份使用该机构的经过身份验证的域，并且无法提供与客户端域的SPF或DKIM一致性。
如何验证和验证发送域 - MailerSend 域名 |邮件发送开发人员 代理指南：何时使用发件人身份与域 - MailerSend RFC 7208 SPF RFC 6376 DKIM RFC 9989 DMARC
当前设置需要多少条DKIM记录？
当前 2048 位DKIM配置的两个帐户颁发的CNAME记录。发布两者而不是复制旧的单记录设置。
如何验证和验证发送域 - MailerSend 域名 |邮件发送开发人员 代理指南：何时使用发件人身份与域 - MailerSend RFC 7208 SPF RFC 6376 DKIM RFC 9989 DMARC
我应该立即删除旧的DKIM记录吗？
不会。当前的迁移说明表明还不需要将其删除。 Domains API 规定旧版支持将于 2027 年 2 月 1 日结束；在实施时重新检查该通知。
如何验证和验证发送域 - MailerSend 域名 |邮件发送开发人员 代理指南：何时使用发件人身份与域 - MailerSend RFC 7208 SPF RFC 6376 DKIM RFC 9989 DMARC
Return-Path记录从哪里来？
来自域的验证页面。默认子域是 mta，但它是可配置的，因此请使用实际颁发的名称和目标。
如何验证和验证发送域 - MailerSend 域名 |邮件发送开发人员 代理指南：何时使用发件人身份与域 - MailerSend RFC 7208 SPF RFC 6376 DKIM RFC 9989 DMARC
自定义跟踪CNAME是否对退回邮件地址进行身份验证？
不。跟踪和Return-Path是不同的配置。分别验证Return-Path记录和收到的信封身份。
如何验证和验证发送域 - MailerSend 域名 |邮件发送开发人员 代理指南：何时使用发件人身份与域 - MailerSend RFC 7208 SPF RFC 6376 DKIM RFC 9989 DMARC
Return-Path子域可以满足严格的SPF对齐吗？
当它与可见的 From 域不同时则不然。严格对齐需要精确的域相等；检查对齐的DKIM作为另一个可能的传递路径。
如何验证和验证发送域 - MailerSend 域名 |邮件发送开发人员 代理指南：何时使用发件人身份与域 - MailerSend RFC 7208 SPF RFC 6376 DKIM RFC 9989 DMARC
接受的SMTP或 API 请求是否有足够的证据？
不需要。保留从实际应用程序工作流程接收到的消息，并检查接收者的SPF 、 DKIM和DMARC身份和结果。
如何验证和验证发送域 - MailerSend 域名 |邮件发送开发人员 代理指南：何时使用发件人身份与域 - MailerSend RFC 7208 SPF RFC 6376 DKIM RFC 9989 DMARC
本指南中还有哪些内容尚未得到验证？
帐户特定记录、活动应用程序路由、权威DNS和实时接收消息证据。人类 SME 和独立技术审查仍有待进行。
如何验证和验证发送域 - MailerSend 域名 |邮件发送开发人员 代理指南：何时使用发件人身份与域 - MailerSend RFC 7208 SPF RFC 6376 DKIM RFC 9989 DMARC
[ 来源 ]
来源
- 如何验证和验证发送域 - MailerSend
部分 添加/验证发送域；手动DNS ；两个DKIM CNAME581–589；返回路径295–305；自定义跟踪
- 域名 |邮件发送开发人员
部分 获取DNS记录 1157–1166：2048 位对，两者均为强制，旧版支持截止日期 2027 年 2 月 1 日
- 代理指南：何时使用发件人身份与域 - MailerSend
部分 域 107–119；身份比较136–137
- RFC 7208 SPF
部分 §3.2; 3.3; 4.6.4
- RFC 6376 DKIM
部分 §3.5; 3.6.2; 6.1
- RFC 9989 DMARC
部分 §4.4; 4.7; 4.10; 5
[ 词汇表 ]
词汇表
- 发件人身份
- 可以通过不同的经过身份验证的 MailerSend 域发送的经过验证的个人地址。
- 已认证域名
- 其颁发的DNS记录已通过 MailerSend 发送验证的域。
- Return-Path CNAME
- 为所选域下的 MailerSend 退回处理配置的DNS别名。
- DKIM迁移
- 从旧版单记录过渡到当前的 2048 位DKIM CNAME。
- 严格对齐
- DMARC对齐要求成功的身份验证域与可见的发件人域之间完全匹配。
企业出处
为什么顶级金融机构和政府 退役了他们的电子邮件安全仪表板。
传统的电子邮件身份验证平台会向您出售仪表板并要求您的工程师来完成这项工作。在高风险环境中，手动监督意味着延迟执行、配置漂移和不受监控的影子域。
EmailAuth是代理电子邮件来源平台。 我们的代理人强制执行 p=reject，保持第三方发件人一致并将您的域名移至完整状态 RFC 9989 合规性、新的DMARC标准，以及人机交互审核能力。
SaaS · 专用租赁 · 气隙本地部署 · BYOK 加密