Skip to content

What is DMARC and how to set it up

DMARC, which is the short form of Domain-based Message Authentication, Reporting, and Conformance, is a TXT record added to your domain's DNS records that allows you to detect and prevent spoofed email (for example, with a spoofed sender). The DMARC policy tells the receiving email server what to do after checking the SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) records, which are other email authentication methods.

Principle

A DMARC record stores the DMARC policy of a domain. DMARC records are stored in the Domain Name System (DNS) as DNS TXT records. A DNS TXT record can contain almost any text that a domain administrator wants to associate with their domain. One way that DNS TXT records are used is to store DMARC policies.

For example, a DMARC domain record might look like this:

Name Type Content
_dmarc.domain.tld TXT v=DMARC1; p=quarantine; adkim=r; aspf=r; rua=mailto:postmaster@domain.tld;

The DMARC policy determines what happens to an email after SPF and DKIM records have been checked. The email either passes or fails the SPF and DKIM checks. The DMARC policy determines whether failure will result in the e-mail being marked as spam, blocked, or delivered to the intended recipient. Later, the recipient of the email may send a report of these incidents to the domain owner.

Note: Email servers may mark email as spam even if there is no DMARC record, but DMARC provides clearer guidance on when to do so.

Deployment

The domain.tld domain policy may be as follows:

"If an email fails the DKIM and SPF tests, mark it as spam."

These policies are not recorded as human-readable sentences, but rather as machine-readable commands so that email services can automatically interpret them. This DMARC policy would actually look like this:

v=DMARC1; p=quarantine; adkim=s; aspf=s;

What does this mean?

  • The v=DMARC1 means that this TXT record contains a DMARC policy and should be interpreted as such by email servers.
  • The p=quarantine indicates that email servers should quarantine emails that do not conform to DKIM and SPF - they consider them potential spam. Other possible settings include p=none, which allows emails that fail to pass, and p=reject, which instructs email servers to block emails that fail.
  • The adkim=s means that DKIM checks are "strict". This can also be set to "relaxed" by changing "s" to "r", for example adkim=r.
  • aspf=s is the same as adkim=s, but for SPF.

"asf" and "adkim" are optional settings. The "p=" attribute specifies what the email servers should do with emails that do not meet the SPF and DKIM requirements. If the domain.tld administrator wanted to tighten this policy even more and signal more strongly to email servers to consider unauthorized messages as spam, he would modify the "p=" attribute as follows:

v=DMARC1; p=reject; adkim=s; aspf=s;

This basically says, "If the email fails the DKIM and SPF tests, don't deliver it."

The DMARC policy may contain guidelines for sending messages about emails that do or do not pass DKIM or SPF. DMARC reports are extremely important because they provide the domain administrator with the information they need to decide how to modify their DMARC policy (for example, if their legitimate email fails SPF and DKIM or if a spammer is trying to send illegitimate email).

The domain.tld administrator may add a rua section to the DMARC policy to send periodic notifications of usage:

v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:postmaster@domain.tld;

Domains that do not send email should still have a DMARC record to prevent spammers from using the domain. The DMARC record should contain a DMARC policy that rejects all email that does not meet the SPF and DKIM requirements (which should be all email sent by the domain).