Why your email is going to spam — and how to fix it
When outbound email ends up in spam folders — or disappears completely — the cause is almost always one of four things: a broken authentication record, a misaligned DMARC policy, a blacklisted sending IP, or content filtering. Here’s how to work through each.
Check your authentication records first
Modern mail providers use three DNS-based standards to decide whether to trust your email.
SPF (Sender Policy Framework) lists which mail servers are allowed to send email on behalf of your domain. If your email comes from a server not in your SPF record — a new CRM, a transactional mail service, a cloud application added last year — receiving servers can mark it as suspicious or reject it.
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outbound mail. Receiving servers verify the signature against a public key in your DNS. If DKIM isn’t configured, or the signing key doesn’t match DNS, authentication fails.
DMARC ties these together and tells receiving servers what to do when SPF or DKIM fails — nothing (p=none), quarantine the message, or reject it. It also controls alignment: your From address domain must match the domain used by SPF or DKIM.
Check your domain’s SPF, DKIM and DMARC records →
The most common failures
SPF covers the wrong senders — or too many
If you’ve added cloud services over time without auditing your SPF record, it’s likely missing some senders. It may also be exceeding the 10-lookup limit. Every include: in your SPF triggers a DNS lookup, and the RFC hard-limits this at 10. Exceeding it causes some providers to treat your SPF as invalid — producing delivery failures that look completely random.
DKIM stops signing silently
DKIM failures rarely generate bounce messages. Mail continues delivering to many providers but authentication is failing. Common causes: DKIM was never set up, a Microsoft 365 licence change disabled it, or a DNS record was deleted during a migration. The only reliable way to detect this is DMARC aggregate reports, which show DKIM alignment pass/fail rates over time.
DMARC policy is p=none
A DMARC record with p=none is monitoring-only. It sends reports but does not affect mail delivery in any way. Many organisations set this up years ago and never progressed to p=quarantine or p=reject. The result is a DMARC record that looks like compliance without providing any actual protection or affecting deliverability.
Your sending IP is blacklisted
If your mail server’s outbound IP appears on a major blacklist — Spamhaus, SpamCop, Barracuda, UCEPROTECT — many providers will reject your mail at the SMTP connection level, before authentication is even checked. This typically causes hard delivery failures rather than spam-folder placement.
Check your IP or domain against 14 blacklists →
How to diagnose
- Run your domain through the Email Authentication Checker — it validates SPF, DKIM selectors and DMARC in seconds.
- Check your sending IP against the Blacklist Checker.
- If you have a DMARC record with
rua=set, review the reports and look at DKIM and SPF pass rates. - If you’re on Microsoft 365, check Exchange Admin Center → Policies & rules → DKIM to confirm signing is enabled for your domain.
What to fix first
No DMARC record: publish one at p=none with a reporting address immediately. The reports will show what’s failing before you enforce anything.
SPF missing senders: audit every cloud service that sends email on your behalf and update the record. If you’re over 10 lookups, restructure the record.
DKIM not signing: configure it on every sending platform. For Exchange Online this is done in the Exchange Admin Center — it is not automatic when you add a custom domain.
IP blacklisted: identify the cause (spam sent through your server, a compromised account, a shared IP), fix it, then request delisting through each blacklist’s process.
The Website Security Scanner runs all of these checks plus HTTP security headers in a single scan.
Need help with your email infrastructure?
Talk to an engineer