Email deliverability: a diagnostic method

Deliverability is not a single switch. A receiver may accept a message and place it in junk, defer it for a later retry, or reject it permanently. Each outcome has different evidence and requires a different response.

This guide is the starting point for the collection. The provider-specific guides describe Gmail and Outlook.com requirements; the authentication guide covers DKIM and DMARC; the Microsoft response guide decodes the responses Microsoft actually documents.

Start with the SMTP result

Preserve the complete SMTP response, including its enhanced status code, explanatory text, receiving hostname and UTC timestamp.

• A 2xx response means the receiving system accepted responsibility for the message. It does not promise inbox placement.
• A 4xx response is temporary. Keep the message queued and retry using an increasing delay.
• A 5xx response is permanent for that delivery attempt. Do not repeatedly send the unchanged message to the same recipient.

The text matters as much as the number. Codes such as 5.7.1 describe a broad policy or security class; the accompanying text identifies the actual condition.

Establish which service answered

Do not treat Gmail, Google Workspace, Outlook.com and Exchange Online as interchangeable.

• Personal Gmail accounts end in gmail.com or googlemail.com. Google’s sender requirements are written for these accounts.
• Google Workspace domains may use Google’s receiving infrastructure, but organizational policy can also affect delivery.
• Outlook.com is Microsoft’s consumer service for addresses including outlook.com, hotmail.com, live.com and msn.com.
• Exchange Online hosts organizational domains and publishes a separate NDR reference.

Record the recipient domain and the receiving hostname before choosing a provider playbook.

Verify identity from a newly delivered message

Inspect Authentication-Results from the receiving system, not a header copied from an earlier test.

Check:

1. The connecting IP is expected and has valid forward and reverse DNS.
2. SPF evaluates the intended envelope sender domain.
3. DKIM verifies at least one signature from a domain you control.
4. At least one passing SPF or DKIM identity aligns with the visible From: domain, producing DMARC pass.
5. The message was transmitted using TLS where the receiver requires it.

Authentication establishes identity. It does not create a good reputation and does not override a receiver’s content, user-choice or abuse controls.

Separate configuration from reputation

A correctly authenticated stream can still be rejected or placed in junk. Use the receiver’s own evidence where it is available:

• Google Postmaster Tools reports compliance, authentication, reputation, spam rate and delivery errors for eligible traffic to personal Gmail accounts.
• Microsoft SNDS reports data about traffic from registered IP addresses to Outlook.com.
• Microsoft JMRP returns reports for messages Outlook.com users mark as junk or phishing.

Low-volume traffic may not produce enough data for some dashboards. Absence of a graph is not evidence of either good or bad reputation.

Check the sending operation

Review facts that receivers can observe:

• Was the recipient expecting this message?
• Can subscribed recipients leave the list easily?
• Are invalid recipients and permanent failures removed?
• Did volume or cadence change suddenly?
• Is a compromised account or application sending through the same infrastructure?
• Are From:, DKIM and link domains stable and recognisable?

For subscription mail, complaints are operational evidence. Suppress a recipient when a provider feedback loop identifies that recipient, and use campaign-level feedback to find the acquisition source or message type causing complaints.

Change one class of problem at a time

Blue Canoe’s operating practice is to make the smallest change supported by the evidence, then send a fresh controlled test. Avoid changing IP, domain, content and volume simultaneously: that destroys the comparison and introduces new reputation variables.

When a receiver explicitly reports rate or connection limits, reduce parallelism and allow queued retries to work. Do not use throttling as a universal cure for permanent policy failures.

Escalate with a reproducible case

If the configuration meets the provider’s published requirements and delivery still fails, prepare:

• sending IP and hostname;
• envelope sender and visible From domain;
• full SMTP response;
• UTC timestamp;
• recipient provider;
• Message-ID from a representative message;
• current SPF, DKIM and DMARC results;
• the specific remediation already completed.

Use the provider’s current support route. Avoid asking for a whitelist or submitting repeated cases without new evidence.

Primary references

• Gmail email sender guidelines
• Google Postmaster Tools dashboards
• Outlook.com policies and requirements
• Outlook.com SNDS and JMRP
• Enhanced mail system status codes (RFC 3463)

Reviewed against these sources on 27 August 2026.