Why Are My Emails Going to Spam? The Six Real Causes (and How to Fix Each)

You send a quote. Nothing comes back. Four days later you ring the client and they say, slightly embarrassed, that they found it in junk.

Nothing bounced. No error. No warning in your email settings. That is the awkward part of email filtering — it is silent by design, and you usually find out from a customer rather than from your software.

The cause is almost never what people assume. It is rarely your subject line or the word “free”. In most cases it is one of three DNS records that are missing, wrong, or quietly broken by a change you made months ago.

What Gmail is actually checking

When a message arrives, the receiving server asks three questions, and all three are answered by DNS records you publish. None of them require special software and all are free.

SPF: is this server allowed to send as you?

SPF is a public list of the servers permitted to send email using your domain. It lives as a TXT record on the domain itself and looks like this:

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

Each include: adds a service. The ending matters: -all tells receivers to reject anything from a server not on the list, while ~all is a softer “accept but be suspicious”.

DKIM: was the message signed by you, and unaltered?

Your mail server signs every outgoing message with a private key. The matching public key sits in your DNS. Receivers verify the signature to confirm the message genuinely came from you and nothing was changed in transit. Unlike SPF, DKIM survives forwarding, which is why a message passed through a mailing list can still be trusted.

DMARC: what should happen when those fail?

DMARC is the policy. It sits at _dmarc.yourdomain.com and tells receivers whether to do nothing, send failures to spam, or refuse them outright. It also carries a reporting address, which is how you find out who is sending mail using your domain — including anyone spoofing it.

The six things that actually cause it

1. No SPF record at all

The most common problem on small-business domains, and the easiest to fix. Without one, receivers have nothing to check against, and Gmail now treats that as a strong negative signal rather than a neutral one. Add a TXT record naming your email provider and you have solved the biggest part of it in five minutes.

2. More than one SPF record

This one catches people out because it looks careful. You add a second SPF record for a new tool instead of editing the first. Two records is not twice the coverage — the specification says a domain must have exactly one, and two makes SPF fail completely. Merge them into a single record with both include: entries.

3. SPF has quietly exceeded ten lookups

This is the one almost nobody finds on their own, and it is worth understanding properly.

SPF permits a maximum of ten DNS-querying mechanisms across your entire record. That counts not just your own include: entries but everything those includes pull in behind the scenes. Your provider’s single include: might cost three lookups on its own.

It breaks gradually. You start with two services and plenty of headroom. Over a year you add a CRM, an invoicing tool, a help desk and a newsletter platform. One day you cross ten, and SPF does not degrade politely — it becomes invalid, and receivers treat it as failing. Your record still looks perfectly reasonable in your DNS panel.

The only way to spot it is to follow the whole chain and count, which is exactly what our checker does. If you are at nine or ten, remove an include: for something you no longer use, or flatten the largest one into IP ranges.

4. DKIM was never set up, or was lost in a migration

Plenty of providers do not enable DKIM by default; you have to switch it on and paste a key into DNS. It also goes missing during host migrations, when records are copied by hand and the long DKIM key is skipped.

DKIM is awkward to check because it lives at a name only your provider knows — a “selector” — and there is no way to list them. That is why some checkers report “no DKIM” for domains that have it perfectly configured, and why ours reads your MX records first to work out who runs your mail before deciding.

5. DMARC stuck on p=none

p=none collects reports and blocks nothing. It is the right place to start and a poor place to stay, yet most domains that have DMARC at all have been sitting on it for years. You get the visibility without any of the protection, and anyone can still send mail pretending to be you.

The path is: start at p=none with a rua= address, read the reports until every legitimate sender passes, then move to p=quarantine, then p=reject. Skipping to reject before reading the reports is the standard way to accidentally block your own invoicing system.

6. Your sending IP is on a blocklist

Less common, but absolute when it happens. Usually it follows a compromised mailbox being used to send spam, or a shared hosting IP where a neighbour misbehaved. Each blocklist has a removal process, but fix the underlying cause first or you will simply be relisted.

Notes for specific setups

The three records are the same everywhere, but where you find them and what goes wrong differs by provider. These are the ones that come up most.

Google Workspace

SPF is straightforward — include:_spf.google.com — but DKIM is off by default and surprises a lot of people. You have to generate the key in the Admin console under Apps → Google Workspace → Gmail → Authenticate email, publish it in DNS, and then come back and press “Start authentication”. Generating the key without that last step is the usual half-finished state.

Microsoft 365 and Outlook

Microsoft publishes DKIM keys for you, but signing is often disabled until you enable it per-domain in the Defender portal. The two CNAMEs it expects are selector1._domainkey and selector2._domainkey — and because they are CNAMEs pointing at Microsoft rather than TXT records, some DNS panels reject them if you paste a trailing dot. Outlook is also noticeably stricter than Gmail, so a domain can look fine in testing and still be filtered there.

GoDaddy, Hostinger, Namecheap and other shared hosts

These usually set up a workable SPF when you buy email, and the trouble starts when you add a second sending service. Their DNS panels frequently let you create a second SPF record without warning, which silently breaks SPF altogether. If you have email with the host and send newsletters through anything else, check that you have exactly one SPF record containing both.

Mail from your website’s contact form

A common blind spot. Form submissions are usually sent by the web server using PHP’s mail function, not by your email provider — so they come from a server that is not in your SPF and carries no DKIM signature. The right fix is not to add the web server to SPF but to send through your provider’s SMTP, so form mail is signed exactly like everything else.

Newsletter and transactional platforms

Mailchimp, Brevo, SendGrid and the rest each want their own DNS entries, and each adds to your SPF lookup count. This is the single most common route to the ten-lookup problem above. Add them deliberately, and remove the ones you have stopped using.

What does not matter nearly as much as people think

A lot of deliverability advice is folklore. These get far more attention than they deserve:

• Spam-trigger words. Modern filters are not running a list of forbidden words. Writing “free” in a properly authenticated message from a domain with a good history is fine.
• Unsubscribe links in one-to-one mail. Required for bulk sending, irrelevant for a quote sent to one person.
• Excessive formatting. Worth a little, long after authentication. A plain-text email from a domain with no SPF still goes to spam.

The ordering matters because people spend days rewriting subject lines while the actual cause sits in a DNS record they have never looked at.

A sensible order to work through

1. Check the three records. Fix anything failing before looking at anything else.
2. Make sure the From domain matches what you authenticated. Sending as [email protected] while only mail.company.com is authorised is a common, invisible mismatch.
3. Wait, then re-check. DNS changes usually appear within minutes but can take up to 48 hours. Re-run the check rather than assuming.
4. Warm up gradually. A domain that has never sent email and suddenly sends four hundred messages looks exactly like a spammer, even with perfect records.
5. Only then look at content. By this point it is usually the smallest factor.

How to tell whether it worked

Re-run the check and confirm every line passes. Then send a message to an address at a different provider from your own — if you use Google Workspace, test against Outlook — and look at the message headers for spf=pass, dkim=pass and dmarc=pass. In Gmail, open the message, choose “Show original”, and all three appear at the top.

Three passes means the mechanical part is correct. Anything still landing in spam after that is reputation or content, which is a slower, more gradual problem — but a much better one to have, because it improves with every message that gets read instead of deleted.