The idea
SPF answers one question: did this message come from a server I approved? Useful, but limited. It says nothing about the message itself.
DKIM answers a different question. Your sending system signs each message with a private key. The matching public key sits in your DNS, where anyone can read it. The receiving inbox fetches that key and checks the signature. If it matches, two things are true at once: the message really came from your domain, and nobody changed it in transit.
It is a wax seal on an envelope, except the seal also covers the letter inside.
Two keys, two places
The whole design rests on a pair of keys that belong in different places, and mixing them up is the one thing you must not do.
- →The private key lives at your sender. Your mailbox provider or email platform holds it and usually never shows it to you. It signs outgoing messages.
- →The public key lives in your DNS as a TXT record. It can only verify signatures, never create them, so it is safe for the whole world to read.
- →You only ever publish the public one. If a vendor asks you to paste a private key into DNS, something has gone badly wrong.
Where the record goes
DKIM records sit at a name that includes a selector, which is just a label your sender chooses. That is how one domain can run several signing keys at once, one per sending service.
Name: selector._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...Your sender gives you the selector and the key. Enter the name relative, as selector._domainkey, not the full name with your domain on the end. Most DNS hosts append the domain for you.
Why the key looks broken in half
This one alarms people, so it is worth explaining. DKIM keys are long. DNS has a hard rule from RFC 1035 that a single text string cannot exceed 255 characters. A 2048 bit key is comfortably longer than that.
So long keys get split into several quoted strings, which are joined back together when read. You may see your key wrapped across multiple chunks in your DNS panel, or in quotes with a break in the middle. That is normal and correct. It is not corruption, and you should not try to tidy it into one string.
What does break things is editing the key by hand. Adding a space, dropping a character, or losing the trailing padding all produce a key that fails silently. Copy and paste, do not retype.
How it fits with DMARC
DKIM and SPF are not competitors. They are the two things DMARC checks.
DMARC asks whether a message passes SPF or DKIM, and whether the domain that passed lines up with the domain in the visible From line. That second part is called alignment, and it is what stops someone passing SPF on a domain they own while displaying yours in the From field.
A message needs only one of the two to pass and align. In practice DKIM is the more durable of the pair, because it survives forwarding. When a mailing list or a forwarded message relays your mail through another server, SPF usually breaks. The DKIM signature travels with the message and still verifies.
That is the case for setting up both rather than picking one.
Checking yours
Because the selector is chosen by your sender, DKIM is harder to spot check than SPF. The reliable route is your sending platform's own authentication screen, which will tell you whether the record it expects is actually visible in DNS.
Our free check looks at the email records on your domain and shows you what is in place today.
We have step by step instructions for every major platform, including the ones that will not let you.
See how to add DKIM on your platform