某些 DNS 檢查器中出現奇怪字元，但 DKIM 和 SPF 中沒有其他字元，可能導致 DMARC 失敗

從我在 Rackspace Cloudways 附加組件中設置的所有 3 個電子郵件地址發送的電子郵件最終都在 GMail 中的垃圾郵件中。

當我在 GMail 中“查看原始郵件”時，我看到…

SPF:    NEUTRAL with IP 173.203.187.81
DMARC:  'FAIL'

… 其中 173.203.187.81 是 IP 地址 Rackspace。

我的 DNS 提供商是 CloudFlare。

設置了 DMARC 策略，如下所示…

_dmarc.boldstatements.com.au    v=DMARC1; p=none; ruf=mailto:admin@mydomain.net; rua=mailto:admin@mydomain.net

Cloudways 為我提供了這張 DKIM TXT 記錄…

20220817-maluhsjy._domainkey    v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC0PqtvPuYkElqS+b80iEj4aepAdf6n+CDXRFTG/1Q8RMdw/D6hNmQpv8FCTyIuplZt/qTxBbBFrPLJK5tp7bqkSEG2YpPSnHDCGihaOCsRkJP0aAbnuQRmjHq6H0yCwtJKjRhW7H4pbjx9/LA6dXIaw4N1emtSLWcGejVrhVZ+CwIDAQAB

當我使用 dnschecker.org 和其他一些 DNS 查找工具來查看我的 TXT 記錄時，我得到以下奇怪的輸出……

\239\187\191v=spf1 a mx include:_spf.elasticemail.com include:emailsrvr.com -all

這些字元\239\187\191肯定不在 CloudFlare 的 TXT 記錄中。

CloudWays 的支持聲稱這些字元導致 DMARC 失敗，但由於它們沒有出現在其他 DNS 檢查器上，例如https://mxtoolbox.com/>和<https://www.whatsmydns.net/，並且因為 SPF返回“中性”，我懷疑它們實際上是https://dnschecker.org/和 Cloudways 支持使用的 DNS 檢查器中的一個錯誤。

有什麼想法嗎？

筆記

感謝 Patrick Mevzek 在下面的回答，我能夠找到解決方案。

簡單描述一下我最初是如何陷入這種混亂的：基本上，我將 DNS 記錄的值從 Cloudways 支持聊天視窗直接複製粘貼到 Cloudflare。

並刪除我需要將值從 Cloudflare 複製到 Notepad++ 中的字元，將編碼更改為 ANSII，這會使無關字元出現，刪除它們，然後改回 UTF-8（以防萬一），然後粘貼回 CloudFlare .

FWIW，

\239\187\191是 3 個字節的十進制值 239、187、191 的 DNS 編碼，它以十六進制映射到EF BB BF，這是 Unicode 程式碼點的 UTF-8 編碼U+FEFF，即ZERO WIDTH NO-BREAK SPACE

我懷疑此 TXT 記錄是通過從某處複製和粘貼以及一些“智能”行為創建的，顯然該空間在某些 UI 的螢幕上不可見，但確實落在了 TXT 記錄中。

這必須清理，也就是刪除。

至於：

這些字元\239\187\191 肯定不在CloudFlare 的TXT 記錄中。

和

但由於它們不會出現在其他 DNS 檢查器上，例如https://mxtoolbox.com/>和<https://www.whatsmydns.net/，

我懷疑各種系統（錯誤地但不幸的是根本沒有標準，DNS 是在 Unicode/UTF-8 之前發明的，然後很多事情，比如SPF剛剛決定濫用TXT記錄）只是將TXT記錄內容視為 UTF 中的字元串-8 所以他們解碼並顯示它，但顯然“零寬度空間”在任何 HTML 頁面上都不可見。

一個更好的 UI 會處理這個問題並正確顯示和/或警告它。一個更好的 UI 會更好，所以只需在添加記錄時刪除該字元，因為這裡顯然是錯誤的（但TXT記錄中的明顯內容是有限的……你必須看到它是v=spf1或類似的，然後採取相應的行動）。現在這讓我對應該在自己的 UI 中修復什麼有了一個好主意，謝謝你的想法:-)

引用自：https://serverfault.com/questions/1109042