Domain-based Message Authentication, Reporting and Conformance (DMARC) is an email authentication and security policy protocol.
DMARC extends SPF and DKIM validation by adding a third validation known as alignment. It is intended to mitigate the weaknesses that exist in both DKIM and SPF. DMARC allows domain owners to specify a policy on how the receiver should treat email from the domain.
DMARC is formally defined in RFC7489.
DMARC also makes monitoring of email traffic for an entire domain possible. Mailhardener leverages DMARC to provide the email monitoring feature.
To understand DMARC, you must first know that an email can contain multiple email addresses. See our article email address types explained to learn more about that.
For this article, you need to know these email addresses:
RFC5321.MailFromis the sender email address used in the SMTP protocol between email servers. It is also known as the envelope address, return address or bounce address. This email address is usually not shown to the recipient.
RFC5322.Fromis the sender email address as shown to recipient.
It is important to understand that these two addresses can be different. They can even be from different domains.
A simple analogy with paper mail would be to treat the
RFC5321.MailFrom address as the address written on an envelope, and the
RFC5322.From as the sender address written on the letter itself.
A domain owner (that's you) publishes a DMARC policy in a DNS
TXT type record placed at subdomain
_dmarc, for example:
We'll call this DNS TXT record the DMARC record.
When a DMARC capable email server receives an email, it will check the domain used in the
RFC5322.From address for the existence of a DMARC record.
If a DMARC record is found the email server will check the email for alignment.
If the email fails alignment, the server will apply the policy that was found in the DMARC record. In the policy you can instruct the receiver to reject or quarantine emails that fail alignment.
Even without a DMARC record, a receiving email server may still use alignment validation as one of the factors in spam detection.
A DMARC capable email receiver will not only use SPF and DKIM validation, but also check received emails for alignment.
As we explained in our SPF and DKIM articles, an unauthorized sender can work around SPF and DKIM validation by using a domain they control in the
RFC5321.MailFrom address or DKIM signature.
DMARC closes this security hole by requiring that the domain name used in the various email addresses and DKIM signatures are equal.
In DMARC terms, an email is aligned when at least one of the following requirements is met:
RFC5321.MailFromaddress equals the domain used in the
An email can pass both SPF and DKIM validation, but still fail alignment. If both SPF and DKIM validation fail, the message will not be aligned.
If the email fails alignment, the policy defined in the DMARC record is applied by the receiver.
In the DMARC policy a relaxed mode or strict mode can be specified for both SPF and DKIM alignment. In strict mode the domain must match exactly to pass alignment, in relaxed mode the receiver will treat subdomains as equal.
Example: an email where the
RFC5321.MailFrom domain is
mail.domain.com and the
RFC5322.From domain is
domain.com will pass relaxed alignment but fail strict alignment.
The DMARC policy instructs the receiver on how to treat received emails that fail alignment. There are 3 possible values:
none policy is instructed, the receiver will not take any additional measures against these emails.
There is no guarantee that the email will be delivered to the recipient's inbox though, the server may still decide to reject the email or mark is as spam based on various other factors.
none policy is also the default policy that will be applied if no policy is specified in the DMARC record.
quarantine policy is used if the domain owner is not willing to give a strong statement about emails that fail DMARC alignment.
Most email servers use the alignment result as one of the factors for spam detection.
A quarantined email may still be delivered to the recipient's inbox, but has a higher possibility to be marked as spam.
Some organisations do actually quarantine the emails, requiring human inspection do decide if the email should be delivered to the recipient's inbox.
reject policy is the strongest level of advise a domain owner can give to the receiver.
It advices the receiving server to reject email that fail DMARC alignment.
If the email it rejected, it will not be delivered to the inbox of the recipient.
Besides alignment validation, DMARC can also be used to request reporting from receiving email systems.
The reports contain aggregated data over a certain period (usually 24 hours) on how the receiver processed the email it received from various senders that (attempt to) send email using your domain. Per sender the report will specify the number of processed emails, the applied policy, the authentication results (SPF and DKIM) and the alignment result. Finally, the report will specify the disposition the receiver applied to the emails (none, rejected or quarantined).
The reports itself are not human friendly to read, and the number of reports received on a daily basis can get quite high (one per receiver). To make the reports usable a service like Mailhardener is often used to combine, enrich, analyse and visualise the various reports that are received on a daily basis.
To enable reporting, the
rua value is set in the DMARC record.
The receiving server sends the report to the URL specified in the
Currently, the only supported protocol to be used in the URL is
mailto:, meaning that the reports are always send via email.
Here is an example DMARC record that has reporting enabled:
In a typical situation, a domain owner will enable DMARC with a
none policy first.
This will not affect the way receiving servers are processing email from the domain, but it will allow for monitoring.
A service like Mailhardener is then used to process the various DMARC reports to gather insight in all senders that use the domain name.
After some time (usually a month or so, depending on the various services used) there will be a reasonably complete overview of all services that are sending email in name of the domain, and whether these servers are passing SPF, DKIM and DMARC alignment.
If needed, the domain and/or sender configurations are adjusted to make sure all legitimate senders pass alignment.
Then the DMARC policy is changed to
quarantine, to start blocking unauthorized senders.
Depending on the amount of unauthorized senders that are encountered, and the nature of the business, a domain owner may go one step further and deploy a
From that point on, the monitoring system is used to keep an eye on all senders (both authorized and unauthorized). Based on the monitoring results the DKIM, SPF and DMARC settings may be adjusted accordingly.
When transitioning from
reject, a percentage can be specified in the DMARC record using the
If the percentage is set the receiver will only apply the policy to that percentage of emails that fail alignment.
This way the domain can make a more controlled transition, minimizing the risk of accidentally blocking legitimate senders.
The DMARC record is a DNS record of type
TXT with subdomain label
_dmarc, such as
A DMARC record consists of key-value pairs separated by a semicolon (
;), any whitespace is ignored.
The key and value is separated by an equal sign (
v=DMARC1; p=reject; rua=mailto:firstname.lastname@example.org
To inspect the DMARC DNS record of your own domain, you can use our DMARC inspector tool.
In this example, the DMARC record is set up with a
reject policy (in the
p field) and receivers are instructed to send aggregate reports to Mailhardener for processing.
v=DMARC1; version indicator is required, the DMARC record must start with the version indicator. A DNS query on
_dmarc.[domain] may only result in 1
TXT record that begins with
Apart from the version (
v=DMARC1) field, all other fields are optional.
If the value is not set in the DMARC record, a default value is used.
||Required, must be set to
||The policy the receiver should apply to emails that fail SPF and DKIM authentication, or fail alignment.|
||The policy the receiver should use for any subdomain of this domain. If not set, the same policy is used as found in
||The percentage of emails the fail SPF and DKIM or fail to align that the policy
||An URL where to send aggregate reports to. Currently only reporting via email (using the
||An URL where to send failure (forensic) reports to, uses same format as
||The interval at which the receivers should send a
||Instruct the receiver to use strict (
||Instruct the receiver to use strict (
||Instruct the receiver when to send a
||The format to send the
rua settings specify where DMARC capable receivers should send the reports to.
v=DMARC1 (currently the only version) this must always be a
Reporting to HTTP or other protocols may be implemented in the future, but is currently not supported.
DMARC failure reporting (previously known as forensic reporting) is a DMARC feature that would allow for real-time reporting of emails that fail alignment. In practice this feature is rarely supported by DMARC capable email servers. Mostly due to the potential high volume of reports and privacy concerns as the report may contain information about the email content.
Failure reporting is set up using the
rf values in the DMARC record.
When a DMARC capable receiver receives an email that fails alignment matching the
fo value, a forensics report in format
rf is send to the email address defined in
fo setting in the DMARC record can be a list of colon-separated values. The accepted values are:
0report if both DKIM and SPF fail alignment
1report if either DKIM or SPF fails alignment
sreport only if SPF fails alignment
dreport only if DKIM fails alignment
Currently, the only supported report format that can be specified in the
rf field is
As explained earlier, the failure reporting feature is rarely supported and is expected to be deprecated.