DMARC reporting
A DMARC policy protects your domain from spoofing and phishing email attacks by establishing rules for receiving mail servers to follow when evaluating the authenticity of email messages claiming to be from your domain. If a domain does not have a DMARC policy in place or if it has not been added properly, it could result in emails not being delivered to their intended recipients.
They provide information about how the receiving mail server should handle email messages claiming to be from the domain covered by the DMARC policy. Depending on if the criteria are met, the email provider will return one of the following actions:
None - The policy was applied by the ISP because all audits passed, so there was no reason to reject or quarantine the email and it was delivered.
Quarantine - The ISP quarantined the email, in accordance with the domain's policy. If the receiving mail server has a quarantine mailbox, this is where the message will be delivered.
Reject - The ISP rejected the email, in accordance with the domain's policy.
MailerCheck’s DMARC monitoring tool allows you to set up automatic DMARC reports from the most popular email providers like Gmail, with full reporting about your domain usage. DMARC reports are automated emails sent by receiving mail servers to the email address specified in the DMARC policy.
By analyzing DMARC reports, you can get a better understanding of how your domain is being used and take steps to protect it.
How to set up DMARC monitoring:
Navigate to the Monitoring tab and click DMARC.
Click the Monitor domain button to add a domain.
Enter the domain address and click Add.
Next, you will see a report showing the SPF, DKIM and DMARC records found on that domain.
If no DMARC record is present, you have the option to create one by clicking the Setup button.
Once all of the preferences have been set, the DMARC record will be displayed, which can be added to your DNS.
Click Finalize record.
How to read DMARC reports
There are two main types of DMARC reports that the mailbox provider sends: forensic reports (also known as failure reports) and aggregate reports.
After the record has been added, MailerCheck will show the aggregate reports that are received from email providers. Reporting is based on a date and the domain, and you can check the reports received for a domain by selecting a date range and clicking the Report button.
DMARC aggregate reports provide information about the DMARC, SPF and DKIM authentication status of all emails that go through the authentication process. Unlike forensic reports, aggregate reports do not contain any sensitive information, but they do provide insights crucial for monitoring your domain sending activity, including:
Information about the Email Service Provider (ESP) including domain and email address
Date range
Email source IP address
Number of messages sent
SPF domain
SPF authentication result
SPF domain alignment result
DKIM domain
DKIM authentication result
DKIM domain alignment result
Policy applied by the receiver
| Value | Meaning |
|---|---|
| Applied policy | The DMARC policy that has been applied to the email by the ISP, independant of the value provided by the domain DMARC policy. |
| DMARC Override | DMARC policy override happens when the receiving email server overrides the DMARC record that is set by the sender. This occurs when the sender has specified that they want their email to be rejected if it doesn’t match an incoming mail server’s policy, but the receiving email server decides that it is not appropriate for its own set of policies. |
| SPF Authentication | The IP address that sent the email (Source IP in the Delivery Center report) is compared with the IP address published in the SPF record for the domain. |
| SPF Alignment |
The |
| DKIM Authentication | The email’s DKIM header is compared to the domain’s publicly available DKIM key. |
| DKIM Alignment |
The |
| ARC | ARC provides a valid “chain of custody” for email messages, allowing each entity that handles the message to effectively see all entities that previously handled it. In addition, it shows the message’s authentication assessment each step throughout handling. |
Applied Policy
The Applied Policy is an important part of DMARC reports because it can help you to understand how your DMARC policy is being treated by receiving mail servers. For example, if the DMARC policy for the sending domain is p=reject, then all messages that fail DMARC authentication will be rejected, regardless of the policy provided by the DMARC record.
If you see that a lot of your messages are being quarantined or rejected, then you may need to adjust your DMARC policy to be more strict.
| None | This policy was applied by the ISP because all audits passed, so there was no reason to reject or quarantine the email. |
| Reject | The ISP rejected the email, in accordance with the domain's policy. |
| Quarantine | The ISP quarantined the email, in accordance with the domain's policy. |
| forwarded | The email was likely forwarded, based on local algorithms that identified forwarding patterns. Authentication can be expected to fail. |
DMARC Override
The DMARC override tag is an important part of DMARC reports, since it can help you to understand why some of your messages are not being rejected even though they fail DMARC authentication.
For example, if you have a DMARC policy of p=reject and your emails are failing DMARC authentication but are still being delivered, the DMARC override tag can help you to understand why. This information will tell you whether the receiving mail server has overridden your DMARC policy, and if so, why.
| local_policy | The local policy of the Mail Receiver exempted the email from being subjected to the action requested by its Domain Owner. |
| mailing_list | The email was sent from a mailing list, so the filter program decided that it probably wasn’t legitimate. |
| sampled_out | The message did not apply to the policy because its percentage setting pct was set in the DMARC record. |
SPF Authentication
When an email server receives an email, it will check the SPF record for the domain in the From header, or "return-path" field of the email. If the IP address of the sending server is not listed in the SPF record, the email will be rejected or quarantined.
The SPF Authentication tag indicates whether the SPF check passed or failed. If you see that a significant number of your messages are failing SPF authentication, you may need to investigate the IP addresses that are sending emails on behalf of your domain.
| None | No SPF record was found for the domain or the server was unable to resolve the domain name in the DNS. |
| neutral | SPF neutral can be interpreted in DMARC as either pass or fail, depending on how you set up DMARC on your email server. This is normally controlled by a flag in your DMARC setup. |
| fail (hard fail) | The IP address is not authorized to send from the domain. The SPF record does not contain the sending server or IP address used for sending email to the mailbox provider. |
| softfail (soft fail) | The IP address may or may not be authorized to send from the domain. The mailbox provider will likely mark the message as suspicious, however, they will still accept it. A softfail does not necessarily cause deliverability problems by itself because mailbox providers rely on other data points to make a filtering decision. |
| temperror (temporary error) | A temporary error occurred during the SPF verification process. This result is often due to technical issues that took place during the verification process. Temperrors do not necessarily mean the SPF record is invalid. |
| permerror (permanent error) | The published SPF record could not be verified by the mailbox provider and could be because: - multiple SPF records are found on one domain; - the SPF record is syntactically incorrect; - the number of DNS lookups involved in a single SPF check exceeds 10; - the number of void lookups involved in a single SPF check exceeds 2. |
SPF Alignment
SPF Alignment helps to prevent email spoofing by ensuring that the domain in the From header of an email message matches the domain in the SPF record.
If you are noticing a lot of emails fail this check, it could indicate a misconfiguration in your email setup, or it could be a sign that someone is sending unauthorized emails that appear to be from your domain.
| Pass | There is an exact match to the domain (i.e. example.com = example.com) or if there is a parent / child match (example.com & blue.example.com) |
| Fail | The from domain doesn't exactly match the return-path domain or its subdomain. |
DKIM Authentication
DKIM Authentication verifies that the email message has not been tampered with since it was sent.
When an email is received, the mail server performs the DKIM check by verifying this digital signature. If the signature is valid and the headers have not been altered, the check passes; if not, it fails.
If a lot of messages are failing DKIM authentication, it’s best to investigate the DKIM configuration for your domain. Here are some steps you can take:
Check your DKIM records. Make sure that your DKIM records are correctly published in the DNS.
Check your DKIM keys. Check that your DKIM keys are valid and that they are not expired.
| Pass | The DKIM header is the same as the domain’s. |
| Fail | The email's DKIM header doesn't exactly match the domain's public DKIM key. |
DKIM Alignment
For DKIM Alignment to pass in DMARC, the domain in the DKIM signature must either match exactly or be a subdomain of the domain found in the "From" header of the email.
If you're seeing a lot of emails fail this check, it could indicate a misconfiguration in how your emails are being signed.
| Pass | There is an exact match to the domain (i.e. example.com = example.com) or if there is a parent / child match (example.com & blue.example.com). |
| Fail | The d= tag doesn't exactly match the from domain or its subdomain. |
Report Source
A report source is the Internet Service Provider (ISP) that received the email and generated the report. This information is important because it can help you to identify the source of any DMARC failures.
These reports are sent by the receiving mail servers, which could be managed by an ISP or another mail service like Gmail, Yahoo, Outlook, etc.
Saving reports
Each report is added to a folder and kept in your account so you’ll always have access to the list of IPs sending emails with your domain. Keep in mind, each day can have multiple reports.
Reports will also show various suggestions for next steps to prevent unauthorized sendings from happening. These suggestions can help guide you to either forbid the sending source, disregard it, or authorize it.