The Sending-Domain Health Reference: Which Signal Means Pause

This is a lookup document for the deliverability signals on an outreach sending domain. It is for the RevOps and recruiting-ops owner who has to decide, mid-incident, whether to keep sending, throttle, pause, or start recovery. Jump to the signal that tripped, read its exact threshold, what it proves, and how it lies to you, then take the matching action.

Most guidance you will find on this bundles one number - usually 0.3% - with a product pitch. That single number is true and insufficient. The real work is knowing which of half a dozen signals tripped, whether the reported figure can be trusted, and what the correct response is for each. This reference gives you that, updated for the 2024 Gmail and Yahoo bulk-sender rules, Microsoft's May 2025 enforcement, and the Postmaster Tools v2 change that removed the domain-reputation early-warning light.

The threshold table: which number means which action

The fastest read is a band. Map the tripped signal to its number, and the number to keep, throttle, or pause. These bands come from Google's published guidance and independent deliverability sources, not from any one vendor's marketing.

The complaint bands follow Google's guidance to stay below 0.1% and never reach 0.3%. The bounce bands follow Validity's 2024 State of Email finding that placement degrades above 2% and providers throttle or reject above 5%. The hard-bounce floor of 0.5% reflects that permanent 5xx failures should be rare on a clean list.

Two rules sit behind the table. First, the bands are slopes, not cliffs: the damage from a rising complaint rate builds well before you hit the enforcement line. Second, hard bounces (permanent 5xx failures) and soft bounces (temporary 4xx failures) are different animals. Suppress every hard bounce immediately. Retry soft bounces automatically and suppress an address after roughly three persistent failures.

How the three providers actually enforce

Gmail, Yahoo, and Microsoft share a 5,000-per-day bulk-sender line and a 0.3% complaint ceiling, but they diverge on volume definitions and on what non-compliance does to your mail. Read this table before you assume one provider's behavior applies to another.

Since February 2024, Google and Yahoo require anyone sending 5,000 or more messages a day to personal Gmail or Yahoo addresses to authenticate with SPF and DKIM, publish a DMARC record, include a one-click unsubscribe link, and keep the spam-complaint rate under 0.3%. Yahoo is the exception on volume: it has explicitly declined to publish a numeric threshold, applying its rules to "significant volume" instead. Microsoft uses the same 5,000-per-day line for its consumer domains.

The behavioral difference matters most when you are diagnosing a bounce. Gmail and Yahoo apply graduated filtering, so non-compliance shows up as slowly worsening placement with no single SMTP code to catch. Microsoft is blunt: beginning May 5, 2025, it rejects non-compliant bulk mail with a permanent error. The exact string is 550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level. Because it is a permanent 5xx rejection, the message is never retried and never reaches the inbox or the junk folder.

There is one more enforcement gate worth knowing precisely. One-click unsubscribe (RFC 8058) has been enforced since June 2024 and requires two specific headers in every marketing email: List-Unsubscribe and List-Unsubscribe-Post. Google accepts only RFC 8058 headers. Yahoo also accepts a mailto fallback. If your unsubscribe is a link in the body but not in the headers, Google treats you as non-compliant.

Why the complaint rate lies: the denominator problem

The single most dangerous misread on this whole page is a clean-looking complaint rate that hides a filtering problem. The rate is complaints divided by inbox-delivered mail, not by total sent. Gmail reports the share of DKIM-authenticated messages delivered to engaged recipients' inboxes that recipients then mark as spam. Yahoo calculates its rate on inbox-delivered mail too.

Follow the mechanism. If most of your mail is already routing to spam folders, those recipients never see it and never complain, so the denominator shrinks to the small slice Gmail allowed into the inbox. A domain can send thousands of messages, have low opens, and still show a high reported spam rate on that slice. Inverted, a domain in real trouble can post a falsely low number because the mail that would have generated complaints never landed in an inbox.

The worse your placement gets, the safer your dashboard looks. That is the trap.

The correction is to never read the complaint rate against total sent. Read it against inbox-delivered volume, and cross-check with engagement. If opens and replies are falling while your complaint rate looks fine, the low rate is an artifact of poor placement, not proof of health. Since October 2025 this cross-check matters more than ever, because the domain-reputation chart that used to flag placement decay is gone.

Reading engagement decay when the reputation light is gone

With domain and IP reputation removed from Postmaster Tools, complaint rate and bounce rate are now the earliest signals you have. Google redirected users to v2 on September 30, 2025, retired the old dashboard on October 31, 2025, and is retiring the v1 API by the end of 2025. Every dashboard carried over except Domain and IP Reputation, which are gone entirely.

What v2 keeps: spam rate, delivery errors, authentication status, encryption levels, feedback loop data, and a new Compliance Status dashboard that runs eleven checks and pairs a compliant or needs-work verdict with a specific reason. What you lost is the reputation warning light teams used to detect trouble before complaints spiked. That safety net is gone, so leading indicators now do the job that reputation used to do.

In practice this means engagement decay becomes a first-class signal. A falling open rate, a reply-rate cliff, or a sudden drop in delivered volume on an unchanged send is the early tell that placement is slipping. Because these leading signals now carry the weight, watch them daily. Gmail computes the spam rate daily, so a single Wednesday spike to 0.6% is a real hit even if the month averages 0.04%.

The recovery timeline: delisting is fast, reputation is slow

Recovery has two clocks that people conflate, and conflating them is how teams get re-listed. Delisting from a blacklist is fast. Rebuilding the reputation that got you listed is slow. Treat them as separate timelines.

Full domain-reputation recovery usually takes 4 to 12 weeks after the root cause is fixed. A light dip with clean authentication recovers in 2 to 4 weeks. A damaged domain with spam complaints, list problems, or blacklist listings needs 8 to 12 weeks or longer. A blacklist rebuild is roughly two to three times the length of a light dip.

The trap is resuming full volume the moment delisting confirms. Spamhaus can clear you in 24 to 72 hours, but if you jump back to prior volume the same behavior re-triggers the listing, and subsequent appeals are much harder to win. There is also a recoverable-eligibility clock on Gmail: a sender above 0.3% becomes ineligible for Gmail's mitigation support and regains eligibility only after keeping the rate below 0.3% for seven consecutive days.

This is also where in-house expertise runs thin. In Refolk's index of professional profiles, only 30 named US email-deliverability specialists, managers, and consultants exist versus 7 in the UK, a roughly 4.3x gap. Narrower still, only 9 US profiles pair the DMARC skill with an "email deliverability" headline, and only 2 pair the deliverability skill with a cold-email or outbound headline. Most teams meet these incidents without an in-house expert, which is exactly why a lookup reference like this one earns its keep.

The procedure: from tripped signal to stable resume

Run this in order. The single most common failure is skipping straight to delisting or warm-up before the root cause is fixed, which resets the clock and burns goodwill with the blacklist.

Sources agree on stop-first. They disagree on whether to burn a torched domain or recover it: one school favors architecture that isolates outbound so a damaged domain can be discarded, another holds that most damage is recoverable with discipline. The deciding factor is the root cause. If the cause is a dirty list, a new domain buys you nothing, which is covered below.

Fixing authentication is the step engineers most often get wrong under pressure. Verify all three results pass on a real test message, not just that the records exist. A DMARC record that is present but invalid is worse than useless. Validity's January 2025 study found that 84% of From-domains had no DMARC record at all, and of the 16% that did, 7.64% were invalid.

How this goes wrong: the false positives that cost you

This is the section to read twice. Every threshold above can be reported truthfully and still lead you to the wrong action, because the number is measured in a way that hides the real state. Here are the failure modes, what the false reading looks like, and the check that catches it.

A clean complaint rate that hides filtering. The dashboard shows 0.05% because most mail already went to spam and those recipients never saw it. The rate is calculated on a shrunken inbox denominator. Check: read the rate against inbox-delivered volume and cross-check against opens and replies, not against total sent.

Treating 0.3% as a cliff, not a slope. The spam rate's impact on delivery is graduated, and the damage starts building well before 0.3%. A team that only acts at the cap has already lost placement. Check: investigate at 0.2%, not 0.3%.

Averaging away a bad day. Gmail computes the spam rate daily. A single Wednesday spike to 0.6% is a real hit even if the month averages 0.04%. Check: read the daily chart, not the monthly average.

A campaign-level bounce average masking one bad inbox. A 10-inbox pool can post a healthy overall bounce rate while one inbox generates 5% or more on its own. Check: view bounce per inbox, not per campaign.

Delisting without fixing the root cause. Requesting delisting before the underlying issue is fixed results in immediate re-listing, and subsequent appeals are much harder to win. Check: verify list and authentication before you request delisting.

Assuming a fresh domain resets a data problem. A new domain does not reset the problem if the cause was your data. You will be back in six weeks with the same spam traps. Check: verify the list, not just the domain.

Trusting "verified" vendor data. Vendor verification decays. One widely used source is about 91% accurate with a three-to-six-month decay lag, meaning roughly 9% of "verified" contacts are already invalid. Check: re-verify any list older than 30 days.

Watching a v1 reputation light that no longer exists. Any script still hitting v1 endpoints returns empty responses since October 31, 2025. An empty response can read as "no problem." Check: confirm dashboards and API calls point to v2.

Keep the reference current: the copy-paste alert rule

The thresholds here are enforced values, but the tools that report them keep moving. Wire the numbers into automated triggers so a person is not eyeballing a dashboard during a spike, and re-check the mechanism, not the value, when a provider announces a change.

IF spam_complaint_rate (daily, inbox-delivered) >= 0.30%  -> PAUSE domain, alert owner
IF spam_complaint_rate (daily, inbox-delivered) >= 0.20%  -> THROTTLE, investigate complaint source
IF total_bounce_rate (per inbox) > 5%                     -> PAUSE that inbox
IF total_bounce_rate (per inbox) 2-5%                     -> CLEAN list, retry after re-verify
IF hard_bounce_rate (per inbox) > 2%                      -> SUPPRESS and pause
IF open_rate drops >30% week-over-week on unchanged send  -> placement warning, read daily
IF bounce string contains "550" AND "5.7.515"            -> AUTH failure, fix SPF/DKIM/DMARC first

Before you close an incident, run the checklist below. It is the difference between a recovery that holds and one that re-lists you inside a week.

Two things to re-check on a schedule, because they change without notice. First, provider thresholds and enforcement dates: describe them by mechanism (a daily complaint rate on inbox-delivered mail, a permanent 5xx for auth failures) so a changed number does not break your process. Second, the tooling surface: Postmaster Tools already dropped reputation charts, and the v1 API retires by the end of 2025, so confirm your alerting reads the signals that still exist. When a provider announces a change, update the number in your trigger rule and leave the logic alone.

The scarcity of deliverability expertise is the reason to keep this reference where your on-call owner can reach it. With only 9 US profiles in Refolk's index pairing DMARC skill with a deliverability headline, most teams will not have a specialist in the room when a domain trips. A precise lookup table, wired to automated triggers, is what stands in for that expert at 2 a.m.