What should I check when my emails go to spam?

A message that bounces was refused by the receiving server, and the bounce usually says why.

A message in the spam folder was accepted, then scored by a filter that tells the sender nothing.

So the diagnosis is indirect: you check the inputs a filter is known to use, since you cannot read its decision.

Authentication is the input you control completely, which is why it comes first.

The received message's own headers, opened in the recipient's mail client, show the authentication verdicts the receiver reached — the one direct piece of evidence available.

The sender policy must list the server or service that sent this particular message. A newsletter platform added without updating the policy fails here.

The policy must also stay within its limit of ten DNS lookups, beyond which it produces an error for every message rather than a pass.

There must be exactly one sender policy record; two produce an error, not a merge.

The message should carry a DKIM signature from a selector whose public key is published.

Read the authentication results in the received message's headers to see which of these the receiver actually evaluated as passing.

DMARC passes only when SPF or DKIM passes for a domain that matches the From address.

A message sent by a platform using its own bounce domain passes SPF for the platform, not for you, so SPF does not align.

A DKIM signature made with the platform's domain rather than yours does not align either.

That combination — everything passing, nothing aligned — is the most common cause of good mail being filtered, and it is invisible unless you read the alignment specifically.

The fix is almost always to configure the platform to sign with a key published under your domain.

The sending server's IP address should have reverse DNS that resolves back to a name, and that name should resolve forward to the same address.

Many receivers treat missing or mismatched reverse DNS as a strong negative signal.

For mail sent through a platform, this is the platform's responsibility and usually correct.

For mail sent from your own server, it is yours, and the record is set by whoever owns the IP address rather than in your domain's DNS.

A published DMARC policy with reporting enabled lets receivers send you aggregate reports showing which sources pass and fail — the best view you will get of what receivers see.

The reputation of the sending IP address and domain, which each receiver computes from its own history.

Whether recipients mark your mail as spam, which is the strongest signal of all and entirely internal to the receiver.

The content of the message and how a filter scores it.

Whether an address is on a blocklist, which depends on each list and is outside what a site scan reads.

So a clean authentication result removes one class of cause; it does not guarantee the inbox.

The received message's headers, for the verdicts on the one message you are looking at.

The DMARC aggregate reports, for the verdicts on everything sent as your domain.

The domain's DNS records, for what the policies actually say.

The sending platform's own diagnostics, for bounces and complaints it recorded.

Starting from the DNS records is fastest because it is exact; the others tell you whether the records are doing what you think.