Email Authentication with SPF, DKIM and DMARC

Email was designed without a way to prove who sent a message: anyone can put any address in the From line. SPF, DKIM and DMARC let the owner of a domain publish which mail is really theirs, and let the receiving server check. This article covers what each one checks, how they fit together, the DMARC standard as it now stands, and what PCI DSS v4.0.1 says about them.

Fraud by business email is expensive. The FBI's Internet Crime Complaint Center recorded 24,768 complaints of business email compromise in 2025, with reported losses of $3.05 billion (IC3 2025 Internet Crime Report). Email authentication stops mail that forges a domain exactly. It does not stop a look-alike domain, or a genuine account that has been taken over.

SPF: which servers may send

SPF (RFC 7208) is a DNS TXT record listing the servers allowed to send mail for a domain. The receiving server checks the address the message was sent from at the protocol level, often called the envelope sender or Return-Path, not the From line the reader sees.

example.com.  TXT  "v=spf1 ip4:192.0.2.10 include:_spf.mailprovider.example -all"

• -all asks receivers to fail mail from anywhere else; ~all asks for a soft fail.
• An SPF check may cause at most 10 DNS lookups through include, a, mx and similar terms. Beyond that the check returns an error, so each email service added to the record counts against the limit.
• A domain that sends no mail can say so with v=spf1 -all.

SPF breaks when mail is forwarded, because the forwarding server is not on the original domain's list.

DKIM: a signature on the message

DKIM (RFC 6376) has the sending server sign selected header fields and the body with a private key. The public key is published in DNS under a selector, and the receiver uses it to check that the message came from the domain and was not changed on the way.

s2026._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

• RFC 8301 requires RSA keys of at least 1024 bits and says signers should use at least 2048.
• Selectors let a new key be published and put into use before the old one is withdrawn, which is how keys are rotated. No standard sets an interval. Rotate on a schedule you can keep, and at once if a private key may have been exposed.
• A DKIM signature usually survives forwarding, which is why it matters more than SPF for a domain that wants a strict DMARC policy.

DMARC: tying both to the From line

DMARC checks that SPF or DKIM passed for a domain that matches the one in the From line, which is called alignment. It then tells the receiver what the domain owner wants done with mail that fails, and where to send reports. The record lives at _dmarc under the domain.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

• p=none asks for no action and collects reports; p=quarantine asks for failing mail to be treated as suspicious; p=reject asks for it to be refused.
• rua is where aggregate reports go: summaries from receivers of which servers sent mail as your domain and whether it passed.

The current standard

In May 2026 RFC 9989 replaced RFC 7489, the original DMARC document, with a standards-track specification. Reporting moved to RFC 9990 for aggregate reports and RFC 9991 for failure reports. The changes a domain owner will notice:

• pct is gone. Receivers applied values other than 0 and 100 inconsistently. A new tag, t=y, covers the testing case: it asks receivers not to apply the published policy, and the owner can expect failing mail to be treated one level below it.
• np sets a separate policy for subdomains that do not exist.
• A DNS tree walk replaces the public suffix list for finding a domain's policy and its organisational domain.
• p=reject comes with warnings. Domains whose users might post to mailing lists should not publish it, because list mail fails DMARC and causes problems for the list and its subscribers. Such a domain that still wants it should first publish p=none for at least a month, then p=quarantine for as long again, and compare the results. A domain that publishes p=reject must sign its mail with DKIM and not rely on SPF alone. Receivers must not reject mail on a p=reject policy alone.

Putting them in place

1. List everything that sends mail as your domains: the mail service, the website, the payment or booking platform, marketing and support tools.
2. Give each one SPF and DKIM that align with the From domain. RFC 9989 asks for at least one aligned result and prefers both. Use the records each provider documents, and keep SPF within its lookup limit.
3. Set up a mailbox for aggregate reports and publish DMARC at p=none. RFC 9989 recommends parsing the reports by machine, so decide how that will happen before they arrive.
4. Fix every legitimate sender the reports show failing. RFC 9989 requires this before any move to enforcement, and notes that, depending on how often a domain sends mail, it can take months.
5. Move to p=quarantine. Consider p=reject for domains that send only automated mail, and for domains that send nothing (with v=spf1 -all beside it), following RFC 9989's staged checks.
6. Keep it current. A new email service that is not added to SPF and DKIM will start failing.

Two free tools help check the records: MXToolbox SuperTool looks up a domain's SPF, DKIM and DMARC records, and Google Admin Toolbox Check MX checks a domain's mail server and SPF records. M3AAWG, an industry working group against messaging abuse, publishes best-practice documents on email authentication.

What PCI DSS says

PCI DSS v4.0.1 does not require SPF, DKIM or DMARC. It names them once, in the guidance to 5.4.1, as anti-spoofing controls that help stop phishers spoofing the entity's domain and impersonating its personnel. 5.4.1 itself requires processes and automated mechanisms to detect and protect personnel against phishing, and email authentication is one of the examples given. PCI DSS Requirement 5.4.1: protecting personnel against phishing covers the rest.

Email authentication does not encrypt anything, so it has no part in protecting card data sent by email. 4.2.2 requires the PAN to be secured with strong cryptography whenever it is sent by end-user messaging, and its guidance names email as an example. It applies even when a customer asks for a card number to be sent that way. The guidance adds that sending the PAN this way should only be considered where there is a defined business need, under the acceptable use policies required by 12.2.1.