[DMARC] provides the strongest protection against spoofed email, ensuring that unauthenticated messages are rejected at the mail server, even before delivery.
Binding Operational Directive 18-01
Department of Homeland Security
SPF is an email authentication standard that allows domain owners to specify which servers are authorized to send email with their domain in the Mail From: email address. SPF allows receivers to query DNS to retrieve the list of authorized servers for a given domain. If an email message arrives via an authorized server, the receiver can consider the email authentic.
Example DNS Record
example.net. IN TXT “v=spf1 a mx-all”
SPF is not ideal for all email use cases and can fail if a message is forwarded. The Mail From domain authenticated by SPF is not easily visible by an email recipient.
DKIM is an email authentication standard that cryptographically associates a domain name with an email message. Senders insert cryptographic signatures into email messages that receivers can verify by using DNS-hosted public keys. When verification is successful, DKIM provides a reliable domain-level identifier that can survive forwarding, unlike SPF.
Example DNS Record
selector._domainkey.example.net IN TXT
“v=DKIM1; k=rsa; p=public key data”
DKIM is generally more complex to set up than SPF, requiring a cryptographic signature on each message sent. DKIM will fail when content is modified in transit, like messages sent through a mailing list.
For more information, please visit www.dkim.org
DMARC is an email authentication standard that works in conjunction with SPF and DKIM. It brings long-missing features to email, enables senders to gain visibility into how their email domains are used and abused, describes how to combine existing authentication technologies to create secure email channels, and provides receivers with clear directives on how to safely dispose of unauthorized email—all at Internet scale.
Example DNS Record
dmarc.domain.com. IN TXT “v=DMARC1; p=reject;
For more information, please visit www.dmarc.org
The DMARC model uses DNS as the mechanism for policy publication. DMARC records are hosted as TXT DNS records in a DMARC specific namespace. The DMARC namespace is created by prepending “_dmarc.” to the email domain that is to become DMARC compliant. For example, if the email domain “example.com” publishes a DMARC record, issuing a DNS query for the TXT record at “_ dmarc.example.com” will retrieve the DMARC record.
The DMARC specification allows senders to publish policy records containing parameters that receivers use to inform the processing of emails that purport to come from the sender’s email domain. The features that DMARC enables are:
Flexible Policies: The DMARC model allows email senders to specify one of three policies to be applied against email that fails underlying authentication checks:
Subdomain-Specific Policies: DMARC records can specify different policies for top-level domains vs. subdomains using the p= and sp= tags.
Phased Rollout of Policies: DMARC records can include a “percentage” tag (“pct=”) to specify how much of an email stream should be affected by the policy. Using this feature, senders can experiment with progressively stronger policies until enough operational experience is gained to move to “100% coverage.”
Identifier Alignment Flexibility: The DMARC specification allows domain owners to control the semantics of Identifier Alignment. For both SPF and DKIM generated authenticated domain identifiers, domain owners can specify if strict domain matching is required or if parent and/or subdomains can be considered to match.
Feedback Controls: DMARC records include parameters that specify where, how often, and in which format feedback should be sent to the email domain owner.