我正在开发一种帮助用户发送电子邮件的工具。我计划在后端使用 MTA（邮件传输代理），如 AWS-SES 或 Sendgrid 等。为了使电子邮件成功到达 recipeints 收件箱，用户必须通过配置 DNS 来设置 DKIM/SPF各自域的设置。
现在，如果我以 SES 为例，我知道他们有一个 API，允许我添加一个“身份”并使用该 API 取回所有必要的 DNS 记录。我确信 Sendgrid 和其他 MTA 具有类似的 API，允许添加身份并返回 DNS 记录供用户应用。
我向用户显示返回的 DKIM DNS 设置，他们将其添加到他们的 DNS 提供商，然后当他们发送电子邮件时，recipints 会正确获取它（标题中没有任何“通过 amazonses.com”的东西）
现在举个例子——假设我正在构建的工具托管在 chillybilly.xyz 上，并且其中一个使用我的工具的用户有一个名为 frankthetank.xyz 的域，他们想用它来通过我的平台发送电子邮件.
当用户尝试通过我的平台验证他的域时，我将在 AWS SES 中点击上面提到的 API - 并向用户显示如下内容：
之后，他们可以为成功的 DKIM/SPF 添加这些 CNAMES 和 TXT 记录，并可以开始发送电子邮件。但是如果你仔细观察，他们可以看到我使用的是 SES，因为这些 CNAMES 和 TXT 记录的值。这是我想要避免的事情，相反，我想要那些被称为类似的东西7nuk24xywyawocu6ctqjxmjasiaiq3vq.dkim.chillybilly.xyz来显示我的品牌，但在后台它仍然会指向正确的 SES。
现在我知道，这样的事情是可能的，因为当我注册 ConvertKit 时，他们向我展示了如下内容：
如您所见，这两个值指向 converkit.com 但是当我通过 DNS 查找运行它们时：
我可以看到它在后台指向属于 Sendgrid 的 MX 和 TXT 记录。我怎样才能做到这一点？（我相信同样的原则也适用于 SES 或任何其他 MTA）
编辑：
我尝试了一些事情 - 我在 chillybilly.xyz （我的项目的域）中设置了 CNAME、MX 和 TXT，并从 frankthetank.xyz 指向了两个 CNAMES 调用spf.frankthetank.xyz和dkim.frankthetankxyz
https://dnschecker.org/all-dns-records-of-domain.php?query=spf.frankthetank.xyz&rtype=ALL&dns=google
如您所见，我能够获得与 ConvertKit 使用 Sendgrid 所做的非常相似的结果。但它并没有以这种方式得到验证。:(
当我检查这些 DNS 查找（上面的链接）时，我看到的唯一区别是 CNAME 也出现在我的查找中，但在 convertkit 的情况下却没有。所以我认为我接近解决方案，但不确定我缺少什么，有什么想法吗？:)
第一个 SPF：如果您更换例如。sendgrid 的外发 SPF 记录，包含在您的 SPF 记录中，带有您自己的品牌，同时您还负责跟踪 sendgrid 可能对其外发邮件服务器的名称和地址执行的所有动态操作。您不想这样做，因此如果您通过 sendgrid 发送，则需要包含 sendgrid 的 SPF。因此，由于您使用 sendgrid，因此您无法在不给自己造成痛苦的情况下摆脱 SPF 记录中的“include: sendgrid.net”。
DKIM 与此类似，亚马逊的示例是为亚马逊 DNS 中存在的记录创建 CNAME。如果你想用你自己的替换它（你可以，没问题），你必须将这些记录放入你自己的 DNS 中。这没问题，但是，您必须以某种方式将签名密钥转移给签署这些电子邮件的人，这可能是个问题。借助亚马逊解决方案，他们创建了密钥，并为您提供了他们放入其 DNS 中的公钥的链接，该链接与他们签署您的电子邮件所用的私钥相匹配。
但是，如果您想从 Amazon 或 sendgrid 的邮件服务器中删除“品牌”，唯一的方法就是购买它们，因为这是通过反向 DNS 完成的，它们永远不会将其传出服务器指向您的 DNS 名称空间中的名称。
因此，您可以只做指向原始源记录的 CNAME 记录，或者像 convertkit 示例一样将正确的 SPF 放在您的域下。
或者有一个中间件在 sendgrid/AWS 中通过域验证过程，在您的域上创建 DNS 记录，然后您告诉您的客户对您创建的新 DNS 记录进行 CNAME，然后在客户单击后完成验证按钮说他们已经这样做了
这不会阻止电子邮件标头或跟踪 DNS 记录以查找原始提供商，但对于普通人来说这可能没问题。
但是我想提醒这一点 - 混淆层实际上会伤害 DNS 层。
例如，SPF 在 RFC 中有一个明确的硬编码 10 次查找限制 - Sendgrid 自己写了关于它 - https://docs.sendgrid.com/ui/account-and-settings/spf-limitations
额外的 DNS 查找将增加邮件传递流和/或您的应用程序中任何基于 DNS 的查找的响应时间——这可能会在许多层面上造成很大的痛苦，尤其是当 MTA 正在实时处理时，任何延迟都会产生巨大的潜在连锁影响。
为了对此进行一些数学运算，假设一封电子邮件需要 20 毫秒才能通过带有 DNS 的 MTA 进行处理和发送 - 这是假设此逻辑成立的最佳案例示例。您每小时可以发送大约 180k 封电子邮件。如果我们需要通过添加至少 1 个额外的 dns 查找来将其翻倍，这将减半至每小时 90k 封电子邮件。如果您依赖于容量，您现在需要投入两倍的硬件来维持相同的吞吐量。
SG 有一个
automatic_security在Authenticate a Domain API 中调用的选项。我认为这个选项在后端的作用是让 SG 使用其 DNS 记录管理/轮换 DKIM 密钥和其他记录。因此，当您将此选项设为 true 时，它们会返回 CNAME 记录而不是 MX 和 TXT 记录。MX/TXT 记录由 SG 在幕后管理。关于 CNAME 记录的方便之处在于其他 CNAME 记录可以很容易地指向它们。所以我指出
chillybilly.xyz -> SG CNAME records我从 SG 回来，然后我指出frankthetank.xyz records -> chillybilly.xyz CNAME records并因此在两者之间创建了一种中间件。请不要这
chillybilly.xyz是我的应用程序的域，并且frankthetank.xyz是客户的域。这是我们在解决问题时所依据的假设。当然，正如其中一个答案指出的那样，由于中间有另一层，这将增加 DNS 查找，我们仍然需要评估这样做是否真的对我们有意义，或者在最终扩大规模时是否会增加电子邮件传递时间。但解决方案确实有效。我认为它是一个 SG 唯一的实现。我无法使其与 AWS SES 一起使用。我很快就会和他们打个电话 - 如果我知道更好，会编辑这个答案:)