4. 概述和关键概念
DMARC Policy Record 是位于 _dmarc 名称下的 DNS TXT record. v=DMARC1 tag 区分大小写且 MUST 位于首位. 默认值包括 adkim=r, aspf=r, fo=0, psd=u 和 t=n. policy value 为 none, quarantine 和 reject.
4.7. DMARC Policy Record 格式
DMARC Policy Record 遵循 DKIM [RFC6376] 为基于 DNS 的 key record 定义的可扩展 "tag-value" 语法.
第 9 节创建一个已知 DMARC tag 注册表, 并注册本文定义的初始集合. 只有该注册表中定义的 tag 才会被处理. 未知 tag MUST 被忽略.
以下 tag 是有效的 DMARC tag:
adkim: plain-text, 可选, 默认值为 "r". 指示 Domain Owner (第 3.2.7 节) 或 PSO (第 3.2.16 节) 是否要求 strict 或 relaxed DKIM Identifier Alignment mode. 详情见第 4.4.1 节. 有效值如下:
r: relaxed mode.s: strict mode.
aspf: plain-text, 可选, 默认值为 "r". 指示 Domain Owner 或 PSO 是否要求 strict 或 relaxed SPF Identifier Alignment mode. 详情见第 4.4.2 节. 有效值如下:
r: relaxed mode.s: strict mode.
fo: Failure reporting options, plain-text, OPTIONAL, 默认值为 "0". 提供生成 failure report 时请求使用的选项. report generator 可以选择遵循这些请求选项. 如果未同时指定下文的 "ruf" tag, 则此 tag 的内容 MUST 被忽略. 此 tag 可以包含此处所示的一个或多个值, 但 "0" 和 "1" 互斥. 如果为该 tag 分配多个值, 值列表应使用冒号分隔, 例如 fo=0:d, 且值可以按任意顺序出现在列表中. 有效值及其含义如下:
0: 如果所有底层认证机制都未能产生对齐的 "pass" 结果, 生成 DMARC failure report.1: 如果任一底层认证机制未能产生对齐的 "pass" 结果, 生成 DMARC failure report.d: 如果消息具有未通过评估的签名, 则生成 DKIM failure report, 无论其是否对齐. DKIM-specific reporting 见 [RFC6651].s: 如果消息未通过 SPF evaluation, 则生成 SPF failure report, 无论其是否对齐. SPF-specific reporting 见 [RFC6652].
np: 针对给定 Organizational Domain 的不存在子域的 Domain Owner Assessment Policy (第 3.2.8 节), plain-text, OPTIONAL. 对此 tag 而言, "non-existent subdomain" 的定义与第 3.2.13 节中 "non-existent domain" 的定义相同. 此 tag 表达的策略指示 Domain Owner 或 PSO 对使用当前 Organizational Domain 的不存在子域且未通过 DMARC validation 的邮件所偏好的消息处理方式. 它仅适用于所查询 Organizational Domain 的不存在子域, 不适用于现有子域或该域本身. 其语法与下文定义的 "p" tag 相同. 如果缺少 "np" tag, 则对不存在子域 MUST 应用 "sp" tag 指定的策略, 如果存在 "sp" tag, 否则应用 "p" tag 指定的策略.
p: Domain Owner Assessment Policy (第 3.2.8 节), plain-text, 对 DMARC Policy Record RECOMMENDED. 指示 Domain Owner 或 PSO 对使用其域但未通过 DMARC validation 的邮件所偏好的消息处理方式. 该策略适用于所查询的域和子域, 除非使用 "sp" 或 "np" tag 明确描述子域策略. 如果在其他方面语法有效的 DMARC Policy Record 中不存在此 tag, 则该记录被视为包含 "p=none", 见第 4.10.1 节. 此 tag 不适用于 third-party reporting record, 见 [RFC9990] 和 [RFC9991]. 可能的值如下:
none: Domain Owner 未表达偏好.quarantine: Domain Owner 认为此类邮件可疑. 该邮件可能有效, 但失败结果造成重大疑虑.reject: Domain Owner 认为所有此类失败都清楚表明该域名的使用无效. 关于 SMTP rejection method 及其影响, 见第 7.2 节.
psd: 指示域是否为 PSD 的标志, plain-text, 可选, 默认值为 "u". 可能的值如下:
y: PSO 包含此 tag 且值为 "y", 用于指示该域是 PSD. 如果在策略发现期间找到包含此 tag 且值为 "y" 的记录, 此信息将用于确定适用于相关消息的 Organizational Domain 和 DMARC Policy Domain.n: DMARC Policy Record 发布于一个非 PSD 的域, 但该域是其自身及其子域的 Organizational Domain.u: 默认值表示 DMARC Policy Record 发布于一个非 PSD 的域, 且该域可能是也可能不是其自身及其子域的 Organizational Domain. 使用第 4.10 节描述的机制确定此域的 Organizational Domain.
rua: aggregate feedback report 发送目标地址, 是由逗号分隔的 DMARC Reporting URI plain-text 列表, OPTIONAL. 如果存在, Domain Owner 请求 Mail Receiver 按 [RFC9990] 定义向所列 URI 发送 aggregate feedback report. 可以指定任何有效 URI. 发送 aggregate feedback report 的 Mail Receiver MUST 实现对 "mailto:" URI 的支持, 即能够通过电子邮件发送 DMARC report. 如果未提供此 tag, Mail Receiver MUST NOT 为该域生成 aggregate feedback report. 涉及 Mail Receiver 不支持的 scheme 的 URI MUST 被忽略. [RFC9990] 还讨论了 URI 的域名不同于发布 DMARC Policy Record 的域时适用的考虑. 其他考虑见第 11.6 节.
ruf: message-specific failure information 的报告目标地址, 是由逗号分隔的 DMARC URI plain-text 列表, OPTIONAL. 如果存在, Domain Owner 请求 Mail Receiver 针对以特定方式未通过 DMARC evaluation 的消息, 见上文 "fo" tag, 向所列 URI 发送详细 failure report. 根据 "fo" tag 的值, 此类报告的格式见 [RFC9991], [RFC6651] 和 [RFC6652]. 可以指定任何有效 URI. 发送 failure report 的 Mail Receiver MUST 实现对 "mailto:" URI 的支持, 即能够通过电子邮件发送 message-specific failure information. 如果未提供此 tag, Mail Receiver MUST NOT 为该域生成 failure report. 涉及 Mail Receiver 不支持的 scheme 的 URI MUST 被忽略. [RFC9990] 讨论了 URI 的域名不同于宣告策略的域时适用的考虑. 其他考虑见第 11.6 节.
sp: 针对给定 Organizational Domain 的所有子域的 Domain Owner Assessment Policy, plain-text, OPTIONAL. 指示 Domain Owner 或 PSO 对使用当前 Organizational Domain 的现有子域且未通过 DMARC validation 的邮件所偏好的消息处理方式. 它仅适用于消息 Organizational Domain 在 DNS 层次结构中的现有子域, 不适用于 Organizational Domain 本身. 其语法与上文定义的 "p" tag 相同. 如果 "sp" tag 缺失, 且 "np" tag 也缺失或不适用, 则对子域 MUST 应用 "p" tag 指定的策略. 注意, 由于 DMARC policy discovery (第 4.10.1 节) 的影响, 对发布在 Organizational Domain 和 PSD 的子域上的 DMARC Policy Record, "sp" 将被忽略.
t: DMARC policy test mode, plain-text, 可选, 默认值为 "n". 对 DMARC Policy Record 所适用的 Author Domain, "t" tag 向执行 DMARC validation check 的参与方发出信号, 表明 Domain Owner 是否希望实际应用 "p", "sp" 和/或 "np" tag 中声明的 Domain Owner Assessment Policy. 此 tag 不影响 DMARC report 的生成, 且对值为 "none" 的任何策略, 即 "p", "sp" 或 "np", 没有影响. 关于此 tag 使用的进一步讨论见附录 A.6. 可能的值如下:
y: 请求执行 DMARC validation check 的参与方不应用该策略, 而是应用其可能已经部署的任何特殊处理规则, 例如重写 RFC5322.From header field, 见附录 A.6. Domain Owner 当前正在测试其指定的 DMARC assessment policy, 并预期对任何失败消息应用的策略比指定策略低一级. 也就是说, 如果策略为 "quarantine" 且 "t" tag 的值为 "y", 则对失败消息应用 "none" 策略. 如果策略为 "reject" 且 "t" tag 的值为 "y", 则对失败消息应用 "quarantine" 策略, 无论 "t" tag 值为 "y" 可能触发的任何其他特殊处理规则如何.n: 默认值, 请求按指定方式对任何产生 DMARC "fail" 结果的消息应用 Domain Owner Assessment Policy.
v: Version, plain-text, REQUIRED. 标识取回的记录为 DMARC Policy Record. 此 tag MUST 是列表中的第一个 tag. tag value 区分大小写, 唯一可能的值为 "DMARC1". 如果此 tag 不是列表中第一个, 此 tag 缺失, 或其值不是 "DMARC1", 则 MUST 忽略整个记录.
4.8. 形式化定义
DMARC Policy Record MUST 符合本节中的形式化定义. 未知 tag MUST 被忽略. 记录其余部分中的语法错误 MUST 被丢弃, 并改用默认值, 如果存在默认值, 或直接忽略.
由于未知 tag MUST 被忽略, 向已注册 tag 列表中新增 tag 本身不要求生成新的 DMARC 版本, 也不要求相应改变 "v" tag 的值. 但对任何现有 tag 的改变确实要求新的 DMARC 版本.
DMARC Policy Record 格式的形式化定义使用 [RFC5234] 和 [RFC7405] 中描述的 ABNF 语法, 如下:
dmarc-uri = URI
; "URI" is imported from [RFC3986];
; commas (ASCII 0x2C) and exclamation
; points (ASCII 0x21) MUST be
; encoded
obs-dmarc-uri = dmarc-uri obs-dmarc-report-size
; Obsolete syntax, reporters should ignore the
; obs-dmarc-report-size if it is found in a
; DMARC Policy Record.
obs-dmarc-report-size = "!" 1*DIGIT [ "k" / "m" / "g" / "t" ]
dmarc-sep = *WSP ";" *WSP
equals = *WSP "=" *WSP
dmarc-record = dmarc-version *(dmarc-sep dmarc-tag) [dmarc-sep]
dmarc-tag = 1*ALPHA equals 1*dmarc-value
; any printing characters but semicolon
dmarc-value = %x20-3A / %x3C-7E
dmarc-version = "v" equals %s"DMARC1" ; case sensitive
; specialized syntax of DMARC values
dmarc-request = "none" / "quarantine" / "reject"
dmarc-yorn = "y" / "n"
dmarc-psd = "y" / "n" / "u"
dmarc-rors = "r" / "s"
dmarc-urilist = (dmarc-uri / obs-dmarc-uri)
*(*WSP "," *WSP (dmarc-uri / obs-dmarc-uri))
dmarc-fo = ("0" / "1") *(":" dmarc-afrf)
/ dmarc-afrf [":" ("0" / "1")] [":" dmarc-afrf]
/ *(dmarc-afrf ":") ("0" / "1")
dmarc-afrf = "d" / "s"
; each may appear at most once in dmarc-fo
在每个 dmarc-tag 中, dmarc-value 的语法取决于 tag name. 每个 dmarc-value 的 ABNF rule 在下表中指定:
| Tag Name | Value Rule |
|---|---|
| p | dmarc-request |
| t | dmarc-yorn |
| psd | dmarc-psd |
| np | dmarc-request |
| sp | dmarc-request |
| adkim | dmarc-rors |
| aspf | dmarc-rors |
| rua | dmarc-urilist |
| ruf | dmarc-urilist |
| fo | dmarc-fo |
表 2: Tag Name 和 Value.
4.9. 流程图
+---------------+ +--------------------+
| Author Domain |< . . . . . . . . . . . . | Return-Path Domain |
+---------------+ . +--------------------+
| . ^
V V .
+-----------+ +--------+ +----------+ v
| MSA |<***>| DKIM | | DMARC | +----------+
| Service | | Signer | | Validator|<***>| SPF |
+-----------+ +--------+ +----------+ * | Validator|
| ^ * +----------+
| * *
V v *
+------+ (````````````) +------+ * +----------+
| sMTA |------->( other MTAs )----->| rMTA | **>| DKIM |
+------+ (````````````) +------+ | Validator|
| +----------+
| ^
V .
+-----------+ .
+---------+ | MDA | v
| User |<--| Filtering | +-----------+
| Mailbox | | Engine | | DKIM |
+---------+ +-----------+ | Signing |
| Domain(s) |
+-----------+
MSA = Mail Submission Agent
MDA = Mail Delivery Agent
sMTA = sending MTA
rMTA = receiving MTA
上图展示了消息通过 DMARC-aware system 的典型流程. 虚线, 例如 -->, 表示实际消息流. 点线, 例如 < . . >, 表示用于取回与受支持消息认证方案相关的消息策略的 DNS query. 星号线, 例如 <**>, 表示消息处理模块和消息认证模块之间的数据交换.
简单来说, 当消息到达 DMARC-aware rMTA 时, 会发起 DNS query 以确定是否存在适用于 Author Domain 的 DMARC Policy Record. 如果找到 DMARC Policy Record, rMTA 将使用 SPF 和 DKIM validation check 的结果确定 DMARC validation status. 随后, DMARC validation status 可作为接收方邮件系统作出消息处理决定的因素.
相关各方的具体操作详情见第 5.1 节和第 5.3 节.
4.10. DNS Tree Walk
Organizational Domain (第 3.2.14 节) 根据上下文承担两个不同目的:
-
当没有专门为 Author Domain (第 3.2.2 节) 发布 DMARC Policy Record 时, Author Domain 的 Organizational Domain 为该域建立 DMARC Policy Record (第 3.2.6 节), 见第 4.10.1 节.
-
Authenticated Identifier (第 3.2.1 节) 的 Organizational Domain 和 Author Domain 的 Organizational Domain 用于确定二者之间的 Identifier Alignment, 见第 4.10.2 节.
[RFC7489] 将 Organizational Domain 定义为 "The domain that was registered with a domain name registrar". [RFC7489] 讨论了使用 Public Suffix List (PSL) 作为 Organizational Domain 父域的权威列表, 并进一步描述了确定 Author Domain 或 Authenticated Identifier 的 Organizational Domain 的方法. 然而, [RFC7489] 没有要求 Mail Receiver 使用某个特定 PSL, 虽然它建议使用 https://publicsuffix.org/ 上的列表, 也没有就参与 DMARC 的 Mail Receiver 定期获取 PSL 的频率提供指导. [RFC7489] 承认, Mail Receiver 选择不同 PSL 可能造成互操作性问题, 甚至建议如果能够创建更可靠且更安全的 Organizational Domain 确定方法, 该方法应取代对 PSL 的依赖.
DMARC 的此次更新为 Domain Owner 提供了更大灵活性, 尤其适用于拥有大型复杂组织并可能希望对其 DNS 和 DMARC Policy Record 进行分散管理的 Domain Owner. 此更新不只是使用 PSL 辅助识别 Organizational Domain, 而是定义了一种俗称 "DNS Tree Walk" 的发现技术. 任何 DNS Tree Walk 的目标都是发现有效的 DMARC Policy Record, 而将其用于确定 Organizational Domain, 允许在命名空间中的多个位置发布 DMARC Policy Record.
然而, 这种灵活性可能带来成本. 由于 DNS Tree Walk 依赖 Mail Receiver 执行一系列 DNS query, 恶意 Domain Owner 可能发送 Author Domain 含有数十甚至数百个 label 的邮件, 以对 Mail Receiver 发起 denial-of-service 攻击. 为防范这种 DNS 滥用, 流程内置了一条捷径, 使 label 数超过 8 个的 Author Domain 不会导致超过 8 次 DNS query. 发布时观察到的数据表明, 使用中的 Author Domain 最多有 7 个 label, 因此选择 8 作为查询限制, 以便为命名空间未来扩展留出一些余量, 而无需更新本文.
DNS Tree Walk 的通用步骤如下:
-
在 Tree Walk 的起点查询 DNS, 查找符合 DMARC Policy Record 格式的 TXT record. DNS Tree Walk 的起点取决于 DNS Tree Walk 的最终目标. 第 4.10.1 节和第 4.10.2 节描述了可能的起点. 返回的记录集合可能为空.
-
丢弃不以标识当前 DMARC 版本的 "v" tag 开头的记录. 如果针对单个目标返回多个 DMARC Policy Record, 则全部丢弃. 如果仅剩一条记录且它包含 "psd=n" 或 "psd=y" tag, 则停止.
-
将相关 DNS domain name 拆分为一组有序 label. 将 label 数量赋给 "x", 并从右到左为 label 编号. 例如, 对 "a.mail.example.com", "x" 的值为 4, "com" 是 label 1, "example" 是 label 2, "mail" 是 label 3, 依此类推.
-
如果 x < 8, 从相关域中移除最左侧, 即编号最高的 label. 如果 x >= 8, 从相关域中移除最左侧, 即编号最高的 label, 直到剩下 7 个 label. 得到的 DNS domain name 是下一次查找的新目标.
-
在与此新目标匹配的 DNS domain name 处查询 DNS, 查找 DMARC Policy Record. 返回的记录集合可能为空.
-
丢弃不以标识当前 DMARC 版本的 "v" tag 开头的记录. 如果针对单个目标返回多个 DMARC Policy Record, 则全部丢弃. 如果仅剩一条记录且它包含 "psd=n" 或 "psd=y" tag, 则停止.
-
通过移除上一次查询目标的最左侧 label 来确定下一次查询目标. 重复步骤 5, 6 和 7, 直到流程停止或不再剩余 label.
举例说明, 对于 Author Domain 为 "a.b.c.d.e.f.g.h.i.j.mail.example.com" 的任意消息, 完整 DNS Tree Walk 需要以下 8 次查询, 才可能定位 DMARC Policy Record 或 Organizational Domain:
_dmarc.a.b.c.d.e.f.g.h.i.j.mail.example.com_dmarc.g.h.i.j.mail.example.com_dmarc.h.i.j.mail.example.com_dmarc.i.j.mail.example.com_dmarc.j.mail.example.com_dmarc.mail.example.com_dmarc.example.com_dmarc.com
4.10.1. DMARC Policy Discovery
应用于电子邮件消息的 DMARC Policy Record 将是在以下位置之一找到的记录, 这些位置按优先级从高到低列出:
- Author Domain.
- Author Domain 的 Organizational Domain.
- Author Domain 的 PSD.
策略发现首先查询一个有效 DMARC Policy Record, 查询名称通过在被评估消息的 Author Domain 前添加 label "_dmarc" 构成. 如果在该处找到有效 DMARC Policy Record, 则这就是应用于该消息的 DMARC Policy Record. 但是, 这并不必然意味着 Author Domain 也是 Identifier Alignment check 中使用的 Organizational Domain. 它是否也是 Organizational Domain 取决于 "psd" tag 的值, 如果存在该 tag, 或取决于第 4.10.2 节描述的一些条件.
如果第一次查询未找到有效 DMARC Policy Record, 则执行 DNS Tree Walk, 以查找 Author Domain 的 Organizational Domain 或其 Public Suffix Domain. 此 DNS Tree Walk 的起点按如下方式确定:
-
如果 Author Domain 有 8 个或更少 label, 起点为 Author Domain 的直接父域.
-
否则, 起点为按第 4.10 节步骤 3 开始描述的方法缩短 Author Domain 后产生的名称.
如果要应用的 DMARC Policy Record 是 Author Domain 的记录, 则 Domain Owner Assessment Policy 取自该记录的 "p" tag.
如果要应用的 DMARC Policy Record 是 Organizational Domain 或 PSD 的记录, 且 Author Domain 是该域的子域, 则在 Author Domain 存在时, Domain Owner Assessment Policy 取自 "sp" tag, 如果存在. 在 Author Domain 不存在时, 取自 "np" tag, 如果存在. 如果没有适用的 "sp" 或 "np" tag, 则对子域使用 "p" tag 策略.
如果取回的 DMARC Policy Record 不包含有效 "p" tag, 或包含无效的 "sp" 或 "np" tag, 则:
-
如果存在 "rua" tag 且它包含至少一个语法有效的 reporting URI, Mail Receiver MUST 表现得如同取回了包含 "p=none" 的记录, 并继续处理.
-
否则, Mail Receiver 不对该消息应用 DMARC 处理.
如果 DNS Tree Walk 产生的集合中不包含 DMARC Policy Record, 即存在没有此类记录的任何指示, 而非瞬态 DNS error, Mail Receiver MUST NOT 对该消息应用 DMARC 机制.
查询 DMARC Policy Record 时 DNS error 的处理由 Mail Receiver 自行决定. 例如, 为确保邮件流受到的干扰最小, 瞬态错误可导致消息被投递, 即 "fail open". 也可导致消息被临时拒绝, 即 SMTP 4yx reply, 从而促使发送 MTA 在该状况可能消除后重试, 以便得到明确的 DMARC 结论, 即 "fail closed".
注意: PSD policy 不用于已经发布 DMARC Policy Record 的 Organizational Domain. 具体而言, 当 Organizational Domain 已拒绝提供反馈地址时, 这不是一种提供反馈地址 (rua/ruf) 的机制.
4.10.2. Identifier Alignment Evaluation
可能需要执行多次 DNS Tree Walk, 以确定 Authenticated Identifier 和 Author Domain 是否对齐. 对齐意味着二者具有相同的 Organizational Domain, 即 relaxed alignment, 或二者完全相同, 即 strict alignment. 为 Identifier Alignment Evaluation 发现 Organizational Domain 而执行的 DNS Tree Walk 可以从以下位置之一开始:
-
被评估消息的 Author Domain.
-
如果被评估消息存在 SPF "pass" 结果, 则从 SPF-Authenticated Identifier 开始.
-
如果被评估消息存在一个或多个 DKIM "pass" 结果, 则从任一 DKIM-Authenticated Identifier 开始.
在以下任一条件下, 无需执行 Identifier Alignment Evaluation:
-
Author Domain 和 Authenticated Identifier 均为同一域, 且该域发布了 DMARC Policy Record. 在此情况下, 此公共域被视为 Organizational Domain. 例如, 如果相关公共域为 "mail.example.com", 且在 "_dmarc.mail.example.com" 发布了有效 DMARC Policy Record, 则 "mail.example.com" 是 Organizational Domain.
-
未发现适用于 Author Domain 的 DMARC Policy Record. 在此情况下, DMARC 机制不适用于相关消息.
-
Author Domain 的 DMARC Policy Record 指示 strict alignment. 在此情况下, 只需对 Author Domain 和 Authenticated Identifier 执行简单字符串比较.
为发现某个域的 Organizational Domain, 对相关任一域按需执行第 4.10 节描述的 DNS Tree Walk.
对于每个取回了有效 DMARC Policy Record 的 Tree Walk, 按从最长域名到最短域名的顺序, 从已取回有效 DMARC Policy Record 的域中选择 Organizational Domain:
-
如果有效 DMARC Policy Record 包含值为 "n" 的 "psd" tag, 即 "psd=n", 则它就是 Organizational Domain, 选择流程完成.
-
如果有效 DMARC Policy Record, 不包括 Tree Walk 起始域自身的记录, 包含值为 "y" 的 "psd" tag, 即 "psd=y", 则 Organizational Domain 是 DNS 层次结构中该域下一级的域, 选择流程完成. 例如, 如果在 Tree Walk 过程中首先查询 "_dmarc.mail.example.com", 随后查询 "_dmarc.example.com", 并在 "_dmarc.example.com" 找到包含值为 "y" 的 "psd" tag 的有效 DMARC Policy Record, 则 "mail.example.com" 是 DNS 层次结构中位于 "example.com" 下一级的域, 因而是 Organizational Domain.
-
否则, 选择在 label 数最少的名称处找到的 DMARC Policy Record. 这就是 Organizational Domain, 选择流程完成.
如果此流程未确定 Organizational Domain, 则初始目标域就是 Organizational Domain.
例如, 给定起始域 "a.mail.example.com", 搜索 Organizational Domain 需要一系列 DNS query 来查找 DMARC Policy Record, 从 "_dmarc.a.mail.example.com" 开始, 到 "_dmarc.com" 结束. 如果在 "_dmarc.mail.example.com" 和 "_dmarc.example.com" 发布了 DMARC Policy Record, 但在 "_dmarc.a.mail.example.com" 或 "_dmarc.com" 没有发布, 则此域的 Organizational Domain 为 "example.com".
另一个示例中, 给定起始域 "a.mail.example.com", 如果搜索 Organizational Domain 时在 "_dmarc.mail.example.com" 找到带有 "psd" tag 且值为 "n" 的 DMARC Policy Record, 则此域的 Organizational Domain 为 "mail.example.com".
最后一个示例中, 给定起始域 "a.mail.example.com", 如果搜索 Organizational Domain 只在 "_dmarc.com" 找到 DMARC Policy Record, 且该记录包含 tag "psd=y", 则此域的 Organizational Domain 为 "example.com".