Start with authentication results, SMTP responses, provider dashboards, bounces, complaints, and recent sending changes. These signals explain more than a list of “spam words.”
1. Authentication or alignment is failing
Messages without valid authentication are harder to attribute and may be rejected or placed in spam. DMARC also depends on alignment: the domain authenticated by SPF or DKIM must align with the domain recipients see in the From address.
Inspect the authentication results of a real received message. Confirm that SPF passes for the actual sending path, DKIM signing is enabled and validates, and DMARC alignment succeeds.
2. Reputation and volume changed
Receiving providers evaluate patterns across domains, IP addresses, and message streams. A sudden volume spike, bursty sending, a new infrastructure path, or traffic mixed with a damaged shared IP can change how mail is treated.
Google recommends consistent sending, gradual increases, and monitoring domain and IP reputation. If messages begin bouncing or being deferred, it recommends reducing volume until the SMTP error rate falls.
3. Recipient feedback says the mail is unwanted
Authentication cannot make an irrelevant message welcome. Poor targeting, stale or purchased addresses, unclear identity, and difficult opt-out paths increase the chance of complaints and disengagement.
Google advises keeping user-reported spam below 0.1% and avoiding 0.3% or higher. Yahoo also sets a 0.3% complaint ceiling for bulk senders. Treat these as hard boundaries and aim lower.
4. The message looks misleading or unsafe
Misleading display names, false reply prefixes, hidden content, confusing links, malformed headers, and identity mismatches can undermine trust and violate provider requirements. Both the sending domain and linked domains carry reputation.
Inspect the complete message. Make the sender, purpose, links, and opt-out route clear. Keep the formatting valid. Never disguise a new outbound message as part of an existing conversation.
5. Infrastructure reputation is shared or inconsistent
On shared infrastructure, another sender can affect the reputation of the shared IP. Across your own operation, mixing transactional, support, and prospecting traffic on the same identity can also make patterns harder for providers and operators to interpret.
Separate message categories where appropriate, keep each stream consistent, and monitor both domain and IP evidence. Rotating across more inboxes does not erase a domain-level problem.
A useful diagnostic order
- Confirm whether the message was accepted, deferred, rejected, or accepted into spam.
- Read the full SMTP response or bounce classification instead of grouping every failure together.
- Inspect SPF, DKIM, DMARC, alignment, DNS, TLS, and message formatting.
- Compare current volume and schedule with the mailbox and domain's recent history.
- Review complaints, hard and soft bounces, suppression, and audience provenance.
- Inspect sender identity, subject, body, links, and unsubscribe behavior.
- Change one material variable at a time and resume at lower volume.
Signals that cannot confirm deliverability
| Signal | Why it is insufficient |
|---|---|
| High open rate | Tracking can be blocked or preloaded, and Google says it cannot verify third-party open-rate accuracy |
| Authentication passes | It proves attributable identity. Recipient interest still depends on relevance and consent. |
| Addresses were verified | Verification reduces address risk; it does not establish interest or placement |
| Warmup completed | A ramp cannot override future audience, volume, reputation, or policy problems |
| More inboxes were added | Rotation distributes activity but does not remove aggregate domain risk |
Primary sources
- Google: Email sender guidelines
Authentication, reputation, volume, complaint, formatting, and troubleshooting guidance. - Google: Postmaster Tools dashboards
How to interpret reputation, authentication, delivery errors, and spam-rate reporting. - Yahoo Sender Hub: Sender best practices
Bulk-sender authentication, complaint, unsubscribe, and list-hygiene requirements. - IETF RFC 3463: Enhanced Mail System Status Codes
Standard structure for distinguishing success, persistent transient failure, and permanent failure.