Skip to content

SPF, DKIM and DMARC in plain English

Three DNS records decide whether your email arrives. What each one actually does, what to publish, and the four mistakes that cause most of the support tickets.

Koltrix Team4 min read
A row of six numbered mailboxes on a wooden rail in front of dense green plants
Photo by Mathyas Kurmann on Unsplash
On this page(6 sections)
  1. The one-sentence version
  2. SPF
  3. DKIM
  4. DMARC
  5. The order to do it in
  6. The four mistakes we see most

If your email is going to spam, the cause is usually one of three DNS records — or the absence of them. They have unhelpful names and every explanation online is written for people who already understand them. Here is the version we wish we had read.

The one-sentence version

  • SPF says which servers may send mail for my domain.
  • DKIM puts a signature on each message so the receiver can tell it was not altered and really came from you.
  • DMARC says what to do when the first two fail, and asks for a report.

SPF

SPF is a single TXT record on your domain listing who is allowed to send as you. It looks like this:

v=spf1 include:_spf.koltrix.com -all

include: delegates to another provider's list of servers. -all at the end means “and nobody else — reject them”. ~all means “and nobody else, but only treat it as suspicious”. Start at ~all if you are nervous; move to -all once you are sure you have listed everything that sends for you, including your CRM and your invoicing tool.

You may only have one SPF record. Two records is the single most common failure. If you already have one, merge the new include: into it rather than publishing a second: v=spf1 include:_spf.google.com include:_spf.koltrix.com ~all is one record that lets both send. Koltrix spots an existing record and shows you the merged version to paste.

There is also a limit of ten DNS lookups while evaluating the record. Each include: costs at least one. Chain enough providers together and SPF starts failing for a reason nothing tells you about.

DKIM

DKIM signs each outgoing message with a private key; you publish the matching public key in DNS at a name called a selector:

kx1._domainkey.yourdomain.com   TXT   "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

The receiver reads the signature header, fetches that record, and checks the message has not been modified in transit. If it verifies, the message is cryptographically tied to your domain, which is worth much more to your reputation than SPF alone.

You do not have to manage the key. Your provider generates the pair and gives you the public half to publish. Koltrix generates a 2048-bit key for each domain, used by that domain alone, and the signing runs on the mail server itself, so every outbound message is signed without your application doing anything.

A 2048-bit public key is about 400 characters, and a single TXT string holds at most 255. Some DNS providers quietly split the value into several quoted pieces when you save it. That is fine: receivers join the pieces back together. Copy the value whole and paste it once.

DMARC

DMARC is the policy record, published at _dmarc.yourdomain.com:

v=DMARC1; p=quarantine

The p= value is the instruction to receivers:

  • p=none — do nothing differently. Useful while you read reports to find out who sends as you; it protects nobody.
  • p=quarantine — put failures in spam. A sensible default, and the least that sender logos (BIMI) require.
  • p=reject — refuse failures outright. This is the goal.

An optional rua=mailto:… tag asks receivers to send you aggregate reports. They arrive as XML, they are unreadable by hand, and they are the only way to find out that your invoicing tool has been failing SPF for eight months — if something reads them. With no report reader, leave it out; it changes nothing about enforcement.

DMARC also requires alignment: the domain in the From: header your reader sees has to match the domain that passed SPF or DKIM. This is why mail sent “as you” through a third party can pass SPF and still fail DMARC.

The order to do it in

  1. Publish SPF and DKIM. Send yourself a test message and confirm both pass.
  2. If you know everything that sends as your domain (often just your email provider), publish DMARC at p=quarantine. That is what Koltrix suggests.
  3. If you don't know, start at p=none with a rua= address, read the reports for a few weeks, and add every legitimate sender to SPF or stop it. Then move to p=quarantine.
  4. Once nothing legitimate fails, consider p=reject.

The four mistakes we see most

  1. Two SPF records. Merge them. One record, one v=spf1.
  2. A fully qualified host name that the registrar qualifies again, producing kx1._domainkey.yourdomain.com.yourdomain.com. Some control panels (Cloudflare, GoDaddy, Namecheap) want just the part in front of your domain, kx1._domainkey, and @ for the domain itself.
  3. Jumping straight to p=reject. You will discover which systems were sending as you by having their mail rejected, which is an expensive way to find out.
  4. Staying at p=none for ever. It enforces nothing, so anyone can still send mail that claims to be you, and sender logos stay switched off.

If you just want to know where a domain stands right now, our SPF, DKIM and DMARC checker reads all three and tells you what is missing. It is free and needs no account.

Start with Koltrix

Your domain, one inbox, and an API that sends.

A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.

SharePost on XLinkedIn