如何使用中間域為 DKIM 和 SPF 設置 DNS 設置？
我正在開發一種幫助使用者發送電子郵件的工具。我計劃在後端使用 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.frankthetankxyzhttps://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
- 原始 RFC。如果您對 SPF 進行任何形式的混淆，您很可能會遇到此問題
額外的 DNS 查找將增加郵件傳遞流和/或您的應用程序中任何基於 DNS 的查找的響應時間 - 這可能會在許多層面上造成很大的痛苦，尤其是當 MTA 正在實時處理時，任何延遲都會產生巨大的潛在連鎖影響。
為了對此進行一些數學運算，假設一封電子郵件需要 20 毫秒才能通過帶有 DNS 的 MTA 進行處理和發送 - 這是假設此邏輯成立的最佳案例範例。您每小時可以發送大約 180k 封電子郵件。如果我們需要通過添加至少 1 個額外的 dns 查找來將其翻倍，這將減半至每小時 90k 封電子郵件。如果您依賴於容量，您現在需要投入兩倍的硬體來維持相同的吞吐量。