奇怪的字符出现在某些 DNS 检查器中,但 DKIM 和 SPF 的其他检查器中则没有,可能导致 DMARC 失败

cla*_*Ray 7 domain-name-system spf cloudflare dmarc

从我在 Rackspace Cloudways 附加组件中设置的所有 3 个电子邮件地址发送的电子邮件最终都会成为 GMail 中的垃圾邮件。

当我在 GMail 中“查看原始邮件”时,我看到...

SPF:    NEUTRAL with IP 173.203.187.81
DMARC:  'FAIL'
Run Code Online (Sandbox Code Playgroud)

...其中 173.203.187.81 是 Rackspace 的 IP 地址。

我的 DNS 提供商是 CloudFlare。

设置了 DMARC 策略,如下......

_dmarc.boldstatements.com.au    v=DMARC1; p=none; ruf=mailto:admin@mydomain.net; rua=mailto:admin@mydomain.net
Run Code Online (Sandbox Code Playgroud)

Cloudways 向我提供了此 DKIM TXT 记录...

20220817-maluhsjy._domainkey    v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC0PqtvPuYkElqS+b80iEj4aepAdf6n+CDXRFTG/1Q8RMdw/D6hNmQpv8FCTyIuplZt/qTxBbBFrPLJK5tp7bqkSEG2YpPSnHDCGihaOCsRkJP0aAbnuQRmjHq6H0yCwtJKjRhW7H4pbjx9/LA6dXIaw4N1emtSLWcGejVrhVZ+CwIDAQAB
Run Code Online (Sandbox Code Playgroud)

当我使用 dnschecker.org 和其他一些 DNS 查找工具来查看我的 TXT 记录时,我得到以下奇怪的输出......

\239\187\191v=spf1 a mx include:_spf.elasticemail.com include:emailsrvr.com -all
Run Code Online (Sandbox Code Playgroud)

这些字符\239\187\191肯定不在 CloudFlare 的 TXT 记录中。

CloudWays' support claims that these characters are causing the DMARC to fail, but since they don't appear on other DNS checkers such as https://mxtoolbox.com/ and https://www.whatsmydns.net/, and since SPF is returning "neutral", I suspect they are actually a bug in https://dnschecker.org/ and the DNS checker that Cloudways support are using.

Any thoughts?

NOTES

Thanks to Patrick Mevzek's answer below I was able to find a solution.

Just a quick description of how I ended up in this mess in the first place: Basically I copy pasted the values of the DNS records from a Cloudways support chat window straight into Cloudflare.

And to remove the characters I needed to copy the value from Cloudflare into Notepad++, change the encoding to ANSII, which made the extraneous characters appear, delete them, then change back to UTF-8 (just in case), and paste back into CloudFlare.

Pat*_*zek 29

FWIW,

\n

\\239\\187\\191 is DNS encoding of 3 bytes of decimal values 239, 187, 191 which maps in hexadecimal to EF BB BF, which is the UTF-8 encoding of Unicode codepoint U+FEFF, which is ZERO WIDTH NO-BREAK SPACE

\n

I suspect this TXT record was created by copy and pasting from somewhere and some "smart" behavior and obviously the space is not visible on screen in some UI but did land up in the TXT record.

\n

This has to be cleaned, aka removed.

\n

As for:

\n
\n

These characters \\239\\187\\191 are definitely not in the TXT record in CloudFlare.

\n
\n

and

\n
\n

but since they don\'t appear on other DNS checkers such as https://mxtoolbox.com/ and https://www.whatsmydns.net/,

\n
\n

I suspect that various systems (mistakenly but there is unfortunately no standard there at all, DNS was invented far before Unicode/UTF-8 and then lots of things like SPF just decided to abuse TXT records) just consider the TXT record content to be a string in UTF-8 so they decode it and display it, but obviously the "zero-width space" is not visible on any HTML page.

\n

更好的用户界面会处理这个问题并正确显示和/或发出警告。更好的用户界面甚至会在添加记录时删除该字符,因为这里显然是错误的(但TXT记录中的明显内容是有限的\xe2\x80\xa6,你必须看到它是v=spf1或类似的,然后采取相应的行动).\n这让我对应该在自己的 UI 中修复哪些内容有了一个好主意,感谢您的想法:-)

\n

  • @user253751“零宽度无中断空格”**是**“字节顺序标记” - 它是一个对其周围的文本没有影响的字符,因此被选为安全指示符。U+FFFE 是保留的非字符,是由于在 *UTF-16* 中以错误的方式读取而导致的。 (6认同)
  • @clayRay + 向您的 DNS 提供商抱怨,其 UI 没有检测到这一点,也没有帮助您查看问题,因此您最终发布的内容与您认为发布的内容不同。也许他们有兴趣解决这个问题。您很可能不是唯一受到此类情况影响的人,即使数量很少。 (2认同)