SPF, DKIM and DMARC Explained: How Email Authentication Works

SPF, DKIM and DMARC are three DNS records that let a receiving mail server verify who sent a message and whether it arrived unchanged. SPF (Sender Policy Framework) lists the servers allowed to send for a domain. DKIM (DomainKeys Identified Mail) signs each message so the receiver can prove it was not altered in transit. DMARC (Domain-based Message Authentication, Reporting and Conformance) tells the receiver what to do when SPF or DKIM fails and sends the domain owner reports about who is sending as them.

They are layers, not alternatives. SPF checks the sending server, DKIM checks the message, and DMARC checks that whichever one passed actually belongs to the domain shown in the From line. Since February 2024, Google and Yahoo require all three from anyone sending bulk mail, and Gmail rejects unauthenticated messages outright.

InboxKit publishes all three when you add a domain, so on InboxKit-managed domains this guide explains what is already there. On domains you manage yourself, use it to set the records up in the right order and to read what the SPF checker, DKIM checker and DMARC checker report back.

SPF is a TXT record at your domain root that lists the IP addresses and mail systems allowed to send email with your domain in the envelope sender (the return path). A receiving server looks up the record, checks whether the connecting server's IP is on the list, and records a pass, fail or soft fail.

Example records:

The all qualifier decides what happens to everyone not on the list:

The ten-lookup limit. Every include:, a, mx and redirect term costs a DNS lookup, and the receiver stops evaluating after ten (RFC 7208, section 4.6.4). Past ten the record returns a permanent error and SPF fails for every message. Google's include alone uses three lookups, so a domain that also lists a CRM, a helpdesk and a sequencer can hit the limit without noticing. The SPF checker counts the lookups for you; the SPF setup guide covers flattening when you are over.

One record per domain. Two TXT records starting with v=spf1 on the same name is a permanent error, the same as exceeding the lookup limit. Merge the includes into a single record instead.

DKIM adds a cryptographic signature to each message. Your mail server signs selected headers and the body with a private key and adds the result as a DKIM-Signature header. The receiver fetches the matching public key from DNS and verifies the signature. If anything covered by the signature changed on the way, verification fails.

Where the key lives:

selector._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjAN..."

The selector is a label chosen by the sending system, so one domain can publish several keys. Google Workspace uses google by default; Microsoft 365 uses selector1 and selector2 and rotates between them. A sequencer or CRM that sends on your behalf usually asks for its own selector.

Key sizes:

What DKIM does not do. It does not say who is allowed to send, only that this message carries a valid signature for the domain in the d= tag. That is why DKIM alone does not stop spoofing of the visible From address; DMARC alignment closes that gap.

The DKIM checker fetches the key for a selector and reports its size and validity. The DKIM setup guide walks through enabling it for Google Workspace and Microsoft 365.

DMARC sits on top of SPF and DKIM. It adds two things neither of them has: a policy that tells receivers what to do with mail that fails, and reports that tell you who is sending with your domain.

Policies:

Example records:

pct applies the policy to a share of failing mail, which lets you move to quarantine or reject gradually. rua is where aggregate reports go; expect one XML report per receiving provider per day.

Alignment is the part people miss. A message passes DMARC only if SPF or DKIM passes and the domain that passed matches the domain in the visible From header. In relaxed mode (the default) a subdomain counts as a match; in strict mode (aspf=s or adkim=s) it must be identical. This is the check that breaks when a sequencer sends from its own return-path domain, or when a tracking domain signs with a different d=: SPF and DKIM can both pass while DMARC fails.

Google requires at least p=none from bulk senders; it does not require quarantine or reject. Cold email domains should still move to p=quarantine once reports are clean, because an unenforced policy does nothing to stop someone else sending as you.

The DMARC checker shows the policy, the pct value and the alignment modes for any domain; the DMARC setup guide covers reading the reports.

A receiving server runs the checks in this order:

A message passes DMARC when SPF passes and aligns, or DKIM passes and aligns. Both do not have to pass, which is deliberate: forwarding breaks SPF (the forwarder's server is not in your record) but leaves DKIM intact, so a correctly signed message survives forwarding.

You can see the result of all four steps on any message you have received. Open the raw source and read the Authentication-Results header, or paste it into the email header analyzer.

All three, if you send cold email or any volume of outbound. The requirements are not a best practice any more; they are the entry conditions at the two largest mailbox providers.

Cold email crosses the bulk threshold sooner than it looks: 50 mailboxes at 30 messages a day is 1,500 a day per domain, and Google counts across the whole domain. Set up all three on every sending domain before the first campaign, not after the first bounce.

Set them up in this order:

1. 1SPF first, with ~all, listing every system that sends for the domain. Setup guide.
2. 2DKIM next, one selector per sending system, 2048-bit keys. Setup guide.
3. 3DMARC last, at p=none with a rua address, and read the reports for two to four weeks before moving to quarantine. Setup guide.
4. 4Verify with the DNS checker, then send yourself a message and confirm three passes in the Authentication-Results header.

On InboxKit, steps 1 to 3 happen automatically when a domain is connected, and the dashboard shows each record's status. The DNS setup guide shows what that looks like.