Cold Email Deliverability Checklist for B2B Outbound

01 / FIRST PRINCIPLE

Delivered does not necessarily mean inboxed.

Cold email teams often use "delivered" and "deliverability" as though they mean the same thing.

They do not.

A sending platform may record a message as delivered once the receiving mail server accepts it. That does not tell you whether the message reached the primary inbox, another folder, quarantine or spam.

Think about the stages separately:

Sent

Your sending provider attempted to transmit the message.

Accepted

The recipient's mail system accepted the message rather than returning an immediate rejection.

Placed

The receiving system decided where the message should appear.

Seen

The recipient actually had a realistic opportunity to notice it.

Engaged

The recipient opened, replied, forwarded, clicked, deleted, reported or otherwise interacted with it.

A campaign can therefore have excellent technical delivery statistics and still produce weak commercial results.

Likewise, poor reply rates alone do not prove that you have a deliverability problem.

Bad targeting, weak positioning, irrelevant copy and deliverability problems can produce similar surface-level symptoms.

The purpose of a deliverability audit is to separate them.

Do not diagnose deliverability from reply rate alone.

A change in replies is a reason to investigate. It is not proof that messages are landing in spam.

02 / QUICK AUDIT

The cold email deliverability checklist.

Tick a check only after you have inspected it. Progress is remembered on this browser; no account or email is required.

0 / 30 checks passed

Infrastructure audit recommended.

Resolve obvious authentication, list and sending-control issues before increasing activity.

This checklist is an operational diagnostic, not an inbox-placement guarantee.

03 / PROVIDER REQUIREMENTS

Start with the requirements mailbox providers actually publish.

Cold email advice often mixes official requirements with opinions about sending volume, warm-up periods, copy length and infrastructure.

Keep them separate.

The following summary should be treated as a provider-policy snapshot and reviewed periodically because requirements can change.

Official mailbox-provider requirements — reviewed 18 September 2026
Provider	Authentication	High-volume considerations	Spam / recipient controls	Important note
Gmail	SPF or DKIM for all senders to personal Gmail accounts. Bulk senders must use SPF, DKIM and DMARC.	Approximately 5,000 or more messages in 24 hours to personal Gmail accounts from the same primary domain meets the bulk threshold.	Keep reported spam below 0.3%; Google recommends below 0.1%. Applicable bulk marketing/subscribed messages need one-click and visible unsubscribe.	Alignment, TLS and valid forward/reverse DNS also matter.
Outlook.com	SPF, DKIM and DMARC for domains sending more than 5,000 messages per day to the consumer ecosystem.	The announcement covers Outlook.com, Hotmail.com and Live.com consumer addresses.	Microsoft recommends functional unsubscribe handling, list hygiene and transparent sending.	Non-compliant high-volume messages can be rejected with authentication-related SMTP errors. Read the complete response.
Yahoo	SPF or DKIM for general senders; SPF, DKIM and DMARC for bulk senders.	Yahoo does not publish the same fixed public bulk threshold as Google.	Bulk senders must keep reported spam below 0.3%, make unsubscribing easy and honour requests according to Yahoo requirements.	DMARC alignment matters for bulk traffic.

These are condensed explanations, not substitutes for the providers’ complete rules. See the primary references below.

04 / SENDING DOMAINS

Protect the identity you send from.

The sending domain sits underneath every mailbox in the campaign.

That makes it a shared source of risk.

One mailbox problem can sometimes remain local.

A domain-level problem can affect several mailboxes at once.

For companies using cold email, the first decision is therefore not "Which sequencer should we buy?"

It is:

Which identity are we prepared to use for this traffic, and how will we protect it?

Main domain vs separate sending domains

Some outbound teams separate cold outreach from the company's primary corporate email domain to reduce operational exposure.

That is an infrastructure strategy, not a mailbox-provider requirement.

If separate sending domains are used:

they should represent the company transparently
they should be properly authenticated
they should not impersonate another company
reply handling should remain functional
opt-outs must remain synchronized
ownership should be documented
they should not be treated as disposable spam infrastructure

Do not create misleading domains simply to bypass filtering.

A second domain does not fix bad behaviour.

Moving the same poor list, aggressive sending behaviour and weak controls to another domain simply moves the problem.

The purpose of domain separation is risk management.

It is not permission to ignore reputation.

Domain rotation is not a substitute for root-cause diagnosis.

05 / AUTHENTICATION

SPF, DKIM and DMARC: what each one actually does.

SPF

Sender Policy Framework

SPF tells receiving systems which servers are authorised to send mail on behalf of a domain.

Think of it as an authorised-sender list.

A correct SPF configuration helps the receiver verify that the infrastructure transmitting the message is permitted to do so.

missing sending services
conflicting configurations
obsolete services remaining in the record
authentication passing on one platform but failing on another

Do not merely check whether an SPF TXT record exists.

Check whether real messages are passing SPF.

DKIM

DomainKeys Identified Mail

DKIM cryptographically signs outgoing messages.

The receiving mail server can use that signature to verify that the message was authorised by the signing domain and was not improperly changed in transit.

Google currently requires DKIM keys of at least 1,024 bits for mail sent to personal Gmail accounts and recommends 2,048-bit keys where supported.

DKIM never being enabled after mailbox setup
incorrect selectors
expired or replaced records
a provider signing with a domain that does not align as expected

Again:

"DKIM record exists" is not the same as "DKIM passes on the message."

DMARC

Domain-based Message Authentication, Reporting and Conformance

DMARC builds on SPF and DKIM.

It tells receivers how the domain owner wants authentication failures handled and introduces alignment between the domain visible to the recipient and authenticated domains.

Common DMARC policy levels include:

p=none

Monitor.

p=quarantine

Ask receivers to treat failing mail with greater suspicion.

p=reject

Ask receivers to reject messages that fail the policy.

For an organisation implementing DMARC for the first time, monitoring and understanding legitimate sending sources should come before aggressively changing enforcement.

Do not change DMARC policy blindly.

Authentication is foundational, not sufficient.

A perfectly authenticated message can still be filtered if other reputation, behavioural or recipient-quality signals are poor.

Sending mailbox
Sending infrastructure
SPF / DKIM authentication
DMARC alignment
Receiving mailbox provider
Accept / filter / reject

06 / MAILBOX REPUTATION

New infrastructure needs behaviour that looks controlled.

There is no universal mailbox-provider rule saying that every new mailbox must be warmed for exactly X days or can safely send exactly X cold messages per day.

Treat fixed numbers presented online as operational heuristics unless they come directly from the provider governing that mailbox.

What matters is the underlying principle:

A new or lightly used sender should not suddenly behave like a mature, high-volume sender.

CONTROLLED

Gradual changes in activity

Consistent sender identity

Valid recipients

Real replies

Reasonable sending windows

Normal conversation behaviour

Stable infrastructure

RISKIER

Large unexplained volume jumps

High invalid-recipient rates

Repeated sends after bounces

Large identical batches

Unmanaged mailboxes

Frequent infrastructure changes

Recipients repeatedly indicating messages are unwanted

Mailbox reputation is accumulated behaviour.

Software cannot simply switch it on.

Warm-up is not a substitute for clean data, proper authentication or relevant outreach.

07 / DATA QUALITY

Deliverability starts with who you send to.

A campaign can damage itself before the recipient reads the first line.

Sending to addresses that do not exist creates bounces.

Sending to the wrong people creates irrelevance.

Sending to people who repeatedly do not want the message creates negative signals and complaints.

A list is therefore part of infrastructure.

Not merely a sales asset.

Verify before sending.

Verification does not prove that a recipient wants the message.

It helps answer a narrower technical question:

Is this address likely to accept mail?

Use verification to identify:

valid addresses
invalid addresses
risky or uncertain results
catch-all domains
temporary problems
addresses requiring further review

Treat catch-all differently.

A catch-all mail server may accept mail for addresses even when the verification service cannot prove that the individual mailbox exists.

"Catch-all" therefore does not mean:

verified safe address

It means:

recipient validity could not be confirmed in the normal way.

If catch-all contacts are used, control the volume and monitor the resulting bounce behaviour separately.

Suppression should follow the person, not the mailbox.

If someone opts out, do not simply contact them again from:

another sender
another domain
another sequence
another campaign

Maintain suppression centrally wherever possible.

Changing the sender does not erase the recipient's previous response.

08 / SENDING BEHAVIOUR

Scale should be earned, not assumed.

Cold email sending volume should respond to evidence.

Do not choose volume because a software plan says the account can technically send it.

Increase activity only after the underlying system remains stable.

Before scaling, ask:

Are addresses clean?

If not, more volume creates more bounces.

Is authentication passing?

If not, volume amplifies the fault.

Are replies relevant?

If not, scale amplifies poor targeting.

Are spam complaints controlled?

If not, more recipients create more negative signals.

Are mailboxes behaving consistently?

If not, find the outlier.

Did the last increase create a change?

Compare campaign performance and provider responses before and after each meaningful infrastructure change.

Avoid sudden changes.

Large jumps in volume can make troubleshooting much harder.

If replies fall on the same day that you:

add new domains
add new mailboxes
import a new list
double volume
change sending software
change tracking
change copy

you now have several possible explanations.

Change fewer variables at once.

That gives you something much more valuable than speed:

diagnostic clarity.

09 / MESSAGE CONSTRUCTION

Do not try to copywrite your way around a broken infrastructure stack.

Deliverability is not just about avoiding a secret list of "spam words."

Mailbox providers evaluate far more than vocabulary.

Your message, sender, authentication, recipient behaviour, infrastructure and sending history interact.

A few practical controls are still useful.

Keep the first message operationally simple.

If a link, image, tracking system or attachment is not necessary to start the conversation, consider whether it needs to be in the first message.

Every additional component creates another variable to troubleshoot.

Be careful with tracking.

Open tracking can be affected by privacy protections and automated image loading.

Click tracking can introduce redirect infrastructure between the recipient and the final page.

Do not make critical deliverability decisions using open rate alone.

Make the sender obvious.

The recipient should understand who contacted them and why.

Do not disguise the commercial nature of the conversation or impersonate another person or company.

Relevance beats cosmetic personalization.

A personalised first sentence does not rescue an irrelevant offer.

The message needs a credible reason to exist for that recipient.

Read the B2B Outreach Playbook and compare cold email vs LinkedIn.

10 / MONITORING

Watch the signals that can actually diagnose a problem.

Deliverability signals: what they do and do not prove
Signal	What it can tell you	What it cannot prove
Hard bounce rate	Recipient validity or technical acceptance problems may exist.	Inbox placement among messages that were accepted.
SMTP rejection codes	Why a receiving system rejected or deferred a message.	How successfully other providers are placing the same mail.
Authentication results	Whether SPF, DKIM and DMARC are passing as expected.	That a properly authenticated message will reach the inbox.
Spam complaints	Recipients are actively reporting messages as unwanted.	Why recipients disliked the message.
Replies	Some messages are reaching people and generating interaction.	Overall inbox placement.
Open rate	Limited directional information depending on tracking setup.	Reliable human readership or inbox placement.
Provider compliance tools	Provider-specific authentication, complaint or compliance information where available.	Performance across every receiving mail system.

Segment by receiving provider.

Separate Google-hosted recipients, Microsoft-hosted recipients, other corporate providers and consumer mailbox providers. A problem concentrated inside one ecosystem is different from one affecting every destination.

11 / DIAGNOSTIC TABLE

Something changed. Where should you look first?

Symptoms, possible causes and first checks
Symptom	Possible causes — not confirmed diagnoses	First check
Large increase in hard bounces	Poor list source · Old data · Verification failure · Incorrect email generation · Recipient-domain issue	Inspect actual bounce codes and compare by list source.
Authentication failures appear	DNS change · Incorrect SPF · DKIM selector issue · Sending provider configuration · DMARC alignment issue	Inspect message headers and test mail from the affected mailbox.
One domain performs much worse than others	Domain-specific reputation · Different DNS configuration · Different mailbox provider · Different history · Blocklist issue	Compare authentication, history, sending behaviour and recipient mix domain-by-domain.
Replies drop immediately after a major volume increase	Sending behaviour · New recipient segment · New mailbox group · List-quality change · Provider filtering	Return to the last controlled period and isolate what changed.
Messages are accepted but tests suggest poor placement	Reputation · Recipient engagement · Sending behaviour · Content / tracking infrastructure · Provider-specific filtering	Do not change five things at once. Segment by sender and recipient provider and run controlled tests.
Microsoft returns authentication-related rejection	SPF · DKIM · DMARC · Alignment or sender configuration	Read the complete SMTP code and verify authentication against Microsoft's current sender rules.
One mailbox fails while others on the domain remain stable	Mailbox-specific restriction · Different sending behaviour · Provider issue · Account health	Pause the mailbox and compare configuration and recent activity against healthy mailboxes.
Replies are low but technical indicators look normal	Targeting · Offer · Message · Timing · Buyer relevance	Stop treating deliverability as the default explanation. Review targeting and message quality separately, or use Getting replies but not meetings?

Getting replies but not meetings? →

12 / TROUBLESHOOTING

A practical deliverability triage sequence.

01 — Stop unnecessary scaling

Do not increase sending volume while the cause is unknown.

This does not necessarily mean shutting down every healthy sender.

Isolate the affected component.

02 — Read the errors

Review:

SMTP codes
bounce classifications
authentication results
sending-provider warnings
mailbox restrictions

Do not replace the infrastructure before reading what it is telling you.

03 — Test authentication

Send test messages from affected mailboxes.

Inspect:

SPF
DKIM
DMARC
alignment
sending domain
message path

04 — Compare healthy vs unhealthy senders

Look for differences in:

domain
mailbox provider
age
sending volume
prospect source
geography
campaign
message
tracking configuration

05 — Audit the recipient list

Re-verify questionable data.

Separate:

confirmed valid
invalid
catch-all
unknown
previously bounced
opted out

06 — Segment by recipient provider

Determine whether the problem is:

universal
Google-specific
Microsoft-specific
domain-specific
mailbox-specific
campaign-specific

07 — Reduce variables

Use a smaller controlled sample.

Do not simultaneously change:

copy + domain + mailbox + list + volume + sequencer.

Otherwise, even if performance improves, you will not know why.

08 — Resume based on evidence

Scale after the system stabilises.

Do not automatically return to the previous volume simply because the campaign sent successfully for one day.

13 / WHAT NOT TO DO

Seven deliverability mistakes that make diagnosis harder.

1. Blaming the sequencer first

Sending software may be part of the problem, but switching platforms does not repair domain reputation, recipient quality or authentication errors automatically.

2. Buying more inboxes before identifying the cause

More mailboxes multiply infrastructure.

They do not automatically improve its quality.

3. Replacing every domain after one bad campaign

Identify whether the issue is domain-specific before throwing away infrastructure.

4. Treating every reply-rate decline as spam placement

Commercial performance and technical delivery are different problems.

5. Trusting a DNS checker without testing actual messages

Records can exist while authentication still fails in real mail flow.

6. Retrying bounced or opted-out recipients elsewhere

A new mailbox does not turn an unsuitable recipient into a suitable one.

7. Chasing magic words

No single banned-word list explains modern email filtering.

Fix the system.

Then improve the message.

14 / DOMAIN RECOVERY

Should you repair the domain or replace it?

Do not discard a domain purely because one campaign performed badly.

First identify what is actually wrong.

INVESTIGATE RECOVERY WHEN

Authentication can be corrected.

The problem followed a specific campaign or list.

Only individual mailboxes appear affected.

A configuration mistake has been identified.

The issue is temporary or provider-specific.

The domain remains legitimately owned and useful.

CONSIDER MIGRATION WHEN

Persistent blocking remains after the underlying causes have been addressed.

The domain has accumulated a history you no longer want associated with future outreach.

Infrastructure design itself needs replacing.

The domain no longer represents the company appropriately.

Migration is commercially more sensible than continued diagnosis.

There is no universal public "domain reputation score" that tells every sender when a domain must be abandoned.

Different receiving systems make their own decisions.

15 / COMPLIANCE

Deliverability rules and legal permission are not the same thing.

Passing SPF, DKIM and DMARC does not make an email legally permissible.

Likewise, meeting a jurisdiction's marketing rules does not guarantee that Gmail, Outlook or Yahoo will accept or place the message.

Treat these as separate layers:

Layer 1

Applicable law and regulation

Layer 2

Mailbox-provider requirements

Layer 3

Sending-platform policies

Layer 4

Recipient expectations

Layer 5

Your company's internal standards

Cold outreach rules differ by country, recipient type, data source and circumstances.

Campaigns targeting multiple jurisdictions should therefore be reviewed against the laws applicable to those destinations.

This resource is operational guidance, not legal advice.

16 / LEADSCORER APPROACH

How LeadScorer handles cold email infrastructure.

LeadScorer treats deliverability as an operating system rather than a one-time DNS task.

For managed cold email engagements, the work can include:

Infrastructure planning

Structure the sending environment around the campaign and risk profile.

Authentication

Check the technical foundation supporting active senders.

Prospect hygiene

Use researched and verified contact data with exclusions and suppression controls.

Controlled execution

Manage sending behaviour instead of maximising volume for its own sake.

Monitoring

Review campaign, mailbox and recipient signals as the campaign operates.

Iteration

Change the audience, message, infrastructure or sending behaviour according to the problem actually observed.

LeadScorer cannot guarantee inbox placement.

Receiving mailbox providers control filtering and acceptance decisions.

Explore managed cold email services →

17 / DECISION TREE