Why are my newsletters going to spam?

Newsletter filtering stopped being mysterious in February 2024. Gmail published hard requirements for anyone sending 5,000 or more messages a day to Gmail accounts, Yahoo shipped a matching set, and both now enforce them at delivery time. A newsletter that misses any one of them (authentication, one-click unsubscribe, spam rate) gets junked or rejected regardless of how good the content is.

That changes how you diagnose. Before 2024, spam placement was mostly a reputation story you influenced slowly. Now the first question is binary: does your newsletter pass SPF, DKIM, and DMARC with the From domain aligned, and does it carry the RFC 8058 unsubscribe headers? If no, nothing else you tune matters. If yes, you are back in the classic territory of complaint rates and engagement, and those have published numbers too.

This page is platform-agnostic: the requirements attach to your sending domain, not to whichever ESP pushes the button. The one structural detail newsletters add is the subdomain. Most ESPs send your newsletter from something like news.yourdomain.com, and authentication has to be correct on that subdomain specifically, which is exactly where default ESP setups quietly fail.

Newsletters usually leave from a delegated subdomain (news., mail., em.) so the marketing stream carries its own reputation. The catch is that SPF and DKIM have to pass for the domains actually used on the wire, and align with the From address your readers see. SPF is evaluated against the bounce (Return-Path) domain, which many ESPs keep on their own infrastructure by default; DKIM alignment depends on the d= domain in the signature matching yours.

The classic failure looks like this: the ESP signs with its own domain, SPF passes for the ESP's bounce domain, and neither aligns with yourdomain.com in the From header. Every check on the ESP dashboard shows green, and DMARC still fails. The fix is completing the ESP's custom domain authentication so DKIM signs as your domain (or your newsletter subdomain), and pointing the required CNAME or TXT records at DNS you actually control.

One more subdomain trap: DMARC policy inheritance. If your organizational domain publishes a DMARC record and the subdomain has none, the subdomain inherits it (including any sp= subdomain policy). Moving the root to enforcement while the newsletter subdomain still fails alignment turns a spam-folder problem into outright rejection. Check the subdomain's effective policy before the root tightens.

Google's ceiling is a spam rate below 0.30% in Postmaster Tools, with a recommendation to stay under 0.10%. In list terms: 3 complaints per 1,000 messages that Gmail users receive is the edge of the cliff, and 1 per 1,000 is where Google wants you. Yahoo publishes the same 0.3% figure, measured on mail delivered to the inbox. These are small numbers; one stale segment or one re-mailed old list can clear them in a single send.

You cannot manage what you cannot see, and complaint data lives with the providers, not your ESP. Postmaster Tools reports your Gmail spam rate per domain; Yahoo offers a complaint feedback loop. If your newsletter domain is not registered in Postmaster Tools yet, that is the first ten minutes of any diagnosis, because it tells you whether you have an authentication problem, a complaint problem, or both.

Engagement is the quieter half of the same signal. Mailbox providers watch what recipients do with your mail, and a list full of addresses that never open is indistinguishable from a scraped one. The practical countermeasure is a sunset policy: stop mailing addresses that have not engaged in some defined window, and win them back through a separate, smaller stream if at all. Shrinking the list this way reliably improves placement for everyone left.

RFC 8058 defines the mechanism both providers now require: a List-Unsubscribe header carrying an HTTPS URL plus a List-Unsubscribe-Post: List-Unsubscribe=One-Click header, so the mailbox provider can unsubscribe a reader with a single tap from the inbox UI. The POST design exists because security software fetches every link in mail headers automatically; a plain GET unsubscribe link would get triggered by scanners, so the standard requires an explicit POST to count as intent.

Treat the unsubscribe path as complaint prevention. A reader who cannot leave in one click leaves via the spam button instead, and that report counts against the 0.30% ceiling forever. Making unsubscribe effortless is how you keep complaints down; hiding it is how newsletters with clean lists still end up filtered. Most established ESPs emit the RFC 8058 headers once configured; verify by inspecting the raw headers of a real delivered message, not the ESP's marketing page.

List hygiene and unsubscribe headers handle the behavioral half, but the authentication half only stays fixed if SPF, DKIM, and DMARC stay correct as ESPs, subdomains, and tools change. Monitoring shows you the failure after a campaign already landed in spam; it does not stop the next one.

The end state worth reaching is DMARC at p=reject with every legitimate sender authenticated and aligned, newsletter subdomain included. Receivers drop spoofed mail, your own campaigns stop tripping authentication filters, and inbox placement goes back to reflecting what you send rather than how your DNS is configured.

When Gmail or Yahoo tightens enforcement, it hits every un-authenticated client domain in your book the same week, and the tickets all read the same: the newsletter stopped landing. Audit marketing subdomains across the portfolio, not just root domains, because ESP-delegated subdomains are where alignment silently fails. Palisade hosts and manages SPF, DKIM, and DMARC records per client domain, watches the aggregate reports continuously, and walks each domain to p=reject automatically, with ConnectWise, HaloPSA, and Autotask integrations so the alert lands in your PSA. Your own MSP domain is a free NFR domain to prove the workflow on before you roll it out to clients.