Why are my emails going to spam when SPF, DKIM, and DMARC pass?

Your emails can go to spam even when SPF, DKIM, and DMARC all pass. Authentication proves who sent the message and whether the authenticated identity aligns with the visible From domain. It does not prove good domain or IP reputation, trustworthy tracking hosts, consistent SMTP identity, wanted content, or favorable recipient-side treatment.

Start with the message that actually landed in spam. Confirm its authentication results, identify every domain and IP the receiver saw, and compare the outcome across providers. Changing DNS again without that evidence can hide the real problem.

Why authenticated emails can still go to spam

SPF, DKIM, and DMARC answer identity questions:

Check	What a pass proves	What it does not prove
SPF	The connecting IP is authorized for the envelope sender domain	The visible From domain has a good reputation
DKIM	A signed part of the message survived verification	The signing domain is trusted or aligned with the visible From domain
DMARC	At least one authenticated identity passed and aligned	The message is wanted, safe, or likely to reach the inbox

A receiver makes a separate filtering decision after authentication. That decision can use reputation, complaint history, sending patterns, message format, links, content, recipient behavior, and local policy.

Google’s current sender guidelines reflect this separation. They cover authentication, forward and reverse DNS, TLS, message format, sending volume, spam rates, and domain and IP reputation. Passing one part does not satisfy every other part.

Check domain and IP reputation first

Authentication can be correct while the authenticated identity carries weak history.

Review:

• Domain age and recent sending history.
• Domain and sending-IP blacklist status.
• Shared-IP reputation when the provider controls egress.
• Complaint, bounce, and deferral trends by mailbox provider.
• Sudden changes in volume, cadence, audience, or message format.

Example: SPF, DKIM, and DMARC pass for mail.example.com, but the sending provider routes the campaign through a shared IP with poor reputation. The domain records need no further edit. The evidence to collect is the connecting IP, provider-specific SMTP responses, and reputation data available from the mailbox provider or sending service.

Google advises senders to raise volume gradually, avoid bursts, monitor server responses, and watch domain and IP reputation. Yahoo’s sender best practices also treat authentication, complaint control, unsubscribe handling, and sending practices as separate parts of sender health. Microsoft says its filtering considers IP and domain reputation, authentication, list accuracy, complaints, content, and other signals in its Outlook.com sender support guidance.

Use the domain reputation checker for observable age, blacklist, authentication, MX, and HTTPS signals. A public checker cannot see a mailbox provider’s complete private reputation model.

Inspect every tracking host in the sent message

The tracking domain shown in a sending platform is not always the only host present in the final message.

A real message can include:

• An open pixel on one host.
• Click redirects on another host.
• A branded CNAME that hands off to a shared provider hostname.
• Links added by a template, calendar tool, signature, or security scanner.

Example: links.example.com resolves correctly and serves a valid certificate. The sent .eml still contains a pixel on a different shared host. The configured CNAME passed, but the message surface contains an extra identity that deserves review.

Save one representative sent message as .eml. List the hostnames in its HTML, text, and headers. Compare them with the tracking domain approved for the campaign. Check unexpected hosts for DNS resolution, HTTPS validity, redirects, ownership, and public reputation evidence.

The tracking domain checker verifies CNAME, DNS, HTTPS, and redirect handoff for the host you enter. It cannot discover a second host unless you inspect the sent message.

Read message evidence beyond DNS

Public DNS tells you what could authenticate. A received message tells you what did authenticate.

Inspect these fields in the copy that reached the test mailbox:

• Authentication-Results for the receiver’s SPF, DKIM, and DMARC decisions.
• DKIM-Signature for the signing domain and selector.
• From, Return-Path, and the DKIM d= value for alignment.
• Received headers for the connecting path and handoffs.
• List-Unsubscribe and List-Unsubscribe-Post when they apply to the message type.
• Every visible link, redirect host, and tracking pixel.

Do not treat a DNS lookup as proof that a specific message used the expected selector, return path, or sending route. A provider dashboard can show a green record while the live message uses a different identity.

The receiver requirements guide explains which Gmail, Yahoo, and Microsoft checks can be supported by public DNS or pasted headers and which still require provider or message-level evidence.

Verify the SMTP identity receivers see

This step matters most for dedicated IPs, custom SMTP relays, and self-managed egress. Teams using a hosted mailbox provider often inherit its server identity.

For a custom sending path, compare:

1. The connecting IP address.
2. Its PTR or reverse DNS hostname.
3. The forward DNS result for that hostname.
4. The hostname announced in HELO or EHLO.
5. The live SMTP banner when the server exposes one.
6. The IP and domain reputation evidence tied to that path.

Example: the domain passes DMARC through aligned DKIM, but a custom relay announces a generic cloud hostname. Its PTR points somewhere else, and that hostname does not resolve back to the sending IP. Authentication passed at the message layer. The server identity is still inconsistent.

Google requires valid forward and reverse DNS for sending domains or IPs covered by its guidelines. The additional HELO and banner comparison helps an operator find contradictions in a custom SMTP path. It is evidence to review, not an inbox-placement prediction.

Use the PTR and rDNS checker for the public reverse and forward lookup. The SMTP egress checks guide covers the complete identity review.

Separate sender problems from recipient-side filtering

One failure pattern does not always describe the whole campaign.

Compare outcomes across:

• Gmail, Yahoo, Outlook.com, and corporate domains.
• Different corporate security gateways.
• Recipients inside and outside one company tenant.
• The same message with and without optional tracking.
• SMTP acceptance, spam placement, and outright rejection.

Example: test messages reach Gmail and Yahoo but go to junk for every recipient at one company. That pattern points toward the recipient domain’s gateway, tenant policy, blocklist, or user rules. It does not prove the sender is clean, but it narrows the next investigation.

Look at SMTP response codes first. A rejection or deferral is different from a message accepted and placed in spam. For accepted mail, use headers and provider-specific tools where available. Ask the recipient’s administrator for a message trace or quarantine reason when the problem is isolated to one organization.

Recipient-side evidence can explain a local outcome. It cannot be generalized into a promise about other recipients.

Troubleshoot spam placement in the right order

Use this sequence to avoid random DNS edits:

1. Preserve one failed example. Save the received message, full headers, timestamp, recipient provider, and SMTP response.
2. Verify the message, not only the domain. Confirm SPF, DKIM, DMARC, and alignment from Authentication-Results.
3. Map the scope. Record which providers, domains, and recipients show the same outcome.
4. Check reputation evidence. Review domain age, blacklist status, sending IP, complaints, bounces, deferrals, cadence, and volume changes.
5. Inspect the message surface. List tracking pixels, redirects, visible links, unsubscribe headers, and unexpected hosts.
6. Review custom SMTP identity. Compare PTR, forward DNS, HELO, banner, and the connecting IP when you control egress.
7. Review recipient-side policy. Investigate gateways, tenant rules, quarantine reasons, and user filters when the pattern is local.
8. Change one cause at a time. Rerun the infrastructure check, preserve the new evidence, and compare another representative sample.

Infrastructure QA should run before placement sampling so known setup failures do not distort the diagnosis. The seed-list testing comparison explains what each evidence class can and cannot answer.

What a free deliverability checker can prove

The free email deliverability checker can expose observable problems across MX, SPF, DKIM when a selector is provided, DMARC, blacklist status, domain age, tracking-domain routing, and SMTP egress identity.

A passing result means those checks did not expose a known infrastructure blocker for the tested inputs at that time. It does not reveal every private reputation score, complaint signal, message classification, corporate gateway rule, or recipient preference. It does not guarantee inbox placement.

Use the result to remove fixable infrastructure uncertainty. Then combine it with a real message, SMTP responses, provider evidence, and recipient-specific findings.

If the incident first appeared as a performance change, use the sudden reply-drop diagnostic to verify measurement, reply routing, delivery, audience, and message changes in order.

If Microsoft 365 is the sending mailbox or the affected receiver, use the Microsoft 365 cold email troubleshooting workflow to separate Exchange Online restrictions, message trace evidence, remote rejections, and placement testing.

FAQ

Can emails go to spam even when SPF, DKIM, and DMARC pass?

Yes. Authentication proves sender identity and alignment. Providers also evaluate domain and IP reputation, complaint signals, message characteristics, sending patterns, and recipient-side rules.

Does a DMARC policy of p=reject improve inbox placement?

DMARC enforcement protects the domain from unauthenticated use. It can remove an authentication weakness, but it does not create good reputation or guarantee inbox placement.

Can tracking links cause an email to go to spam?

Tracking and redirect hosts can add risk when they are unexpected, shared, broken, or associated with poor reputation. Inspect the hosts in the sent message instead of assuming the configured CNAME is the only one used.

How can I tell whether the problem is sender-side or recipient-side?

Compare results by mailbox provider and recipient domain, inspect SMTP responses and message headers, and check whether one corporate gateway or tenant behaves differently from the rest.

Does a passing deliverability checker mean my email will reach the inbox?

No. A passing checker means the observable infrastructure did not expose a known blocker at that time. Private reputation, recipient feedback, content classification, and final inbox placement remain outside that result.