SPF, DKIM and DMARC Explained (And Why Your Email Goes to Spam)

Two problems, one root cause.

The first: your invoices and quotes keep landing in customers' spam folders, and you have no idea why.

The second, worse one: anyone in the world can send email that appears to come from your domain. Email was designed in the 1980s with no way to verify the sender. The "From" field is just text — as forgeable as writing someone else's name on an envelope.

Three DNS records fix both. They are free, they take about an hour, and most small businesses have never heard of them.

SPF — who is allowed to send

SPF (Sender Policy Framework) is a public list of the servers permitted to send email for your domain.

When a message claiming to be from you@yourbusiness.com arrives, the receiving server looks up your SPF record and asks: is the server this actually came from on the list? If not, the mail is suspicious.

An SPF record is a TXT record on your root domain:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Reading it left to right:

• v=spf1 — this is an SPF record.
• include:_spf.google.com — Google Workspace may send for us.
• include:sendgrid.net — so may SendGrid.
• ~all — anything else is a soft fail: flag it, do not necessarily reject it.

The mistake almost everyone makes: forgetting a sender. Your newsletter tool, your invoicing software, your CRM and your helpdesk all send email as you. Miss one and its messages start failing. List every service before you publish.

The second mistake: more than one SPF record. The spec allows exactly one. Two records means both are invalid and all your mail fails. Merge them into a single line.

There is also a hard limit of ten DNS lookups per SPF evaluation. Each include: costs at least one. Businesses using six or seven services quietly exceed it, and once you do, the record fails entirely — with no error message anywhere.

DKIM — proof the message was not altered

SPF checks where mail came from. It does not prove the content is genuine. DKIM (DomainKeys Identified Mail) does.

Your sending server signs each message with a private cryptographic key. You publish the matching public key in DNS. The receiving server verifies the signature, which proves two things: the message genuinely came from you, and nobody modified it along the way.

You do not write a DKIM record by hand. Your email provider generates the key and gives you a TXT record to publish, usually at a hostname like google._domainkey.yourbusiness.com.

Set it up in every service that sends on your behalf, not just your main mailbox.

DMARC — what to do when the checks fail

Here is the thing nobody explains: SPF and DKIM on their own do very little. They report a result, but they never say what the receiving server should do about a failure. Most servers, faced with no instruction, deliver the message anyway.

DMARC is the instruction. It is a TXT record at _dmarc.yourbusiness.com:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourbusiness.com; pct=100

• p= is the policy — what to do with mail that fails.
  • p=none — do nothing, just report. Monitoring mode.
  • p=quarantine — send it to spam.
  • p=reject — refuse it outright. The strongest setting.
• rua= — where to send aggregate reports. This is the valuable part: you get daily XML reports showing every server sending mail as your domain, including the ones you do not know about.

If you have SPF and DKIM but no DMARC, you have done the work and skipped the part that makes it count. A spoofed email still gets delivered.

The rollout that does not break your email

Never start at p=reject. You will discover your invoicing system was never in SPF at the moment your invoices stop arriving.

1. Publish SPF and DKIM for every sending service you can identify.
2. Publish DMARC at p=none with a rua address. Nothing changes for your mail flow; you just start collecting data.
3. Read the reports for two to four weeks. They will reveal legitimate senders you forgot. Add them.
4. Move to p=quarantine, optionally with pct=25 to apply it to a quarter of mail first.
5. Move to p=reject once reports are clean for a couple of weeks.

The raw XML reports are unreadable by design. Free tools like Postmark's DMARC digest or dmarcian's starter tier turn them into something human.

Why this affects deliverability too

Gmail and Yahoo now require SPF, DKIM and DMARC for anyone sending meaningful volume to their users. Microsoft has moved the same way. This is no longer optional hygiene — it is the entry requirement.

Even at low volume, authentication is a significant input to whether you land in the inbox or the promotions tab. If your quotes keep going to spam and you have been rewriting subject lines to fix it, check your DNS first. It is very often the actual cause.

A note on domains you do not send from

Own yourbusiness.net as a defensive registration and never send from it? Attackers love those. Publish a null policy so nobody can spoof them:

v=spf1 -all

v=DMARC1; p=reject;

That says: no server may send for this domain, reject everything claiming to.

Check your domain

siteIQ's website audit checks your domain's SPF and DMARC records as part of its email security category, and flags a missing or misconfigured record alongside the rest of your findings.

If you are tightening things up generally, pair this with our guide to security headers and the small business security checklist. Email authentication is the one people skip, and it is the one that lets someone invoice your customers using your name.