Why are my emails going to spam?

Most emails go to spam for one of three reasons: the message fails authentication (SPF, DKIM or DMARC is missing, broken or not aligned with your From domain), the sending IP or domain has a poor reputation or is on a blocklist, or recipients complain about it. Content matters, but it is rarely the main cause. Diagnose in that order: authentication, then reputation, then complaints and list quality, then content.

Quick checklist

Work through these before changing a word of your copy:

1. SPF passes for the server that actually sends your mail, and your domain has only one SPF record.
2. DKIM signs with your domain (d=yourdomain.com), not your provider's.
3. DMARC passes: SPF or DKIM passes and that domain matches your From domain.
4. The sending IP has reverse DNS that resolves back to the same IP.
5. The IP and domain are not on a major blocklist, such as Spamhaus.
6. Complaints stay low: Gmail asks senders to keep spam reports below 0.1% and never reach 0.3%.
7. You only send to people who asked for the mail, and you stop sending to addresses that bounce.
8. Each message has a plain-text part, a real Message-ID and Date, and links on your own domain.

The fastest way to check most of this list at once is to send a real message to the free email spam test. Send it the way production mail goes out, from your app or provider, not typed by hand into a mail client.

1. Authentication: SPF, DKIM and DMARC

Mailbox providers check three DNS-based standards on every message:

• SPF (RFC 7208) lists the servers allowed to send for a domain. It checks the return-path (envelope sender) domain, not the From address people see.
• DKIM (RFC 6376) adds a signature to each message. The d= tag names the domain that signed it.
• DMARC (RFC 7489) ties them to the From address. It passes when SPF or DKIM passes for a domain that aligns with the From domain.

Alignment is where most setups break. A message from you@example.com sent through a provider that signs with its own domain and uses its own bounce address passes SPF and DKIM, but for the provider's domain, so DMARC fails.

You can see exactly what the receiver decided in the Authentication-Results header. In Gmail, open the message, click the three dots and choose Show original:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1 header.b=AbC123;
       spf=pass (google.com: domain of bounces@rp.example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounces@rp.example.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

All three say pass, and the DKIM domain and the SPF domain both belong to example.com, the From domain. Paste your own headers into the email header analyzer to read them without squinting.

Records for a typical setup look like this:

example.com.           TXT  "v=spf1 include:spf.yourprovider.example ~all"
s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
_dmarc.example.com.    TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Check yours with the SPF checker, DKIM checker and DMARC checker, or all at once with the deliverability checker. Two SPF problems come up often: publishing a second v=spf1 record instead of merging includes, and going over SPF's limit of 10 DNS lookups, which makes SPF return permerror.

If authentication is the problem, large providers will often tell you outright. Gmail rejects some unauthenticated mail with:

550-5.7.26 This mail has been blocked because the sender is unauthenticated.

Outlook.com rejects high-volume senders that fail its requirements with 550 5.7.515 Access denied, sending domain [example.com] does not meet the required authentication level.

2. Sender reputation and blocklists

Once authentication passes, providers judge whether your mail is wanted. Reputation attaches to your sending IP and, increasingly, to your domain.

Things that hurt it:

• A shared IP used by bad senders. If your provider puts you on the same IPs as someone sending unwanted mail, you share the consequences.
• A new domain or IP with no history, sending a large volume on day one. Ramp up gradually.
• Blocklist listings. Spamhaus, SpamCop and others list IPs and domains seen sending spam. Many receivers reject or filter mail from listed IPs. Check your sending IP and domain with the blocklist checker. If you don't know the IP, the spam test finds it for you, or read the first Received header in the original message.
• Missing or mismatched reverse DNS on the sending IP.

For Gmail, set up Google Postmaster Tools on your domain. It shows the spam rate Gmail users report, plus authentication pass rates, as Gmail sees them. Microsoft offers SNDS for IP data.

3. Complaints, bounces and list quality

The strongest signal a mailbox provider has is how its users react. Every "Report spam" click counts against you, and so does mail sent to addresses that don't exist.

• Remove hard bounces immediately. Repeatedly sending to unknown users looks like a bought or stale list.
• Don't send to people who didn't ask. Imported contact lists and old customer exports draw complaints.
• Make unsubscribing easy for anything that isn't strictly transactional. If people can't find the unsubscribe link, they press the spam button instead.
• Keep transactional and marketing mail apart. A newsletter that draws complaints should not drag down the IPs and domain your password resets use. A separate subdomain such as mail.example.com for transactional mail helps.

4. Bulk sender rules from Gmail, Yahoo and Microsoft

Since 2024, Gmail and Yahoo have required more from senders, and Outlook.com followed in 2025. For senders of around 5,000 or more messages a day to their users, the rules include:

• SPF and DKIM, plus a DMARC record (at least p=none) with the From domain aligned with SPF or DKIM
• One-click unsubscribe (RFC 8058) on marketing and subscribed mail
• A spam complaint rate below 0.3%, with Gmail recommending under 0.1%
• Valid forward and reverse DNS for sending IPs, and TLS for transmission

The details are in Google's sender guidelines, Yahoo's sender best practices and Microsoft's announcement for Outlook.com. Our guide to Google, Yahoo and Microsoft sender rules puts them side by side. Smaller senders aren't exempt in practice: unauthenticated mail is treated with suspicion at any volume.

5. Content

Content is the last thing to check, not the first. The issues that actually move filters are mostly technical:

• HTML with no plain-text alternative
• A message that is one large image with little text
• URL shorteners or links to domains with a bad reputation
• Missing Message-ID or Date headers, often from hand-rolled SMTP code
• Links whose visible text shows one domain and whose href goes to another

The spam test runs the message through a real spam filter and lists every rule that fired, with its weight and what to change.

How to diagnose it, step by step

1. Send a real message to the email spam test. You get a score out of 10 and a list of failures, with the most important first.
2. If authentication fails, check each record with the SPF, DKIM and DMARC checkers and fix alignment first. Our SPF, DKIM and DMARC guide walks through each record.
3. If the IP or domain is listed, look it up in the blocklist checker, fix what caused the listing, then request removal on the list's own site.
4. If everything passes but Gmail still filters you, check your spam rate in Google Postmaster Tools. A high rate means recipients don't want the mail, and no DNS change will fix that.
5. For one specific message that landed in spam, open the original, copy the headers and paste them into the header analyzer to see the receiver's own verdict.
6. Turn on DMARC reports so you find out when a service sending as your domain is failing. Free DMARC monitoring reads the reports for you.

How Groundmail helps

Groundmail sends transactional and product email from our own mail infrastructure. When you add a domain, we give you the exact SPF include, DKIM key and return-path record, and check them before the domain is verified. Every message is signed with your domain's DKIM key and uses a return path on your domain, so DMARC aligns from the first send. Transactional and product email go out on separate IPs, so a product email that draws complaints can't affect your sign-in codes. Hard bounces are suppressed automatically.

Start with the quickstart, and see the deliverability docs for how streams work.