Cold Email Deliverability: Provider Rules and Diagnosis

When a cold email gets no reply, one of two things happened. Nobody saw it, or somebody saw it and did not care. Only the second is a copywriting problem. The first is a deliverability problem, and rewriting the subject line will not touch it.

This page is a lookup. It lists what the big mailbox providers require, gives a fixed order for finding the fault when placement drops, and sets out the numbers worth watching each week. For the setup itself (sending domains, DNS records and the ramp schedule), follow the email warmup system.

What the providers require#

Google and Yahoo publish sender requirements that apply to anyone who mails their users, cold senders included. This is the one article on this site that explains them in full. The other cold-email pages link here.

Two details in Google's sender FAQ ↗ catch cold senders out. Once you reach the bulk threshold, Google treats you as a bulk sender permanently. And every sender must meet the guidelines, so non-compliant mail can be rejected or sent to spam well below 5,000 a day.

Microsoft announced authentication requirements for high-volume senders to Outlook.com ↗. Domains that send more than 5,000 messages a day must pass SPF, DKIM and DMARC, starting May 5, 2025. Microsoft said non-compliant mail would go to the Junk folder first, with rejection to follow later. Check the post for the current enforcement status.

For a small outbound team, the practical reading is short. Authenticate every domain as if you were a bulk sender. Keep complaints far under the limit instead of just beneath it. Put a clear opt-out in every message. A one-click header is the safest route if your tool supports it, and a plain-text opt-out line costs almost nothing. The email compliance automation guide shows how to build it.

Terms you will meet#

Reputation attaches to your sending domain and, where you control them, your sending IP addresses. If you send through Google Workspace or Microsoft 365 mailboxes, the IPs belong to the provider, so your domain's behavior is the part you can change. That is one reason a bad habit on one domain follows you.

Diagnose in a fixed order#

When placement drops, the instinct is to rewrite the copy. Resist it. Work down the layers below and stop at the first fault, because each layer can hide the ones after it.

If mail reaches the inbox and nobody answers, deliverability is fine. The problem is who you email or what you say.

Read the authentication headers#

In Gmail, open a test message and choose Show original. The result looks like this, with your own domain in place of the example:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@send.example.com;
  spf=pass smtp.mailfrom=send.example.com;
  dmarc=pass header.from=send.example.com

All three should say pass, and the domain in each line should be your sending domain. A sudden drop often comes from a new tool that signs with its own domain. Then you see dkim=pass for the vendor's domain and dmarc=fail, because the passing domain does not align with your From address. A DNS edit that created a second SPF record produces a similar failure.

Read the SMTP responses#

Replies that start with 4 are temporary, so the provider is asking you to try later. Replies that start with 5 are permanent refusals. Gmail's SMTP error reference ↗ explains two codes that cold senders meet often.

Deferrals are a warning, not a failure. A tool that keeps retrying through them at full speed turns a warning into a block.

When you need to escalate to your sending tool's support or a provider's postmaster team, collect four things first: the time of the failed send, the recipient's domain, the exact SMTP response text and the full headers of a test message. A report that includes them gets a useful answer. A report that says "our emails go to spam" does not.

Symptoms that point to one layer#

What to check each week#

Problems show up in the numbers before they show up in the pipeline. Track per inbox and per domain. A campaign average hides one bad inbox.

Postmaster Tools reports on Gmail recipients only, and a small domain may show little or nothing, so keep your own per-inbox log as well. DMARC aggregate reports arrive as XML. A free report reader, or your DMARC host, turns them into a table. An unknown sender in that table is usually a tool someone connected without telling you.

Our advice on thresholds is to write the pause rule down before you need it. Pause any inbox whose bounces or complaints are rising, then investigate. A pause costs a few days. A damaged domain costs weeks, and nobody argues well with a deteriorating domain in the middle of an incident.

Retire a domain before you nurse it#

Sometimes retiring a domain is faster than repairing it. We lean toward retiring earlier than feels comfortable, because a domain's history follows it and a fresh one costs little. The condition is that you fix the cause first. Usually it is one of three things: a list nobody verified, a message that attracted complaints, or a sending tool that ran faster than anyone intended.

Do not move the same list to a new domain and expect a different result. The list carries the problem with it. Verify and clean it with the list hygiene system, then start the new domain at the bottom of the ramp, not where the old one ended.

What content can and cannot fix#

Authentication gets you through the door. Recipient behavior decides the rest, and relevance lowers complaints more than any copy trick does. Plain text, few links, an honest subject line and a visible way to opt out remove most content risk. After that, extra polish buys little.

The message needs one specific reason to exist. For how to build that line at scale, see cold email personalization at scale.

Deliverability is maintenance. The cheapest habit is a weekly ten-minute look at spam rate, bounces and authentication results for each inbox, with a written rule for when to pause.