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.

Use the SPF checker to inspect the published record, including duplicate-record and lookup-budget findings. It diagnoses DNS evidence; it cannot prove that a specific message passed SPF.

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.

DKIM selectors are message-specific. If you know a selector, use the DKIM checker to inspect its public key and record shape; then inspect a fresh message to confirm that your sender is signing with it.

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.

The DMARC checker shows the effective public policy and inheritance evidence. It cannot prove alignment for a real message, so use message headers as the final check.

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. Skipping the reporting window between p=none and p=quarantine is what blocks legitimate mail later.

If you send through Samva, this guide explains the protocol choices, while verifying your sending domain gives the product-specific DNS workflow. For the larger operating picture, including suppression and engagement, see Deliverability.

Rotating a DKIM key

Rotate a signing key on a schedule or after any suspicion the private key was exposed. A rotation never replaces the current key in place. Samva publishes the new public key under a new selector, so both keys stand in DNS at once:

1. Samva generates the new key pair and shows a second _domainkey TXT record, tagged New key, in the domain's DNS table. Publish it. The current key keeps signing.
2. Once the new record resolves publicly, Samva switches signing to the new selector and asks the provider to verify it. Sending is held for that verification alone.
3. The former record stays in the table tagged Keep published. Messages signed before the switch, including delayed, queued, and forwarded mail, still carry the old selector and only verify while that record exists.

Retiring the former record is a separate decision. Keep it published for at least a week and for at least two full TTLs of the record as your DNS host actually serves it, then confirm no mail signed with the old key is still in flight. Samva shows the earliest date that could apply but never removes the record itself.

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. Treat p=none as the first step toward enforcement.
• 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

Google's current sender guidelines say that a sender of more than 5,000 messages a day to personal Gmail accounts 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 rate reported in Google Postmaster Tools below 0.30 percent.

Google's sender guidelines and sender FAQ are the primary source for its current thresholds and enforcement. Yahoo's sender requirements are a separate primary source with comparable bulk-sender expectations. The RFC 8058 mechanics belong in the one-click unsubscribe guide, rather than in this authentication overview.

Plan the first sends after verification

Use the DKIM checker with the selector from a real test message, then confirm the receiving mailbox reports aligned authentication. Once that works, plan a gradual increase in legitimate sending volume with the email domain warm-up guide. Authentication and a sensible sending ramp address different parts of deliverability; neither guarantees inbox placement.

When authentication is ready: BIMI

SPF, DKIM, and DMARC establish a verifiable sending identity. BIMI is an optional next step for domains that want a supporting mailbox provider to consider displaying a brand indicator. It requires effective DMARC enforcement and an aligned real message, then adds a BIMI DNS record, hosted logo, and certificate evidence.

Start with the BIMI checker to inspect the public DNS and asset evidence. For Gmail's logo and verified-checkmark requirements, including VMC versus CMC, read Gmail BIMI requirements. Neither a successful DNS inspection nor a technically valid BIMI setup guarantees that a provider will display an indicator.

Authentication 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.