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
Email source IP address
Number of messages sent
SPF authentication result
SPF domain alignment result
DKIM authentication result
DKIM domain alignment result
Policy applied by the receiver
|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.|
|DKIM Authentication||The email’s DKIM header is compared to the domain’s publicly available DKIM key.|
|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.|
|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.|
|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.|
|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.|
|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 parents/childs.|
|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.|
|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 parents/childs.|
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.