Why is my email going to spam even though your application reports it as sent? Usually, the receiving mailbox accepted the message but assigned it a low trust score based on authentication, sender reputation, recipient engagement, message content, and sending behavior.

A successful API response or SMTP 250 response means a receiving server accepted responsibility for the message. It does not guarantee inbox placement. Gmail, Yahoo Mail, Outlook, Apple Mail, and corporate gateways apply their own filtering after—or alongside—SMTP acceptance, and those systems can place a legitimate email in spam when enough risk signals accumulate.

First, distinguish spam placement from a delivery failure

Before changing DNS records or rewriting copy, identify what actually happened. “Email went to spam” can describe several very different outcomes, and each one has a different fix.

Accepted and delivered to spam

This is the classic inbox-placement problem. Your sending platform shows a successful handoff, the recipient can find the message in Spam or Junk, and there is no bounce. The recipient provider accepted the mail but judged it as unwanted, suspicious, or insufficiently trustworthy.

This is most often caused by a combination of weak authentication, poor reputation, low engagement, questionable list quality, or misleading message structure. It is rarely fixed by changing one word in the subject line.

Deferred or temporarily rejected

A temporary SMTP failure usually starts with 4xx, such as 421 4.7.0 or 450 4.2.0. These responses tell the sending system to retry later. A mailbox provider may defer mail because it wants to slow an unfamiliar sender down, because the sending IP has a poor recent reputation, because traffic volume changed abruptly, or because the recipient server is under load.

Deferrals are not spam-folder placement, but they can be an early warning. If a provider repeatedly defers your mail, review your authentication, bounce rate, complaint rate, and sending pattern before it becomes a permanent block.

Permanently rejected or bounced

Permanent failures usually start with 5xx. For example, 550 5.7.1 is commonly used for policy or security-related rejections, though the exact explanation in the enhanced status text matters more than the number alone. A response mentioning authentication, spam, a block list, sender policy, or an IP address points to a delivery rejection—not a message sitting in spam.

Keep the complete SMTP response or webhook event. Compare these examples:

250 2.0.0 OK: accepted; placement is still unknown.
421 4.7.0 Try again later: temporary deferral; retry behavior matters.
550 5.1.1 User unknown: invalid or nonexistent recipient.
550 5.7.1 Message rejected: policy, authentication, reputation, or recipient-side security rule may be involved.

A transactional email API or SMTP relay can show the handoff status, bounce response, and message events, but only recipient-side testing and header inspection can tell you whether an accepted message landed in the inbox or spam folder.

Why email filters put messages in spam

Spam filtering is not a single test. A mailbox provider evaluates many signals, assigns them different weights, and changes those weights over time. That is why two nearly identical emails can land differently at Gmail and Outlook, or why the same email can reach one recipient’s inbox and another recipient’s spam folder.

Identity and authentication signals

Receiving systems want evidence that the domain in the visible From: address authorized the email. They evaluate SPF, DKIM, and DMARC, plus related infrastructure signals such as reverse DNS, TLS, and consistent sending domains.

Authentication failures are especially harmful because they resemble spoofing. A message may still be delivered when authentication fails, but it begins with a substantial trust disadvantage.

Reputation signals

Mailbox providers develop reputations for domains, IP addresses, URLs, and message streams. A new sending IP is not automatically bad, but it has little history. A domain with high complaints, frequent bounces, sudden volume spikes, or inconsistent traffic will often receive more filtering scrutiny.

Reputation is also contextual. A provider may trust a domain’s password reset mail while filtering its promotional traffic if both are sent from the same poorly managed stream. Separating transactional and marketing mail can make reputation clearer and reduce collateral damage.

Recipient behavior and engagement

Mailbox providers observe what recipients do with mail. Positive signals can include opening, reading, replying, moving a message from spam to inbox, adding the sender to contacts, or repeatedly receiving and keeping similar messages. Negative signals can include spam complaints, deleting without reading, ignoring mail, or repeatedly receiving messages at addresses that never engage.

You cannot force engagement with technical configuration. The practical solution is to send expected mail, at an expected frequency, to people who asked for it or whose product activity clearly requires it.

Content, links, and message construction

Spam filters inspect message structure as well as words. A message can be technically authenticated and still be filtered if it has deceptive links, mismatched branding, a suspicious redirect chain, malformed HTML, an image-only body, link-shortener abuse, or language that resembles phishing.

Content is normally a contributing signal rather than the sole cause. Avoid treating “spam trigger words” lists as a serious deliverability strategy. A legitimate invoice email can safely contain words such as “payment” or “urgent”; a deceptive email cannot become trustworthy merely by avoiding those words.

Set up SPF correctly

Sender Policy Framework, or SPF, is a DNS TXT record that identifies which hosts are authorized to send mail using a domain in the SMTP envelope sender, also called the MAIL FROM or return-path domain. It is defined in RFC 7208.

SPF does not directly authenticate the visible From: address that recipients see. That distinction is important: SPF becomes useful for DMARC only when the SPF-authenticated return-path domain aligns with the visible From domain.

A valid SPF record example

Publish one TXT record at the root of the domain used for your envelope sender:

example.com. IN TXT "v=spf1 include:spf.email-provider.example -all"

The parts mean:

v=spf1 identifies the record as SPF version 1.
include:spf.email-provider.example authorizes the infrastructure named by that provider.
-all states that all other senders should fail SPF.

If you send from both a business mailbox service and a transactional provider, the record may need both authorized sources:

example.com. IN TXT "v=spf1 include:_spf.google.com include:spf.email-provider.example -all"

Use the exact include domain documented by each service. Do not guess it, and do not copy an include value from another provider’s documentation.

Common SPF mistakes

The most common error is publishing multiple SPF TXT records. RFC 7208 requires a receiver to treat multiple SPF records as a permanent error, often shown as permerror. Merge all legitimate mechanisms into one record instead.

Sign every message with DKIM

DomainKeys Identified Mail, or DKIM, attaches a cryptographic signature to an email. The receiving server retrieves a public key from DNS and checks that the signed portions of the message have not changed and that the signing domain authorized the key. DKIM is specified in RFC 6376.

Unlike SPF, DKIM can often survive normal message forwarding because the signature travels with the email. However, a mailing list or forwarding system can still break a signature if it modifies signed headers or the message body.

What a DKIM DNS record looks like

A DKIM public key is normally published at a selector-specific hostname:

s1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

The selector in this example is s1. Your outgoing message contains a corresponding header similar to:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; ...

The receiver combines s=s1 and d=example.com to query s1._domainkey.example.com.

DKIM configuration checks

Your email should normally show dkim=pass in an Authentication-Results: header at the receiving mailbox. The DKIM d= domain should be your own sending domain or a subdomain you control, not only a provider-owned domain.

For stronger DMARC alignment, sign with the exact From domain or an aligned subdomain. For example, a visible From: Billing <billing@example.com> can align with d=example.com under relaxed alignment. A signature from d=mailer.example.net does not align with example.com.

Rotate keys when your provider supports it, remove unused selectors after a safe transition period, and avoid manually altering message bodies after they are DKIM-signed. Changes to signed content—from a proxy, template layer, or link-tracking system—can invalidate signatures.

Use DMARC to connect identity to the visible From address

DMARC, or Domain-based Message Authentication, Reporting, and Conformance, tells receivers how to evaluate SPF and DKIM in relation to the visible From: domain. It also provides reporting options. DMARC is specified in RFC 7489.

A key point: DMARC passes when either SPF or DKIM passes and the passing identifier aligns with the visible From domain. You do not need both SPF and DKIM to pass DMARC in every individual message, but configuring both gives you redundancy and is expected by major mailbox providers for higher-volume sending.

Start with a monitoring policy

A practical initial DMARC record is:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100"

This record means:

v=DMARC1: DMARC record version.
p=none: request monitoring rather than quarantine or rejection.
rua=mailto:dmarc-reports@example.com: request aggregate XML reports.
adkim=r: relaxed DKIM alignment.
aspf=r: relaxed SPF alignment.
pct=100: apply the policy to all relevant mail.

The rua mailbox must be able to receive a large volume of XML reports. Many teams use a DMARC reporting service rather than manually reading compressed report attachments.

After you know every legitimate source passes aligned SPF or DKIM, consider a stronger policy:

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100"

Eventually, some organizations use p=reject. Do not move to enforcement simply because a checklist says to. First confirm that your support desk, invoicing tool, CRM, product mailer, help center, recruiting platform, and employee mailbox provider all authenticate properly.

Why DMARC can fail when SPF and DKIM look fine

The usual cause is alignment. Imagine these results:

From: updates@example.com
Return-Path: bounce@mailer.vendor.example
DKIM-Signature: d=mailer.vendor.example; s=send1
Authentication-Results: spf=pass; dkim=pass; dmarc=fail

SPF and DKIM can both pass for the vendor domain, but neither domain aligns with example.com in the visible From address. Configure custom return-path and DKIM signing domains where your provider supports them.

Google’s current sender guidelines require all senders to use SPF or DKIM, while senders that exceed 5,000 messages per day to Gmail accounts must use SPF, DKIM, and DMARC. Yahoo similarly emphasizes authentication and DMARC, especially for bulk senders. Treat these measures as a baseline for all production sending, not a threshold to postpone until you become large.

Check message headers instead of guessing

A spam-folder message contains the most useful diagnostic evidence. Send a test email to a controlled Gmail, Outlook.com, Yahoo Mail, or corporate mailbox, then view the full headers or original source.

Look for these fields:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounce.example.com;
       dkim=pass header.d=example.com;
       dmarc=pass header.from=example.com
Return-Path: <bounce@bounce.example.com>
From: Product Alerts <alerts@example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; ...

What to verify in the headers

Check the following in order:

SPF result: Look for spf=pass, then identify the smtp.mailfrom domain.
DKIM result: Look for dkim=pass, then identify the header.d signing domain.
DMARC result: Look for dmarc=pass and verify that it refers to the visible header.from domain.
Return-path: Confirm it is a domain you intentionally configured and can authenticate.
Received chain: Confirm the message was sent through your intended SMTP relay or email API provider, not an unexpected server.
TLS indicators: A Received: header may show encrypted transport information; major mailbox providers expect secure SMTP transport.

Do not diagnose deliverability from a screenshot of the message body alone. The headers tell you what the receiving system actually evaluated.

For a fast preflight, send a test to mail-tester.com and review its report. Use it to spot missing authentication, malformed HTML, broken links, and obvious infrastructure issues. It is a useful testing aid, not a simulation of every mailbox provider’s proprietary filtering system.

Reputation, volume, and sending patterns matter

Authentication establishes identity; it does not create a positive reputation by itself. A fully authenticated sender can still land in spam if recipients complain, addresses bounce, or sending behavior looks abnormal.

Keep transactional and marketing mail distinct

Transactional messages are triggered by a user action or necessary account event: password resets, login alerts, receipts, invoices, verification codes, and service notifications. Marketing messages promote products, content, or offers and generally require subscription management.

When possible, separate these streams by subdomain and operational purpose. For example:

alerts.example.com      password resets and account notifications
receipts.example.com    purchase receipts and invoices
news.example.com        opted-in newsletters and campaigns

This separation helps protect critical mail. A campaign with elevated complaints should not damage the reputation of password reset messages. It also makes DMARC reports, bounce analysis, and internal ownership clearer.

Avoid sudden volume jumps

A domain that normally sends 500 emails a day and abruptly sends 100,000 can trigger filtering even if every recipient is legitimate. Ramp volume in a controlled way when launching a new sender, moving providers, adding a new IP, or importing a previously inactive audience.

There is no universal daily warm-up schedule that fits every sender. The safe principle is consistency: begin with your most engaged recipients, increase gradually, monitor bounces and complaints, and pause expansion if results worsen.

Watch complaints and inactive recipients

A spam complaint is one of the strongest negative signals available to mailbox providers. Remove or suppress recipients who complain where feedback data is available. Do not keep sending because an address has not technically bounced.

Long-inactive addresses are also risky. They may have been abandoned, converted into spam traps, or simply belong to people who no longer recognize your brand. Re-engagement should be limited, clearly labeled, and followed by suppression of nonresponders rather than endless reminders.

Before a large campaign, validate imported or old addresses with an email address verification tool and retain the results in your suppression workflow. Verification reduces obvious delivery problems; it does not replace consent or make an unengaged list safe to mail.

Fix content and link signals without chasing myths

Message content affects filtering, but most deliverability problems are not solved by replacing “free” with “complimentary.” Focus on whether the message looks coherent, honest, and consistent with the domain that sent it.

Build a normal, readable email

A healthy email generally includes:

A recognizable From name and address.
A subject line that accurately describes the message.
Plain-text and HTML parts in a multipart alternative message.
A visible, working destination for each important link.
A branded domain for links where practical.
A valid physical or business identity where required for commercial mail.
A clear unsubscribe method for subscription and marketing mail.

Avoid image-only emails, giant embedded images, deceptive display text, invisible text, attachments you do not need, copied HTML from word processors, and malformed markup. Ensure links use HTTPS and that redirect domains are reputable and consistent with your brand.

Be careful with URL shorteners and tracking domains

A message from example.com that sends every link through an unrelated shortener or a newly created tracking domain can look suspicious. Configure a custom tracking domain when your sending platform supports one, and make sure it has valid DNS and TLS configuration.

Do not put raw IP addresses in links. Do not use misleading link text, such as showing https://example.com while linking to another domain. Those patterns resemble phishing and can trigger security scanners even in legitimate mail.

Include unsubscribe infrastructure for promotional mail

For marketing and subscription mail, use both a visible unsubscribe link and machine-readable headers. One-click unsubscribe implementations commonly use headers like:

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

The one-click behavior should unsubscribe the recipient without requiring a login, survey, or additional confirmation step. Do not add unsubscribe headers to a true password reset or receipt merely to imitate promotional mail requirements; classify messages accurately.

Maintain list hygiene and consent records

A clean technical setup cannot rescue a list that should not receive the message. List quality directly influences bounces, complaints, engagement, and ultimately reputation.

Use clear acquisition practices

Collect email addresses through explicit forms, account registration, checkout, event registration, or another understandable interaction. Explain what recipients will receive and how often, especially for newsletters and promotional sequences.

Avoid purchased lists, scraped addresses, pre-checked marketing consent boxes, and appending email addresses to a list based on third-party data. Even if an address is technically valid, the owner may not know your organization and may mark your first email as spam.

Handle bounces correctly

Separate bounces into categories. A permanent recipient failure such as 550 5.1.1 should normally result in immediate suppression. A temporary failure may be retried according to your provider’s retry logic, but repeated temporary failures should not be retried forever.

Store suppression decisions centrally. If your product sends through a REST API while a support tool or campaign platform sends through SMTP, every source must respect the same unsubscribe and hard-bounce suppression list.

Make expectations specific

“Sign up for updates” is vague. “Receive one product digest each Friday and occasional release announcements” creates a better expectation. Lower surprise usually means fewer complaints, and fewer complaints improve deliverability.

Use the right tools and data sources

Testing is most useful when it mirrors the mailbox providers that matter to your recipients. A single seed inbox cannot prove global inbox placement, but it can reveal broken authentication or obvious content problems.

Practical diagnostic toolkit

Use these tools and checks together:

Mail-tester.com: Send a test message to receive a report on authentication, formatting, links, and common configuration issues.
MXToolbox: Inspect SPF, DKIM, DMARC, MX, and block-list-related DNS diagnostics.
Google Postmaster Tools: Review domain reputation, spam rate, authentication, and delivery data for Gmail traffic when enough data is available.
DMARC aggregate reports: Identify every service sending as your domain and find alignment failures.
Your provider’s event webhooks or logs: Separate accepted, deferred, bounced, and complained messages by recipient domain and sending stream.
Raw message headers: Validate what the recipient provider actually saw.

If you send programmatically, keep a durable message ID that connects your application event, API request or SMTP submission, sending-provider event, and recipient response. That makes it possible to answer whether a specific password reset was generated, accepted by the relay, deferred, bounced, or delivered.

If you need implementation details for sending through a REST API or authenticated SMTP relay, consult the platform’s email API setup guides and confirm that the envelope sender, From domain, DKIM domain, and tracking domain are configured as intended.

A step-by-step recovery plan

When email is already landing in spam, do not change everything at once. A controlled recovery makes it possible to identify what improved results.

Pause risky campaigns. Stop sending to old imports, inactive subscribers, and addresses with repeated soft bounces.
Check DNS and authentication. Confirm exactly one SPF record, working DKIM signatures, and a valid DMARC record. Verify DMARC alignment in received headers.
Review the visible identity. Make the From name, From domain, reply-to address, links, and branding consistent.
Split message streams. Keep transactional, lifecycle, and promotional mail separated by subdomain or at least by clear operational segmentation.
Suppress bad recipients. Immediately suppress hard bounces and complaints; stop repeatedly mailing long-inactive addresses.
Send to engaged recipients first. Resume with recipients who recently opened, clicked, logged in, purchased, or otherwise interacted with your product.
Monitor by mailbox provider. Gmail, Outlook, Yahoo, and corporate domains may behave differently. Segment results rather than relying on a blended rate.
Change one variable at a time. If you change providers, templates, domains, list rules, and volume simultaneously, you will not know which action mattered.

Recovery is usually measured in days or weeks, not minutes. Reputation is based on patterns, so the remedy is sustained behavior: authenticated mail, stable volume, relevant messages, low complaints, and disciplined suppression.

When the problem is your provider—and when it is not

Email providers influence deliverability through their infrastructure, IP management, bounce processing, abuse controls, TLS configuration, and tools for domain authentication. A reputable provider can make correct sending easier, but it cannot make an unconsented list, deceptive content, or a high complaint rate deliver well.

If every message from a newly configured domain goes to spam across multiple recipient providers, start with your configuration: SPF, DKIM, DMARC alignment, return-path domain, link domain, and message headers. If only one provider rejects or filters mail while the rest accept it, inspect that provider’s exact response text and any available sender dashboards.

For shared-IP services, reputation is partly collective, so the provider should have active anti-abuse controls and traffic segmentation. But your domain reputation, recipient behavior, and message quality remain yours. For dedicated IP services, you gain more isolation but also take full responsibility for establishing and maintaining the IP’s reputation.

The short answer: earn trust at every layer

If you are asking why is my email going to spam, the answer is usually not “because of one spammy word.” It is because the recipient provider sees incomplete proof of identity, weak historical trust, unwanted-recipient signals, suspicious message construction, or some combination of those factors.

Start with authentication that passes and aligns. Then protect reputation with permission-based acquisition, bounce and complaint suppression, predictable sending volume, useful content, and separation between transactional and marketing streams. Finally, inspect real headers and provider events so you can diagnose evidence instead of guessing.

FAQ

Why does my email go to spam even though SPF, DKIM, and DMARC pass?

Authentication proves that the sender is authorized; it does not prove recipients want the message. High complaints, low engagement, poor list quality, unfamiliar sending patterns, suspicious links, or a weak domain reputation can still place authenticated email in spam.

Does an SMTP `250` response mean my email reached the inbox?

No. 250 means the receiving server accepted the message. It may later be routed to Inbox, Spam, Promotions, another filtered folder, or a downstream security system.

How long does it take to recover from spam-folder placement?

There is no fixed timeline. Technical fixes can take effect once DNS changes propagate, but sender reputation improves through consistent positive sending behavior over time. Expect to monitor results over days or weeks rather than after one test send.

Should I use `p=quarantine` or `p=reject` in DMARC immediately?

No. Begin with p=none while reviewing DMARC aggregate reports. Move to enforcement only after every legitimate sender—including third-party tools—passes aligned SPF or DKIM.

Can a transactional email be marked as spam?

Yes. Password resets, receipts, and verification emails can be filtered when authentication fails, the sender domain lacks trust, the recipient has marked similar mail as spam, or the message resembles phishing. Transactional purpose helps only when the message is expected and technically trustworthy.

Why Is My Email Going to Spam? Causes, Tests, and Fixes