Why Your Business Emails Land in Spam (SPF, DKIM, and DMARC Explained)

If your business emails — invoices, quotes, appointment confirmations — keep landing in customers' spam folders, the cause is almost always missing or broken email authentication. Receiving servers can't prove your mail is really from you, so they treat it as suspicious. Fixing it comes down to three DNS records: SPF, DKIM, and DMARC.

This goes deeper than a definitions list. We'll walk through an actual message that failed, read the headers, and show exactly what was missing.

Why do legitimate emails get flagged as spam?

Because "legitimate" isn't something the receiving server can take on faith — it has to be provable. When an email arrives, the receiving mail server (Gmail, Outlook, a corporate server) runs a series of checks to answer one question: can I prove this message really came from the domain it claims to be from? If the answer is no, the message gets penalized — a lower inbox score, a spam-folder placement, or an outright rejection.

Email was designed in an era of trust. Anyone can put anything in the "From" field — that's why phishing works. SPF, DKIM, and DMARC are the three standards that were bolted on to close that hole. If you haven't set them up, your real mail looks exactly as unverifiable as a scammer's, and modern providers increasingly treat "unverifiable" as "spam."

A real example: the invoice that never arrived

Here's a case we see constantly. A contractor sends an invoice from billing@theirbusiness.com using a website plugin. The customer swears it never came. It did — it went to spam. Here's the relevant slice of the message headers the receiving server generated:

Authentication-Results: mx.google.com;
   spf=fail (google.com: domain of billing@theirbusiness.com
      does not designate 198.51.100.24 as permitted sender)
      smtp.mailfrom=billing@theirbusiness.com;
   dkim=none (message not signed);
   dmarc=fail (p=NONE) header.from=theirbusiness.com

Read it line by line, because every line is a failure:

• spf=fail — the message was sent from server 198.51.100.24 (the website host), but the domain's SPF record doesn't list that server as allowed to send mail. So the receiving server sees mail claiming to be from theirbusiness.com coming from a server the domain never authorized.
• dkim=none (message not signed) — there's no cryptographic signature at all. The server has no way to verify the message wasn't tampered with or forged.
• dmarc=fail — because both SPF and DKIM failed, DMARC fails too. And p=NONE means the domain owner never told receivers what to do about failures, so the server falls back to its own judgment — which is "this looks like spoofing, send it to spam."

Three green checkmarks turned into three red flags. The invoice was real, but nothing about it was provable, so it got buried. Now here's what each record does and how to fix it.

What is SPF and how do you fix it?

SPF (Sender Policy Framework) is a DNS record that lists which servers are allowed to send email for your domain. Fix it by publishing an SPF record that names every legitimate sender.

It's a single TXT record on your domain. If you send through Google Workspace and a website plugin, it might look like:

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

The include: entries authorize each sending service. The ~all at the end means "anything not listed is suspicious." The most common mistake is sending through a new service — a CRM, an email marketing tool, a website form — without adding it to SPF. The moment you do, that mail starts failing. In the example above, the fix was adding the website host's mail service to the SPF record.

What is DKIM and how do you fix it?

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every message, proving it genuinely came from your domain and wasn't altered in transit. Fix it by enabling DKIM in your mail provider and publishing the public key they give you as a DNS record.

Your mail provider signs each outgoing message with a private key. The matching public key lives in your DNS. The receiving server uses the public key to verify the signature. If it matches, DKIM passes and the server knows the message is authentic and untampered. In our failed example, DKIM was simply never turned on — a two-step fix: enable signing in the provider, publish the key.

What is DMARC and how do you fix it?

DMARC ties SPF and DKIM together and tells receiving servers what to do when a message fails — and where to send reports. Fix it by publishing a DMARC record with a clear policy.

A starter DMARC record looks like:

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

p=quarantine tells receivers to send failing mail to spam rather than deliver it (once you're confident your legit mail passes, you can move to p=reject). rua= is the address that receives aggregate reports so you can see who's sending as your domain. The record in our example was p=NONE — which is the "do nothing, just watch" setting. It's fine as a first step for monitoring, but leaving it there indefinitely means you get none of DMARC's protection.

In what order should you set these up?

Set them up in order: SPF first, then DKIM, then DMARC. DMARC depends on the other two working, so it goes last.

1. SPF — publish the record listing every service that sends mail for you.
2. DKIM — enable signing in your provider and publish the public key.
3. DMARC — once SPF and DKIM pass, add a DMARC policy, starting at p=none to monitor, then tightening to p=quarantine and eventually p=reject.

Get the order wrong — DMARC set to reject before SPF and DKIM are solid — and you can block your own legitimate mail. That's why the sequence matters.

Get it done right

Email authentication is unforgiving: one wrong character in a DNS record, or one forgotten sending service, and your mail silently starts failing. It's also invisible — you don't find out until a customer says "I never got your invoice." This is exactly the kind of infrastructure we set up and monitor so it just works.

This is one piece of the bigger picture — your domain, DNS, and hosting all have to be configured correctly together. For how those fit, read Domain and Hosting, Demystified. And if you'd rather have it handled end to end, our managed email, domain, and hosting service is at solutions.anth.tech.

Want us to audit your email deliverability and fix what's broken? Book a call →