Why Are My Emails Going to Spam? How to Fix It

When your emails land in the recipient’s spam folder, the receiving mail server has made a judgement: it could not confirm the message really came from you, or it did not trust the domain or server that sent it. Content matters much less than people assume. The overwhelming majority of deliverability problems for small businesses and agencies are caused by missing authentication records, a blacklisted domain or IP, or a sending setup that changed without anyone updating DNS.

That is good news, because those are fixable in an afternoon, and they are checkable from the outside.

This guide is for people sending from their own domain — invoices, client email, contact-form notifications, newsletters. If you are a recipient trying to rescue a sender’s mail from your spam folder, mark it Not spam and add the address to your contacts; the rest of this page is for the sender.

Start with the evidence: read the headers

Send a message to a Gmail address you control, open it from the spam folder, and choose ⋮ → Show original. Gmail prints a summary at the top:

SPF:   PASS with IP 203.0.113.10
DKIM:  'PASS' with domain example.com
DMARC: 'PASS'

Anything other than three passes is your first fix. Outlook and other providers show the same results in the Authentication-Results header.

The checks receivers run

Check	What it proves	What failure looks like	Where to fix it
SPF	The sending server is allowed to send for your domain	SPF: FAIL or SOFTFAIL, or “no SPF record”	A TXT record at the domain root
DKIM	The message was signed by your domain and not altered	DKIM: FAIL or no signature	A TXT record at selector._domainkey
DMARC	SPF or DKIM aligns with the visible From: domain, and what to do if not	DMARC: FAIL, or no policy	A TXT record at _dmarc
Blacklists	The domain and sending IP have not been reported for abuse	Listed on Spamhaus, SpamCop, Barracuda, or SURBL	Clean up the cause, then request delisting
Reverse DNS	The sending IP has a matching hostname	Missing PTR record on your mail server	Your mail host or VPS provider

SPF: list every service that sends as you

An SPF record is a single TXT record at your domain root naming the servers allowed to send mail for it:

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

The failures are predictable:

• A sender is missing. You added a newsletter tool, a CRM, a helpdesk, or a website contact-form service, and nobody added its include: to SPF. Mail from that service fails SPF.
• There are two SPF records. Only one is allowed. Two records is a permanent error (PermError), and receivers treat it as no SPF at all. Merge them into one.
• Too many DNS lookups. SPF allows at most ten DNS lookups in total, including nested include:s. Stacking services quietly crosses the limit and breaks SPF for everything.

DKIM: sign with your own domain

DKIM adds a cryptographic signature to each message; receivers verify it against a public key you publish in DNS. Every major provider — Google Workspace, Microsoft 365, Zoho, and every serious sending service — supports it, but many do not switch it on until you add the record and click Start authentication.

If you send through several services, each one needs its own DKIM record with its own selector. A missing selector for one service means its mail is unsigned.

DMARC: tie it together and get reports

DMARC checks that SPF or DKIM passed for the same domain the recipient sees in the From: line, and tells receivers what to do when they do not. Since 2024, Google and Yahoo require a DMARC record from anyone sending in volume, and it helps everyone else too.

Start in monitoring mode:

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Read the aggregate reports for a couple of weeks to find senders you forgot, fix their SPF and DKIM, then tighten the policy to p=quarantine and eventually p=reject. Jumping straight to reject blocks your own legitimate mail from services you did not know about.

Blacklists: find out whether you are listed

If authentication passes and mail still lands in spam — or bounces with a message mentioning Spamhaus, SpamCop, or Barracuda — your domain or sending IP may be on a DNS blocklist. The common causes are a compromised mailbox or website form sending spam, a shared IP from a cheap host where another customer misbehaved, or a newsletter sent to an old, purchased, or scraped list.

Fix the cause first, then use each list’s own removal process. Requesting delisting while the compromised account is still sending gets the listing reinstated.

Other reasons mail goes to spam

Once authentication and reputation are clean, the remaining factors are behavioural:

1. Sending from a brand-new domain or IP at high volume. Warm up gradually.
2. Low engagement. If recipients never open your mail, or mark it as spam, providers learn to file it there. Remove addresses that have not engaged in months.
3. Missing unsubscribe. Bulk and marketing mail needs a working one-click unsubscribe.
4. Misleading or image-only content, URL shorteners, and links to domains with a bad reputation.
5. The From: domain does not match the sending service and there is no DMARC alignment — common with website contact forms that send “from” the visitor’s address.

How to stop emails going to spam in Gmail and Outlook

As the sender: make sure SPF, DKIM, and DMARC all pass, confirm you are not blacklisted, and ask regular correspondents to add you to their contacts.

As the recipient: open the message in the spam folder and mark it Not spam (Gmail) or Not junk (Outlook), add the sender to your contacts or Safe Senders list, and in Gmail create a filter for the address with Never send it to Spam ticked.

Why this breaks without anyone noticing

Email authentication is DNS, and DNS changes. A migration to a new host, a new marketing tool, a registrar change, or a well-meaning cleanup of “unused” records can remove an SPF include or a DKIM key. Nothing visibly breaks — the website still loads — but mail from that day onwards starts landing in spam, and the first sign is a client asking why you never replied.

SitesRadar monitors SPF, DKIM, and DMARC records and checks your domain and mail servers against Spamhaus, SpamCop, Barracuda, and SURBL blocklists on every plan, including the free one, and alerts you when something changes. It sits alongside uptime, SSL, domain expiry, and DNS change detection — see DNS monitoring across client domains for the broader picture, and what happens when a domain expires for the most drastic way to lose your email.

FAQ

Why are my emails suddenly going to spam? Something changed: a new sending service was added without updating SPF or DKIM, a DNS record was removed during a migration, your domain or IP was blacklisted, or recipients started marking your mail as spam. Check the authentication results in a received message’s headers first.

How do I check if my domain is blacklisted? Look up your domain and your mail server’s IP addresses against the major DNS blocklists — Spamhaus, SpamCop, Barracuda, and SURBL. A monitoring tool can run those checks continuously.

Do I need SPF, DKIM, and DMARC? Yes. SPF and DKIM prove your mail is legitimate; DMARC ties them to your visible From: address. Google and Yahoo require all three for bulk senders, and they improve delivery for everyone.

Can I have two SPF records? No. Two SPF records cause a permanent error and receivers treat SPF as failed. Combine all senders into a single record.

Why do my contact form emails go to spam? Website forms often send “from” the visitor’s address through your web server, which is not authorised by the visitor’s domain and fails DMARC. Send from your own domain through an authenticated service, and put the visitor’s address in the Reply-To header instead.