期待已久的推出终于来了！微软正在向用户发送DMARCRUA 总报告，而您可能还没有注意到这一点。微软 DMARC 总报告通过以下电子邮件地址发送： dmarcreport@microsoft.com.原始的 Microsoft DMARC 聚合文件以标准 XML 格式发送。微软终于接受了DMARC 报告，这基本上意味着现在 Hotmail、Outlook、Live 和 msn.com 用户将能享受到微软 DMARC 聚合数据的各种好处。
处理微软DMARC汇总数据
PowerDMARC报告分析器将微软DMARC的汇总数据解析成一种有组织的格式，以帮助你更有效地处理它。
为了帮助用户利用微软发送的汇总报告数据的好处，PowerDMARC的 DMARC报告分析器已经被预设为可以直接在平台上接收他们的报告。 用户需要做的就是在PowerDMARC平台上添加他们的域名，同时配置DMARC的DNS记录，而我们则以一种简单易懂的方式处理和呈现报告。 在这里你会发现。
- 从Hotmail、Outlook、Live和msn.com收件人地址发送的DMARC汇总数据，从原始的XML文件格式解析为简单和可读的信息，组织成表格。
- PowerDMARC的预配置可以绕过RFC违规行为，使我们能够接收和解析由微软服务器发送的DMARC数据，而不需要你担心。
- 注册多个域名，监控你的电子邮件渠道，并直接从仪表板上的可操作按钮进行DNS更改，唾手可得。
- 将结果分为各种类别，如每个结果、每个发送源、每个组织、每个国家、地理位置和详细的统计资料或搜索栏上每个域的搜索结果，进行筛选
- 深入了解你的电子邮件的性能，并迅速发现使用你的微软商业域名发送的域名欺骗、冒名顶替或虚假电子邮件的企图。你也将能够分析来自你的发送源的任何SPF、DKIM故障。
上面显示的是我们每个组织的DMARC汇总报告的截图，显示从微软发送的DMARC RUA数据。
你在自行处理微软DMARC汇总报告时可能面临的问题
微软DMARC聚集的电子邮件不符合RFC标准
用户对这些由微软发送的含有报告的电子邮件所面临的主要问题是，它们不符合互联网电子邮件的RFC规范。虽然RFC 5322第2.1.1章明确规定，一行字符不得超过78个字符，但这些微软DMARC汇总邮件中的BASE64附件数据是一个连续的行，没有适当的换行，超过了78个字符的限制。由此产生的违反RFC的行为是大多数这些邮件落在用户的拒绝日志中，而不是被送到他们的收件箱中的原因。
原始XML文件难以阅读
与所有报告机构发送的DMARC数据一样，原始的RUA文件是可扩展标记语言（XML），难以阅读和理解。
接收微软DMARC RUA的前提条件
要接收 outlook.com 上域名的汇总报告，您需要确保在 DNS 上发布了有效的 PowerDMARC 记录，并定义了DMARC 策略。然后，报告组织会将汇总报告数据发送到您指定的网络服务器或电子邮件地址。这将帮助您获得第三方电子邮件供应商的可见性和 DMARC 合规性，否则您将无法控制这些供应商。
立即开始电子邮件验证之旅，保护您在 Microsoft Office365 和其他平台上的域。免费试用 DMARC 试用或安排 DMARC 演示了解在贵组织实施强大的电子邮件安全态势的好处！
- SPF 软失效与硬失效：有什么区别？- 2024 年 4 月 26 日
- 美国联邦贸易委员会报告称电子邮件是冒充欺诈的热门媒介- 2024 年 4 月 16 日
- SubdoMailing 和子域名网络钓鱼的兴起- 2024 年 3 月 18 日