PowerDMARC

How To Read DMARC Reports?

Maitham Al Lawati
read dmarc records

read dmarc records

Reading Time: 13 min

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:

  1. Detect and identify email threats.
  2. Notice inconsistencies with your email authentication setup.
  3. Gain insights into email behavior and mail flows.
  4. 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:

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:

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:

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

  1. <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.
  2. <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.
  3. <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).

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:

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?

  1. Log in to Your DNS Management Console: Access the DNS management console of your domain registrar or hosting provider.
  2. Create aNew TXT Record: Find the option to add a new DNS record and select “TXT” as the record type.
  3. Enter theDMARC Record Name: In the “Name” or “Host” field, enter _dmarc.yourdomain.com (replace “yourdomain.com” with your actual domain name).
  4. 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

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.

  1. 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:

Sign up today to get your free DMARC report analyzer!

DMARC Report FAQs

Latest posts by Maitham Al Lawati (see all)
Exit mobile version