Subscribe for updates and more.

Email DNS

Planted 02024-02-14

SPF, DKIM, DMARC, oh my.

  • Sender Policy Framework (SPF)
  • DomainKeys Identified Mail (DKIM)
  • Domain-based Message Authentication, Reporting & Conformance (DMARC)

The Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) provide domain-level authentication; they enable cooperating email receivers to detect mail authorized to use the domain name, which can permit differential handling.

Domain-based Message Authentication, Reporting, and Conformance (DMARC) enables domain-specific message-handling policies for receivers, and reporting of authentication and disposition of received mail.

SPF

The Sender Policy Framework (SPF) is an open standard specifying a technical method to prevent sender address forgery.

SPFv1 allows the owner of a domain to specify their mail sending policy, e.g. which mail servers they use to send mail from their domain.

  1. Domain owner publishes which mail servers they use to send email as a TXT record in the domain’s DNS zone
  2. When someone’s mail server receives a message claiming to come from that domain it can check if it comes from an unknown server, and considered fake

The domain sender policies alone are not worth much — it is the receiving mail servers that need to enforce them.

Example SPF policy

example.net.  TXT  "v=spf1 mx a:pluto.example.net include:aspmx.googlemail.com -all"

Learn more about the record syntax.

DKIM

DKIM allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient.

  1. Domain owner stores public key in DNS _domainkey
    • A CNAME record can also be used to point at a different TXT record, for example when one organization sends email on behalf of another.
  2. Emails sent include a DKIM-Signature header that mail servers can use to verify the email comes from where it says it does by looking up the public key.

DMARC

DMARC policies are published in the DNS as text (TXT) resource records (RR) and announce what an email receiver should do with non-aligned mail it receives.

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling.

DMARC builds on the widely deployed SPF and DKIM protocols, adding linkage to the author (“From:”) domain name, published policies for recipient handling of authentication failures, and reporting from receivers to senders, to improve and monitor protection of the domain from fraudulent email.

At a high level, DMARC is designed to satisfy the following requirements:

  • Minimize false positives.
  • Provide robust authentication reporting.
  • Assert sender policy at receivers.
  • Reduce successful phishing delivery.
  • Work at Internet scale.
  • Minimize complexity.

Example DMARC policy

example.net.  TXT  "v=DMARC1;p=reject;pct=100;rua=mailto:[email protected]"

In this example, the sender requests that the receiver outright reject all non-aligned messages and send a report, in a specified aggregate format, about the rejections to a specified address. If the sender was testing its configuration, it could replace “reject” with “quarantine” which would tell the receiver they shouldn’t necessarily reject the message, but consider quarantining it.

Read the specification


See also

Understanding SPF, DKIM, and DMARC: A Simple Guide