Free DMARC Report Analyzer: How to Read DMARC XML Reports

Before you start using a DMARC report analyzer, you have to ensure your DMARC is set up properly!

Is Your DMARC Set Up Correctly? Check your DMARC for Free

Check Now!

A DMARC report analyzer is the best tool to help you review your DMARC (Domain-Based Message Authentication) reports collectively and efficiently in order to see an overview of your email’s authentication or discover new problems.

In this post, we will show you how to prevent brand abuse and improve your email deliverability with our DMARC Report Analyzer tool.

We will cover: 

• What are DMARC Reports?
• DMARC Report Example
• Difference between DMARC Aggregate Reports and Forensic Reports
• How to Read DMARC XML Reports
• How does a Free DMARC Report Analyzer work?
• How to Read DMARC Reports with GlockApps Free DMARC Report Analyzer Tool
• Free DMARC Report Analyzer for DMARC XML Reports

What are DMARC Reports?

You may use DMARC to receive automated reports from email servers that receive messages on your domain.

It’s critical that you keep an eye on your daily DMARC reports. Examining the data in the reports may help you understand which messages from your domain are passing SPF, DKIM, and DMARC authentication.

DMARC reports tell you:

• Which servers or services are sending messages that fail DMARC
• What percent of messages from your domain pass DMARC
• What servers or third-party senders are sending mail for your domain
• What DMARC actions the receiving server takes on unauthenticated messages from your domain: none, quarantine, or reject.

When the majority of messages pass DMARC, modify your DMARC policy to impose more rigorous enforcement. Strict enforcement is more effective at preventing email spoofing.

Learn More: Email Spoofing Attacks in 2023

DMARC Report Example

What is the Difference between DMARC Aggregate Reports and Forensic Reports?

Every time your domain’s authentication (SPF and DKIM) fail, forensic reports are generated. This is utilized for a comprehensive examination of forged emails since these reports contain information about the fraudulent email, such as the From email address to another email address; subject; and in some cases, the header of the message.

After analyzing aggregate reports and authorizing all legitimate sources, it’s suggested that you turn on these reports to improve email security and identify any new threats.

Summarizing everything above, aggregate reports help you identify and authorize your genuine emails, while forensic reports aid in the analysis of forged emails and the identification of attack characteristics to be used against them.

How to Read DMARC XML Reports

After DMARC deployment, you will receive zip compressed reports full of useful information about your DMARC performance. Some people may have a hard time understanding these XML reports or find it practically impossible to organize XML files and store past reports.

This is why there are DMARC analyzer tools like our DMARC Report Analyzer that can help you analyze incoming reports.

Learn More about How to Read DMARC Reports.

How does a Free DMARC Report Analyzer work?

The latest version of our DMARC report analyzer helps users create a visual dashboard to help organize and analyze DMARC XML reports. It also provides feedback within your DMARC report about authorized and unauthorized IP addresses sending high volumes of emails from your sending domain.

After you set up a custom GlockApps email to receive your DMARC XML reports, our powerful DMARC analyzer tool will store past reports while analyzing future received DMARC reports.

Use our free DMARC XML analyzer to review up to 10,000 DMARC Aggregate Reports and ensure only authenticated emails are being sent from your domain. No payment details required.

Get 10,000 Free Aggregate DMARC Reports Every Month

How to Read DMARC Reports with GlockApps’ Free DMARC Report Analyzer Tool

After you publish a DMARC record to your domain’s DNS record, DMARC reports will start to appear in your GlockApps account.

Our free DMARC XML analyzer will give you a complete insight into DMARC XML report data, what it means, and what you can do with it to correct any possible email deliverability issues.

DMARC Aggregate Report Overview

The DMARC Report Overview shows useful information from your XML feedback by analyzing individual reports and constructing an aggregate report.

The columns above layout key elements in your DMARC reports including:

DOMAIN – the domains where you published a DMARC record to collect DMARC data.

POLICY – the policy applied to non-compliant messages used in your DMARC record for the domain.

COMPLIANCE – the percentage of DMARC compliant messages sent from the domain for the chosen period.

SOURCES – the number of sources (IP addresses) sending emails from the domain.

DMARC PASS – the number of DMARC compliant messages sent from the domain for the chosen period.

DMARC FAIL – the number of DMARC non-compliant messages sent from the domain for the chosen period.

SPF FAIL – the number of messages with failed SPF sent from the domain for the chosen period.

DKIM FAIL – the number of messages with failed DKIM sent from the domain for the chosen period.

FORWARD – the number of the email messages sent from the domain and then forwarded for the chosen period.

UNKNOWN – the number of source IP addresses that have sent emails for your domain, but have missed an SPF record or DKIM signature for your domain.

TOTAL – the total number of email messages sent from the domain for the chosen period.

Your DMARC analyzer displays analytics for a period of 30 days by default. You can choose a longer or shorter period using the calendar above the diagram.

The DMARC aggregate report gives you a human-friendly overview of how many sources are sending from your domain and how many emails passed and didn’t pass email authentication.

If you notice an unusually high number of sending sources for your domain, it may be a signal for you to thoroughly investigate to identify any possible new threats.

Click on the domain name to access a more detailed report about the mail sources sent from your domain.

Mail Sources

The diagram at the top of the DMARC report shows you mail traffic sent for the selected domain during the chosen interval.

Our DMARC report analyzer will help you quickly observe trends and identify any anomalies in email sending volume. If one day your volume suddenly increased to an unusual level, narrow down the time frame to that date and look for the sending sources who sent you a message on that day.

If you are unfamiliar with any of those sources, then it may be time to apply the ‘reject’ policy to improve email security and block any new threats.

When to Apply DMARC Reject Policy

The hardest part of DMARC is deciding when to use a “reject” or “quarantine” policy. This should happen when you confirm that your legitimate email sources are authenticating emails with SPF and DKIM.

Then, the next step is to gradually quarantine (p=quarantine) a portion of traffic (pct=10) and increase it over time. The “quarantine” policy will place failing messages in spam/junk folders.

Once comfortable, you can switch to the “reject” policy (p=reject). This will tell email receivers to discard the messages failing DMARC check completely, essentially stopping fraud on your domain as long as you control the approved sources.

Without the GlockApps’ free DMARC Analyzer marketers may find it practically impossible to organize DMARC XML reports or store past reports. By helping you observe trends within your DMARC aggregate reports, you can quickly take action and change your DMARC policy if any new threats arise.

By default, the data reporting is sorted by the sending IP. For your convenience, you can group the data by the sending organization, host, or reporter.

Now, let’s look at what the columns mean.

SENDING IP

Here, GlockApps uses DNS-based reporting so you can see the IP addresses and names of the SMTP servers that are sending emails on behalf of your domains. Green indicates authorized IP addresses. Unauthorized IP addresses are shown in grey.

DISP

Disposition tells you what action was applied to the messages and can have one of three values:

none – no specific action was taken regarding the email’s delivery. This usually means the email was delivered to the inbox.

quarantine – the email was treated as suspicious. Depending on the capabilities of the email receiver (whether it be Google, Yahoo, or Microsoft), this can mean that the email was placed into the spam folder, scanned for further processing, and/or flagged as suspicious.

reject – the email was rejected during the SMTP transaction.

POLICY OVERRIDE

A DMARC policy override occurs when an email recipient decides to override the policy that you have specified in your DMARC record.

For example, a policy override could happen when you have a DMARC reject policy (p=reject) and your outbound email is forwarded, which breaks email authentication. In this case, SPF will fail; however, the email receiver may decide to override your reject policy and accept the email.

The common DMARC overrides have five values:

forwarded – the email was relayed via a known forwarder, or local algorithms identified the email as likely having been forwarded. There is no expectation that authentication would pass.

local_policy – the Mail Receiver’s local policy exempted the email from being subjected to the Domain Owner’s requested policy action. For example, when the requested policy is set to “reject” but the ARC check passed, the mail receiver’s can override the “reject” policy with “none”.

Authenticated Received Chain (ARC) is an email authentication system designed to allow an intermediate email server like a mailing list or forwarding service to sign an email’s original authentication results.

ARC preserves email authentication results across subsequent intermediaries (“hops”) that may modify the email, and thus would cause email authentication to fail and lead to possible email deliverability issues. But if an ARC chain were present and validated, a receiver who would otherwise reject the messages might choose to evaluate the ARC results and make an exception, allowing legitimate messages from these indirect mail flows to be delivered to the inbox.

mailing_list – local algorithms determined that the email arrived via a mailing list, and thus the original email’s authentication was not expected to succeed.

sampled_out – the message was exempted from the application of policy by the “pct” setting in the DMARC policy record.

trusted_forwarder – the email authentication failure was anticipated by other evidence linking the email to a locally maintained list of known and trusted forwarders.

other – some policy exceptions not covered by the other entries in this list occurred.

DMARC EVAL

Shows whether or not the emails passed DMARC evaluation and can have one of the two values: Aligned or Fail.

The result is produced based on the results of the SPF and DKIM evaluation explained below.

The “Aligned” result means DMARC evaluation passed because SPF evaluation and DKIM alignment passed.

The “Fail” result means DMARC evaluation didn’t pass because SPF evaluation and/or DKIM evaluation failed.

When you identify all the authorized senders in your aggregate DMARC reports, make sure they are signing emails with DKIM and are added to your domain’s SPF to avoid possible email deliverability issues.

If you want to learn more about what SPF or DKIM records to add to your DNS record, check out our article about Improving Email Deliverability Using MX, SPF, and PTR Records.

Sender Policy Framework EVAL

This column shows whether or not the messages passed SPF evaluation and can have one of the two values: Pass or Fail.

SPF evaluation passes when the domain of the “Mail FROM” address (also called Return-Path, Return email address, Bounce email address) aligns with the domain in the header “From” address. When the “Mail FROM” address is empty, alignment is checked against the EHLO domain.

To check whether or not your “Mail FROM” and “From” domains match, go to the email reports, open the report,”x”, and press CTRL+B. Notice the “Bounce email address” below the “From” field and compare the domains.

DMARC has the optional tags – adkim and aspf. Each of these tags can have two values: “r” for the relaxed mode and “s” for the strict mode. By default, if these tags are not supplied, the relaxed mode is assumed.

In the relaxed mode, the SPF -authenticated “Mail FROM” domain and “From” domain must match or share the same Organizational Domain. The “Mail FROM” domain may be a parent domain or a child domain of the “From” domain.

In the strict mode, only an exact domain match is considered to produce SPF alignment.

DKIM EVAL

Shows whether or not the messages passed DKIM evaluation and can have one of the two values: Pass or Fail.

DKIM evaluation passes when the domain found in the “d=” field of a DKIM-signature in the email header aligns with the domain found in the header “From” address.

The domain in the “d=” tag must match or share the “From” domain in the relaxed mode, and exactly match the “From” domain in the strict mode.

If you set the adkim and aspf tags to “s” for strict compliance and in reality, your adkim and aspf are “relaxed”, your emails will fail DMARC compliance. But if they are set to “relaxed” and your actual compliance is “strict”, your email will pass DMARC compliance.

HEADER FROM

Here you can see the domain used in the “From” field in the email.

SPF DOMAINS

Here you can see which domain’s IP address is published in the SPF record.

When you identify all the authorized senders in your aggregate DMARC reports, make sure they are signing emails with DKIM and are added to your domain’s SPF to avoid possible email deliverability issues.

If you want to learn more about what SPF or DKIM records to add to your DNS record, check out our article about Improving Email Deliverability Using MX, SPF, and PTR Records.

SPF AUTH

This column displays the result of an SPF check against the given domain and IP address to verify that the IP is included in the SPF. The result can have one of 7 values:

None – the SPF verifier had no information at all about the authorization or lack thereof of the client to use the checked identity or identities.

Neutral – indicates that although a policy for the identity was discovered, there is no definite assertion (positive or negative) about the client.

Pass – the client is authorized to inject mail with the given identity.

Fail – the client is not authorized to use the domain in the given identity.

Softfail – this result is treated as somewhere between “fail” and “neutral”/”none”. The host is not authorized but the receiving server did not make a strong policy statement.

Temperror – the SPF verifier encountered a transient (generally DNS) error while performing the check.

Permerror – the domain’s published records could not be correctly interpreted.

DKIM DOMAINS

Here you can see the domain published in the “d=” tag in the DKIM signature.

DKIM AUTH

This column displays the result of a DKIM signature check that verifies if the message is correctly signed by the “d=” domain in the DKIM header.

The result can have one of 7 values (RFC 7001):

None – the message was not signed.

Pass – the message was signed, the signature or signatures were acceptable to the ADMD, and the signature(s) passed verification tests.

Fail – the message was signed and the signature or signatures were acceptable to the ADMD, but they failed the verification test(s).

Policy – the message was signed, but some aspect of the signature or signatures was not acceptable to the ADMD.

Neutral – the message was signed, but the signature or signatures contained syntax errors or were not otherwise able to be processed. This result is also used for other failures not covered elsewhere in this list.

Temperror – the message could not be verified due to some error that is likely transient in nature, such as a temporary inability to retrieve a public key. A later attempt may produce a final result.

Permerror – the message could not be verified due to some error that is unrecoverable, such as a required header field being absent. A later attempt is unlikely to produce a final result.

TOTAL

The sum of the message count in that specific report subset.

Free DMARC Report Analyzer for DMARC XML Reports

A DMARC report analyzer is extremely important when managing a successful email marketing program. After implementing DMARC, you may begin to receive too many DMARC reports, so instead of analyzing individual reports, use our free DMARC XML analyzer to organize these XML reports and identify legitimate sending sources or any new threats.

To make it easier, create a list of each source that you know sends emails from your domains. Our free DMARC XML analyzer will notify you as new sources appear in your DMARC reports, so you can match them to the known sources on your list. These could be email providers, eCommerce systems, marketing services, or even server notifications and alerts.

Without the GlockApps DMARC Analyzer marketers may find it practically impossible to organize DMARC XML reports or store past reports. By helping you observe trends with a complete insight into your DMARC aggregate reports, you can quickly take action if any new threats arise.

Want to learn more about our Free DMARC Report Analyzer?