SPF, DKIM and DMARC: Why Your Email Lands in Spam

You send a newsletter to 2,000 subscribers. Open rates collapse. Nothing changed in the content, the subject line is fine, the list is clean. What changed is that somewhere between your server and the recipient’s inbox, a filter decided your mail was not worth trusting.

In almost every case we investigate, the cause is authentication. Not content, not spam words, not images — authentication. And it is one of the few problems in email marketing that has a definite, verifiable fix.

The Problem Email Was Built With

SMTP, the protocol that moves email, was designed in an era when everyone on the network was trusted. It has no built-in way to verify that a message claiming to come from your domain actually did. Anyone can write anything in the From field.

Three standards were layered on top to fix this. They are not alternatives — they work together, and each solves a different part of the problem.

SPF: Which Servers May Send for You

Sender Policy Framework is a DNS record listing the servers authorised to send mail using your domain. When a receiving server gets a message claiming to be from your domain, it looks up your SPF record and checks whether the sending server is on the list.

A record looks like this:

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

Reading it: SPF version 1; authorise Google Workspace; authorise SendGrid; authorise one specific IP; and ~all means anything else is a soft fail — accept but mark suspicious.

Two mistakes are extremely common. The first is having more than one SPF record. The specification allows exactly one; two records mean a permanent error and every message fails authentication. If you add a new provider, extend the existing record — never publish a second.

The second is the ten-lookup limit. Every include costs a DNS lookup, and nested includes count too. Exceed ten and the whole record fails. Sites that have accumulated five or six providers over the years frequently sit over the limit without knowing it.

DKIM: A Signature That Proves Nothing Was Altered

DomainKeys Identified Mail adds a cryptographic signature to each outgoing message. Your sending server signs with a private key; the receiving server fetches the matching public key from your DNS and verifies it.

DKIM proves two things SPF cannot: that the message genuinely originated from an authorised system, and that it was not modified in transit. It also survives forwarding, which SPF often does not — a significant advantage when recipients auto-forward to another address.

Your email provider generates the key pair and gives you a DNS record to publish, typically at selector._domainkey.yourdomain.com. Use a 2048-bit key where the provider supports it.

DMARC: Telling Receivers What to Do About Failures

SPF and DKIM detect problems. DMARC decides what happens next, and — just as valuable — reports back to you.

A starting record:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100

p=none means take no action, just report. This is where every domain should start. You will receive daily aggregate reports showing every source sending mail as your domain, including ones you have forgotten about — the old CRM, the invoicing system, the form handler on a legacy site.

Once the reports show only legitimate sources passing, tighten the policy:

Policy	Effect	When to use it
p=none	Monitor only, deliver normally	First four to eight weeks
p=quarantine	Failing mail goes to spam	Once legitimate sources all pass
p=reject	Failing mail is refused outright	When you are confident and want full protection

Moving straight to p=reject without a monitoring period is how companies accidentally block their own invoices. The reports exist precisely so you do not have to guess.

Alignment: The Detail That Trips Everyone

DMARC requires more than SPF or DKIM passing. It requires the passing domain to align with the domain in the visible From address.

This catches out anyone using a third-party sending service without configuring a custom domain. The mail passes SPF — against the provider’s domain, not yours. DMARC sees the mismatch and fails the message anyway.

The fix is to set up domain authentication inside the sending platform, which produces CNAME records that make the service sign as your domain. Every serious provider supports it. If yours does not, change provider.

What Changed in 2024 and Why It Still Matters

Google and Yahoo introduced requirements for bulk senders that made this non-optional. Anyone sending more than 5,000 messages a day to their users must have SPF, DKIM and DMARC in place, must keep spam complaints below 0.3 percent, and must offer one-click unsubscribe.

The practical effect reaches far beyond bulk senders. Filters across the industry now treat unauthenticated mail with more suspicion generally. A small business sending a few hundred messages a month is not formally covered by the rules but experiences the consequences of the shift.

The Things That Still Matter After Authentication

Authentication gets you considered. It does not get you delivered. Once the records are right:

• Warm up new sending domains gradually. A brand-new domain sending 5,000 messages on day one looks exactly like a spam operation.
• Remove addresses that bounce. High bounce rates damage reputation quickly, and reputation is slow to rebuild.
• Make unsubscribing trivial. A recipient who cannot find the link presses “report spam” instead, and that costs far more.
• Keep transactional and marketing mail on separate subdomains. A marketing campaign that draws complaints should not take your invoices down with it.
• Watch engagement. Sustained low open rates tell filters your mail is unwanted, whatever your authentication says.

A Verification Sequence That Takes Ten Minutes

1. Query your domain’s TXT records and confirm exactly one SPF record exists.
2. Count the DNS lookups it triggers; confirm the total is under ten.
3. Send a message to an account on a major provider and inspect the headers for spf=pass, dkim=pass and dmarc=pass.
4. Confirm the DKIM signing domain matches your From domain.
5. Publish DMARC at p=none with a reporting address and read the first week of reports.

Almost every deliverability problem we are asked to investigate is visible in those five steps.

Frequently Asked Questions

Can I have more than one SPF record?

No. The specification permits exactly one per domain. Two produce a permanent error and every message fails SPF. Merge all authorised senders into a single record.

Do I need DMARC if SPF and DKIM already pass?

Yes. Without DMARC, receivers have no instruction about what to do when authentication fails, and you get no visibility into who is sending as your domain. The reports alone justify it.

Why does my mail pass authentication and still go to spam?

Authentication proves identity, not welcomeness. If recipients delete without reading or mark as spam, filters respond to that regardless. Reputation and engagement sit on top of authentication.

Should I use a subdomain for marketing email?

For any meaningful volume, yes. Sending marketing from a subdomain isolates its reputation from your primary domain, so a campaign that performs badly does not affect business correspondence.

How long does it take to recover a damaged sending reputation?

Weeks to months, depending on severity. Recovery means consistent low-complaint sending over time. There is no faster route, which is why prevention matters so much more than repair.

Do these records affect a website at all?

No. They are DNS TXT records and have no effect on web hosting or site performance. They can be added without touching the site.

The Bottom Line

Email authentication is one of the few genuinely solvable problems in marketing. Three DNS records, configured once, verified once, and a category of failure disappears.

The work is not difficult but it is exacting — a single extra SPF record or one lookup too many and the whole thing silently fails. That is precisely why it is worth verifying rather than assuming.

If you would rather have it checked properly, our email marketing service begins with a full authentication audit, and our server administration team handles the DNS side. The DMARC.org overview and Google’s sender guidelines are the references we work from.