DMARC被要求承担许多它从未设计的工作。团队们把它作为垃圾邮件过滤器、钓鱼过滤器和一般信任信号来使用。但它并不是这些。当前的DMARC协议在RFC 9989中定义，回答了一个故意狭窄的问题：可见的"From"地址的域名所有者是否授权此消息，以及该授权是否可以通过对齐的SPF或DKIM结果来确认？这个问题是值得回答的。它的范围也比DMARC所获得的声誉要狭窄得多。正确划分边界非常重要，因为一个认为他们已经防钓鱼的团队如果达到p=reject会跳过DMARC留未触及的所有控制措施。 如何证明电子邮件的发送者 在整个过程中会反复出现三个术语，因此在这里用简单的英语说明一下。SPF是一个已发布的服务器列表，域名表示允许为其发送邮件的服务器；接收者检查邮件是否确实来自其中之一。DKIM是添加到邮件中的加密签名，使得接收者可以确认它确实来自签名域，并且在传输过程中没有被篡改。DMARC将两者联系到一件事上：可见的From地址。最后一个术语比听起来更重要。每封电子邮件都有两个“发件人”地址。一个是可见的From，邮件应用程序显示给你的姓名和地址（例如，“你的银行<alerts@your-bank.com>”）；这是一个人实际阅读和信任的部分。另一个是后台用于投递的隐藏信封地址，你永远看不见。攻击者可以将这两个地址设置为不同的值，这正是消息看起来像是来自你银行但实际上是从其他地方投递的原因。DMARC的工作是确保身份验证与可见的地址对齐，而不是隐藏地址。 这些内容的实际样子 所有三个记录作为文本记录存在于您域名的DNS中，和您网站的地址配置在同一个地方。您不需要记住语法；认识形状有助于理解。SPF记录列出了谁被允许发送。这一个授权Google Workspace和一个营销工具，并说其他任何内容都应视为可疑：example.com。TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all" 包含的条目引用各个提供商自己的服务器列表，-all意味着“如果不在这些列表上，就不是我们”。DKIM记录发布了签名密钥的公共部分，以便接收者可以检查您的邮件签名。长字符串是密钥本身：selector1._domainkey.example.com。TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ...AB" 最后，DMARC记录将其结合起来，并告诉接收者在消息失败时该怎么做。这个记录要求他们拒绝失败并发送报告：_dmarc.example.com。TXT "v=DMARC1; p=reject; rua=mailto:reports@example.com" 这里的p=reject是本文其余部分不断提到的相同政策，而rua=是您聚合报告发送到的地址。 如何实际决定通过 DMARC建立在SPF和DKIM之上，并独立评估它们。消息可以通过的两种独立方式：SPF通过隐藏信封域并且该域与可见的From域对齐，或者DKIM签名验证并且其签名域与可见的From域对齐。如果任一对齐路径成功，DMARC就通过。如果都不成功，则失败。 "对齐"仅仅意味着两个域名足够接近，以算作相同的组织。 flowchart TD A[来件邮件] --> S{SPF验证并与From域对齐？} S -->|是| P([DMARC通过]) S -->|否| D{DKIM验证并与From域对齐？} D -->|是| P D -->|否| F([DMARC失败]) 如果SPF或DKIM都通过并与可见的From域对齐，则DMARC通过。只有当二者都未通过时才会失败。对齐是大多数解释跳过的部分，这里包含了一个有用且可验证的细节。DMARC定义了两种对齐模式。在宽松模式（默认设置）下，两个域只需共享相同的组织域，因此来自mail.example.com的DKIM签名与example.com的From对齐。在严格模式下，它们必须完全相同，并且同样的签名将失败。如果您看到“SPF通过，DMARC失败”，并想知道两者如何能同时为真，这通常意味着SPF成功确认了隐藏信封域，但该域与可见的From地址不够接近以对齐。严格与宽松模式则决定了是否将紧密相关的域视为相同。 请注意测试从未检查的内容：邮件正文、链接、附件或发送者意图。这只是一个源头检查，而不是内容检查。 DMARC的帮助之处 DMARC设计的案例是完全域名欺骗。如果有人在From地址上放置your-bank.com而没有产生对齐的SPF或DKIM结果，p=reject政策要求参与的接收者拒绝该消息，尽管接收者仍然对其处理方式保留最终控制权。