☰

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

tag-icon • tag-icon domain-name-system spf cloudflare dmarc
一些 DNS 检查器中出现奇怪的字符，但其他 DKIM 和 SPF 检查器中没有出现，可能导致 DMARC 失败

我已在 Rackspace Cloudways 插件中设置的所有 3 个电子邮件地址发送的电子邮件最终都被归类为 GMail 中的垃圾邮件。

当我在 GMail 中“查看原始消息”时，我看到...

SPF:    NEUTRAL with IP 173.203.187.81
DMARC:  'FAIL'

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

我的 DNS 提供商是 CloudFlare。

已设置 DMARC 策略，具体如下...

_dmarc.boldstatements.com.au    v=DMARC1; p=none; ruf=mailto:[email protected]; rua=mailto:[email protected]

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。

答案1

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 中修复什么有了很好的了解，感谢您的想法 :-)

答案2

SPF‘中性’是您给出的 SPF 记录绝对不可能出现的结果。

该记录中没有任何限定词可以产生“中立”结果，最终机制是-all，会产生“失败”的结果。

此外，根据 RFC 7208，SPF 记录是通过仅选择以v=spf1（不区分大小写）开头的 TXT 记录来找到的，因此，如果这些额外的字节实际上是假定记录的一部分，那么它永远不会被识别为 SPF 记录。

答案3

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

是的，他们是：

$ dig -t txt +short $yourdomain.com.au 
"\239\187\191v=spf1 a mx include:emailsrvr.com include:_spf.elasticemail.com ~all"

相关内容