在 MDaemon 查询 DNS 是否存在 DMARC 记录时，该记录可能包含各种标签，指示域的拥有者是希望接收与声称来自此域邮件相关的 DMARC 综合报告还是故障报告。“DMARC 报告”屏幕上的一些选项供您用来指定是否希望发送请求的报告类型，并指定这些报告应该包含的元数据。只有启用了“启用 DMARC 验证和报告”这个选项（位于“DMARC 验证”屏幕），该屏幕的选项才可用。此外，DMARC 规范要求使用报告收件人提供的 STARTTLS。因此您应该尽可能启用 STARTTLS。
DMARC 报告
发送 DMARC 综合报告
如果您希望向要求 DMARC 综合报告的域发送该报告，请启用此项。如果对入站邮件的“From:” 执行 DMARC DNS 查询时发现其 DMARC 记录包含“rua=”这个标签（例如rua=mailto:dmarc-reports@example.com），这就表示该域的拥有者希望接收 DMARC 综合报告。因此 MDaemon 将存储有关此域和声称来自此域的入站邮件的 DMARC 相关信息 它会记录接收综合报告的邮件地址、每封邮件使用的验证方式（SPF、DKIM 或两者）、该邮件是否通过验证、发件服务器、其 IP 地址和应用的 DMARC 策略等。然后在每晚午夜（UTC），MDaemon 将使用存储的数据来生成各个域的报告，并将其发送至指定的地址。一旦发送了这些报告，已存储的 DMARC 数据将被清除，MDaemon 也将再次重新开始整个流程。
|
MDaemon 不支持对综合报告使用 DMARC 报告的间隔标签（例如“ri=”）。MDaemon 从上次生成和发送 DMARC 报告后， 在每晚午夜（UTC）将综合报告发送至为其编译了 DMARC 数据的任何域。 |
立即发送综合报告
如果您希望从当前已存储的 DMARC 数据生成并发送批量的综合报告，而不是等候 MDaemon 在执行下一个午夜批量事件时进行这个任务，请点击此项。这将立即发送报告并清除已存储的 DMARC 数据，就和每晚午夜执行的操作一样。然后 MDaemon 将开始再次存储 DMARC 数据，直到执行下一个午夜 UTC 事件或您再次点击此按钮为止。
|
因为 MDaemon 必须在午夜 UTC 自动运行来发送综合报告并清除已存储的 DMARC 数据，如果您在那时关闭了 MDaemon，则不会生成任何报告，也不会清除 DMARC 数据。每当 MDaemon 再次运行时便会继续收集 DMARC 数据，不过直到下一个午夜 UTC 事件或您点击了“立即发送综合报告”这个按钮时才会生成报告并清除数据。 |
发送 DMARC 故障报告（仅在发生事件时发送该报告）
如果您希望向要求 DMARC 故障报告的域发送该报告，请启用此项。如果对入站邮件的“From:” 执行 DMARC DNS 查询时发现其 DMARC 记录包含“ruf=”这个标签（例如ruf=mailto:dmarc-failure@example.com），这就表示该域的拥有者希望接收 DMARC 故障报告。这些报告不像综合报告那样是实时创建的，故障报告只在发生事件时才被触发，而且包含有关各个事件和故障错误的详细信息。域管理员可以使用这些报告来进行取证分析，并通过修改其邮件系统的配置来修复问题或识别其他问题，例如持续网络钓鱼攻击。
将触发故障报告的故障类型取决于该域的 DMARC 记录中“fo=”标签的值。默认情况下，仅在未通过所有基本的 DMARC 检查（例如未通过 SPF 和 DKIM） 时才生成故障报告，不过域可以使用各种“fo=”标签值来表示它们希望仅在未通过 SPF 、DKIM 或其他验证组合时就接收故障报告。因此，取决于在 DMARC 记录的“ruf=”标签中的收件人数量、“fo=”标签的值、以及在邮件处理期间遇到的独立验证失败的数量，可以从一封邮件生成多个故障报告。如果您希望限制接收 MDaemon 将发送的指定报告的收件人数量，请使用下方的“准许至多这些 DMARC 'rua' 和 'ruf' 收件人”这个选项。
至于报告格式，MDaemon 只准许“rf=afrf”这个标签（使用滥用报告格式的验证故障报告），这是 DMARC 的默认值。所有报告都以这个格式发送，即使域的 DMARC 记录含有“rf=iodef 这个标签。
|
为了支持 DMARC 故障报告，MDaemon 完全支持： RFC 5965： 邮件反馈报告的可扩展格式、RFC 6591: 使用滥用报告格式的验证故障报告、RFC 6652: 使用滥用报告格式的发件人策略框架（SPF）验证故障报告、RFC 6651: 针对故障报告的域名秘钥标识邮件（DKIM）的扩展 和 RFC 6692: 滥用报告格式（ARF）报告中的源端口. 当 DMARC 的“fo=”标签要求报告 SPF 相关故障时，MDaemon 将按照 RFC 6522 来发送 SPF 故障报告。因此，在该域的 SPF 记录中必须存在那个规范的扩展。SPF 故障报告不独立于 DMARC 处理或在缺少 RFC 6522 扩展的情况下进行发送。 当 DMARC 的“fo=”标签要求报告 DKIM 相关故障，MDaemon 将按照 RFC 6651 发送 DKIM 故障报告。因此，在 DKIM 签名报头字段中必须存在该规范的扩展，而且这个域必须在 DNS 中发布有效的 DKIM 报告 TXT 记录。 DKIM 故障报告不独立于 DMARC 处理或在缺少 RFC 6651 扩展的情况下进行发送。 |
准许至多这些 DMARC“rua”和“ruf”收件人（0 = 无限制）
如果您希望限制将接收 MDaemon 所发送的指定 DMARC 综合报告或 DMARC 故障报告的收件人数量，请在此处指定最大值。如果 DMARC 记录的“rua=”或“ruf=”标签包含的地址数量大于您所指定的限制，那么 MDaemon 会将指定报告按顺序发送至列出的地址，直到达到地址最大值为止。默认情况下不设置限制。
将所有报告的副本通过电子邮件发送到：
在此处输入一个或多个由逗号分隔的电子邮件地址，来将所有 DMARC 汇总报告和 DMARC 失败报告的副本发送到这些地址（仅 fo=0 或 fo=1）。
DMARC 报告元数据
使用这些选项来指定您公司或组织的元数据，会将这些数据包含于您所发送的 DMARC 报告中。
组织名称
这是负责生成 DMARC 报告的实体。它必须是您的 MDaemon 域之一。从下拉列表中选择域。
联系人邮件
使用此项来指定报告收件人在报告问题时可以联系的本地邮件地址。使用逗号来分隔多个地址。
联系信息
使用此项为报告收件人包含任何额外的联系信息，例如网站和电话号码等。
报告返回路径
这是用于 MDaemon 所发送的报告邮件的 SMTP 返回路径（退回地址），以防投递出现问题。使用“noreply@<mydomain.com>”来忽略这些问题。
还请参阅：
