If you want to understand DMARC reports, it’s probably because you’re already dealing with email in some way. Maybe you run a small company and you’re trying to figure out why some of your emails aren’t getting through. Or maybe you’re an IT manager tasked with implementing email security. Either way, you’ve realized you need to understand DMARC, and more specifically, DMARC reports.
So what is DMARC? DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It’s a standard email authentication protocol that helps protect your domain from being used for phishing attacks, email spoofing, and other cybercrimes. Essentially, DMARC allows domain owners to specify what should happen when an email that appears to be from their domain fails authentication checks. But DMARC also does something else: it sends reports. These reports tell you which emails are passing and which are failing authentication checks, and why.
The trouble is, that DMARC reports are not easy to read. They come in an XML format that looks like a bowl of spaghetti if you’re not familiar with it. But understanding these reports is crucial because they contain all the information you need to improve your email authentication and make sure your emails are delivered. So how do you make sense of them?
What is a DMARC Report?
DMARC reports are data sets generated by recipient email servers when they get emails from a domain with DMARC implemented. These reports(data sets) are sent back to the domain owner, who can analyze DMARC reports to:
- Detect and identify email threats.
- Notice inconsistencies with your email authentication setup.
- Gain insights into email behavior and mail flows.
- Review your SPF and DKIM authentication results.
By leveraging this information, domain owners can take proactive measures to improve their email authentication setup, rectify authentication failures, and establish a more secure environment. They can monitor fraudulent activities and even learn about malicious sources impersonating their domain names to send fake messages to clients and partners.
By taking action against such abuse, domain owners protect not only their brand’s reputation but also safeguard their customers from potential harm.
The Importance of DMARC Reports
DMARC reports enable you to make data-driven decisions about your email security setup and systems. They help you monitor the functionality of your DMARC, SPF, and DKIM authentication protocols. Here’s why you should enable it:
Monitoring Email Authentication Systems
DMARC reports provide a detailed overview of how your emails are being authenticated. By examining these reports, you can ensure that your SPF and DKIM settings are correctly configured and that your legitimate emails are passing through as expected.
Improving Email Deliverability
By understanding how your emails are being authenticated, you can take steps to improve their chances of reaching the inbox. For example, if you see that emails from a particular server are failing SPF checks, you can update your SPF record to include that server. This could significantly improve the delivery rate for those emails.
Detecting Phishing and Spoofing Attacks
DMARC reports help you quickly identify and detect phishing and spoofing attacks. By analyzing the data, you can pinpoint unauthorized sources attempting to use your domain and take steps to block them.
Gaining Visibility Into Your Email Infrastructure
It forces you to think about your email infrastructure. Many organizations have a complex web of servers, third-party services, and legacy systems sending email. DMARC reports shine a light on this complexity. This visibility can be the first step towards simplifying and improving your email setup. You might discover servers you didn’t know were sending mail, or third-party services that are no longer needed.
Educating Employees
DMARC reports can be downloaded in a human-readable format, such as CSV files using PowerDMARC, which can be shared with employees to educate them about potential threats and improve overall email security awareness within your organization.
Types of DMARC Reports – Aggregate vs Forensic DMARC Reports
DMARC reports are of two main types – DMARC aggregate reports (RUA) and DMARC forensic reports (RUF). While both types of reports are sent in similar file formats, they dispense different information to domain owners.
DMARC Aggregate Reports
DMARC Aggregate reports are like a bird’s eye view of your email traffic. They provide an overview of the DMARC analytics and activity for a domain. The DMARC aggregate report includes information pertaining to:
- The number of messages that passed or failed DMARC authentication
- IP addresses of sending mail servers
- Authentication status for sender policy framework(SPF) and DomainKeys identified mail(DKIM)
Aggregate reports are widely supported and sent by all major email service providers including Google and Microsoft, and are sent irrespective of the domain owner’s enforcement policy.
DMARC Forensic Reports
DMARC forensic reports, also known as failure reports, are close-up snapshots of individual emails that failed DMARC authentication. In some cases, Forensic DMARC reports may include:
- The entire email message
- Authentication status
- Reason for authentication failure
Failure reports in DMARC come in handy while investigating specific forensic incidents like potential email fraud or domain name abuse and impersonation.
They, however, sometimes contain sensitive information leading to privacy concerns in case an attacker gains access to them. This has led PowerDMARC to facilitate PGP encryption on these reports to ensure only you can access the contents.
Most of the time, you’ll be dealing with aggregate reports. They’re less intrusive and more useful for getting a general sense of what’s happening with your email.
What does a Raw DMARC record look like?
This is a simplified example of a raw DMARC XML record
Anatomy of a DMARC Raw Report
DMARC reports are typically sent in XML format. While these raw reports can be challenging to read, understanding their structure is valuable. Here’s a breakdown of key elements:
XML Declaration
<?xml version=”1.0″ encoding=”UTF-8″ ?>
This line specifies that the file is an XML document and defines the version of XML being used and the character encoding (UTF-8 in this case).
<feedback> Element
This is the main section of a DMARC report (root element ). It holds all the information that the email receiver has collected about the emails sent from your domain. This element acts like the “container” for all the details in the report.
<report_metadata> Section
The metadata section contains basic information about the report itself. This includes:
<org_name>:
This element specifies the name of the organization that generated the report. In the example provided, the organization is “google.com“. This helps the recipient identify Google email service provider as the report sender.
<email>:
This element provides the contact email address associated with the organization that generated the report. It is typically an automated or no-reply email address used for sending DMARC reports. In the example, the email address for the DMARC reporting service is “noreply-dmarc-support@google.com”.
<extra_contact_info>:
This element contains additional contact information, such as a URL for further support or documentation regarding the DMARC report. In this example, it provides a URL (“http://google.com/dmarc/support“) that recipients can visit for more details about the DMARC reporting or for troubleshooting purposes.
<report_id>:
This is a unique identifier for the report. Each DMARC report is assigned a unique report ID to distinguish it from other reports. The ID “8293631894893125362” in the example helps track and manage the report, especially when dealing with large volumes of reports over time.
<date_range>:
This element specifies the time period that the report covers. The <date_range> contains two child elements:
- <begin>: The start of the reporting period, expressed in Unix epoch time (the number of seconds since January 1, 1970). In this example, “1234573120” represents the start time.
- <end>: The end of the reporting period, also expressed in Unix epoch time. In this example, “1234453590” represents the end time.
The <report_metadata> section provides context for the DMARC report by identifying the source, specifying the reporting period, and offering contact details for further assistance.
<policy_published> Section
The <policy_published> section in a DMARC XML report shows the rules that the domain owner has set for handling their emails. These rules are stored in the domain’s DNS records and tell email servers what to do with emails that fail authentication, like whether to deliver, mark as spam, or reject them.
Here’s a breakdown of the elements within the <policy_published> section:
<domain>:
Specifies the domain name to which the DMARC policy applies. In the example, this is “yourdomain.com“. It indicates that the DMARC settings are relevant to this specific domain.
<adkim>:
Indicates the DKIM alignment mode. The value can be “r” for relaxed alignment or “s” for strict alignment. In the example, “r” (relaxed) means that the domain in the DKIM signature does not have to match exactly with the domain in the “From” header; a subdomain is acceptable.
<aspf>:
Specifies the SPF alignment mode. Similar to DKIM, “r” stands for relaxed alignment, and “s” stands for strict alignment. In the example, “r” (relaxed) means the domain used in the SPF check does not have to exactly match the domain in the “From” header.
<p>:
Defines the DMARC policy to apply to emails that fail the DMARC check. The value can be “none,” “quarantine,” or “reject.” In the example, “none” means no action is taken; it is used primarily for monitoring purposes.
<sp>:
Specifies the DMARC policy for subdomains of the domain. It can also be “none,” “quarantine,” or “reject.” In the example, “none” indicates that no specific policy is applied to subdomains.
<pct>:
Indicates the percentage of emails to which the DMARC policy is applied. The value is a number between 0 and 100. In this example, “100” means the policy is applied to all emails from the domain.
<record> Section
The <record> section in a DMARC XML report provides detailed information about individual email messages evaluated under the DMARC policy. This section contains specific data on how each message was handled by the receiving mail server, including the source IP address, the number of messages evaluated, and the results of the DMARC, SPF, and DKIM checks.
Here’s a breakdown of the different sections
- <row>:
This part tells us where the email came from and how it was evaluated.- <source_ip>: The IP address from which the email was sent. In the example, “302.0.214.308” represents the sending IP address. If you see an IP address you don’t recognize, that’s a red flag. It could mean someone is trying to spoof your domain.
- <count>: The count tells you how many emails were sent from that IP address, which can help you determine whether the activity is legitimate or not. In this case, it’s just 1 email.
- <policy_evaluated>: This tells us what happened to the email after the security checks
- <disposition>: Specifies the action taken on the email by the receiving mail server based on the DMARC policy. In this case, “none” means no action was taken. If it’s “quarantine,” it means the email was sent to the spam folder. If it’s “reject,” it means the email was not delivered at all.
- <dkim>: Indicates whether the DKIM check passed or failed. “fail” in this example means the DKIM check did not pass.
- <spf>: Indicates whether the SPF check passed or failed. “pass” means the SPF check was successful.
- <identifiers>:
Provides identifying information for the message, like who sent it.- <header_from>: The domain found in the “From” header of the email. In this example, it is “yourdomain.com,” indicating the email was sent using this domain.
- <auth_results>:
Shows the results of the authentication checks performed on the email.- <dkim>: Provides details of the DKIM check.
- <domain>: The domain used in the DKIM signature. Here, it is “yourdomain.com.”
- <result>: The result of the DKIM check (“fail” indicates the signature did not verify correctly).
- <human_result>: An optional field that can provide a more detailed explanation of the DKIM result; it is empty in this example.
- <spf>: Provides details of the SPF check.
- <domain>: The domain used in the SPF check (“yourdomain.com” in this example).
- <result>: The result of the SPF check (“pass” indicates the email’s IP address was allowed to send mail on behalf of the domain).
- <dkim>: Provides details of the DKIM check.
What to Watch for in the DMARC Reports
Here are some key things to look for in your DMARC reports, whether you’re using a tool or reading the raw XML:
- Sudden spikes in email volume. This could indicate a spam campaign using your domain. If you normally send 10,000 emails a day and suddenly you’re sending 100,000, something’s probably wrong.
- New IP addresses sending mail. Start by looking at the source IP addresses in the report. Cross-reference these with your known email sending infrastructure and authorized third-party senders. Any new unfamiliar IPs could indicate unauthorized use of your domain.
- High SPF and DKIM failure rates. This could mean that your authentication records need updating. This might happen if you’ve added a new email service but forgotten to update your SPF record, or if you have exceeded the 10 DNS lookup limit in SPF. It could also result from misconfigured SPF records, unauthorized third-party senders, or an expired or improperly rotated DKIM key.
- Alignment issues occur when there are discrepancies between the “header from” domain and your actual domain. This is a classic sign of spoofing, where someone is attempting to make their emails appear as if they are coming from you.
- High Volume of Forensic Reports. If you receive a large number of forensic reports, it may indicate a widespread issue with your email setup or an ongoing phishing attack.
- Geographical anomalies. If you’re a U.S.-based company and suddenly you’re seeing a lot of emails originating from, say, Eastern Europe, that could be a red flag.
- Subdomain Monitoring. Pay attention to authentication results for subdomains. Attackers often target less-monitored subdomains.
The Challenge of Manual Analysis
Reading DMARC reports manually is tedious and error-prone. It’s the kind of task computers are good at and humans are bad at. Imagine trying to spot a trend across hundreds of reports, each containing data about thousands of emails. This is why most organizations use some kind of DMARC reporting tool. These tools can aggregate data from multiple reports, present it in a more readable format, and alert you to potential issues.
The Power of DMARC Report Visualization
PowerDMARC is one such tool. It can take your raw Domain-based Message Authentication, Reporting, and Conformance (DMARC) reports and turn them into actionable insights. Instead of poring over XML files, you can look at charts that show you at a glance how your email authentication is performing. But even with a tool like PowerDMARC, you still need to know what you’re looking at.
How to Enable DMARC Reporting?
- Log in to Your DNS Management Console: Access the DNS management console of your domain registrar or hosting provider.
- Create aNew TXT Record: Find the option to add a new DNS record and select “TXT” as the record type.
- Enter theDMARC Record Name: In the “Name” or “Host” field, enter _dmarc.yourdomain.com (replace “yourdomain.com” with your actual domain name).
- Define the DMARC Policy and Reporting Settings: In the “Text” field, enter the DMARC policy and reporting instructions. Here’s what the DMARC policy record that enables both aggregate and forensic reporting will probably look like.
Breakdown of the Terms
- V=DMARC1: This specifies the version of DMARC being used. It is always set to DMARC1.
- p=reject: This defines the DMARC policy for handling emails that fail the DMARC check
- pct: Percentage of emails to enforce policy
- rua: This tag specifies where to send aggregate reports. It might look like `rua=mailto:dmarc-reports@yourdomain.com`. You can add multiple addresses separated by commas.
- ruf: Similarly, the RUF tag specifies where to send forensic reports. To enable forensic reporting, follow the same procedure as the RUA tag, but use `ruf=mailto:dmarc-failures@yourdomain.com`.
- fo: Specifies when forensic reports are generated (e.g., `fo=1` for all failures, `fo=d` for DKIM failures only).
You can use our DMARC record generatorto easily create the DNS TXT Record. Sign up on the PowerDMARC portal and click on PowerToolbox from the menu > selectDMARC record generator. Select your preferred DMARC policy option from none, quarantine, and reject. On all three domain policies, reports will continue to be sent from recipient mail servers; however, the action taken will differ. It is always advised to shift to reject gradually by first monitoring your domains at “none” and then opting for partial enforcement with quarantine. Finally, switch from quarantine to reject when you are confident with your mail flows and legitimate email sources. This will ensure that your legitimate senders don’t get blocked by receivers.
- Publish your record to receive DMARC reports: Once you have configured the necessary tags, publish the DNS TXT Record in your DNS management console and save the changes. It may take some time (up to 24-48 hours) for DNS changes to propagate globally.
Note: DMARC forensic reports are not supported by all mailbox providers due to privacy concerns.
DMARC Reports & Deliverability in 2024
With DMARC reports flooding your inboxes every day, you wouldn’t want the pain of going through them and analyzing them line by line, fishing for useful information. PowerDMARC helps you monitor your domain’s activity with reports, and gain complete insight into your authenticity status, and authentication issues to reduce your spam score and improve deliverability with time.
PowerDMARC reporting helps you view your DMARC Aggregate RUA reports easily in an organized tabular format, parsing data and segregating information into categories with the option to filter data according to IP addresses, organizations, sending sources, and specific stats, providing ultimate flexibility when you read DMARC reports for your email.
Using a Dedicated Mailbox VS Using PowerDMARC’s DMARC Report Analyzer
To organize and read DMARC reports more easily and efficiently, you can maintain a dedicated mailbox wherein you can redirect all the DMARC XML reports you receive from various third parties and email service providers that you use for sending your marketing and business emails. This keeps your main inbox decluttered.
However, note that a dedicated mailbox for your reports will only help you organize and manage your data better. It will not help you parse or read the XML files, and will not provide a user-friendly or actionable interface for viewing, sorting, or filtering your DMARC and SPF authentication results as we do.
Perks of Configuring PowerDMARC’s DMARC Reports:
- View RUA reports in 7 distinct viewing formats: per organization, per result, per sending source, per host, per country, according to geo-locations, and segregate detailed stats.
- Enter the domain(s) of your choice to filter results for that particular domain only in the search bar
- Select a specific date range to filter results for that timeline
- Bright color scheme and interactive dashboard that helps you understand your authentication results at a glance when in a hurry, as well as in great detail.
Sign up today to get your free DMARC report analyzer!
DMARC Report FAQs
- Fix SPF Permerror: Overcome SPF Too Many DNS Lookups Limit - April 26, 2024
- How to Publish a DMARC Record in 3 Steps? - April 2, 2024
- Why is DMARC failing? Fix DMARC Failure in 2024 - April 2, 2024