SPF, DKIM and DMARC Explained for Email Deliverability

SPF, DKIM and DMARC are three DNS records that let a receiving mail server check whether an email really came from the domain it claims to come from. SPF lists the servers allowed to send for your domain, DKIM adds a cryptographic signature that proves the message was not altered, and DMARC tells receivers what to do when those checks fail and sends you reports about it. Set them up in that order, start DMARC in monitoring mode, and tighten it once the reports show that all your real mail passes.

Large mailbox providers have been asking bulk senders for all three, and messages without them are increasingly filtered or rejected. The rest of this post explains what each record does, how to publish it, and the mistakes we see most often when helping businesses fix their email.

Why do SPF, DKIM and DMARC matter for deliverability?

Email was designed without any built-in way to prove who sent a message. Anyone can put your domain in the From line. Mailbox providers fight spam and phishing by checking authentication first, then looking at reputation and content.

If your domain has no authentication, a receiving server has to guess. Guessing usually means a lower trust score, more mail in the spam folder, and in some cases outright rejection. With all three records in place and passing, you give the receiver a clear, verifiable answer, and your sending reputation builds on your own domain instead of being shared with strangers.

What is SPF and how does it work?

SPF (Sender Policy Framework) is a TXT record on your domain that lists which servers may send mail using that domain in the envelope sender address. When a message arrives, the receiving server looks up the record and checks whether the connecting server's IP address is on the list.

A typical record looks like this:

v=spf1 include:_spf.yourmailhost.com include:sendingtool.example ~all

The parts mean:

• v=spf1 marks it as an SPF record.
• Each include: pulls in the server list published by a service that sends on your behalf.
• ~all says that anything not listed should be treated as suspicious (a soft fail). -all is a hard fail.

Three rules prevent most SPF problems:

1. Publish one SPF record per domain. Two separate SPF records cause both to fail. Merge them into one.
2. Stay under ten DNS lookups. Every include: costs at least one lookup, and nested includes add more. Past ten, the check returns an error.
3. List every real sender. Your mailbox host, your newsletter tool, your CRM, your helpdesk and your invoicing system may all send as your domain.

SPF has one known weakness: it checks the hidden envelope sender, which the recipient never sees, and it breaks when mail is forwarded. That is why it cannot work alone.

What is DKIM and how does it work?

DKIM (DomainKeys Identified Mail) signs each outgoing message with a private key held by your sending service. The matching public key is published in DNS under a selector name, for example s1._domainkey.yourdomain.com.

The receiving server reads the signature header in the message, fetches the public key from DNS and checks that the signature matches. If it does, two things are proven: the message was signed by someone who controls that domain's key, and the signed parts of the message were not changed on the way.

Practical points:

• Each sending service needs its own DKIM setup. Your mailbox host signs your normal mail. Your newsletter tool must also be configured to sign with your domain, or it will sign with its own.
• Use 2048-bit keys where the service allows it.
• Selectors let you run several keys at once, which makes rotating a key possible without downtime.

DKIM survives most forwarding, which covers the gap SPF leaves.

What is DMARC and how does it work?

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the other two to the address people actually see. It asks one question: did SPF or DKIM pass for a domain that aligns with the visible From domain?

Alignment is the key idea. A message can pass SPF for your newsletter tool's domain and still fail DMARC, because that domain is not yours. DMARC passes only when at least one of the checks passes for your own domain.

The record lives at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

• p= is the policy. none means monitor only, quarantine means send failures to spam, reject means refuse them.
• rua= is where receivers send daily aggregate reports.

In what order should you set them up?

Changing everything at once is how legitimate invoices end up in spam. A safe sequence:

1. Inventory every service that sends as your domain. Check billing, support, marketing, CRM and any website contact forms.
2. Publish or fix SPF so it lists all of them in a single record.
3. Turn on DKIM in each service and publish its public key.
4. Publish DMARC with p=none and a reporting address.
5. Read the reports for two to four weeks. They show every source sending as your domain and whether it passes.
6. Fix the failing legitimate sources, then move to p=quarantine, and later to p=reject.

The reports are XML files and not pleasant to read by hand. A small parser or a reporting service turns them into a list of sending sources with pass and fail counts, which is all you need.

What are the most common mistakes?

• Two SPF records after adding a new tool. Merge them.
• DKIM left on the vendor's default domain, so DMARC alignment fails even though DKIM "passes".
• Jumping straight to p=reject and blocking your own billing emails.
• Forgetting subdomains. Mail sent from news.yourdomain.com needs its own SPF and DKIM, and DMARC can set a separate subdomain policy with sp=.
• Ignoring parked domains. A domain that never sends mail should publish v=spf1 -all and a DMARC reject policy so nobody can spoof it.

Is authentication enough to reach the inbox?

Authentication gets you through the door. After that, receivers look at your reputation: how many recipients open, reply, delete or mark you as spam, and how many of your messages bounce. A perfectly authenticated domain sending to an old, unchecked list will still struggle, because high bounce rates and spam complaints damage reputation faster than authentication can build it.

So treat SPF, DKIM and DMARC as the foundation, then look after list quality, sending volume and content. Warm up new domains gradually, keep a consistent sending pattern, and make unsubscribing easy.

Working with Syntora Ai

Email marketing was where Syntora Ai started in 2019, and fixing authentication is still one of the quickest wins we see for a business whose mail goes missing. If you want someone to audit your SPF, DKIM and DMARC setup and read the reports with you, write to hello@syntorahq.ai or use the contact page.