Which ISPs deliver DMARC reports and what configuration is needed?

Key findings

• Major ISPs: Google and Yahoo are prominent providers that consistently deliver DMARC reports.
• Microsoft's stance: As of earlier discussions, Microsoft (Outlook.com, Hotmail, etc.) has historically been less consistent in sending DMARC aggregate reports, although this can change over time. It's important to keep up to date with their policies.
• Diverse reporters: Beyond the big players, many other smaller and international ISPs and mail receivers also send DMARC reports, including Mail.Ru, Seznam.cz, and Zoho.com, amongst others. You can gain detailed insight into the specific mail receivers sending reports by checking your DMARC aggregate reports.
• Report types: DMARC reports come in two main types: aggregate (RUA) reports, which provide an overview of email authentication results, and forensic (RUF) reports, which offer detailed information about individual failures (though RUF reports are sent less frequently due to privacy concerns).

Key considerations

• DMARC record accuracy: A misconfigured DMARC record, particularly missing or incorrect rua (aggregate report URI) or ruf (forensic report URI) tags, can prevent ISPs from sending reports to your specified email address.
• External domain verification (EDV): If you specify an email address for reports that is on a different domain than the DMARC record, you often need to verify ownership of the reporting domain. This involves adding a specific TXT record to the reporting domain's DNS, as outlined in RFC 7489, Section 7.1. Without this, many mail receivers will not send reports due to security concerns.
• DMARC policy: While a p=none policy allows you to receive reports without affecting email delivery, it's a critical first step. Gradually progressing to p=quarantine or p=reject strengthens your email security.
• Report analysis: The volume of DMARC reports can be overwhelming. Using a DMARC analysis tool is essential for parsing these XML reports into actionable insights, helping you to efficiently monitor and troubleshoot DMARC issues.

Key opinions

• Google is reliable: Many marketers consistently report receiving DMARC reports from Google, making it a primary source of authentication data.
• Varied ISP support: It's a common observation that not all ISPs (or mail receivers) are equally diligent about sending DMARC reports, leading to incomplete visibility for some domains.
• Importance of DMARC accuracy: Marketers emphasize that even minor errors in the DMARC record's TXT entry can prevent reports from being sent or properly processed by receiving mail servers.
• External domain verification confusion: There's often confusion around the necessity and implementation of external domain verification (EDV) for DMARC reports, particularly when sending reports to a third-party service or a different domain. Some observe inconsistent EDV enforcement by large providers.

Key considerations

• Comprehensive report collection: Marketers should aim to receive reports from as many ISPs as possible to get a holistic view of their email authentication success and potential issues. This often involves ensuring the DMARC record is correctly configured.
• DMARC policy progression: Starting with a p=none policy is a widely recommended approach to gather data without impacting email delivery, before gradually enforcing stricter policies like p=quarantine or p=reject.
• Leveraging DMARC tools: Given the complexity of raw DMARC reports, marketers find significant value in using DMARC reporting tools to visualize data and identify trends related to legitimate email traffic and potential spoofing attempts.
• Stay updated: ISP policies and DMARC enforcement can evolve. Marketers should stay informed about changes from major mail providers like Google and Yahoo, as their updates often set industry standards and can impact report delivery or authentication requirements. Implementing DMARC is a dynamic process that requires ongoing monitoring.

Key opinions

• Major players are key: While many ISPs support DMARC reporting, Google and Yahoo are consistently cited as the primary deliverers of aggregate reports, providing the most substantial data volume.
• Microsoft's variability: Experts confirm that Microsoft's approach to DMARC report delivery has historically been less predictable than Google or Yahoo, often not sending aggregate reports, which can leave a gap in data for senders.
• External domain verification is crucial: The external domain verification (EDV) step is a fundamental security measure required by the DMARC standard (RFC 7489) to prevent unauthorized parties from receiving reports. If reports are sent to a domain different from the sending domain, this TXT record must be present.
• DMARC record integrity: Experts stress that any malformation in the DMARC TXT record, such as incorrect syntax or missing required tags, can lead to ISPs ignoring the record entirely, thus no reports are generated.

Key considerations

• DNS configuration: Proper DNS setup for the DMARC record, including the _dmarc subdomain and correct rua and ruf addresses, is fundamental. An incorrect record means no reports will be sent.
• Policy enforcement: While p=none is the starting point for receiving reports, experts advise a staged approach to move to p=quarantine and p=reject for full protection, using report data to guide these transitions (see how to set up DMARC).
• Monitoring tools: Due to the volume and XML format of aggregate reports, specialized DMARC monitoring and analysis platforms are almost indispensable for interpreting the data effectively. These tools help visualize authentication results and identify sources of unauthorized mail, preventing potential blacklisting (or blocklisting) issues.
• Understanding report nuances: DMARC reports provide insight into both SPF and DKIM authentication results, and how they align with the DMARC domain. Understanding these details is key to diagnosing why legitimate emails might be failing authentication and ensuring proper DMARC functionality.

Key findings

• DMARC record location: The DMARC record is a TXT record published in the DNS at the _dmarc subdomain of the domain you wish to protect. This record contains tags that instruct receiving mail servers on how to handle emails and where to send reports.
• Report URI tags: The rua tag specifies the email address(es) for aggregate reports, and the ruf tag specifies addresses for forensic reports. Both are crucial for receiving feedback.
• External domain verification (EDV) mandate: As per DMARC specifications, if the rua or ruf email address is on a different domain than the DMARC record, a specific TXT record (e.g., example.com._report._dmarc.yourdomain.com) is required on the receiving domain to verify consent.
• Report content: Aggregate reports typically contain XML data summarizing email volume, authentication results (SPF and DKIM pass/fail), and DMARC policy application for a given period. Forensic reports contain more detailed message-specific information.

Key considerations

• Standard compliance: Adhering strictly to DMARC standards (RFC 7489) ensures that DMARC records are correctly interpreted by mail receivers, leading to consistent report generation and enforcement of policies.
• Record validation: Documentation emphasizes the need to validate the DMARC record after publishing to ensure there are no syntax errors or misconfigurations that would render it ineffective. Tools and checkers are often recommended for this purpose.
• Policy impact on reports: The DMARC policy tag (p) directly influences how receiving servers treat unauthenticated mail, but it does not directly affect whether reports are sent. Reports are sent regardless of the policy (i.e., p=none, p=quarantine, or p=reject) as long as the reporting URI is correctly specified.
• Report processing: Documentation highlights that DMARC reports, particularly aggregate reports, are designed for automated processing due to their XML structure. This underscores the need for DMARC analysis tools to make the data actionable.