I remember a client calling in panic a few years back: “Gmail is rejecting all our emails!” Turns out their domain had zero authentication — no SPF, no DKIM, no DMARC. In 2020, you could get away with that. In 2026? It’s a death sentence for deliverability.

Gmail and Yahoo made it clear: no authentication, no delivery. End of discussion.

If SPF, DKIM, and DMARC sound like magic spells to you — don’t worry. I’ll explain everything in a moment.

What do all these acronyms actually mean?

Imagine you’re sending a physical letter. SPF is a list of people authorized to send letters on your behalf. DKIM is your signature — proof that you actually wrote this letter. And DMARC? It’s instructions for the post office: “If the letter doesn’t have my signature or was sent by someone unauthorized, throw it away.”

Together, they create a system that tells the world: “Yes, this email really comes from me.”

SPF — who can send emails from your domain

SPF is the simplest of the three protocols. It’s just a DNS record (TXT type) that lists all servers authorized to send emails from your domain.

What it looks like in practice

Let’s say you use MailingAPI for transactional emails and Google Workspace for company email. Your SPF record will look like this:

example.com. TXT "v=spf1 include:spf.mailingapi.com include:_spf.google.com ~all"

What does this mean?

  • v=spf1 — protocol version (always the same)
  • include:spf.mailingapi.com — MailingAPI servers are OK
  • include:_spf.google.com — Google servers are OK
  • ~all — treat everything else with suspicion

The trap half of people fall into

SPF has a limit of 10 DNS “lookups.” Each include: is one lookup. Sounds like a lot? Not when you use several external services, and each of them has their own includes inside…

I once helped a company that had 14 lookups in their SPF. Gmail simply ignored the entire record. The solution? We had to consolidate services and use SPF flattening.

How to check your SPF

dig example.com TXT | grep spf

Or simpler — go to MXToolbox SPF Check and enter your domain.

DKIM — digital signature for every email

DKIM is a bit more complicated, but the idea is simple: every outgoing email gets a digital signature. The recipient’s server checks this signature using the public key in your DNS.

If someone modifies the email content along the way — the signature doesn’t match. Gmail knows something’s wrong.

Configuring DKIM

There are two options here:

Option A — do everything yourself (the hard way):

# Generate keys
openssl genrsa -out dkim_private.pem 2048
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pem

# Add public key to DNS
mailingapi._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

# Configure your server to sign messages...
# And pray you didn't mess anything up

Option B — use MailingAPI (the easy way):

mailingapi._domainkey.example.com. CNAME dkim.mailingapi.com.

One CNAME record and you’re done. We generate keys, rotate them regularly, sign emails — all automatically.

How to check if DKIM works

Send a test email to yourself and check the headers. You’re looking for something like:

Authentication-Results: ... dkim=pass

dkim=pass — great. dkim=fail — you’ve got a problem.

DMARC — policy and reports

DMARC is like a supervisor over SPF and DKIM. It tells mail servers: “If an email fails SPF and DKIM, do this with it.” Additionally, it generates reports so you know who’s trying to send emails as you.

Implementing DMARC — don’t do it all at once!

I’ve seen companies set p=reject on day one and block half of their own emails. Don’t do that.

Week 1-2: Start with monitoring

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

p=none means “don’t do anything, just report.” For two weeks, collect data and check if all your legitimate email sources pass authentication.

Week 3-4: Gradually tighten the policy

_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@yourdomain.com"

p=quarantine means “put in spam.” pct=10 means “but only 10% of messages.” Gradually increase the percentage.

After a month+: Full protection

_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com"

Now unauthorized emails are rejected. Your domain is protected.

Most common problems (and how to fix them)

“Too many DNS lookups”

SPF has a limit of 10 lookups and you’re exceeding it. Solutions:

  • Remove unused includes
  • Use SPF flattening (converts includes to direct IP addresses)
  • Consolidate services

“DKIM signature not verified”

The public key in DNS doesn’t match the signature. Check:

  1. Whether the DNS record has propagated (can take up to 48h)
  2. Whether the selector in the signature matches the one in DNS
  3. Whether there are typos in the record

Emails still going to spam despite authentication

Authentication is the foundation, but not everything. Also check:

  • Domain and IP reputation
  • Message content
  • Bounce rate and spam complaints

Tools I use every day

Tool What it checks
MXToolbox SPF, DKIM, DMARC, blacklists — everything in one place
mail-tester.com Comprehensive message test (score 1-10)
DMARC Analyzer Readable DMARC reports instead of raw XML

Final thoughts

Configuring SPF, DKIM, and DMARC isn’t rocket science, but it requires attention. One mistake in a DNS record and your emails stop arriving.

If you don’t want to deal with this — MailingAPI handles it for you. One CNAME record and you have full authentication without worrying about keys, rotations, and lookup limits.

And if you prefer to do it yourself — you now have everything you need. Good luck.