Why Your Email Is Going to Spam — and How to Fix It

This is one of the most common support calls I handle. A business has set up SPF, thinks everything is fine, and then discovers their emails to certain recipients are consistently landing in junk. Or worse — they're not arriving at all. The frustrating thing is that SPF passing is just one piece of a much bigger picture, and on its own it means very little.

After dealing with email deliverability issues across hundreds of Microsoft 365 tenants over the years, I've seen the same root causes come up repeatedly. Here's what to actually check.

1. SPF Passes But DKIM Isn't Configured

This is the most common scenario I see. An IT team sets up SPF correctly — the record lists all the authorised sending IPs — but nobody has configured DKIM. Without a DKIM signature, the email has no cryptographic proof that the content hasn't been tampered with in transit. Modern spam filters, particularly Google's and Microsoft's, weight DKIM heavily. An email that passes SPF but has no DKIM signature gets a lower trust score than one that passes both.

In Microsoft 365, DKIM is not enabled by default. You have to go into the Defender portal, find the DKIM settings for each domain, and enable it. Once enabled, Microsoft generates two CNAME records you need to add to your DNS. Most people set this up once and forget about it — but if you've added new sending domains since your initial setup, they won't have DKIM configured.

2. DMARC Is Missing or Set to p=none

SPF and DKIM are the checks. DMARC is the policy that tells receiving mail servers what to do when those checks fail. Without DMARC, a server that receives an email failing SPF and DKIM has no guidance — it makes its own decision, which varies by provider and often results in inconsistent behaviour.

More importantly, DMARC with p=none does nothing to protect your domain from spoofing — it's monitoring mode only. Many organisations set it to p=none when they first configure it and never move it to quarantine or reject. The result is that anyone can send email appearing to come from your domain, and there's nothing stopping receiving servers from delivering it.

3. Third-Party Senders Not in SPF

Most businesses send email from more than one place — their mail server, a CRM like HubSpot or Salesforce, a marketing platform like Mailchimp, an invoicing tool, and so on. Every one of those platforms needs to be listed in your SPF record. If they're not, email they send on your behalf will fail SPF at the recipient's mail server.

The catch is that SPF has a hard limit of 10 DNS lookups. If your SPF record includes too many includes, it breaks entirely — not gracefully fails, but produces a permerror that causes deliverability problems across the board. I've seen this catch businesses out when they add a new sender platform without realising how close to the limit they already are.

4. Sending IP or Domain Reputation

Even with perfect SPF, DKIM and DMARC, emails can land in spam if the sending IP address has a poor reputation. This happens most often with shared email infrastructure — if you're on a shared IP range and another customer on that range has been sending spam, your IP reputation suffers by association.

Microsoft 365 uses dedicated IP ranges for business email, which generally have good reputations, but newly provisioned tenants or those with very low email volumes can sometimes end up on less reputable shared ranges initially. If you're sending from a third-party platform, check whether they offer dedicated IPs — worth the cost for high-volume sending.

5. Content and Engagement Signals

Spam filters don't just look at authentication — they analyse the email content itself. Links to domains with poor reputations, certain phrases historically associated with spam, high image-to-text ratios, and missing plain text versions of HTML emails all contribute to a higher spam score. If recipients consistently delete your emails without opening them, or mark them as spam, that engagement signal feeds back into how future emails are treated.

Where to Start

The quickest way to diagnose a deliverability problem is to look at the email headers of a message that landed in spam. The Authentication-Results header shows you exactly what SPF, DKIM and DMARC returned for that specific email. If SPF shows pass, DKIM shows pass, and DMARC shows pass, the issue is likely content or reputation rather than authentication. If any of those show fail, you have a clear starting point.

For checking your domain's DNS records — SPF, DKIM, DMARC and MX — without having to open a terminal, the Network Tools page queries them directly and shows you the current live values.