How You Can Leverage the DMARC Analytics to Fix Deliverability Issues
After you published a DMARC record to your domain’s DNS, DMARC reports will start to appear in your GlockApps account.
In this post, I’m going to explain the report data, what it means and what to do with it to correct deliverability issues.
Aggregate Report Overview
The report overview shows the most important report data. Let’s go through these columns first:
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 the messages with failed SPF sent from the domain for the chosen period.
DKIM FAIL – the number of the 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 the email messages sent from the domain for the chosen period.
The default period to show the data is set to the last 30 days. You can choose a longer or shorter period using the calendar above the diagram.
The overview report gives you a general understanding 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 is a signal for the thorough investigation of your mail streams to identify possible malicious senders.
Click on the domain name to access the detailed report about mail sources.
Mail Sources
The diagram at the top of the report will show you mail traffic sent for the domain during the chosen interval.
It helps you quickly identify any anomalies in the volume of sent emails. If you notice that one day your volume jumped up to an abnormal value, narrow the period to that particular date and see the sending sources that sent the message that day.
If those were not the sources you know, then it might be the time to apply the ‘reject’ DMARC policy to block any further spamming attacks (after making sure that your legitimate sources sent DMARC compliant emails).
If those were your IP addresses or sources you know, check the compliance of sent emails. If something is broken (SPF, DKIM or DMARC), fix the issue.
By default, the data is sorted by the sending IP. For your convenience, you can group the data by the sending organization, host, or reporter.
The goal here is to identify each legitimate sender and make sure that DKIM, SPF and DKIM pass.
Now let’s look at what the columns mean.
SENDING IP
Here you can see the IP addresses and the names of the SMTP servers that are sending the emails on behalf of the domain. Your authorized IP addresses are shown by the green color. Unauthorized IP are shown by the grey color. GlockApps performs a DNS-based check to determine authorized and unauthorized sending IP for the domain.
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 delivery of the message. This usually means the message was delivered.
quarantine – the message was treated as suspicious. Depending on the capabilities of the email receiver, this can mean that the message was placed into the spam folder, scanned with additional intensity, and/or flagged as suspicious.
reject – the message 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 policy of reject (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 policy and accept the email.
The common DMARC overrides have five values:
forwarded – the message was relayed via a known forwarder, or local algorithms identified the message as likely having been forwarded. There is no expectation that authentication would pass.
local_policy – the Mail Receiver’s local policy exempted the message 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 mail 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 message, and thus would cause email authentication to fail when that message reaches its final destination. 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.
mailing_list – local algorithms determined that the message arrived via a mailing list, and thus authentication of the original message 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 message authentication failure was anticipated by other evidence linking the message 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 messages 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 evaluation passed.
The “Fail” result means DMARC evaluation didn’t pass because SPF evaluation and/or DKIM evaluation failed.
SPF EVAL
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 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”, you emails will fail DMARC compliance. But if they are set to “relaxed” and your actual compliance is “strict”, your message will pass DMARC compliance.
HEADER FROM
Here you can see the domain used in the “From” field in the message.
SPF DOMAINS
Here you can see the domain where the SPF record with the IP address shown in the Sending IP column is published.
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 record. 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 is 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.
Data Analysis
When you start receiving DMARC reports each day and dig into the data, your goal is to identify the mail sources that are legitimate.
To make it easier, you can create a list of each source that you know sends emails from your domain. As new sources appear in the reports, you can try to match them to the known sources in your list. These could be email providers, ecommerce systems, marketing services, or even server notifications and alerts.
The GlockApps DMARC Analytics does a good thing by resolving the sending IP address to a host. You can sort the sending sources by host or organization to see the name of the host or organization using the IP address shown in the report. It could help you figure out who is sending on behalf of your domain.
When you identify the sources that are authorized to send from your domain in the report, you want to make sure this source is signing emails with DKIM and is added to your domain’s SPF record.
If a lot of legit messages fail authentication checks, you might have missed an allowed source in your SPF configuration and/or have a sending server that is not signing your messages with DKIM correctly. This is a tedious process, but you can take your time and fix issues as you see them.
Email delivery services such a SendGrid, SparkPost, Amazon SES, as a rule, have documentation on what SPF or DKIM records to add to your DNS. The issues may appear when you use your own mail servers where DKIM and SPF might not be simple to implement. In some cases, it might be easier to migrate that email stream from your own email server to a delivery service or email service provider.
Finally, you may see some sending sources with failed SPF and/or DKIM checks that are not familiar to you. This can happen on legitimate messages from email forwarding where the SPF and DKIM headers are not preserved. If they appear in single digits, don’t worry about them much.
As you fix DKIM and SPF with your legitimate sending sources, the number of unknown/threats should be reduced. You may never reduce them completely because spammers try to spoof email for your domain all the time.
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.