Deliverability

Why Are My Emails Going to Spam? 12 Reasons and How to Fix Them (2026)

Opens drop, replies disappear, and then a customer mentions your last three emails were in spam. Here are the 12 causes, how to identify which one applies to you, and what to fix first.

By Sangeeth · August 2026 · 20 min read

It usually starts quietly. Opens drop, replies dry up, and then a customer mentions they found your last three emails in spam. As far as you know, nothing changed.

The spam folder feels arbitrary when this happens, but receiving mail servers are not making random decisions. They weigh authentication, reputation, recipient behaviour, sending patterns, list quality and message structure, and most deliverability problems come down to three questions:

The technical bar has also gone up. Gmail's sender requirements have applied since February 1, 2024. Senders delivering more than 5,000 messages per day to personal Gmail accounts face additional requirements including SPF and DKIM, DMARC, alignment and one-click unsubscribe for marketing and subscribed messages. Gmail says enforcement against non-compliant traffic has been ramping up since November 2025. (Google Help) Microsoft also requires SPF, DKIM and DMARC for domains sending more than 5,000 messages per day to its Outlook.com consumer service. (Microsoft)

Authentication alone still won't get you into the inbox. A perfectly authenticated sender lands in spam all the time when recipients don't want the mail. This guide walks through 12 common causes, how to work out which one applies to you, and what to fix, in that order.

First, diagnose why your emails are going to spam

The instinctive reaction to a deliverability problem is to change everything at once:

• edit SPF;
• regenerate DKIM;
• rewrite the template;
• remove links;
• change the From address;
• reduce sending;
• clean the list.

If the problem then goes away, you have no idea which change fixed it, and you'll be guessing again next time. Start with four checks instead.

Check 1: Determine whether the problem is provider-specific

Send a representative message to test addresses you control at Gmail, Outlook.com, Yahoo and a business Microsoft 365 mailbox, then compare where it lands.

This is not a real deliverability test, since a handful of seed addresses can't reproduce the reputation you have with thousands of real recipients. What it does tell you is whether you're facing an obvious infrastructure failure or something that depends on recipient history.

Check 2: Read the authentication headers

Don't trust a dashboard that says:

What counts is the receiving server's verdict. In Gmail, open the received message, choose Show original, and look at Authentication-Results. A healthy result looks like this:

Authentication-Results: mx.google.com;
   dkim=pass header.i=@news.example.com;
   spf=pass smtp.mailfrom=bounce@news.example.com;
   dmarc=pass header.from=example.com

Now compare this one, which catches a lot of senders out:

Authentication-Results: mx.google.com;
   dkim=pass header.i=@mailer.provider.net;
   spf=pass smtp.mailfrom=bounce@mailer.provider.net;
   dmarc=fail header.from=example.com

SPF passed and DKIM passed, yet DMARC failed. Both checks authenticated provider.net, while the recipient sees example.com in the From header. That is a DMARC alignment problem, covered in reason 2 below.

Check 3: Check Google Postmaster Tools

Google Postmaster Tools reports on mail you send to Gmail users, including user-reported spam rate, domain reputation, IP reputation, authentication and delivery errors. Register your sending domain before you have a serious incident; history is far more useful than monitoring you switch on after the damage is done.

Google currently advises senders to keep their Postmaster Tools spam rate below 0.10% and avoid ever reaching 0.30% or higher. (Google Help)

Check 4: Compare your recent sends

Line up your last several campaigns and record, for each:

• messages sent;
• hard bounces;
• soft bounces;
• complaints;
• unsubscribes;
• recipient segment;
• sending domain;
• From address;
• sending volume.

Then look for what changed immediately before placement got worse. You imported an old list, doubled campaign volume, had a new application start sending through the same domain, or one segment generated most of the complaints. Any of those is a far better lead than whether your subject line contained the word "free."

Gmail, Yahoo and Microsoft sender requirements in 2026

Provider requirements are a baseline, not a promise of inbox placement. For Gmail, all senders to personal Gmail accounts must meet requirements such as SPF or DKIM authentication, valid forward and reverse DNS, TLS and RFC 5322 formatting. Senders above Gmail's bulk-sender threshold also need:

• SPF and DKIM;
• DMARC;
• From-domain alignment with SPF or DKIM;
• one-click unsubscribe for marketing and subscribed messages;
• a visible unsubscribe link;
• maintaining acceptable spam rates.

Google defines a bulk sender as one sending close to 5,000 or more messages to personal Gmail accounts within 24 hours, counted across the same primary domain. Once Google classifies a sender as a bulk sender, its FAQ says that status does not expire. (Google Help)

Microsoft applies SPF, DKIM and DMARC requirements to domains sending more than 5,000 messages per day to Outlook.com consumer domains such as Outlook.com, Hotmail.com and Live.com. (Microsoft) Yahoo publishes comparable authentication, unsubscribe and sender-quality expectations. (Yahoo Sender Hub)

1. Your SPF, DKIM or DMARC is not actually passing

"We configured authentication" and "receivers successfully authenticate our mail" are different statements. DNS errors can sit unnoticed for months.

Common SPF problems

Multiple SPF records

A domain should not publish separate SPF policies like:

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

and:

v=spf1 include:example-email-service.com ~all

If both services legitimately send for the domain, their mechanisms belong in a single record:

v=spf1 include:_spf.google.com include:example-email-service.com ~all

The exact record depends on your actual providers, so check which services really send on behalf of your domain before copying any SPF example into production.

SPF lookup limits

SPF evaluation has a limit on DNS-querying mechanisms, and nested include: statements count toward it. A short-looking record can blow through the limit because one included provider includes several others. Remove obsolete sending services instead of piling on new includes.

Common DKIM problems

DKIM failures usually come from:

• publishing the record under the wrong selector;
• accidentally publishing it under the root domain;
• malformed public keys;
• DNS interfaces splitting or modifying long TXT values;
• configuring one sending subdomain but sending from another.

A selector is queried at a name like the one below, and the selector must match the one your sending provider actually uses:

selector1._domainkey.example.com

Common DMARC problems

DMARC normally lives at:

_dmarc.example.com

A monitoring policy looks like:

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

p=none tells receivers not to quarantine or reject mail solely because it fails DMARC policy enforcement, while still allowing reporting. Don't copy p=reject from a tutorial until you have identified every legitimate system that sends mail for your domain.

Troubleshooting authentication

Query your records independently:

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com

Then send a real message and inspect Authentication-Results. Published DNS is step one; passing at the receiver is the real test. For a record-by-record walkthrough, see our guide to SPF, DKIM and DMARC.

2. Your From domain is not aligned

DMARC doesn't just ask whether SPF or DKIM passed. It asks whether an authenticated domain aligns with the domain the recipient sees. Consider:

From:        hello@example.com
Return-Path: bounce@mailer.provider.net
DKIM d=:     mailer.provider.net

The receiver could produce:

SPF:   pass for provider.net
DKIM:  pass for provider.net
DMARC: fail for example.com

Everything looks authenticated until you check alignment.

How to fix DMARC alignment

Authenticate a domain you control with your sending platform. Depending on the platform, that involves some combination of:

• DKIM CNAME or TXT records;
• a custom MAIL FROM domain;
• a custom return-path subdomain;
• domain verification records.

A typical setup might use:

From:        newsletter@example.com
DKIM d=:     example.com
Return-Path: bounce.mail.example.com

Exact values depend on your provider. You don't need every domain string to be identical, because DMARC supports organizational-domain alignment. What you need is for at least one authenticated identifier, SPF or DKIM, to align with the visible From domain.

A common mistake: sending bulk mail as a free Gmail address

Don't configure a bulk email platform to send marketing mail with:

From: businessname@gmail.com

You don't control gmail.com, so you can't publish the authentication records that would make that domain yours. Use a domain you own.

3. Your domain or IP reputation is poor

Authentication establishes identity. Reputation answers a different question: what has mail from this sender historically looked like? You can have perfect SPF, DKIM and DMARC and still go to spam. Google Postmaster Tools exposes domain and IP reputation information for qualifying Gmail traffic, which is the closest thing to a direct reading you will get. Signals that damage reputation include:

• recipient complaints;
• persistent delivery to invalid addresses;
• abrupt volume changes;
• unwanted mail;
• poor engagement patterns;
• suspicious link domains;
• reputation problems associated with sending infrastructure.

How to recover

Redesigning your template over and over won't fix a reputation problem. Instead:

1. reduce sending to your most clearly engaged recipients;
2. suppress known bad addresses;
3. investigate complaint sources;
4. stop questionable acquisition sources;
5. maintain predictable volume;
6. give reputation time to recover.

Reputation is historical. A DNS fix takes effect within minutes of propagating; repairing reputation takes much longer because receivers need to see new sending history.

Do not rotate domains to escape reputation problems

A new domain doesn't have good reputation, it has little or no history. Pushing large volumes from a fresh domain creates a second deliverability problem and leaves the original cause untouched. Fix the underlying behaviour first.

4. You increased sending volume too quickly

Mailbox providers watch sending patterns. A domain that normally sends 500 messages a day and suddenly sends 50,000 has changed in a way they will notice. No universal warming schedule guarantees inbox placement, because the right ramp depends on:

• previous domain history;
• IP history;
• recipient engagement;
• provider distribution;
• list quality;
• complaint behaviour;
• whether infrastructure is shared or dedicated.

That is why rigid tables like "send exactly 500 on day one and 1,000 on day two" shouldn't be treated as standards.

A better ramp strategy

Start with your strongest audience and widen from there:

Move to the next stage only while delivery indicators stay healthy. If complaints or delivery errors get worse, hold or cut volume rather than pressing on with the schedule. Treat warming as feedback-controlled sending, not a calendar exercise: the question isn't "what day of the warm-up are we on?" but "what happened when we sent the last batch?"

5. Recipients are marking your email as spam

Authentication proves who sent the message. It says nothing about whether recipients wanted it.

Google recommends keeping user-reported spam rates in Postmaster Tools below 0.10% and avoiding 0.30% or higher. (Google Help) In absolute terms those numbers are surprisingly small. The arithmetic below is illustration, not an industry benchmark:

20 complaints / 20,000 delivered messages = 0.10%
60 complaints / 20,000 delivered messages = 0.30%

Why people report legitimate companies as spam

Usually because:

• they do not remember subscribing;
• the sender increased frequency;
• the message is unrelated to what they signed up for;
• unsubscribing is difficult;
• an old customer list was turned into a newsletter list;
• the sender waited months before sending the first campaign.

The Spam button is one tap away. Your unsubscribe process needs to be at least as easy.

How to reduce complaints

• Set expectations during signup.
• Make the sender identity recognizable.
• Avoid surprising frequency changes.
• Segment by subscriber interest.
• Stop repeatedly emailing chronically disengaged contacts.
• Make unsubscribe obvious and functional.

Don't hide the unsubscribe link out of fear of losing subscribers.

6. Your email list is old or low quality

Lists decay on their own. Addresses disappear, employees leave companies, domains expire, people abandon personal accounts and subscribers forget why they signed up. A list collected years ago shouldn't get the same campaign as someone who subscribed yesterday.

Segment by engagement and provenance

Rather than treating every contact the same, store something like:

{
  "email": "alex@example.com",
  "source": "newsletter_form",
  "subscribed_at": "2025-09-12T14:32:00Z",
  "last_engaged_at": "2026-07-28T09:15:00Z",
  "status": "subscribed"
}

Then segment on both how the address was acquired and how recently the subscriber engaged.

Avoid purchased and scraped lists

Buying addresses solves the wrong problem: you get the contacts without the relationship that made them worth having. It also raises your exposure to:

• complaints;
• invalid addresses;
• spam traps;
• poor engagement;
• legal and policy problems.

An address being publicly visible doesn't mean its owner subscribed to your marketing.

7. You are emailing people who did not expect your messages

Consent is not just a database field; expectation matters too. Someone who bought a product, downloaded a PDF, registered for an event, created an account or contacted support gave you their address for a specific purpose. That doesn't mean they expect every kind of marketing campaign you'd like to send.

Make signup expectations explicit

A good signup form says what the visitor will get and how often:

That is much clearer than:

Then send the first message while the subscriber still remembers signing up. Our welcome sequence playbook covers what that first series should contain.

Consider double opt-in

With double opt-in:

1. a visitor enters their email;
2. you send a confirmation message;
3. they click the confirmation link;
4. only then does the address become an active subscriber.

A simplified backend flow:

def signup(email):
    subscriber = create_pending_subscriber(email)
    send_confirmation(subscriber)

def confirm(token):
    subscriber = get_subscriber_by_token(token)
    subscriber.status = "subscribed"
    subscriber.confirmed_at = now()
    subscriber.save()

Double opt-in cuts down on typo addresses and bot submissions, and it gives you a stronger record that the mailbox owner confirmed the subscription.

8. You keep sending to bouncing addresses

Bounce processing belongs in your sending infrastructure, not in a monthly spreadsheet task. A permanent bounce means the message cannot be delivered to that address, and continuing to send to known hard bounces is pointless and harmful.

Amazon SES provides suppression functionality for bounced and complained addresses, and AWS advises removing addresses associated with hard-bounce suppression unless you have good reason to believe they are valid. (AWS Documentation)

Basic suppression logic

def process_bounce(event):
    if event.bounce_type == "Permanent":
        suppress(
            email=event.email,
            reason="hard_bounce"
        )

def process_complaint(event):
    suppress(
        email=event.email,
        reason="complaint"
    )

Don't treat every soft bounce as permanent. A temporary failure could be a full mailbox, greylisting, a temporary server problem or rate limiting, so base your retry strategy on the actual SMTP response and the address's failure history.

The re-import bug

This one turns up again and again in email systems:

1. recipient hard-bounces;
2. system suppresses them;
3. marketer imports an old CSV;
4. contact is recreated as active;
5. system sends to them again.

The fix is to check suppression at send time:

if suppression_exists(recipient.email):
    skip_send(recipient)
else:
    queue_email(recipient)

Suppression should be the final guard before sending, not just an attribute on whatever list is current.

9. Your email or links look suspicious

Spam filtering is far more sophisticated than a list of forbidden words. The word "free" won't send an email to spam on its own; structural patterns matter much more.

Avoid unnecessary redirect chains

Instead of:

email
  -> generic-shortener.example
  -> tracking-provider.example
  -> yoursite.example

aim for a cleaner path:

email
  -> links.example.com
  -> yoursite.example

A custom tracking domain also gives you control over the domain that appears in your links.

Avoid image-only emails

A campaign that is basically one big image is fragile beyond spam filtering: with images disabled, there's almost nothing left to read. Use real HTML text and descriptive alt text.

Send multipart email

A normal marketing message can contain both plain text and HTML:

Content-Type: multipart/alternative

--boundary
Content-Type: text/plain; charset=UTF-8

Your plain-text version.

--boundary
Content-Type: text/html; charset=UTF-8

<html>
  <body>
    <p>Your HTML version.</p>
  </body>
</html>

Your email platform builds the MIME boundaries for you. Your job is to provide a sensible plain-text alternative; don't hand-build MIME unless you run the sending layer yourself. (Our plain text vs HTML guide goes deeper on this.)

Avoid deceptive content

Your From name, subject and content should describe what the message actually is. Don't fake reply prefixes, account warnings or personal conversations to trick someone into opening a marketing email. You might get a click, but the negative recipient behaviour that follows is exactly what hurts you. Deceptive subject lines are also a compliance problem: the FTC applies a primary-purpose test to the content of a message rather than the label the sender attaches to it. (FTC)

10. Your unsubscribe implementation is broken

For qualifying bulk marketing and subscribed mail, Gmail requires one-click unsubscribe, and that is not the same as putting the word "Unsubscribe" at the bottom of the HTML. RFC 8058 defines one-click unsubscribe using headers such as:

List-Unsubscribe: <https://example.com/unsubscribe/abc123>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The HTTPS endpoint needs to process the provider's POST request. (RFC 8058) A simplified endpoint:

@router.post("/unsubscribe/{token}")
def one_click_unsubscribe(request, token: str):
    subscriber = find_by_unsubscribe_token(token)

    if subscriber:
        subscriber.status = "unsubscribed"
        subscriber.save()

    return 200

A production version also needs secure, unguessable tokens and idempotent processing.

Common one-click unsubscribe mistakes

Mistake 1: Only accepting GET. The mailbox provider performs the one-click action using POST.

Mistake 2: Requiring login. Nobody should need to remember an account password just to stop marketing mail.

Mistake 3: Requiring another confirmation. Don't turn "unsubscribe" into a multi-step retention funnel.

Mistake 4: Expiring unsubscribe tokens too aggressively. People unsubscribe from old messages too.

Mistake 5: Only unsubscribing from the current campaign. Suppression should match what the recipient asked to leave. If they opted out of all marketing, another list must not quietly reactivate them.

None of this replaces the visible unsubscribe link in the message body. Keep that as well.

11. You mix transactional and marketing email

Your password-reset email and your Black Friday campaign have very different risk profiles, and there's no reason to make one depend on the other's reputation. A common architecture:

example.com
├── Human/company mail
│
├── news.example.com
│   └── Marketing campaigns
│
└── notify.example.com
    └── Receipts, password resets and account notifications

Separating streams like this helps isolate traffic and makes monitoring clearer. Subdomains aren't magic, though. Each one still needs authentication, alignment, bounce processing, sensible volume and good recipient behaviour, and depending on how a provider aggregates reputation, the organizational domain's reputation can still count.

Keep transactional messages transactional

A password reset should help someone reset their password; an order receipt should describe their order. Stuffing promotional content into operational mail blurs its purpose and creates compliance and deliverability complications you don't need. Keep the streams separate in purpose as well as in infrastructure. The same applies to commercial mail triggered by store events such as abandoned cart emails: a shopping trigger doesn't make a promotional message transactional.

12. You are not monitoring deliverability

The worst time to set up deliverability monitoring is after customers start asking where your emails went. Do it while everything is healthy.

Google Postmaster Tools

Watch the spam rate, domain reputation, IP reputation, authentication, delivery errors and compliance status it reports.

DMARC aggregate reporting

A basic monitoring record might include:

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

Aggregate reports regularly turn up sending systems nobody remembered. Marketing authenticates the newsletter platform, while the CRM, helpdesk, invoicing system, recruitment platform or an old application server keeps sending as the same organizational domain. DMARC reporting is how you build the inventory.

Do not jump straight to p=reject

Going straight from no DMARC to the record below can block legitimate mail from senders you haven't found yet:

v=DMARC1; p=reject

A safer sequence:

1. publish DMARC reporting;
2. collect reports;
3. inventory legitimate sources;
4. authenticate them;
5. verify alignment;
6. gradually tighten policy where appropriate.

Common mistakes that put legitimate email in spam

The same handful of mistakes show up across all 12 causes.

Trusting the sending platform instead of the receiver

"Domain verified" doesn't tell you what Gmail saw on a specific message. Read the headers.

Fixing five things simultaneously

You lose the ability to identify the root cause. Change one meaningful variable at a time.

Treating every deliverability problem as content

Changing "FREE" to "special offer" will not repair failed DMARC or a damaged reputation.

Treating authentication as a guarantee

SPF, DKIM and DMARC are prerequisites for trustworthy sending. They don't force Gmail, Yahoo or Outlook to put your email in the inbox.

Continuing to mail unengaged recipients forever

List size is a vanity metric if much of the list no longer wants the mail. If you are judging recovery by opens, compare against realistic open rate benchmarks rather than your best month ever.

Hiding unsubscribe

You aren't preventing churn. You're pushing recipients toward the Spam button.

Ignoring SMTP response codes

The receiving server often tells you exactly what happened, so store the response. For example:

550 5.7.515 Access denied, sending domain does not meet
the required authentication level

That is far more actionable than a dashboard that just says "delivery failed."

Troubleshooting: diagnose email spam problems by symptom

A practical 7-step recovery plan

If your emails are already going to spam, resist the urge to blast another campaign just to see whether the problem fixed itself.

Step 1: Preserve evidence

Before changing anything, save raw message headers, SMTP responses, campaign metrics, sending volume, Postmaster Tools data and details of recent list imports.

Step 2: Verify authentication

Confirm the received message shows the result below, then confirm alignment:

SPF   = pass
DKIM  = pass
DMARC = pass

Step 3: Fix hard technical failures

Correct invalid SPF, broken DKIM, missing DMARC, alignment failures, DNS mistakes and any missing unsubscribe implementation.

Step 4: Clean sending eligibility

Immediately suppress permanent bounces, complaints and unsubscribed contacts. Then look at old and chronically disengaged segments separately.

Step 5: Identify the best audience

Don't test recovery on the riskiest part of your database. Start with recipients who clearly asked for your mail and have interacted with it recently.

Step 6: Resume conservatively

Increase volume based on feedback, not a predetermined daily multiplier.

Step 7: Monitor every meaningful send

Compare complaints, bounces, provider responses, Postmaster Tools data and segment-level performance after each send. Recovery is a process, not a DNS toggle.

Email deliverability best practices checklist

Before your next major campaign, verify:

• SPF is published correctly.
• Only one valid SPF policy exists for the hostname being evaluated.
• SPF does not exceed its DNS lookup limit.
• DKIM passes on actual received messages.
• DMARC exists.
• SPF or DKIM aligns with the From domain.
• You send marketing mail from a domain you control.
• Sending domains and IPs meet applicable forward and reverse DNS requirements.
• TLS is used for transmission.
• Marketing and transactional traffic are appropriately separated.
• One-click unsubscribe is implemented where required.
• A visible unsubscribe option exists in marketing messages.
• Permanent bounces are suppressed.
• Complaints are suppressed.
• Unsubscribes are enforced at send time.
• Old CSV imports cannot bypass suppression.
• You know how each audience was acquired.
• Purchased and scraped lists are not used.
• Sending volume changes are controlled.
• Links use domains you trust.
• Messages contain a usable plain-text alternative.
• Google Postmaster Tools is configured where applicable.
• DMARC reports are reviewed.
• SMTP rejection details are stored for troubleshooting.

Where SendDoggie fits

A good email platform should take repetitive infrastructure work off your plate without pretending software can manufacture sender reputation. SendDoggie combines marketing campaigns and transactional email with domain authentication, contact management, segmentation, campaign analytics, SMTP sending and an email API. Bounce and complaint feedback is handled inside the sending workflow, rather than left for marketers to clean up manually months later.

The split of responsibility matters. A sending platform can help you configure infrastructure, manage contacts, process sending events and surface campaign data. It cannot make recipients want an email they never asked for. Good deliverability still depends on:

• legitimate audience acquisition;
• useful messages;
• reasonable frequency;
• list hygiene;
• respecting unsubscribes;
• responding to negative signals quickly.

That is why deliverability is an operational system, not a score attached to a single campaign.

Conclusion

When emails start going to spam, the fastest way back is rarely a new subject line. Start lower in the stack, with what the receiving server actually saw. Did SPF, DKIM and DMARC pass, and did the authenticated domains align with the visible From domain?

If authentication is healthy, work upward: reputation, complaints, list quality, sending volume, bounce processing and unsubscribe behaviour.

You need all three working together.

Key takeaways

Sources

1. Google — Email sender guidelines
2. Google — Email sender guidelines FAQ
3. Google Postmaster Tools
4. Yahoo Sender Hub — Sender requirements and best practices
5. Microsoft — Outlook requirements for high-volume senders
6. RFC 7208 — Sender Policy Framework (SPF)
7. RFC 6376 — DomainKeys Identified Mail (DKIM)
8. RFC 7489 — DMARC
9. RFC 8058 — One-Click Unsubscribe
10. Amazon SES — Suppression list documentation
11. FTC — CAN-SPAM Act Compliance Guide for Business