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.
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.
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.
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
35 checks run on every sync of every connected workspace. 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 — and whether the estate hands receivers a pattern to group.
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
Expiry takes every mailbox and live campaign on this domain down at once — renewing before the lapse is a two-minute fix.
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 reply floorA sending domain whose mail is accepted, does not bounce, and is almost never answered. It is judged against the other sending domains in the same workspace over the same window rather than against a fixed number, because a reply rate that means burned for one offer means excellent for another: it fires when a domain carrying real volume returns at or below 25% of the median reply rate of its peers. A normal bounce rate is required rather than incidental. Bounces above the danger line mean a list problem, which bounce_spike already reports, so the case left here is the one with no other explanation: mail delivered somewhere nobody reads. 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
Left unresolved, this hurts deliverability and replies for this client.
How to fix it
- 1.Stop sending from this domain before anything else. Every further send on a domain in this state deepens the pattern that put it there.
- 2.Do not swap the mailboxes out. They are fine, which is exactly why their bounce rate is normal and their warmup score is green. Reputation sits on the domain, so new inboxes on it inherit the problem within days.
- 3.Check where its replies are actually going before you retire it. If your campaigns use a central reply-to address on another domain, the replies this domain earned are being credited there, and the number here understates it. Filtering your inbox for that domain settles it in a minute.
- 4.Decide whether it is worth rescuing. Re-warming means weeks at very low volume sending the same number every day, and a domain costs less than the weeks do. If it carries no brand value, retire it and move the volume onto domains already earning replies.
- 5.Do not replace it with a fresh batch bought the same afternoon. That is the shape blocklists group on, and it is a separate finding in this dashboard.
Domain reputationThe sending domain answers as listed on a blacklist zone Coldops queries.
If you ignore it
Every mailbox on this domain takes the hit across every campaign — sending through the listing extends it.
How to fix it
- 1.See which blacklist flagged the domain — open its row in the Domains section.
- 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 the Domains section first — a listing against one is usually a listing against the group.
Identical copy across clientsCampaigns belonging to different clients whose first email's visible text is identical, compared on the first variant after stripping formatting, link targets and merge fields. Exact match only, never a similarity score — and campaigns within one client stay out of it, since they share a mailbox pool anyway.
If you ignore it
The same email from several clients' domains looks like one operation to receivers — one pattern a filter can group, and a filter that catches it catches every client involved at once.
How to fix it
- 1.Open the campaign this issue names — its first email's text matches campaigns running for other clients.
- 2.Rewrite the opening line and the angle per client, not just merge fields — the body text is what can be grouped, and the merge fields are already ignored in this comparison.
- 3.If two clients genuinely share an offer, stagger the campaigns so the identical copy is not in flight from both estates at once.
Shared tracking domainAn active campaign tracks opens while no mailbox in the workspace has a custom tracking domain, so the pixel and any rewritten links load from the sending platform’s shared default — a host the agency does not control.
If you ignore it
Every tracked message references a domain the agency does not control and shares with strangers, and filters score the domains inside a message, not just the sender.
How to fix it
- 1.Decide first whether you want open tracking at all — cold email usually reads better without it, and turning it off removes this risk entirely rather than moving it.
- 2.If you keep tracking: add a custom tracking domain in your sending platform (a CNAME on a subdomain you own, e.g. link.yourdomain.com) and assign it to every mailbox in the workspace.
- 3.Use a subdomain of a domain you already send from, not a fresh one — a brand-new host referenced in every message has no reputation of its own.
- 4.Re-check after the platform reports the domain healthy; Coldops then watches that domain for blacklisting like any other.
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
Volume too early burns the domain — replacing a burned one means a new domain plus weeks of warmup.
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
Daily sends run short until these are re-authenticated — a disconnected mailbox rarely comes back on its own.
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 bounce rate highA single mailbox bouncing above your configured line (default 2%) over its last 30 days, once that mailbox has at least 30 sends and 5 bounces in the window — the case the campaign average hides, because one hot mailbox in a large fleet barely moves the blend. Raised once per workspace, listing the offending mailboxes. It stays quiet while a campaign-level bounce spike is already open on that workspace so one event never alerts twice.
If you ignore it
A few mailboxes bouncing hard can burn their domains while the campaign's overall rate still looks fine.
How to fix it
- 1.Pause the worst-bouncing mailboxes in your sending platform before their domains take more reputation damage.
- 2.Check what the flagged mailboxes have in common — the same lead list segment or the same sending domain. A single flagged mailbox usually means its own reputation slipped.
- 3.Re-verify the list segment they were sending and remove invalid + catch-all addresses.
- 4.Resume the mailboxes at reduced daily volume once their bounce rate is back under your alert line.
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 page 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.
Sending rides on one domainMost of a workspace's recent volume riding on one primary domain, counting subdomains together — the single point of failure a blocklisting turns into a near-total stop. Yields to the bulk-sender check when both would fire on the same workspace.
If you ignore it
One domain carries nearly all of this workspace's sending — the day it lands on a blocklist, nearly everything stops with it.
How to fix it
- 1.Check which domains this workspace already has connected and how their volume splits — this issue names the one carrying almost everything.
- 2.Move part of the sending schedule onto the under-used domains you already warm — spread the existing volume, don't add fresh domains for it.
- 3.If the workspace genuinely has one domain, treat it as the single point of failure it is: keep its bounce rate low and its list verified, because there is no fallback when it burns.
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 50 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 (open the domain in the Domains section).
- 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
Each send past this point does damage that outlives the campaign — it sticks to the domain, not the list.
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 hygieneAn active campaign with open tracking switched on, or sending HTML instead of plain text — both are settings spam filters score against cold outreach. Read from the campaign's own reported settings (Instantly today); a platform that reports neither flag stays silent rather than guessed at. Informational only: it carries no health penalty and sends no alert.
If you ignore it
Tracking pixels and HTML formatting read as bulk mail to spam filters, so both quietly cost inbox placement on cold outreach.
How to fix it
- 1.Turn open tracking off in the campaign's settings — cold email is judged on replies, and the tracking pixel is one more thing filters can score.
- 2.Switch the campaign to plain-text sending. HTML wrappers and remote images read as bulk mail; plain text reads like a one-to-one email.
- 3.If you need open data for a specific test, run it briefly on a custom tracking domain instead of leaving tracking on across the account.
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 — zero sends until the cause is cleared.
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.
open rate dropThe last week's open rate has fallen at least 60% below the campaign's own trailing four-week baseline, with enough volume and enough baseline opens for the comparison to mean anything. Opens are bot-inflated as an absolute number, so the check only trusts a collapse against the campaign's own history — and it stands down entirely when open tracking is off or the platform reports no per-day opens, because there is no baseline to fall from.
If you ignore it
Opens are the earliest placement signal — when they fall this far below the campaign's own baseline, replies usually follow within days.
How to fix it
- 1.Send a test to a seed inbox on Google and Microsoft — a sudden open collapse is usually placement, not copy.
- 2.Check the campaign's sending domains against the blacklist and authentication findings on this client.
- 3.If opens read exactly zero, confirm open tracking is still enabled on the campaign before treating it as placement.
out of leadsThe campaign has almost no unsent leads left in its list.
If you ignore it
Follow-ups finish and then nothing sends — warmed mailboxes sit idle until the list is topped up.
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.
Reaching no new leadsThe campaign is still sending real volume, but the share of those sends that reach someone for the FIRST time has fallen at least 75% below its own trailing four-week baseline AND is under 5% of sends — so almost every email going out is a follow-up to someone already in sequence. Measured over seven-day windows, because the daily new-contact count is naturally lumpy: leads are uploaded in batches and drain over days, and single-day rules fire on ordinary quiet days. This matters most for what it prevents: reply rate is counted per send, so it falls on its own once the send mix fills with second and third touches, and the reply-rate alert is suppressed while this is open so the fall is never blamed on copy. Needs a provider that reports new contacts per day (Instantly today); it stays silent rather than guessing on platforms that do not.
If you ignore it
Full send volume is going to people already in sequence, so no new conversations start — and reply rate per send falls on its own, which reads as a copy problem it is not.
How to fix it
- 1.Treat any reply-rate fall on this campaign as unexplained until the list is topped up — reply rate is measured per send, so it falls on its own once most sends are follow-ups rather than first touches.
- 2.Upload a fresh verified lead list. The campaign is still sending its full daily volume; it just has nobody new to send to.
- 3.Check the campaign's new-leads-per-day limit on your sending platform. A cap set low (or to zero) starves a campaign that still has plenty of leads left in its list.
- 4.If no more leads are coming, cut the daily send limit to match the follow-ups still owed, so the mailboxes are not burning capacity on an empty funnel.
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
Sends have fallen to a fraction of the prior week's volume — replies follow the volume down.
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.
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, and the benchmark guardrails. 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