“Went to spam” is a symptom, not a diagnosis. The same visible outcome can be caused by a broken DKIM signature, a domain with poor reputation, a list full of stale addresses, a sudden volume spike, user complaints, or content that resembles abusive traffic. Troubleshooting gets much faster when you determine which layer is failing before changing copy or buying another deliverability tool.
First question: was the message accepted, rejected, or delivered to spam?
Start with the sending platform’s event log. If the receiving server rejected the message, save the full SMTP code and text. Gmail may return policy or authentication errors that point directly at the problem. A rejection is different from a message that was accepted and then placed in spam.
For an accepted Gmail message, use “Show original.” Record the Authentication-Results line and the domains used by SPF and DKIM. If DMARC reports pass, note which mechanism aligned with the visible From domain. This tells you whether the identity layer is healthy before you spend time rewriting the subject line.
If only one mailbox provider is affected, segment the diagnosis. Gmail trouble with normal Yahoo delivery suggests a different problem than broad failure across Gmail, Yahoo, Outlook, and corporate domains.
Authentication failures have recognizable fingerprints
SPF can fail because the actual sending IP is not authorized by the envelope-from domain, because a third-party sender was never added, or because the record is malformed. DKIM can fail because signing is disabled, the selector points to the wrong public key, or a message is altered in a way that breaks the signature. DMARC can fail even when SPF or DKIM technically passes if the passing domain does not align with the From domain.
Do not “fix” these problems by publishing multiple SPF records. SPF expects a single policy record for a domain. If several vendors send mail, their authorization generally has to be combined into that one record, while staying within SPF processing constraints.
A practical test is to send one message from each production system to a Gmail account and inspect the original headers. Put the results in a small matrix: source system, SPF result/domain, DKIM result/domain, DMARC result, and any anomaly. That matrix often exposes the bad path immediately.
Reputation problems look different
When authentication is passing but inbox placement deteriorates, look at how the program changed. Did daily volume jump? Did you import an old lead file? Did a new sequence target less relevant recipients? Are most bounces coming from one acquisition source? Did complaints rise after a campaign?
Google’s current sender guidance says to keep user-reported spam in Postmaster Tools below 0.10% and avoid ever reaching 0.30% or higher. Yahoo publishes a 0.3% ceiling for bulk-sender complaint rate. Do not treat either ceiling as a target: a rising complaint rate is evidence that targeting, expectations, or frequency need attention.
Postmaster Tools can help when enough Gmail traffic exists. Check Spam Rate, Domain Reputation, Authentication, and Delivery Errors together. A low reputation graph after a major volume spike tells a different story than authentication failures after a DNS migration.
List quality can poison a technically perfect setup
A domain with perfect SPF, DKIM, and DMARC can still send unwanted mail. Separate contacts by source and recency. Measure hard bounces and unsubscribes for each cohort instead of only for the campaign as a whole. If one spreadsheet creates most invalid recipients, quarantine it.
Remove known hard bounces immediately. Honor opt-outs and maintain suppression centrally so a person who unsubscribes from one campaign is not accidentally re-imported from an older file. For commercial email in the United States, CAN-SPAM also requires a functioning opt-out mechanism and timely honoring of opt-out requests; legal compliance and mailbox reputation are related but not identical.
Content is the last major layer, not the first
After identity, reputation, and list quality are checked, examine the message itself. Deceptive display names, misleading subjects, link-heavy templates, URL shorteners, image-only designs, and mismatched domains can make a questionable program look worse. But changing “free” to “complimentary” will not repair a domain that is failing DMARC or sending to stale addresses.
Test one change at a time. Send comparable cohorts with the same infrastructure and list quality. If you alter sender domain, copy, audience, and volume simultaneously, you lose the ability to attribute the result.
A useful seven-day recovery sequence
Day one is diagnosis: capture bounces, headers, Postmaster signals, and recent program changes. Days two and three are infrastructure repair and suppression cleanup. For the next several days, send only the traffic you can defend as relevant and clean, at a stable rate. Do not immediately return to the old peak volume after one good test.
If the issue is provider-specific, follow that provider’s published guidance rather than generic “spam score” folklore. The goal is not to trick a filter. It is to remove the reason your traffic looks risky.
For a full domain warmup and deliverability playbook, see: {{BACKLINK_2}}