Why Are Business Emails Going to Spam? SPF, DKIM and DMARC

You sent a quote to a client. You replied to an important inquiry. But the reply never comes — because your email quietly landed in their spam folder. For a small business, that's not a minor annoyance; it's lost revenue.

The frustrating part? Most business emails go to spam for technical reasons you can fix once, in about an hour. The single most common cause is missing email authentication — three DNS records called SPF, DKIM, and DMARC. This guide explains what they are in plain English, how to check whether you have them, and how to set them up without breaking your mail.

The Quick Answer: Missing Email Authentication Is the #1 Cause

Before a mailbox provider (Gmail, Outlook, Yahoo) delivers your email to the inbox, it runs a background check on your message. It asks three questions:

1. Did this message come from a server my domain allows? (SPF)
2. Does it carry my domain's unforgeable signature? (DKIM)
3. Does my domain have a policy for what to do when checks fail? (DMARC)

If your domain publishes none of these records, the provider has no way to verify your email is legitimate. Your message looks exactly like the phishing emails it's trying to block — so it gets treated like one.

Google and Yahoo's 2024 rules — and Microsoft's 2025 ones

This isn't theoretical. Since February 2024, Google and Yahoo require SPF, DKIM, and DMARC for bulk senders (anyone sending 5,000+ messages a day to their users), and at least SPF or DKIM for everyone else. Microsoft introduced similar requirements for high-volume senders to Outlook and Hotmail in 2025. Missing records can now mean outright rejection — not just the spam folder, but the message never arriving at all.

Even if you send far fewer than 5,000 emails a day, having all three records is the baseline every business domain should meet. It costs nothing and takes under an hour.

SPF, DKIM and DMARC in Plain English

Think of these three like the ID checks at an airport — each verifies something different, and together they prove you're really you.

SPF — "These servers are allowed to send for my domain"

SPF (Sender Policy Framework) is a DNS record that lists every server authorized to send email on behalf of your domain. When a receiving server gets your message, it looks up your SPF record and checks: did this email come from one of the approved servers?

A typical SPF record looks like this:

`` v=spf1 include:_spf.google.com ~all ``

This says: "Google's mail servers may send for my domain; anything else should be treated with suspicion." The ending matters:

• ~all (soft fail) — "probably not authorized, but let it through anyway." Good for testing.
• -all (hard fail) — "not authorized — reject it." The strict option, recommended once you're sure your list of senders is complete.

One hard rule: only one SPF record per domain. Publishing two breaks the check entirely — receivers don't know which one to trust.

DKIM — a tamper-proof signature on every message

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email, like a wax seal on a letter. The receiving server verifies the signature against a public key published in your DNS. If the message was altered in transit (a classic phishing trick), the signature won't match and the check fails.

Unlike SPF, DKIM survives forwarding — which is why providers increasingly treat DKIM as the more reliable signal of the two.

DMARC — the policy that ties SPF and DKIM together

DMARC (Domain-based Message Authentication, Reporting & Conformance) does two things SPF and DKIM can't do alone:

1. Alignment check — it verifies that the domain in the visible "From" address matches the domain that passed SPF or DKIM. This defeats the common spoofing trick where the envelope says one thing and the From line says another.
2. Policy — it tells receivers what to do with messages that fail: p=none (do nothing, just report), p=quarantine (send to spam), or p=reject (block entirely). It also tells them where to send you reports about who's sending as your domain — including attackers.

A starter DMARC record:

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

The safe path is always: start at p=none (monitoring), read the reports, then tighten to quarantine, then reject.

How to Check Whether Your Domain Has SPF, DKIM and DMARC

The 30-second test: inspect a received email's headers

Send yourself an email from your business address to a Gmail account, then:

1. Open the message → click the three dots → "Show original."
2. Look for the Authentication-Results section. You'll see lines like:

`` spf=pass dkim=pass dmarc=pass ``

If any say fail, none, or are missing entirely, you've found your problem.

Checking your DNS records directly

You can also query your domain's DNS:

• SPF: look for a TXT record on your root domain starting with v=spf1
• DKIM: look for a TXT record on a selector subdomain (e.g. google._domainkey.yourdomain.com) — the exact name depends on your email provider
• DMARC: look for a TXT record on _dmarc.yourdomain.com starting with v=DMARC1

Free tools like MXToolbox's SPF/DKIM/DMARC checkers let you type your domain and see all three at a glance — no command line needed.

The 7 Most Common Reasons Business Emails Land in Spam

1. No SPF record (or a broken one)

The single most common cause. Many businesses set up their domain and email years ago, when nobody checked SPF. If you have no record — or two records, or one that doesn't include your actual mail server — receivers can't verify you.

Fix: publish one SPF record listing every service that sends as your domain (your mail host, your website's contact form, your newsletter tool).

2. No DKIM signing

Even with SPF, many setups skip DKIM. Since DKIM survives forwarding and provides the strongest signal to modern filters, missing DKIM alone can tip borderline messages into spam.

Fix: enable DKIM in your email provider's admin panel (Google Workspace, Microsoft 365, and most hosts have a one-click setup), then publish the DNS records they give you.

3. No DMARC record — no policy, no reports

Without DMARC, receivers make their own guess about your failed messages, and you get zero visibility into who's abusing your domain. Attackers can spoof your domain freely and you'll never know.

Fix: publish a DMARC record at p=none with a reporting address. You'll start getting aggregate reports showing every server sending as your domain — legitimate and otherwise.

4. Damaged sender reputation (bounces, complaints, blacklists)

Mailbox providers score your domain and sending IP based on history. What damages it:

• High bounce rates (sending to dead addresses)
• Spam complaints from recipients
• Hitting spam-trap addresses
• Appearing on public blacklists (Spamhaus, Barracuda)

Fix: clean your list, remove bounced addresses, never buy email lists, and check your domain/IP against blacklist checkers.

5. Sending from a shared or brand-new IP with no history

Small businesses often send from shared hosting IPs — if a "neighbor" on the same IP spams, your mail suffers too. Brand-new domains and IPs also start with zero reputation; a sudden blast of hundreds of emails from a fresh domain looks exactly like a spam operation.

Fix: warm up gradually — start with small volumes to engaged recipients and ramp up over weeks.

6. Content and link patterns that look like phishing

Content matters less than authentication, but it still counts: excessive images with little text, misleading subject lines, URL shorteners (beloved by phishers), broken HTML, and deceptive "re:" or "fwd:" subject lines all raise the spam score.

Fix: write plain, honest subject lines; use your real domain in links (not shorteners); keep a healthy text-to-image ratio.

7. Missing unsubscribe link / high complaint rate (newsletters)

For marketing mail, Gmail and Yahoo now require one-click unsubscribe honored within two days, and they want complaint rates below 0.3% (ideally under 0.1%). Ignore this and even authenticated mail gets filtered.

Fix: add one-click unsubscribe to every bulk email and make unsubscribing easier than clicking "spam."

Setting Up SPF, DKIM and DMARC: The Safe Order

Do these in order — each step builds on the last, and the cautious progression means you never break working mail.

Step 1 — Publish SPF with a soft fail (~all) first

List every sender you know about (your mail host, website forms, newsletter service) and end the record with ~all. Soft fail means receivers will note failures but still deliver — so nothing breaks while you discover senders you forgot.

Step 2 — Enable DKIM signing

Turn on DKIM in your email provider's admin console and publish the DNS records they provide. Verify with a test email (the header check above) that dkim=pass appears.

Step 3 — Publish DMARC at p=none and read the reports

Add the _dmarc TXT record with p=none and a rua= reporting address. For a week or two, read the aggregate reports: they'll show every source sending as your domain. Add any legitimate senders you missed to your SPF record.

Step 4 — Tighten to quarantine, then reject

Once reports show only senders you recognize, move DMARC to p=quarantine (failures go to spam), and finally p=reject (failures are blocked). At this point, nobody can spoof your domain — and your legitimate mail gets maximum trust.

Common Misconfigurations That Break Authentication

More than one SPF record

DNS allows only one SPF TXT record per domain. A second one — often left behind when switching providers — invalidates both. If you change mail providers, replace the SPF record, don't add another.

An SPF record that doesn't include all your senders

The classic: SPF covers your mail host but not your website's contact form, your CRM, or your newsletter tool. Every one of those sends "as" your domain and fails SPF. Audit every service that sends email for you and include them all (via include: mechanisms).

DMARC alignment failures

DMARC requires the domain that passed SPF or DKIM to align with the domain in the visible From address. A common failure: your envelope-from is mail.yourdomain.com but your From line says yourdomain.com, with DMARC in strict alignment mode. Most setups should use relaxed alignment (aspf=r; adkim=r) unless you have a reason for strict.

Forgetting subdomains

Each subdomain needs its own consideration. Undefined subdomains get no SPF protection by default — DMARC at the organizational domain level covers them, which is another reason to publish DMARC even if you think you "don't send email" from those subdomains. Attackers love unprotected subdomains.

Frequently Asked Questions

I set up SPF, DKIM and DMARC — will my emails stop going to spam immediately?

Authentication is the foundation, not the whole house. With all three passing, you've removed the biggest technical barrier — but sender reputation, list quality, and engagement still matter. If your domain was previously flagged, it can take days to weeks of clean sending for reputation to recover. Think of authentication as necessary but not sufficient.

Do I need all three, or is SPF enough?

You need all three. SPF alone breaks on forwarded mail (the forwarding server isn't in your SPF record), and it doesn't cover the visible From address. DKIM survives forwarding and provides the stronger signal; DMARC ties them together and gives you a policy plus reporting. Google and Yahoo's 2024 bulk-sender rules require all three together.

Will SPF, DKIM and DMARC stop phishing emails pretending to be from my domain?

With DMARC at p=reject, yes — that's exactly what it's designed for. Receivers will block any message claiming to be from your domain that fails authentication. At p=none, you only get reports; the protection kicks in at quarantine and is complete at reject.

How long does it take for DNS changes to take effect?

Usually 30 minutes to a few hours, depending on your DNS provider and the TTL (time-to-live) on the records. Some resolvers cache longer — allow up to 24–48 hours before concluding a change "didn't work." You can lower TTLs before making changes to speed up future updates.

My emails go to spam only at Outlook/Hotmail, not Gmail. Why?

Different providers weigh signals differently, and Microsoft has its own reputation system (SNDS — Smart Network Data Services). Outlook-specific issues often trace to IP reputation or Microsoft's own bulk-sender requirements introduced in 2025. Check your IP/domain reputation in Microsoft's SNDS portal and ensure you meet their authentication requirements.

Can I check someone else's domain to see if they have SPF, DKIM and DMARC?

Yes — these are public DNS records. Free tools (MXToolbox, DMARC analyzers, or a simple dig/nslookup) let you look up any domain's records. It's a quick way to audit a client's setup or verify your own work from an outside perspective.

Tired of the spam folder? Start with the 30-second header check above — it tells you in under a minute whether authentication is your problem. If SPF, DKIM, or DMARC is missing, work through the setup order in this guide; most businesses go from zero to fully authenticated in a single afternoon. And if you're just getting your domain set up, our domain registration guide covers getting your DNS foundation right from day one.