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.

An email has more than one sender address

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:

It is important to understand that these two addresses can differ. 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.

How DMARC works

A domain owner (that's you) publishes a DMARC policy in a DNS TXT type resource record placed at subdomain _dmarc, for example: We'll call this DNS TXT record the DMARC record.

When a DMARC capable SMTP 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 receiver concludes that the email is not DMARC aligned, the server will apply the policy that was found in the DMARC record. In this 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.

DMARC alignment

A DMARC capable receiver will not only use SPF and DKIM validation, but also check received emails for alignment.

As we explained in our SPF article, an unauthorized (fraudulent) sender can bypass SPF by using a domain that they control in the RFC5321.MailFrom address. This address is not shown to the recipient by default, so it hardly goes noticed.

With DKIM, the domain that hosts the public key can be specified in the d= part of the DKIM header, so unauthorized senders can still add a valid signature to an email, just not from the same domain as the RFC5322.From address.

DMARC closes these security holes 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:

An email can pass both SPF and DKIM validation, but still fail alignment.

An email message is considered aligned if either SPF or DKIM is aligned.

SPF result DKIM result DMARC result
unaligned unaligned unaligned (policy will be applied)
unaligned aligned aligned
aligned unaligned aligned
aligned aligned aligned

If the email fails alignment, the policy defined in the DMARC record is applied by the receiver.

For example: if an email fails SPF, but has an aligned DKIM signature, it is considered DMARC aligned.

Relaxed vs Strict mode

In the DMARC record a relaxed or strict alignment mode can be specified for both SPF and DKIM. In strict mode the domain must match exactly to pass alignment, in relaxed mode the receiver will treat subdomains as equal.

DMARC setting value effect
aspf r (relaxed) The RFC5321.MailFrom domain part may be a subdomain of the RFC5322.From domain.
aspf s (strict) The RFC5321.MailFrom domain part must match the RFC5322.From domain exactly.
adkim r (relaxed) The d= value in the DKIM header may be a subdomain of the RFC5322.From domain.
adkim s (strict) The d= value in the DKIM header must match the RFC5322.From domain exactly.

SPF example: an email is received where the RFC5321.MailFrom domain is and the RFC5322.From domain is This email will pass relaxed SPF alignment but fail strict SPF alignment.

DKIM example: an email is received that is signed with DKIM using in the DKIM header, but the RFC5322.From domain is This email will pass relaxed DKIM alignment, but fail strict DKIM alignment.

DMARC policy

The DMARC policy instructs the receiver on how to treat received emails that fail alignment. There are 3 possible values:


When the 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 it as spam based on various other factors. The none policy is also the default policy that will be applied if no policy is specified in the DMARC record.


The 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 organizations do actually quarantine the emails, requiring human inspection to decide if the email should be delivered to the recipient's inbox.


A reject policy is the strongest level of advice a domain owner can give to the receiver. It advises the receiving server to reject email that fails DMARC alignment. If the email is rejected, it will not be delivered to the inbox of the recipient.

DMARC reporting

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 themselves 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 visualize 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 rua value.

Here is an example DMARC record that has reporting enabled:


Note that in the example DNS record above there is no p (policy) value specified, so the 'none' policy will be used, meaning that this DMARC record will not affect how email is treated by the receiver, it only requests a report.

Also note that the rua value must contain the scheme (mailto).


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 DMARC report aggregation service like Mailhardener is then used to process the various DMARC reports, to gather insight into 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 services 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.

Once all senders are DMARC aligned, the DMARC policy is changed to quarantine, to start blocking unauthorized senders. In the following period, DMARC reports are to be monitored closely, to identify any legitimate senders that may be been overlooked.

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 reject policy.

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 none to quarantine or reject, a percentage can be specified in the DMARC record using the pct property. 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

The DMARC record is a DNS record of type TXT with label _dmarc, for example:

A DMARC DNS 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;

To inspect the DMARC DNS record of your own domain, you can use our DMARC validator 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.

The version indicator v is required, the DMARC record must start with the version indicator, followed by a separator ;, so a DMARC record must start with v=DMARC1;. A DNS query on _dmarc.[domain] may only result in 1 TXT record that begins with v=DMARC1;.

Apart from the version (v) field, all other fields are optional. If the value is not set in the DMARC record, a default value is used.

Field Default value Description
v Required, must be set to DMARC1. Must be the first value in a DMARC record.
p none The policy the receiver should apply to emails that fail SPF and DKIM authentication, or fail alignment.
sp Same as p The policy the receiver should use for any subdomain of this domain. If not set, the same policy is used as found in p
np Same as p (experimental) The policy the receiver should use for non-existing subdomains of this domain. If not set, the same policy is used as found in p
pct 100 The percentage of unaligned emails that the policy p must be applied to. Can be used to transition slowly from none to quarantine to reject.
rua The URL where to send aggregate reports to. Currently only reporting via email (using the mailto scheme) is supported. If not set, no reports are sent by the receivers.
ruf The URL where to send failure (forensic) reports to, uses the same format as rua. Very few receivers implement this feature.
ri 86400 The interval at which the receivers should send a rua aggregate report, in seconds. Defaults to 86400 (24 hours). DMARC capable receivers may choose to ignore this value.
aspf r Instruct the receiver to use strict (s) or relaxed (r) SPF alignment validation. With strict alignment the RFC5321.MailFrom and RFC5322.From domains must match exactly, with relaxed alignment any subdomain is also accepted.
adkim r Instruct the receiver to use strict (s) or relaxed (r) DKIM alignment validation. With strict alignment the location of the DKIM record must match exactly with the RFC5322.From domain, with relaxed alignment any subdomain is also accepted.
fo 0 Instruct the receiver when to send a ruf failure report. See the segment failure reporting below for supported values
rf afrf The format to send the ruf failure/forensic reporting in. Only afrf is currently supported.

Reporting address format

The ruf and rua settings specify the URL(s) where DMARC capable receivers should send the reports to.

The format of the URL should be:


Where multiple addresses can be specified, separated by a comma (,).

For DMARC1 (currently the only version) the only scheme supported is mailto. Reporting to HTTP or other protocols may be implemented in the future, but is currently not supported.

Note that the reporting address must start with the scheme value! A common made mistake is omitting the scheme, which is actually a syntax error, making DMARC record invalid.

v=DMARC1;     <-- WRONG!

v=DMARC1;  <-- correct

v=DMARC1;,  <-- correct

Failure (RUF) reporting

DMARC failure reporting (previously known as forensic reporting), sometimes also called 'ruf' 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 ruf, fo and 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 sent to the email address defined in ruf.

The fo setting in the DMARC record can be a list of colon-separated values. The accepted values are:

Currently, the only supported report format that can be specified in the rf field is afrf.

Due to privacy related issues, receivers rarely send failure reports. Even when enabled, a domain may never receive an RUF report.

Privacy considerations with failure reporting

DMARC failure reports may contain a verbatim copy of the entire email, including the headers (sender, recipient, subject, etc.), and the full email body. Due to this design, there is a high chance that the RUF report contains Personally Identifiable Information (PII).

Note: the regular RUA DMARC reports (that may be aggregated by service such as Mailhardener) do not contain any PII.

Because of this, very few DMARC reporters will actually generate RUF reports. A domain with the ruf value set in the DMARC DNS record may never receive a RUF report.

Though most DMARC aggregation services (including Mailhardener) support processing RUF reports, we generally do not recommend using RUF with a report aggregation service. If an organization wishes to use failure reporting, it is recommended to set forensics reporting endpoint (the ruf value in the DMARC report) to an inbox within the organization to be reviewed by authorized personnel.

For example:

v=DMARC1; p=reject;;

Here, the DMARC rua endpoint is set to be aggregated by Mailhardener, but the ruf reporting endpoint is set to be processed by the organization ( itself.


DMARC is a versatile email hardening technique that solves common weaknesses with SPF and DKIM. DMARC also allows a domain administrator to monitor email traffic send on behalf of the domain, and identify deliverability issues.

DMARC report aggregation services, such as Mailhardener, are commonly used to aggregate and enrich DMARC reports, to allow for effective monitoring and identifying deliverability issues.

DMARC is recommended for all domains (even those that do not send email). When implemented correctly, DMARC prevents impersonation fraud, and helps to solve most deliverabilty issues.

Further reading

Relevant tools

Share your thoughts!

On last thing: If you have questions, comments or thoughts on this article, don't hesitate to shoot us an email.

You can also follow and reach us on Twitter @Mailhardener.

With Mailhardener you can configure, validate and monitor your domain for all aspects of email security. Mailhardener is free to use for a single domain.
Sign up now