6. 修饰符定义 (Modifier Definitions)
修饰符是提供附加信息的名称/值对。修饰符总是使用"="分隔名称和值。
本文档中定义的修饰符（"redirect"和"exp"）应该出现在记录的末尾，在所有机制之后，尽管在语法上它们可以出现在记录中的任何位置。这两个修饰符的顺序无关紧要。这两个修饰符不得在一个记录中各出现超过一次。如果出现，则check_host()退出并返回"permerror"结果。
未识别的修饰符必须被忽略，无论它们出现在记录中的何处或出现多少次。这允许符合本文档的实现优雅地处理在其他规范中定义的修饰符的记录。
6.1. redirect: 重定向查询 (Redirected Query)
"redirect"修饰符旨在将授权和策略整合到要在单个ADMD内共享的公共集合中。可以从单个记录中控制任意数量域的授权主机和策略。
redirect = "redirect" "=" domain-spec
如果所有机制都无法匹配，并且存在"redirect"修饰符，则处理按如下方式进行：
redirect部分的
这个新的check_host()评估的结果然后被视为当前评估的结果，但如果找不到SPF记录，或者如果
注意，新查询的域本身可以指定重定向处理。
此功能旨在供希望将相同记录应用于多个域的组织使用。例如：
la.example.com. TXT "v=spf1 redirect=_spf.example.com"
ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
_spf.example.com. TXT "v=spf1 mx:example.com -all"
在此示例中，来自这三个域中任何一个的邮件由相同的记录描述。这可能是一个管理优势。
注意：一般来说，域"A"不能可靠地使用重定向到不在相同管理控制下的另一个域"B"。由于
为清楚起见，任何"redirect"修饰符应该作为记录中的最后一个术语出现。如果记录中任何地方存在"all"机制，则必须忽略任何"redirect"修饰符。
6.2. exp: 解释 (Explanation)
explanation = "exp" "=" domain-spec
如果check_host()由于机制匹配（例如"-all"）导致"fail"，并且存在"exp"修饰符，则按下文所述计算返回的解释字符串。如果不存在"exp"修饰符，则必须向调用应用程序返回默认解释字符串或空解释字符串。
如果有任何DNS处理错误（任何RCODE不是0），或者如果没有返回记录，或者如果返回多个记录，或者如果解释字符串中有语法错误，则按照没有给出"exp"修饰符的方式进行。
获取的TXT记录的字符串连接在一起，不加空格，然后被视为解释字符串，进行宏扩展。这个最终结果就是解释字符串。实现可以限制结果解释字符串的长度，以允许其他协议约束和/或合理的处理限制。由于解释字符串旨在用于SMTP响应，[RFC5321]的第2.4节说响应是[US-ASCII]，因此解释字符串必须限制为[US-ASCII]。
评估check_host()的软件可以使用此字符串以短消息或URL的形式从发布域传达信息。软件应该明确解释字符串来自第三方。例如，它可以在解释前面加上宏字符串"%{o} explains: "，如第8.4节中的示例所示。
假设example.com有此记录：
v=spf1 mx -all exp=explain._spf.%{d}
以下是explain._spf.example.com处可能的解释TXT记录的一些示例：
"Mail from example.com should only be sent by its own servers."
-- 一个简单的常量消息
"%{i} is not one of %{d}'s designated mail servers."
-- 一个包含更多信息的消息，包括未通过检查的IP地址
"See http://%{d}/why.html?s=%{S}&i=%{I}"
-- 一个复杂的示例，使用check_host()的参数构造URL，以便可以生成包含详细自定义说明的网页
注意：在递归到"include"机制期间，不得使用