SPF, DKIM and DMARC: what each proves

Your mail is landing in spam and the three acronyms everyone points at are SPF, DKIM and DMARC. Most explanations either stop at “add these records” or disappear into RFC prose. Neither helps when you are staring at a DNS panel.

Email authentication answers one question for a receiving server: is this message really from the domain it claims? The three standards answer different halves of it, which is why you need all three.

The short answer

Publish four DNS records for your sending domain:

; SPF: which servers may send for this domain
send.example.com.   TXT  "v=spf1 include:_spf.mailkube.com ~all"

; Bounce routing: same host as SPF
send.example.com.   MX   10 feedback.mx.mailkube.com

; DKIM: the public key that verifies our signature
kube1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..."

; DMARC: what to do when the first two disagree
_dmarc.example.com. TXT  "v=DMARC1; p=none; rua=..."

Start DMARC at p=none, which asks for reports without affecting delivery. Move to p=quarantine and then p=reject once the reports are clean.

Your dashboard shows the exact values when you add a domain. Copy them from there rather than from this page.

Three of those records sit where you would expect. The SPF one does not, so it is worth a section.

Why SPF is not on your main domain

SPF is checked against the envelope sender, the address the sending server hands over in MAIL FROM. That address is not your From: header. We send your mail from a dedicated send. subdomain, so send.example.com is the domain a receiver evaluates SPF for, and putting the record on example.com means nobody ever reads it.

You get something out of this. Your main domain’s SPF record stays exactly as it is, which matters if you already send through a CRM or a helpdesk, and you keep the ten-lookup budget that an extra include: would eat into. The same host carries the MX that routes bounces back to us, so both records land in one place.

Alignment still works, because send.example.com and example.com share an organisational domain. More on that below.

What each record actually proves

SPF proves the connecting server was authorised. It lists the servers allowed to send for your domain. The receiver checks the IP that opened the connection against that list. What SPF checks is the envelope sender, not the From: header your recipient sees, which is why SPF alone does not stop someone forging your display address.

DKIM proves the message was not altered. We sign outgoing mail with a private key; the receiver fetches the public key from your DNS and verifies the signature. If the body or the signed headers changed in transit, verification fails. DKIM says nothing about which server connected.

DMARC ties the first two to what the reader sees. It requires that a passing SPF or DKIM result be aligned: that the domain SPF or DKIM authenticated matches the domain in the visible From: header. This is the part that stops a forged sender address, and it is why publishing SPF and DKIM without DMARC leaves the obvious attack open.

Alignment is the part people miss

A message can pass SPF and still fail DMARC.

If your envelope sender is on send.example.com and your From: is billing@example.com, SPF passes for the first domain while DMARC asks about the second. Under relaxed alignment, the default, the two only need to share an organisational domain, so example.com and send.example.com align. Under strict alignment they must match exactly.

This is the single most common reason a domain with every record published still fails DMARC. It is also why the subdomain arrangement above is safe: relaxed alignment is what makes it work, and strict alignment is what would break it.

What to do about it

Publish all four records, and keep SPF to one v=spf1 record per host. Two SPF records is a permanent error, not a merge.
Wait for the domain to verify. All four have to resolve before you can send, and DNS propagation is usually minutes rather than hours.
Create an API key or SMTP credential, then send one message and confirm the signature verifies.
Read your DMARC reports for two weeks before you change the policy. The record we give you already carries our reporting addresses; add your own rua alongside them rather than in place of them.
Tighten to p=quarantine, then p=reject, once nothing legitimate is failing.

Common mistakes

Putting the SPF record on your main domain. It is checked on the host your mail is actually sent from, so a record on the apex is never read and your domain never verifies.
Two SPF records on one host. Receivers treat this as permerror and the check fails outright. Merge them into one.
More than ten DNS lookups in SPF. Each include: costs a lookup and the limit is ten. Exceeding it is also a permerror.
-all or p=reject before the reports are clean. A hard fail on a domain you have not finished inventorying drops real mail, and you will find your forgotten CRM and your invoicing tool by having them rejected in production.
Rotating DKIM keys without leaving the old public key published. Mail signed with the old key is still in flight.

Where to go next

Verify your domain and collect the exact records for your account in the domains guide . If you are still seeing rejections after all four pass, the message is probably being judged on reputation rather than authentication, which is a different problem with different signals. The design decisions behind our sending path explain what we do about it, and the pricing page covers what a dedicated IP costs if your volume warrants one.