Why are my emails going to spam?

Your reply rates fell off a cliff. Or a tool flashed a red warning that you're landing in spam. Or a client said they never got the email you know you sent. So you rewrote the subject line, cut the links, removed the word "free," and nothing changed.

That's the tell. When copy tweaks don't move the needle, the problem isn't the copy. It's underneath it, in the part nobody shows you: whether the receiving server can prove your mail is really from you. Let's walk through what's actually happening, in plain terms, so you can find your specific problem instead of guessing.

And take a breath while you read. This is one of the most common problems in email, it's almost always fixable, and it's rarely your fault. It's usually a setting nobody ever told you existed, doing exactly what it was configured to do, quietly, in the dark, for months.

The short version

Mailbox providers (Gmail, Outlook, Yahoo) decide where your mail goes based on two things: can they verify who sent it, and do they trust that sender. Most spam problems are the first one. Your domain isn't proving its identity correctly, so the provider filters you for a technical reason that has nothing to do with what you wrote.

The identity check runs on three records that live in your domain's DNS: SPF, DKIM, and DMARC. When they're set up correctly and they line up, you pass. When they're missing, misconfigured, or (the sneaky one) present but not aligned, you fail, and failing mail gets filtered. The good news is that this half is fixable with precision. The reputation half is slower, but you usually don't have a reputation problem until the authentication is right.

First, rule out the obvious

Authentication is the usual culprit, but be honest with yourself about a few things first, because no DNS fix saves you from these:

• You're emailing people who never asked to hear from you, badly. High bounce rates and spam complaints tank you fast. If your list is scraped junk, fix that before anything else.
• You're sending from a free address. Sending business mail from a gmail.com or outlook.com address through a third-party tool is a near-guaranteed spam ticket. You need to send from your own domain.
• You ramped volume overnight. A brand-new domain blasting hundreds of cold emails on day one looks exactly like a spammer, because that's what spammers do.

If none of those obviously apply, and especially if your mail used to land fine and suddenly stopped, it's almost certainly authentication. Keep reading.

The real reason: broken authentication

Three records do the identity work. You don't need to become an expert, but you need to know what each one is for, because your problem is usually in one specific place.

SPF: who's allowed to send

SPF is a list, published in your DNS, of the servers allowed to send mail for your domain. When a receiver gets your email, it checks whether the sending server is on the list. There are two traps here. First, you can only have one SPF record per domain. People add a second one and quietly break the first. Second, SPF has a hard limit of ten DNS lookups. Every email tool you authorize ("include" in SPF terms) eats into that budget, and if you chain enough of them, SPF silently fails for everyone, even though the record looks fine to the naked eye.

DKIM: cryptographic proof it's really you

DKIM adds a tamper-proof signature to every message you send, using a private key. The matching public key sits in your DNS. The receiver checks the signature against the key, and if it matches, the message is provably yours and provably unaltered. The catch most people miss: every separate sending service needs its own DKIM key. Your main mailbox, your marketing platform, your CRM, your invoicing tool, your outbound sequencer. Forget to set up DKIM for one of them, and that one source starts failing while everything else looks fine.

DMARC: the policy that ties it together

DMARC is the instruction you publish that says "if a message claiming to be from my domain fails the checks, here's what to do with it." It has three levels: monitor (watch and report, change nothing), quarantine (send failures to spam), and reject (block them outright). DMARC is also what generates the reports that tell you which of your sending sources are passing and which are failing. Without it, you're flying blind.

The one that fools everyone: alignment

This is the concept that separates people who actually fix deliverability from people who paste records and hope. Stay with me, because this is probably your problem.

For DMARC to pass, it isn't enough for SPF or DKIM to pass. The passing record has to align with the domain your recipient actually sees in the "From" field. If your email shows as from you@yourcompany.com, but the authentication checks pass for some other domain (say, the shared domain of the email tool you're sending through), then SPF and DKIM technically "pass," but DMARC fails, because nothing lines up with the visible From.

All three records present. Still filtered.

This is why "I set up DMARC and it didn't fix anything" is one of the most common stories in this whole field. The records were there. The alignment wasn't. Fixing alignment usually means configuring each sending tool to send as your domain (an authenticated or custom sending domain) rather than as theirs. Once it's aligned, the same checks flip to pass and your mail starts landing.

What changed in 2024

If your mail used to limp along and then fell apart, this is likely why. In February 2024, Google and Yahoo started requiring authentication from bulk senders instead of merely preferring it. If you send roughly 5,000 messages a day or more to Gmail, you now must have SPF, DKIM, and a DMARC policy in place, offer one-click unsubscribe, and keep your spam complaint rate low. Microsoft has since rolled out similar requirements for high-volume Outlook senders.

The practical effect: setups that were technically broken but tolerated for years stopped being tolerated. The providers drew a line, and a lot of senders who never touched their DNS suddenly found themselves on the wrong side of it, with no explanation beyond a bounce code that tells you nothing and somehow still manages to feel personal. If your problems started around then, you weren't doing anything new. The rules changed under you.

Why it broke all of a sudden

"It was fine, then it wasn't" almost always traces to one of a handful of specific events. Run down this list and something will probably click:

• You added a new sending tool and never set up DKIM for it. The new source fails while your old ones pass, so only some of your mail lands and it feels random.
• You crossed the SPF ten-lookup limit. One too many tools authorized, and SPF tips into failure for everything at once. Nothing visibly changed in the record, which is what makes it maddening.
• You migrated email providers (say, to Google Workspace or Microsoft 365) and the old authentication records didn't get cleaned up or the new ones didn't get added.
• Someone "helpfully" added a second SPF record, which invalidates SPF entirely.
• You hit the 2024 enforcement line because your volume grew, and a setup that skated by under the old rules now gets blocked.
• Your domain reputation took a hit from a bad campaign, a spam-trap hit, or a spike in complaints. This one is reputation, not authentication, and it's the one a DNS fix won't solve on its own.

How to diagnose it yourself

You can get a real read on your own setup in about fifteen minutes, for free, and none of these steps touch anything that can break your mail. You're only reading, not changing. The quickest version is to run your domain through our free authentication check, which reads your live SPF and DMARC in a few seconds and tells you what's broken in plain English. If you'd rather do it by hand, here's the order I'd go in:

1. Read your own headers. Send yourself an email from your normal setup. In Gmail, open it, click the three dots, and choose "Show original." You'll see three lines: spf, dkim, and dmarc, each marked pass or fail. This tells you instantly which of the three is broken.
2. Run a lookup. Put your domain into a free checker like mxtoolbox.com and run the SPF and DMARC lookups. It'll show you whether the records exist, whether you have more than one SPF record, and whether you've blown the ten-lookup limit.
3. Set up DMARC reporting. If you don't have a DMARC record yet, publish one in monitor mode (the safe setting that changes nothing) with a reporting address. Within a day or two you'll start getting reports showing every source sending as your domain and whether each one passes. This is how you find the forgotten tool.

Between the headers and the reports, you'll usually find your exact problem. The headers tell you what's failing. The reports tell you which source is failing, which is the half that actually lets you fix it.

How to fix it (and where people hurt themselves)

The fix follows the diagnosis. Publish a correct single SPF record within the lookup limit. Set up DKIM for every sending source, not just your main one. Get each tool aligned to your own From domain. Then, and only then, tighten your DMARC policy from monitor toward enforcement so the providers see you taking responsibility for your domain.

None of this is secret, and if you're technical and patient, you can absolutely do it yourself. Most people don't, for the same reasons every time: the alignment piece is fiddly to diagnose, it's easy to miss a sending source you forgot you had, and the enforcement step carries real risk if you rush it. Learning DNS live on your own revenue-generating pipeline is a stressful place to learn it.

One last thing worth saying plainly, because plenty of services won't: fixing authentication gets your mail eligible to land. It does not guarantee the inbox, because that also depends on your reputation and how people engage with your mail, and no honest provider controls that. But authentication is the foundation, and a broken foundation is the reason most senders are in spam. Get that right first. Everything else is built on top of it.