Email authentication: SPF, DKIM, and DMARC explained

Email authentication is how a mailbox provider decides whether a message comes from the domain it claims to. Three DNS records answer that question: SPF, DKIM, and DMARC. Publish them correctly and your mail carries a verifiable identity that providers can trust. Skip them and your messages arrive with no proof of origin, which increasingly means the spam folder or an outright rejection.

This guide explains what each record does, how they reinforce each other, the order to set them up, and the mistakes that leave authentication half-working. If you want to check the current state of a domain, run it through the email authentication checker before you start changing records.

The three records, and what each one proves

Authentication works because the receiver checks records you publish in DNS against the message that arrives. Each record answers a different question.

SPF: which servers may send for you

SPF, the Sender Policy Framework, is a DNS TXT record that lists the servers authorized to send mail on behalf of your domain. A record looks like this:

v=spf1 include:_spf.your-provider.com -all

When a message arrives, the receiver reads the return-path domain (the envelope sender, not the visible From address), looks up its SPF record, and checks whether the connecting server is on the list. The -all at the end tells receivers to treat mail from any other server as unauthorized.

SPF has one structural weakness: it authenticates the return-path, which is not the address your recipient sees, and it breaks when mail is forwarded, because the forwarding server is not on your list. SPF is necessary but not sufficient on its own.

DKIM: a signature that survives the trip

DKIM, DomainKeys Identified Mail, attaches a cryptographic signature to every message. The sending server signs selected headers and the body with a private key, and adds a DKIM-Signature header. You publish the matching public key in DNS as a TXT record under a selector:

selector._domainkey.your-domain.com

The receiver reads the selector from the signature, fetches your public key, and verifies the signature. A valid signature proves two things: the message was authorized by your domain, and its signed content was not altered in transit. Because the signature travels with the message, DKIM keeps passing even when mail is forwarded. That durability is why DKIM is the stronger of the two authentication signals.

DMARC: policy and reporting on top

DMARC, Domain-based Message Authentication, Reporting and Conformance, sits above SPF and DKIM. It is a TXT record published at a fixed location:

_dmarc.your-domain.com

A starting record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@your-domain.com

DMARC does two jobs. It tells receivers what to do with mail that fails authentication, set by the policy tag p (none, quarantine, or reject). And it asks receivers to send you aggregate reports, set by rua, so you can see who is sending as your domain and whether that mail authenticates. Without DMARC, you have authentication with no policy and no visibility.

How the three fit together: alignment

The piece that makes DMARC meaningful is alignment. SPF and DKIM each authenticate a domain, but that domain is not always the one your recipient sees in the From field. A phisher can pass a plain SPF check on a return-path they control while the visible From address impersonates your brand.

DMARC closes that gap. It passes only when at least one of SPF or DKIM both authenticates and aligns with the domain in the From header. Alignment means the authenticated domain matches the From domain. So a message satisfies DMARC when:

• DKIM verifies against a domain that aligns with the From domain, or
• SPF passes for a return-path domain that aligns with the From domain.

Either path is enough. This is why a custom MAIL FROM subdomain on your own domain matters: it makes SPF align, and it stops your mail from appearing as sent through a shared provider domain. Between the two, DKIM alignment is the more reliable path, since it holds through forwarding.

Set them up in the right order

Authentication rewards a deliberate sequence. Rushing to a strict DMARC policy before the earlier records are clean will block your own mail.

1. Publish SPF. Add the TXT record listing your sending sources, ending in -all. Keep it to a single SPF record; multiple SPF records for one domain is an error.
2. Publish DKIM. Add the public-key records your sending platform provides, and confirm the platform is signing outgoing mail. Verify a test message shows a passing DKIM signature on your domain.
3. Publish DMARC at p=none. This changes nothing about how your mail is handled. It turns on reporting so you can watch.
4. Read the aggregate reports. For a few weeks, review the rua reports to find every service sending as your domain: your app, your CRM, your support tool, your invoicing platform. Confirm each one authenticates and aligns. This is where you catch the forgotten subdomain or the vendor sending unsigned mail.
5. Move to p=quarantine. Once legitimate mail passes cleanly, raise the policy so failing mail lands in spam rather than the inbox. Watch the reports again.
6. Move to p=reject. When quarantine has run without collateral damage, set the policy to reject so mail that fails authentication is refused outright. This is the posture that stops impersonation.

Each step depends on the one before it. The reporting window between p=none and p=quarantine is the part people skip and later regret.

Common failure modes

A few mistakes account for most broken authentication.

• SPF passes but DMARC fails. The return-path domain does not align with the From domain. Fix it with a custom MAIL FROM subdomain on your own domain, or lean on DKIM alignment instead.
• Too many SPF lookups. SPF allows at most ten DNS lookups. Chained include: statements from several vendors blow past the limit and cause a permanent SPF error. Flatten or consolidate your includes.
• Two SPF records. A domain may have only one SPF TXT record. A second one published by a different team invalidates both. Merge them.
• DKIM signing turned off. The public key is in DNS but the platform is not signing, so verification finds nothing. Confirm signing is enabled and a real message carries the header.
• DMARC stuck at p=none forever. Reporting without enforcement leaves the door open to impersonation. p=none is a starting point, not a destination.
• Forwarded mail failing SPF. Expected, and the reason DKIM matters. A DMARC pass via DKIM covers the forwarded case that SPF cannot.

The Gmail and Yahoo bulk-sender rules

In 2024, Gmail and Yahoo raised the floor for anyone sending in volume, and the rules are now enforced. A sender above roughly 5,000 messages a day to their users must:

• Authenticate with both SPF and DKIM.
• Publish a DMARC policy. p=none meets the requirement, though a stricter policy is the safer posture.
• Send from a domain that aligns with SPF or DKIM.
• Offer one-click unsubscribe following RFC 8058, using List-Unsubscribe and List-Unsubscribe-Post headers.
• Keep the spam-complaint rate below 0.3 percent, measured in tools like Google Postmaster.

The through-line is that authentication is no longer a nicety. It is the entry requirement for reaching the inbox at scale, and the three records in this guide are how you meet it. Once they are in place and your DMARC reports are clean, you have the durable identity that every other part of deliverability builds on.