The model
How a receiver decides
Four questions, asked in order, on every message. Almost every deliverability problem an agency hits is one of these four answered badly — which is why it pays to know which question a symptom belongs to before changing anything.
- 1
Are you who you say you are?
SPF, DKIM and DMARC. Cheap to check, mechanical, binary. A receiver settles this before it reads a word of the message.
- 2
Do we already distrust this domain or IP?
Blacklists, the receiver's own reputation history, and the age of the domain. This is where a listing or a burnt domain does its damage.
- 3
Do people who get your mail want it?
Complaint rate, bounce rate, deletes-without-reading, replies. This is the one the bulk-sender rules made explicit and measurable.
- 4
Does this specific message look like the ones people complained about?
Content, links, the reputation of the link-tracking domain, and how closely the message resembles known bad mail.
Authentication does not get you into the inbox. It gets you considered. A perfectly authenticated message from a domain with a 4% complaint rate lands in spam, and a sender who fixes SPF and expects placement to recover has answered the wrong question.
Layer one
SPF, DKIM, DMARC and MX
Three records that answer three different questions, plus one that decides whether replies can reach you at all. They are usually discussed together and they fail separately.
SPF — which servers may send for this domain
A TXT record on the domain listing the hosts authorised to send mail using it. The receiver compares the sending IP against that list. SPF authenticates the envelope sender (the Return-Path), which is not the From: address a human sees.
example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"Two failure modes cause almost all real SPF breakage, and neither shows up as a missing record.
The 10-lookup limit
RFC 7208 §4.6.4 caps evaluation at 10 DNS-lookup mechanisms — include, a, mx, ptr, exists and the redirect modifier. Past it the receiver MUST return permerror.[1] The count is recursive: every include you add drags in whatever that provider nested inside it, so a record with six visible includes can be over the line. This is how a sender who changed nothing breaks — a vendor edited their own include and spent your budget. The same section separately caps void lookups (those returning no answer), and recommends a limit of two.
Two records is zero records
A domain must publish exactly one v=spf1 record. Publish two and the result is permerror, not a merge.[1] It happens constantly: a new sending tool appends its own record instead of adding an include to the existing one, and SPF fails on every message from that moment. Merge them into one record ending in ~all.
ip4:, ip6: and the final all cost no lookups, so an over-limit record can often be fixed by replacing an include with the IP ranges it resolves to — at the price of having to maintain them yourself.
DKIM — was this message altered in transit
A cryptographic signature over selected headers and the body, added by the sending server. The public key lives in DNS at selector._domainkey.yourdomain.com; the receiver fetches it and verifies. RFC 6376 puts it precisely: DKIM lets the owner of the signing domain claim some responsibility for a message. A valid signature proves that claim, and that the signed parts arrived intact.
Source: IETF[2]
google._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."The selector is arbitrary and provider-chosen, which is why nothing can prove a domain has no DKIM record — you can only prove it does not have one at the selectors you thought to ask about. RFC 8301 sets the floor: signers MUST use RSA keys of at least 1024 bits and SHOULD use at least 2048, and verifiers must not treat a signature under 1024 bits as valid. It also retires rsa-sha1 for signing and verifying entirely.[3]
DKIM survives forwarding; SPF usually does not. When a recipient auto-forwards your mail, the forwarding server is not on your SPF list, so SPF breaks and DKIM is what keeps DMARC passing. This is a large part of why DMARC accepts either.
DMARC — what to do when the first two disagree with the From: address
A policy record at _dmarc.yourdomain.com. It ties SPF and DKIM to the domain the recipient actually sees, tells receivers what to do when neither aligns, and asks them to report back. Worth knowing: DMARC became a Standards Track RFC in May 2026 as RFC 9989, replacing the Informational RFC 7489 that most deliverability writing still cites.
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"p=noneMonitor only. Receivers act as they would have anyway and send you reports. The correct place to start.
p=quarantineTreat failing mail as suspicious — in practice, the spam folder.
p=rejectRefuse failing mail at the SMTP transaction. Nothing is delivered, nothing lands in spam.
Alignment is the part people skip and then cannot debug. DMARC passes when SPF or DKIM passes and the domain it authenticated matches the domain in the visible From: header. For SPF that is the Return-Path domain; for DKIM it is the d= tag in the signature. Relaxed alignment (the default) accepts a shared organisational domain, so mail.example.com aligns with example.com. Strict alignment requires an exact match.[4] A message can pass SPF outright and still fail DMARC, because SPF passed for the wrong domain.
rua= names the addresses aggregate feedback reports are sent to — XML summaries of who sent mail as your domain and whether it authenticated.[5] A DMARC record without one is a policy nobody is watching: you learn about a broken vendor or a spoofing run when placement drops, which is weeks late. ruf= requests per-message failure reports; both tags are optional, and most large receivers do not send ruf at all, for privacy reasons.
MX — where replies go
The record that routes inbound mail. It authenticates nothing and no receiver checks it before accepting your message, so it is not part of the auth stack. It matters for a different reason: a sending domain with no working MX cannot receive the replies you are paying to generate, and cannot receive the warmup traffic that builds its reputation.
An MX change nobody planned is worth an alert on its own. Migrating a domain between mail hosts silently ejects its mailboxes from warmup pools and breaks reply routing, and the sending platform will not tell you.
How they interact
SPF answers “is this server allowed to send for the envelope domain”. DKIM answers “did the signing domain vouch for this message, unaltered”. DMARC answers “does either of those actually belong to the domain in the From: line, and what should I do if not”. You need all three because each one alone is trivially defeated: SPF by forwarding, DKIM by replay, and both by simply putting someone else's name in the From: header.
Layer two
The bulk-sender rules that changed the game
Between 2024 and 2025 the three receivers that matter most stopped treating authentication and complaint rate as best practice and started treating them as entry requirements. If your reference point for cold email predates this, it is out of date.
Google — in force since 1 February 2024
Google's sender guidelines split senders into two tiers. Every sender must set up SPF or DKIM, have valid forward and reverse DNS on the sending IP (the sending address must match the hostname in the PTR record), transmit over TLS, and not impersonate Gmail in the From: header. Senders of more than 5,000 messages a day to personal Gmail addresses must additionally pass both SPF and DKIM, publish a DMARC record, keep the From: domain aligned with either the SPF or the DKIM domain, and support one-click unsubscribe on marketing and subscribed mail.
The number to know: the spam complaint rate
Google states it twice, and the two statements are not the same thing. The requirement is to keep the spam rate reported in Postmaster Tools below 0.30%. The advice, in the same document, is to keep it below 0.10% and never reach 0.30% or higher.[9] Read 0.10% as the operating target and 0.30% as the cliff. Note also that bulk-sender classification is permanent: once a domain reaches the threshold it keeps the obligations even if volume later drops.[10]
Complaint rate is calculated against messages that reached the inbox, not messages sent. That has an unpleasant consequence for a sender already in trouble: as placement worsens, the denominator shrinks and the same number of complaints reads as a higher rate. The metric accelerates in the direction it is already moving, which is why a complaint problem is worth acting on early rather than watching.
Two more specifics from Google's own FAQ: unsubscribe requests should be fulfilled within 48 hours, and the minimum acceptable DMARC policy is p=none — you are not required to enforce.[10] The threshold counts messages to personal Gmail addresses, not to Google Workspace tenants, and messages from the same primary domain count together.
Yahoo — the same bar, published alongside Google's
Yahoo announced matching requirements on the same timeline: authentication with SPF and DKIM, a DMARC policy, aligned From:, one-click unsubscribe honoured within two days, and a spam complaint rate kept under 0.3%. Treating Google and Yahoo as one set of rules is a reasonable simplification in practice.
Source: Yahoo[13]
Microsoft — announced April 2025, effective 5 May 2025
Microsoft brought its Outlook, Hotmail and Live consumer mailboxes into line in 2025: domains sending more than 5,000 emails a day to those addresses must pass SPF and DKIM and publish DMARC at at least p=none, aligned with SPF or DKIM. Microsoft also asks for functional unsubscribe links, which is a looser requirement than Google's one-click.
The enforcement action changed between announcement and launch, and it is worth being precise about. The original post said non-compliant mail would be routed to the junk folder from 5 May 2025. An update on 29 April struck that through and replaced it with outright rejection — 550 5.7.515 Access denied, sending domain does not meet the required authentication level — effective on the same date.[14]Microsoft's own postmaster policy page still describes junk-foldering as the first stage, so its two primary sources disagree. We could not find a Microsoft confirmation of what is enforced today, so this page states what was announced and stops there.
This is the one agencies underestimate. Google's threshold counts messages to personalGmail addresses, which a pure B2B list may never approach, and Yahoo declines to publish a volume threshold at all. Microsoft's line covers its consumer domains — but Microsoft-hosted business tenants run the same filtering machinery, and a large share of B2B recipients sit behind Microsoft 365. The practical read is that the bar is now the bar, whether or not a given list technically trips a threshold.
One-click unsubscribe (RFC 8058)
Two headers, and a working endpoint behind them. List-Unsubscribe carries a URL; List-Unsubscribe-Post carries exactly one value, which tells the receiver the URL can be POSTed to without a human confirming anything. The mail client then renders its own unsubscribe control and calls the endpoint directly.
List-Unsubscribe: <https://example.com/u/abc123>, <mailto:unsub@example.com>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickList-Unsubscribe-Post takes that literal value and no other, and List-Unsubscribe must contain one HTTPS URI — the receiver POSTs the key/value pair straight to it.[6] The URL must not require a login, a confirmation click, or a preferences page. Shipping the header without a functioning POST endpoint is worse than omitting it: the client shows the control, the recipient uses it, nothing happens, and the next thing they reach for is the spam button.
Cold email sits awkwardly here. A one-to-one sequence sent from a personal mailbox is not what RFC 8058 was written for, and most cold-email platforms send a plain-text opt-out line instead. That is a defensible position on volume grounds — it is not a defensible position on complaint rate. The complaint rate is what the receiver measures, and every recipient who cannot find an exit uses the only control that always works.
Layer three
Blacklists and DNSBLs
A DNSBL is a zone you query over DNS: ask about a domain or IP, and a 127.x.x.x answer means listed. Receivers consult them at connection time, so a listing costs you before the message is examined. Not all of them matter, and knowing which is the difference between a calm afternoon and a panicked one.
The lists that actually change outcomes
Spamhaus is the one that matters most, and it is several lists. The SBL covers IPs under the control of spammers and abusers; the XBL covers individual addresses showing signs of compromise, and expires listings automatically once the behaviour stops; the PBL covers end-user ranges that should never send directly to a destination; the DBL lists domain names only, no IPs at all. ZEN is the combined IP zone most receivers query as a single lookup, and it bundles four lists: SBL, CSS, XBL and PBL.
Source: Spamhaus[15]
For cold email on a shared sending platform, the DBLis usually the one that bites — it lists domains, and your sending domain and your link-tracking domain are both domains. The IP lists are typically your platform's problem, not yours, which is one of the reasons agencies rent infrastructure rather than run it.
Beyond Spamhaus: SpamCop's SCBL lists IPs that transmitted mail its users reported, and is time-based, so listings clear automatically once the reports stop[17]; Barracuda's reputation list is widely deployed and takes self-service removal requests, typically processed within 12 hours when the request explains the cause[18]; SURBL lists URIs found in spam messages, which again means your tracking domain.[19]
What a listing actually does
It varies by receiver and by list. Some receivers reject at the SMTP transaction, some score it heavily and let the message into spam, some ignore a given list entirely. The uncomfortable part is that you rarely find out which — a listing shows up as a diffuse drop in placement across some recipients and not others, which is exactly the shape of problem that gets misdiagnosed as bad copy.
Getting delisted
Spamhaus runs a public Blocklist Removal Center: look the domain or IP up, and if it is listed you get the reason and a removal path. Most listings are removable once the underlying cause is fixed, and many expire on their own if the behaviour stops.
Source: Spamhaus[16]
Two rules make delisting go well. First, fix the cause before you request removal — a domain relisted an hour later is treated worse than one that waited. Second, cut volume while you wait; continuing to send at full rate into a listing is how a recoverable week becomes a replaced domain.
Spamhaus is explicit that there is never a charge for removing any Spamhaus listing.[16] Some other operators do sell expedited delisting. That is a fact about the list, not about your domain: before paying, or losing a weekend, check whether the receivers you actually care about query that zone at all. Several of the noisiest lists are consulted by almost nobody.
Layer four
Sending domains vs link-tracking domains
These are two different assets doing two different jobs, and conflating them produces both wasted work and missed risk.
The sending domain
The domain in the mailbox address. It needs SPF, DKIM, DMARC and working MX, it accumulates reputation with every send, it has an age that receivers weigh, and it has a registry expiry date that will take every mailbox on it offline at once if missed. This is the asset.
The link-tracking domain
A CNAME pointing at your sending platform, used to rewrite links so opens and clicks can be attributed. It sends no mail. It needs no SPF, no DKIM, no DMARC and no MX — those records authenticate mail, and this domain does not send any. Adding them is harmless and pointless.
Why the tracking domain still needs a blacklist check
Because it appears inside the message. URI-based lists such as SURBL and Spamhaus's DBL list domains found in spam bodies, and a receiver scanning your links does not care that the domain never sent anything. A listed tracking domain flags every tracked link in every campaign that uses it, across every client sharing it — which, on a shared platform default, can be a lot of clients.
This is the strongest practical argument for a custom tracking domain per client rather than the platform default: a shared default puts your clients' deliverability on the same reputation as everyone else's campaigns on that platform.
Why a new tracking domain is not live immediately
Nothing propagates, technically — DNS is pull-based. What actually happens is that resolvers everywhere are still holding a cached answer, or a cached absence of one, and will keep serving it until it ages out. RFC 1035 defines the TTL as the interval a record may be cached before the source is consulted again; until every resolver in the path between your platform and your DNS host has expired its copy, some of them will keep saying the CNAME does not exist.
Source: IETF[8]
So the wait is not a fixed number of hours — it is your TTL. Google puts it plainly: a record with a TTL of 86,400 seconds takes up to 24 hours for a change to apply, and one with a TTL of 3,600 takes up to an hour.[11] Sending platforms tend to quote a flat one-to-three day window before they will call a tracking domain broken; that is a safety margin covering the TTLs they commonly encounter, not a standard, and we have not found a primary source that fixes the number.
Two practical consequences. First, lower the TTL before you make a change, not after — the old TTL governs how long the old answer survives. Second, do not re-do correct DNS while you are waiting: re-creating a record that was right the first time resets nothing and costs you another cycle. Once the wait clearly exceeds the TTL, stop blaming propagation and check that the CNAME actually resolves and is not proxied — a Cloudflare record in anything other than DNS-only mode will not verify.
Layer five
What normal looks like
Two kinds of number live here and they deserve different amounts of trust. A receiver's published threshold is a rule you can be judged against. A platform average is a description of what other senders did, which is useful for sanity-checking and useless as a target.
Published by the receivers
These are rules. Crossing them has defined consequences.
- Spam complaint rate
- Google states both: keep the rate reported in Postmaster Tools below 0.30%, and separately advises keeping it below 0.10% and never reaching 0.30% or higher. Yahoo publishes the same 0.30% ceiling.[9]
- Bulk sender threshold
- Google counts messages to personal Gmail addresses only, from February 2024, and the classification is permanent once reached. Microsoft applies its own 5,000-a-day line to Outlook, Hotmail and Live. Yahoo declines to publish a threshold at all.[10]
- SPF DNS lookups
- RFC 7208 §4.6.4. Past the ceiling an implementation MUST return permerror, and the record fails whatever it says. Void lookups are separately capped, with two recommended.[1]
- Unsubscribe processing
- Google asks bulk senders to fulfil an unsubscribe request within 48 hours; Yahoo words the same requirement as within 2 days.[10]
- Minimum DMARC policy
- Google, Yahoo and Microsoft all accept a monitoring-only policy. None of the three require quarantine or reject, so publishing p=none is enough to clear the bar.[9]
Below 0.30% required, below 0.10% advised
5,000 messages a day
10 maximum
Within 48 hours
p=none
Observed, not mandated
Vendor platform data and ColdOps' own operating lines. Treat as orientation.
- Typical cold-email bounce rate
- Platform average across 850M+ sends. Useful as a sanity check, not as a target.[20]
- Bounce rate to stay under
- The line above which mailbox providers start filtering. ColdOps alerts here by default.[20]
- Emails per mailbox per day
- Vendor guidance from platform data. No mailbox provider publishes a per-mailbox number, so treat this as convention, not a rule.[20]
- Sends before a bounce rate means anything
- ColdOps' own volume floor. Below it a single bounce swings the percentage, so neither the alert nor the dashboard shows a rate.[20]
1.54%
2%
14 typical, 50 as a ceiling
100
Bounce rate
Typical cold email runs around 1.54%, and mailbox providers begin filtering above roughly 2%. Bounces are the cheapest reputation damage to avoid, because the cause is almost always list quality and the fix is verification rather than infrastructure.
Sample size decides whether a rate means anything. Four bounces on eighty sends and forty bounces on eight hundred are the same percentage and are not the same fact — the first is a coin toss, the second is an emergency. ColdOps refuses to display or alert on a bounce rate below its volume floor for exactly that reason.
Volume per mailbox
No mailbox provider publishes a safe per-mailbox number, and anyone who tells you they do is quoting a vendor. Platform data puts typical cold-email volume around 14 a day per mailbox, with 50 treated as a working ceiling. The number that matters is not the absolute volume but the rate of change.
Google's own ramp guidance is entirely qualitative, and that is the honest state of the art: start with a low volume to engaged recipients, increase slowly, send at a consistent rate, and avoid sudden spikes without a history of sending at that level.[9] There is no published day-by-day warmup schedule from any receiver. Every numeric ramp table you have seen is a vendor convention — useful as a plan, not as a rule you can cite.
Domain age
A domain registered last week has no history, and no history is treated as suspicious rather than neutral. There is no published age at which a domain becomes trusted; the working convention is to keep volume low for the first weeks and let warmup carry the traffic. ColdOps flags domains under 30 days by default.
Warmup and spam placement
Warmup builds engagement history by exchanging mail with a pool of cooperating inboxes. It is genuinely useful for establishing a new domain and it is systematically over-trusted, because a warmup score grades the tool's own traffic, not your campaigns. A workspace can show a healthy warmup score while its real campaigns bounce and land in spam — the two data sets barely overlap. When they disagree, the campaign data is the ground truth.
Google Postmaster Tools reports domain and IP reputation on a four-band scale — Bad, Low, Medium and High — alongside the spam rate the bulk-sender rules are measured against.[12]It is free, it is the receiver's own view of you rather than a vendor's, and most agencies never set it up.
Layer six
List hygiene
Bounce rate is a list metric wearing an infrastructure costume. Almost every bounce problem is a list problem, and almost every list problem is visible before you send.
Verification
A verifier attempts to establish whether an address exists without sending to it, and returns a class per address: valid, invalid, catch-all or unknown. Verifying before launch converts a reputation risk into a line item you can delete.
ColdOps treats invalid addresses above 2% of a verified list as a warning and above 5% as critical, because that is roughly where a list starts producing a bounce rate the receivers will notice.
Catch-all domains
A catch-all domain accepts mail to every address, existing or not, so no verifier can confirm an address on it. Catch-alls are not invalid and they are not safe: some resolve to a real person and some are silently discarded. A list that is mostly catch-all is a list you cannot forecast. ColdOps warns above 15% and flags critical above 25%.
Role addresses
info@, sales@, support@, abuse@ and the rest of the RFC 2142 set are shared functional mailboxes, not people. They convert poorly, they are read by whoever is on rota, and some of them are monitored specifically to catch unsolicited mail. Stripping them costs you almost no pipeline and removes a disproportionate share of complaint risk.
Source: IETF[7]
Decay
A verified list is a photograph, not a fact. People change jobs and mailboxes are deactivated continuously, so a list verified six months ago will bounce at a rate its verification report does not predict. ColdOps treats a list as stale past 30 days and critical past 60 days, adjustable per client for always-on campaigns.
When bounces run higher than the verification report predicted, the cause is usually not the list. Check the sending side first: mailbox health, authentication, warmup, and whether you are sending across ecosystems — Google senders into a Microsoft-heavy list are filtered harder than like-for-like.
The product
Every check ColdOps runs
27 checks run on every sync of every connected workspace. 7 more run once a campaign's list has been verified, 34 in total. Everything below — the names, the thresholds, the consequences and the fix steps — is generated from the same constants the detection engine reads, so this page cannot describe a product we do not ship.
Authentication and DNS
Whether the records receivers evaluate on every message are present, valid, and unchanged since the last look.
Authentication changesAn SPF, DKIM or DMARC record that resolves differently than it did on the previous check.
If you ignore it
DNS records changing under you is how senders who "changed nothing" end up in spam.
How to fix it
- 1.Check the before/after in the issue details — if your team made the change, you're done; dismiss this.
- 2.If nobody touched DNS, a vendor or DNS migration changed it — compare against your ESP's required records.
- 3.Fix or revert at your DNS provider; changes propagate within 24h.
DKIM key revokedA DKIM record whose p= tag is present but empty, which is how a key is revoked, with no live key on any selector we check. Every signature made with that key fails.
If you ignore it
A revoked key means every message this domain signs fails DKIM, and the record still looks present to most checkers.
How to fix it
- 1.If this domain signs with a selector we don't check, this is a leftover from a key rotation — delete the empty record, or dismiss this issue.
- 2.Otherwise the key is dead: generate a fresh DKIM key in your sending platform or mail host and publish it at the selector they give you.
- 3.An empty p= is how a key is revoked, so every message signed with it fails DKIM until a new key is published.
- 4.Re-check with Sync now once DNS propagates.
DMARC reporting offA DMARC record that publishes a policy but names no rua= address, so nothing collects the aggregate reports.
If you ignore it
A DMARC record with no rua= collects nothing, so spoofing and broken alignment stay invisible until placement drops.
How to fix it
- 1.Add a rua= address to the DMARC record, e.g. rua=mailto:dmarc@yourdomain.com.
- 2.Reports arrive as daily XML from each receiver — point them at an inbox you actually read, or a free DMARC reporting tool.
- 3.Without it nothing tells you who is sending as this domain, or that alignment broke after a platform change.
DNS changesThe domain's MX provider changed since the previous check — an unplanned mail-host migration.
If you ignore it
An unplanned MX move silently breaks warmup pools and reply routing for every mailbox on the domain.
How to fix it
- 1.Check the before/after in the issue details — if you migrated the domain on purpose, you're done.
- 2.If nobody moved it, review recent DNS/registrar changes — an unplanned MX move breaks warmup and reply handling.
- 3.After fixing, confirm warmup is still active on the affected mailboxes — some tools silently eject them on MX changes.
Duplicate SPF recordsMore than one v=spf1 TXT record on the domain, which is an automatic PermError under RFC 7208.
If you ignore it
Multiple SPF records are an automatic PermError — receivers treat SPF as failing on every send.
How to fix it
- 1.Merge the multiple v=spf1 TXT records into ONE — more than one is an automatic PermError.
- 2.Combine all include: mechanisms into that single record, ending with ~all.
- 3.Re-check after DNS propagates (up to 24h) with Sync now.
SPF allows any senderThe SPF record's all mechanism authorises senders it should not: +all passes every host on the internet, and ?all returns Neutral, which RFC 7208 says receivers must treat exactly like having no record. A bare all with no qualifier counts as +all.
If you ignore it
An SPF record that ends in +all vouches for anyone who forges this domain, and ?all makes the record say nothing at all.
How to fix it
- 1.Open the SPF TXT record at your DNS provider and change the ending to ~all (or -all once you are sure every sending service is listed).
- 2.+all authorises the entire internet to send as this domain; ?all tells receivers to treat the record as if it did not exist. Neither is ever the right setting for a sending domain.
- 3.Watch for a bare `all` with no sign in front of it — that means +all too.
- 4.If nobody on your team edited DNS, a vendor or a migration tool did. Check who has access before you fix it.
SPF lookup limitThe recursive DNS-lookup count on the SPF record is at or approaching the RFC 7208 ceiling of 10.
If you ignore it
Past 10 DNS lookups receivers return PermError, so SPF silently fails even though a record exists.
How to fix it
- 1.Count the include: entries in the SPF record — every tool you add appends one, and nested includes count too.
- 2.Remove includes for tools this domain no longer sends with.
- 3.Stay under 10 total DNS lookups, or receivers return PermError and treat SPF as failing.
SPF/DKIM/DMARC issuesSPF, DMARC or MX verifiably absent on consecutive checks. A lookup that simply went unanswered never counts as absent.
If you ignore it
Messages may be flagged or quarantined by Google and Microsoft until DNS is fixed.
How to fix it
- 1.Open your DNS provider and fix the flagged record (SPF, DMARC, or MX).
- 2.Missing DMARC? Start with a p=none record. Check SPF includes your ESP.
- 3.Records take up to 24h to propagate — re-check with Sync now after.
Domain reputation
Whether the domains in the envelope and in the links are trusted, listed, young, or about to lapse.
domain expiringThe registry expiry date is close enough that a missed renewal would take every mailbox on the domain offline at once.
If you ignore it
If the domain lapses, every mailbox on it goes offline at once.
How to fix it
- 1.Renew the domain at your registrar today — an expired domain takes every mailbox on it offline at once.
- 2.Turn on auto-renew and confirm the billing card on file is current.
- 3.If it already lapsed, renew immediately — most registrars hold a short grace period before DNS drops.
Domain reputationThe sending domain answers as listed on a blacklist zone ColdOps queries.
If you ignore it
A blacklisted domain gets blocked or spam-foldered across many inbox providers.
How to fix it
- 1.See which blacklist flagged the domain in Domain deliverability.
- 2.Request delisting on the blacklist's site — most process within 24–48h.
- 3.Halve volume until delisted and find what triggered it (content, volume spike, bounces).
Domains registered as one batchThe workspace's sending domains cluster into one registration batch — the same registrar, the same nameserver provider, and registration dates close enough together to read as a single purchase — and that cluster accounts for at least half of the domains RDAP could resolve. It is a property of the estate rather than a fault on any one domain: this is the shape blocklists group on, so the whole cluster carries reputation together. Domains whose registrar or nameservers did not resolve count as unknown and are never grouped with one another.
If you ignore it
Domains bought together at one registrar on one DNS provider are graded together, so a single listing can take most of this client's sending down at once.
How to fix it
- 1.Nothing here is broken yet, so treat this as a purchasing rule rather than an emergency: buy the next batch of domains somewhere else.
- 2.Split future registrations across at least two registrars, and point them at a different DNS provider from the ones already in use.
- 3.Changing the registrar alone gives you smaller batches, not fewer — the nameservers have to move too, because that is the second signal blocklists group on.
- 4.Do not re-register the existing domains to break up the group. They already carry warmup history and age, and both are worth more than the pattern costs.
- 5.If one of these domains does get listed, check the others in Domain deliverability first — a listing against one is usually a listing against the group.
Tracking domain blacklistedThe custom link-tracking domain answers as listed on a blacklist zone, which flags every tracked link in the campaign.
If you ignore it
A blacklisted tracking domain flags every tracked link you send, dragging placement down across campaigns.
How to fix it
- 1.Pause link tracking on the affected mailboxes, or switch them to a fresh custom tracking domain.
- 2.Request delisting on the blacklist's site — most process within 24–48h.
- 3.Consider sending without link tracking until it clears; flagged links hurt placement even when the copy is clean.
Tracking domain issuesThe sending platform has reported the tracking domain as not active for longer than a DNS change could plausibly take to propagate.
If you ignore it
A broken tracking domain can break or flag every tracked link, hurting clicks and inbox placement.
How to fix it
- 1.A newly added tracking domain can take up to 72 hours to propagate. We only flag this after it has been reported not active for longer than that, so it's unlikely to be propagation.
- 2.Open the affected mailboxes in your sending platform and re-check the tracking domain (CNAME) status.
- 3.Check the CNAME still resolves at your DNS provider and isn't proxied (e.g. Cloudflare must stay DNS-only).
- 4.If it can't be fixed quickly, disable link tracking on those mailboxes rather than sending with a domain the platform won't verify.
young domainThe sending domain is younger than your configured age (default 30 days, adjustable from 7 to 90).
If you ignore it
New domains are distrusted by inbox providers and land in spam more often.
How to fix it
- 1.Keep volume under ~20 emails/day per mailbox while the domain is under 4–6 weeks old.
- 2.Keep warmup running and ramp up slowly.
- 3.Don't attach young domains to high-volume campaigns yet.
Mailbox and sending health
Whether the infrastructure underneath the campaign is actually able to deliver, and whether it is degrading.
accounts disconnectedA mailbox the sending platform reports as disconnected, in a sending-error state, or bouncing at the account level. Severity is proportional: critical once hard failures reach 25% of the workspace's mailboxes, a warning below that.
If you ignore it
Disconnected mailboxes send nothing — daily outbound capacity drops until they reconnect.
How to fix it
- 1.Open your sending platform's email accounts and find the disconnected mailbox.
- 2.Re-authenticate it (Google/Microsoft sign-in or app password).
- 3.If it keeps disconnecting, pause it for a few hours, then resume at low volume.
Bulk sender thresholdA single day on which one primary domain sent 5,000 messages or more, counting every subdomain together the way Google does. Total volume is an upper bound on the Gmail-bound volume Google actually counts, so this flags the risk of crossing the line, never the fact of it.
If you ignore it
Once a domain crosses Google's bulk-sender line even once, its requirements apply to that domain permanently.
How to fix it
- 1.Meet Google's bulk sender requirements on this domain: SPF and DKIM both passing, a DMARC record, and one-click unsubscribe (RFC 8058) on every send.
- 2.Keep the spam-complaint rate under 0.10% and never above 0.30% — that is the line Google enforces on bulk senders.
- 3.Subdomains do not split the count. If you spun subdomains to spread volume, split across separate registered domains instead, or accept the volume as one sender.
- 4.The designation does not expire, so treat these requirements as permanent for this domain rather than something to switch on when volume is high.
Inbox placement mismatchThe recipient mix is concentrated on an ecosystem the sending mailboxes are not on — Microsoft-heavy recipients, Google-only senders, or the reverse.
If you ignore it
Mail crossing ecosystems (e.g. Google → Microsoft) is filtered harder, quietly losing inbox placement.
How to fix it
- 1.Add sending mailboxes on the recipients' ecosystem (e.g. Microsoft-hosted senders for a Microsoft-heavy list) so more mail stays in-ecosystem.
- 2.Or split the campaign and route each ecosystem's recipients to matching senders.
- 3.Warm any new mailboxes before ramping their volume.
mailbox burn acceleratingMailboxes on the workspace are degrading faster than their own recent rate, not merely degrading.
If you ignore it
Mailboxes are degrading faster than usual, shrinking healthy sending capacity.
How to fix it
- 1.Open the client's Mailboxes table and find which accounts burned recently.
- 2.Pause or replace burned mailboxes and spread their volume across healthy ones.
- 3.Slow the ramp — burn spikes usually follow a volume increase or a list-quality drop.
spam placementThe platform's WARMUP traffic — the pool's own test messages, not your campaigns — is being filtered to spam for at least 5% of a mailbox's warmup sends, over a floor of 100 sends. ColdOps runs no seed list and no inbox-placement test, so this is the earliest reputation signal available, not a measurement of where your campaigns land.
If you ignore it
Warmup mail being filtered to spam means these mailboxes' reputation is already failing, before any real send pays for it.
How to fix it
- 1.Cut send volume in half immediately.
- 2.Fix any failing SPF / DKIM / DMARC checks (see Domain deliverability).
- 3.Pause the worst mailboxes and let warmup rebuild reputation for 1–2 weeks.
Campaign performance
Movements in the numbers that show a deliverability problem before anyone names it as one.
bounce spikeBounce rate above your configured line (default 2%), once the campaign has at least 100 recent sends. Critical fires at 2x this line, minimum 5 percent. When the workspace's warmup score still reads healthy, the alert says so — warmup grades the tool's own test traffic, so the campaign data wins.
If you ignore it
High bounce rates burn sender reputation and push more mail to spam.
How to fix it
- 1.Pause the affected campaign before the domain takes more reputation damage.
- 2.Re-verify the lead list and remove invalid + catch-all addresses.
- 3.Resume at reduced daily volume once bounces are back under 2%.
campaign completedInformationalThe platform reports the campaign finished. Logged as activity, not as a problem — it carries no health penalty.
If you ignore it
The campaign has finished — no new sends until it's relaunched or replaced.
How to fix it
- 1.Ask the client: relaunch with a new list, or wind down?
- 2.Archive the campaign in Instantly if it's done for good.
campaign errorThe platform reports the campaign itself in an error state.
If you ignore it
A campaign error can stop sends until the failing mailbox or setting is fixed.
How to fix it
- 1.Open the campaign in Instantly — the error banner names the failing mailbox or setting.
- 2.Reconnect or pause any failed mailboxes attached to the campaign.
- 3.Resume the campaign, then hit Sync now in ColdOps to confirm the issue clears.
campaign not sendingAn active campaign that is not sending, established two ways. Where the platform publishes a reason (Instantly today) it is used directly, and only when that reason is not routine — out of schedule, daily limit met, waiting between follow-up steps, paused, draft and completed all mean the campaign is behaving — and only once the condition has lasted an hour, so a sync landing mid-reconnect stays quiet. On every platform it is also derived from the campaign's own send history: 3 straight weekdays on which the platform reported zero sends for that campaign, after it had sent at least 50 emails across at least 5 of the weekdays before it stopped, on 60% of them, and at least 10 on one of the last two weekdays it sent on — a campaign that shrank to a few emails a day over several days wound down rather than stopped. Weekends are never counted, and neither are the two most recent days, which are still in progress somewhere. Crucially, other campaigns in the same workspace must have kept sending through the silence: a public holiday, a closed schedule window or an outage stops everything at once, and only a campaign that goes quiet while its neighbours keep working is reported. A day with no reading is treated as unknown rather than as zero, so a failed sync or a platform that answered with nothing cannot read as a stopped campaign. A routine platform reason silences the derived half only where it can account for days at a time — paused, draft, completed, a follow-up delay, a subsequence, or an empty list. "Out of schedule" and "daily limit met" explain tonight, not three weekdays in a row, so the check still speaks over them: a sending window that never opens is the finding, not the excuse.
If you ignore it
The campaign is live but nothing is going out, so this client is paying for sends that never happen.
How to fix it
- 1.Open the campaign on your sending platform and check whether it is actually going out today.
- 2.Unhealthy or unavailable mailboxes: reconnect them, or detach them and attach healthy ones.
- 3.Bounce protection: clean the list before resuming, or it will halt again on the same addresses.
- 4.Check the sending schedule and the daily limits — a window that closed or a limit set to zero stops a live campaign silently.
- 5.Hit Sync now afterwards to confirm the campaign starts sending again.
out of leadsThe campaign has almost no unsent leads left in its list.
If you ignore it
With no leads left, the campaign stops reaching new prospects.
How to fix it
- 1.Upload a fresh verified lead list to the campaign.
- 2.Or pause the campaign so its mailboxes stay on warmup only.
reply rate dropThe last week's reply rate has fallen at least 50% below the campaign's own trailing four-week baseline (configurable), with enough volume in both windows for the comparison to mean anything. When the workspace's warmup score still reads healthy, the alert says so — warmup grades the tool's own test traffic, so the campaign data wins.
If you ignore it
Fewer replies from the same volume means fewer meetings booked for this client.
How to fix it
- 1.Rotate the step-1 subject line — fatigue is the usual cause on long-running campaigns.
- 2.Send a test to a seed inbox to check spam placement.
- 3.Review copy changes made right before the drop and revert them.
volume dropSend volume has fallen well below the campaign's own prior rate, with enough prior volume for the fall to be real.
If you ignore it
Lower send volume means fewer prospects reached and fewer replies downstream.
How to fix it
- 1.Check that sending mailboxes are active and not hitting daily limits.
- 2.Look for paused campaigns or exhausted lead lists.
- 3.Confirm the sending schedule still covers business hours.
List quality
Runs once a campaign's list has been verified. Four of these need at least 50 unique addresses before a percentage means anything.
Bounces exceed list qualityAfter verificationThe campaign's measured bounce rate is above 2% (critical above 3%) while the verified list said it should be cleaner — a prompt to look at the sending side.
If you ignore it
Bounces higher than the list's quality suggests point to a sending-side or list-age cause worth checking.
How to fix it
- 1.The list verified clean, so check sending-side causes first: mailbox health, SPF/DKIM/DMARC, and warmup.
- 2.Look at the recipient-provider mix — cross-ecosystem sending (e.g. Google→Microsoft) filters harder.
- 3.If the list is old, re-verify it — addresses decay after verification.
Catch-all addresses on listAfter verificationCatch-all addresses above 15% of the verified list, critical above 25%.
If you ignore it
Catch-all domains can't be confirmed, so a chunk of sends may silently fail or bounce.
How to fix it
- 1.Catch-all domains accept anything, so deliverability can't be confirmed — expect some silent failures.
- 2.Consider sending to catch-all contacts on a separate, lower-volume schedule.
- 3.For key accounts, verify individually or find a confirmed second contact.
Invalid addresses on listAfter verificationInvalid addresses above 2% of the verified list, critical above 5%.
If you ignore it
Invalid addresses hard-bounce, and bounces burn sender reputation for the whole campaign.
How to fix it
- 1.Remove the invalid addresses from the list before they bounce — the verification already flagged them.
- 2.Re-upload the cleaned list to the campaign in your ESP.
- 3.Tighten the source: invalid rates this high usually mean an old or unscraped list.
List never verifiedAfter verificationMore than 10% of the campaign's contacts have no verification result, critical above 25%.
If you ignore it
Unverified contacts are unknown risk — they can hide invalids that bounce once you send.
How to fix it
- 1.Upload the missing contacts here so ColdOps can verify the whole list.
- 2.Until then, treat unverified contacts as unknown risk — they may include invalids.
- 3.Make verification a step in your list-building process before launch.
List verification failedAfter verificationA verification job did not complete, so there is no list-health read to separate list problems from sending problems.
If you ignore it
Until verification completes, there's no list-health read to tell list problems from sending problems.
How to fix it
- 1.Check your verifier in Settings → Connections — the API key may be revoked, or the balance too low for the list.
- 2.Top up credits with your verification provider if that's the cause.
- 3.Re-upload the list from the campaign's List Health section to try again.
List verification out of dateAfter verificationThe list was last verified more than 30 days ago, critical past 60 days. Configurable per client.
If you ignore it
Verified lists decay over time as inboxes are deactivated, so old checks bounce more.
How to fix it
- 1.Re-verify the list — inboxes churn, so a list decays a few percent a month.
- 2.Use the Re-verify action on the List Health card to submit a fresh batch.
- 3.For always-on campaigns, re-verify on a schedule (every 30–45 days).
Verifier credits running outAfter verificationThe verification account funding your lists is close to empty, so the next list would go out unchecked.
If you ignore it
Your next list won't verify — so it either goes out unchecked, or the campaign waits on a top-up.
How to fix it
- 1.Top up credits in your verifier's own dashboard — ColdOps uses your account, so we can't buy them for you.
- 2.Turn on auto-refill there if it's offered; it's the only version of this that never comes back.
- 3.Settings → Connections shows the live balance once you've topped up.
Connection
Whether ColdOps can still see the workspace at all.
sync failedThe workspace's API key stopped working, or the platform stopped answering, so there is no fresh data to check.
If you ignore it
We can't pull fresh data for this workspace until the connection is restored.
How to fix it
- 1.Check the workspace API key in Settings → Connections — replace it if it was rotated or revoked.
- 2.Run Sync now to retry.
- 3.Still failing? The workspace itself may be suspended or its plan expired — check its billing in your sending platform.
Counts and thresholds on this page are interpolated from the same constants the detection engine reads — ISSUE_TYPES, the benchmark guardrails and the List Health bands. A test in the repository fails the build if this page states a number by hand that a constant already defines, so the reference cannot drift away from the product it describes.
Provenance
Sources
Every standard, threshold and requirement above is cited to a primary source — an RFC, a receiver's own postmaster documentation, a vendor's own announcement, or the list operator itself. Anything that could not be traced to one was left out rather than rounded off.
What we deliberately left out
Several numbers that circulate widely could not be traced to a primary source, so they are absent rather than hedged: a day-by-day warmup schedule attributed to Google; SpamCop's exact listing-expiry duration; the delisting fees charged by the lists that charge; whether Microsoft's rejection enforcement is what actually runs today; and a fixed hour count for DNS propagation. If you find one of them stated confidently elsewhere, ask where it came from.
- [2]IETFRFCSeptember 2011RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures
- [3]IETFRFCJanuary 2018RFC 8301 — Cryptographic Algorithm and Key Usage Update to DKIM
- [5]IETFRFCMay 2026RFC 9990 — DMARC Aggregate Reporting
- [6]IETFRFCJanuary 2017RFC 8058 — Signaling One-Click Functionality for List Email Headers
- [7]
- [8]IETFRFCNovember 1987RFC 1035 — Domain Names: Implementation and Specification
- [9]GooglePostmaster docsEmail sender guidelines (Gmail Help)
- [10]GooglePostmaster docsEmail sender guidelines FAQ — bulk sender requirements
- [11]GooglePostmaster docsDNS basics — TTL and how long a record change takes to apply
- [12]GooglePostmaster docsPostmaster Tools dashboards — spam rate, domain and IP reputation
- [13]YahooPostmaster docsSender Requirements & Recommendations
- [14]MicrosoftVendor announcementApril 2025Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders
- [15]SpamhausList operatorThe Spamhaus Project — DNSBL Datasets
- [16]SpamhausList operatorSpamhaus Blocklist Removal Center
- [17]SpamCop / Cisco TalosList operatorSpamCop Blocking List (SCBL) — FAQ
- [18]Barracuda NetworksList operatorBarracuda Reputation Block List (BRBL)
- [19]SURBLList operatorSURBL — URI reputation lists
- [20]SmartleadIndustry data2026The State of Cold Email 2026 (H1) — platform data, 850M+ emails