How does DMARC email authentication work?
DMARC fits into existing inbound email authentication processes, helping receivers determine if a message aligns with what it has on record about a sender.
If there’s a misalignment, the receiving server can check the DMARC record for guidance on how to handle the unaligned message. Here’s an example of this flow for a common setup:
- An email is sent.
- The sending server inserts a DKIM header.
- The sending server sends the email to the receiver.
- The email passes through standard validation tests regarding IP, rate limits, reputation, etc.
- The receiving server retrieves verified DKIM domains based on the header, an “envelope from” via SPF, and applies the configured DMARC policies of that domain. It will either pass the email along, quarantine it, or reject it
- The ultimate action taken for the email is sent to the sender’s server via a report.
What are the components of DMARC?
To understand DMARC, it’s important to understand the fundamentals of SPF, DKIM, and Domain Name System (DNS) records:
SPF
SPF helps detect misalignment by reviewing an email’s listed return-path address. When an email can’t be sent to its intended recipient after a delay or after multiple tries, a failure notification is usually sent to the return-path address.
How SPF Works
Domain owners can decide which mail servers their domain is allowed to send from when they set up their SPF protocols.
- SPF information is entered into a TXT record. This defines the mail servers authorized to send email for a domain.
- An inbound mail server receives a new email. It checks the written rules for the domain of the return-path email address. The inbound server compares the IP address of the mail sender with the domains and/or IP addresses defined in the SPF record.
- The receiving server uses the rules specified in the sender’s SPF record and determines whether it should accept, reject, or flag the message.
DKIM
DKIM is an email authentication technique that ensures email content is kept safe from tampering by using an encryption signature inserted into the header of an email message. When a receiving server validates this DKIM signature, it can confirm that the email and attachments have not been modified.
How DKIM validates
- The domain owner publishes a unique cryptographic key, formatted as a TXT record within the domain’s DNS record.
- When a message is sent by an outbound server, it generates and attaches a unique DKIM signature to the header.
- Inbound servers receive an encrypted hash of the message body.
- The receiving server first locates the DKIM public key that’s referenced in the DKIM signature and stored in the DNS records.
- The key is used to decrypt the hash and then generate a new hash of the message body, comparing it to the original included by the sender.
- If the two hashes match, they can validate that the message wasn’t altered in transit.
IP address record
The type of DNS record that points domains to an IP address is called an address record or “A” record.
CNAME record
A CNAME (Canonical Name) record is a type of DNS record that maps an alias name to a canonical domain name. CNAME records usually map a subdomain like “www” or “mailto:” to the domain that hosts that subdomain’s content.
DMARC record
Along with your DNS records, your DMARC record is published and available for anyone online to view. It’s made up of several pieces of information and is stored as a TXT record:
v=DMARC1
The receiving server looks for the above identifier when it scans a DNS record for the domain sending the message. If this tag doesn’t exist, no DMARC check is run.
p=reject, p=none, p=quarantine
Domain holders can select from 3 policy options (set by p=) to advise the receiving server on what to do with mail that doesn’t pass SPF and DKIM but claims to originate from your domain:
- p=none tells the receiver to perform no actions against unauthenticated mail, but instead to send email reports to the mailto: address listed in the DMARC record.
- p=quarantine tells the receiver to quarantine unqualified messages, which usually results in them being marked as spam/junk by email providers.
- p=reject tells the receiver to deny unqualified mail. Only verified email is permitted to pass through to inboxes. Mail that is rejected is blocked from delivery.
rua=mailto:
This section tells the receiving server where it can send high-level aggregate DMARC reports.
ruf=mailto:
Similar to rua=mailto:, ruf=mailto: tells the receiving server where it can send detailed incident reports about DMARC failures. These reports are sent to the administrator of the domain.
fo=
This section displays one of several values related to detailed reporting options:
- 0 generates reports when all authentication mechanisms fail to pass an email
- 1 generates reports when any mechanism fails
- d generates reports if DKIM signatures fail to verify
- s generates reports if SPF fails
sp=
When this is included, it tells the receiving server whether it should apply DMARC policies to subdomains. If you don’t create DMARC policies for subdomains, they inherit the parent domain’s DMARC policy. To define a DMARC policy for subdomains, use the sp policy tag in the DMARC record for the parent domain.
adkim=
When this is included, it sets the DKIM alignment to either s (strict) or r (relaxed). Strict means the DKIM portion will pass only when the d= field in the DKIM signature matches the from address exactly. The relaxed setting allows messages to pass the DKIM portion if the DKIM d= field matches the root domain of the sender’s address, and is the default behavior if there is no adkim= parameter in the DMARC record.
ri=
This value sets the interval for the preferred frequency of aggregate reports sent.
aspf=
Another optional value, aspf= sets the strictness required for SPF alignment to either s (strict) or r (relaxed). Strict means that SPF will align only when the SPF from matches the header from exactly. The relaxed setting allows SPF to align if the Mail From domain and header from domain share the same organizational domain.
pct=
This optional value allows a domain owner to set a percentage on how many emails are sent with a particular policy. This is useful when first implementing DMARC to measure the difference in email delivery success for email sent from your domain.
As an example, p=reject; pct=50 means that 50% of emails are subject to the strictest policy, while the remaining 50% are subject to the next strictest policy.
Drip recommends starting off more lenient and increasing the strictness over time as DMARC establishes itself upon your sending domain reputation and sending behavior.