SPF和DKIM TXT记录是否需要引号？

我已经搜索了几个小时，但是有多个消息来源说了不同的话。

https://support.wordfly.com/hc/zh-CN/articles/204767474-How-do-we-publish-DKIM-and-SPF-in-our-DNS-状态我不应该使用引号，而https： //stackoverflow.com/a/9784925/1293725读引号应包含在这些TXT记录中。

这些只是一些来源示例，但还有更多示例。

那么这些记录是否应该包含引号？

dns spf dkim

— Neograph734
source

这实际上取决于您的系统/设置。例如。我假设使用wordfly，您是在Web表单中输入值。在形式中使用引号确实会使事情搞砸。因此，该过程很可能会假设您使用引号，并在DNS中使用引号输入值。

— closetnoc

@closetnoc是正确的。是否使用引号可能与您用来输入引号的网站/工具有更多关系。

— 宣威航班

谢谢，我先尝试使用引号，然后再看系统是否抛出错误。我发现它令人困惑，因为源表明TXT记录中的空格使每个单词都被视为一个单独的字符串，而且我无法弄清楚这是否是SPF和DKIM的预期行为。但我知道现在应该将其视为一个字符串。

— Neograph734 2015年

我使用引号，将DNS移至新的提供程序（Azure DNS），并且SPF停止工作。删除引号，一切都再次起作用。因此，这取决于提供者。确保您验证记录。您要为其创建SPF记录的实体通常具有工具/按钮来执行此操作。

— nmit026 '17

在（原始）DNS区域文件中，如果TXT记录的值包含空格（与SPF和DKIM记录一样，则需要用双引号引起来）。否则，空格是DNS区域文件中的定界符。

RFC 1305定义了应该如何在Zone罚款中引用值。关于TXT资源记录：

3.3.14。TXT RDATA格式
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/                   TXT-DATA                    /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
哪里：

TXT-DATA一个或多个<character-string>。

^[第20页]

<character-string>用一种或两种方式表示：表示为连续的无内部空格的字符集，或表示为以“开头”并以“结尾”的字符串。在“分隔的字符串内，除”“本身外，任何字符都可以出现，必须使用\（反斜杠）将其引起来。

^[第35页]

但是，如评论中所述，您经常使用另一种工具来编辑DNS记录（尽管WHM确实为您提供了此选项，但通常不直接编辑DNS区域文件）。此其他工具可能会处理引号和使记录有效所需的任何其他转义。如果在使用编辑器/工具提交值时手动将值括在引号中，则这些附加引号可能会被转义并成为TXT记录值的一部分。

顺便说一句，当您执行DNS查找时，您会看到已解析/未加引号的字符串值。

进一步参考：
https : //en.wikipedia.org/wiki/TXT_Record
https://tools.ietf.org/html/rfc1464

— 怀特先生
source

是的，在阅读评论后，我也在注册服务商的网站上找到了手册，说明记录应该不带引号输入（尽管我之前用引号将它们记录下来，并且在线验证程序将其标记为有效，所以也许这两种方式均适用于我的情况））。我已改用推荐的注册商格式。谢谢大家的帮助！

— Neograph734

是的，Cloudflare也有关于报价的特别说明support.cloudflare.com/hc/en-us/articles/…–

— lkraav

在哪里可以找到此规则，“如果TXT值包含空格，则必须用双引号引起来”？这听起来像是个好规则，但是这是谁的规则呢？我在RFC 1464或您提到的Wikipedia文章中找不到任何有关它的信息。（RFC 1464提到转义了内部双引号，但这是不同的。）

— Garret Wilson

嗯，据我所知，这种转义是在RFC 1035的3.3节中为<character-string>生产定义的，稍后在3.3.14节中它指定TXT记录具有<character-string>数据，因此应将其引用。（HINFO无论记录如何，记录中都提到了这一点。）

— Garret Wilson

是的，RFC 1305似乎是定义它的地方。如果在WHM中编辑原始DNS区域，则实际上会提示您“必须遵循RFC 1035中描述的引用和转义约定”。我会更新我的答案，谢谢。

— 怀特先生