What is DMARC?

Domain-based Message Authentication, Reporting, and Conformance, or DMARC is an email authentication protocol. It is designed to give email domain owners the ability to protect their domain from unauthorized use, commonly known as email spoofing.

Overview

A DMARC policy allows a sender’s domain to indicate that their email messages are protected by SPF and/or DKIM and tells a receiver what to do if neither of those authentication methods passes – such as to reject the message or quarantine it. The policy can also specify how an email receiver can report back to the sender’s domain about messages that pass and/or fail.

These policies are published in the public Domain Name System (DNS) as text TXT records.

DMARC does not directly address whether or not an email is spam or otherwise fraudulent. Instead, DMARC can require that a message not only pass DKIM or SPF validation but that it also pass alignment. Under DMARC a message can fail even if it passes SPF or DKIM but fails alignment.

Setting up DMARC may improve the deliverability of messages from legitimate senders.

Alignment

DMARC operates by checking that the domain in the messages From field (also called “RFC5322.From” is “aligned” with other authenticated domain names. If either SPF or DKIM alignment checks pass, then the DMARC alignment test passes.

Alignment may be specified as strict or relaxed. For strict alignment, the domain names must be identical. For relaxed alignment, the top-level “Organizational Domain” must match. The Organizational Domain is found by checking a list of public DNS suffixes and adding the next DNS label. So, for example, “a.b.c.d.example.com.au” and “example.com.au” have the same Organizational Domain because there is a registrar that offers names in “.com. au” to customers. Although at the time of DMARC spec there was an IETF working group on domain boundaries, nowadays the organizational domain can only be derived from the Public Suffix List.

Like SPF and DKIM, DMARC uses the concept of a domain owner, the entity or entities that are authorized to make changes to a given DNS domain.

SPF checks that the IP address of the sending server is authorized by the owner of the domain that appears in the SMTP MAIL FROM command. (The email address in MAIL FROM is also called the bounce address, envelope-from, or RFC5321.MailFrom.) In addition to requiring that the SPF check passes, DMARC checks that RFC5321.MailFrom aligns with 5322. From.

DKIM allows parts of an email message to be cryptographically signed, and the signature must cover the From field. Within the DKIM-Signature mail header, the d= (domain) and s= (selector) tags specify where in DNS to retrieve the public key for the signature. A valid signature proves that the signer is a domain owner and that the From field hasn’t been modified since the signature was applied. There may be several DKIM signatures on an email message; DMARC requires one valid signature where the domain in the d= tag aligns with the sender’s domain stated in the From header field.

DNS record

DMARC records are published in DNS with a subdomain label _dmarc, for example, _dmarc.example.com. Compare this to SPF at example.com, and DKIM at selector._domainkey.example.com.

The content of the TXT resource record consists of name=value tags, separated by semicolons, similar to SPF and DKIM. For example:

“v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dmarcreports@example.com;”

Here, v is the version, p is the policy (see below), sp is the subdomain policy, pct is the percent of “bad” emails on which to apply the policy, and rua is the URI to send aggregate reports to. In this example, the entity controlling the example.com DNS domain intends to monitor SPF and/or DKIM failure rates and doesn’t expect emails to be sent from subdomains of example.com. Note that a subdomain can publish its DMARC record; receivers must check it out before falling back to the organizational domain record.

Step-by-step adoption

The protocol provides for various ratchets, or transitional states, to allow mail admins to gradually transition from not implementing DMARC through to an unyielding setup. The concept of stepwise adoption assumes that the goal of DMARC is the strongest setting, which is not the case for all domains. Regardless of intent, these mechanisms allow for greater flexibility.

Policy

First and foremost, there are three policies:

• none is the entry-level policy. No special treatment is required by receivers but enables a domain to receive feedback reports.
• quarantine asks receivers to treat messages that fail DMARC check with suspicion. Different receivers have different means to implement that, for example, flag messages or deliver them to the spam folder.
• reject asks receivers to outright reject messages that fail the DMARC check.

The policy published can be mitigated by applying it to only a percentage of the messages that fail the DMARC check. Receivers are asked to select the given percentage of messages by a simple Bernoulli sampling algorithm. The rest of the messages should undergo the lower policy; that is, none if p=quarantine, quarantine if p=reject. If not specified, pct defaults to 100% of messages. The case p=quarantine; pct=0; is being used to force mailing list managers to rewrite the From field, as some don’t do so when p=none.

Finally, the subdomain policy, sp=, and the newly added no-domain policy allow to tweak of the policy for specific subdomains.

How Libraesva can help?

DMARC is a standard to prevent unauthorized spoofing of the header From, if you correctly configure DMARC it will be harder for third parties to spoof your organization.

Even if you don’t need or want to use DMARC, we highly advise you to add the following txt record to your DNS: