# The Sending-Domain Health Reference: Which Signal Means Pause

*You can read any deliverability signal on a sending domain, know its exact threshold and how it misleads, and pick keep, throttle, pause, or recover.*

- Canonical URL: https://www.refolk.ai/guides/sending-domain-health-reference
- Pillar: Process, data, and compliance
- Format: Reference
- Published: 2026-08-30
- Last reviewed: 2026-08-30
- Reading time: 16 min

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.

| Signal | Keep sending | Throttle / clean | Pause / recover |
|---|---|---|---|
| Spam complaint rate | <0.1% | 0.1 to 0.3% | at or above 0.3% |
| Total bounce rate | <1 to 2% | 2 to 5% | >5% |
| Hard bounce rate | <0.5% | 0.5 to 2% | >2% |

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.

**30 - spam reports it takes to breach 0.3% on 10,000 delivered emails**

At low volume the cap is brutal, not forgiving: a handful of annoyed recipients trips enforcement.

## 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.

| Provider | Volume trigger | Complaint cap | Non-compliance result |
|---|---|---|---|
| Gmail | ~5,000/day to Gmail | <0.1% target, 0.3% cap | Graduated filtering |
| Yahoo | "significant volume" | 0.3% | Filtering |
| Microsoft | 5,000/day consumer | not published | 550 5.7.515 rejection |

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.

> **Rule:** A 550 5.7.515 bounce is an authentication failure, not a content or reputation problem
>
> Do not warm up or clean your list in response to this code. Fix SPF, DKIM, and DMARC alignment first, because the message is being rejected before content or reputation is ever evaluated.

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.

#### Where complaints actually come from

| Stage | Figure | Note |
| --- | --- | --- |
| Total sent | 10,000 | full outbound volume |
| Inbox delivered | (the only slice counted) | denominator for the rate |
| Marked as spam | 30 | enough to hit 0.3% on 10,000 delivered |

*The complaint rate is measured only on the inbox slice, so poor placement shrinks the denominator and flatters the number.*

## 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.

> **Watch out:** A monitoring script hitting v1 endpoints returns empty, not an error
>
> Any automation still pointed at v1 has been returning empty responses since October 31, 2025. Empty is not the same as healthy. Confirm every dashboard and API call points to v2 before you trust a green board.

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.

| Severity | Delisting | Reputation rebuild |
|---|---|---|
| Light dip | n/a | 2 to 4 weeks |
| Moderate (complaints/bounces) | n/a | 4 to 8 weeks |
| Blacklist / spam trap | 24 to 72 hrs to 14 days | 8 to 12+ weeks |

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.

#### Incident to resume, in order

1. **Detect** - Read spam rate, per-inbox bounce, and blacklist status
2. **Stop** - Halt the offending stream and remove risky audiences
3. **Fix** - Repair SPF/DKIM/DMARC alignment and re-verify the list
4. **Delist** - Request removal only after the cause is fixed
5. **Warm up** - 5 to 10 emails/day, add ~5/day each week
6. **Resume** - Scale up after two clean weeks

*Stop first, fix cause second, delist third, and warm up only after the cause is verified fixed.*

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.

I ran this search: `Email deliverability consultants in the United States who list DMARC and Google Postmaster Tools experience` - [see the full result list](https://www.refolk.ai/s/2s62syx29n).

*Returns named US practitioners with DMARC and Postmaster Tools experience, the exact and scarce profile you need on call during a domain-health incident.*

## 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.

#### Sending-domain incident response

1. **Detect which signal tripped** - Pull spam-rate and delivery-error charts in Postmaster Tools v2, check per-inbox bounce rate, and run a blacklist lookup. Done when you know which signal tripped and by how much. The reputation early-warning light is gone since October 2025, so rely on complaint rate and engagement drops.
2. **Classify severity into a band** - Map the number to an action: complaint 0.1 to 0.3% throttle, at or above 0.3% pause; bounce 2 to 5% clean, above 5% pause; a reply-rate cliff with a URL in the bounce means blacklist. Done when you have a keep, throttle, pause, or recover decision.
3. **Stop the bad stream** - In week zero, stop the offending stream, fix authentication, review complaint sources, and remove risky audiences. Done when no further sends go to the offending segment.
4. **Find and fix root cause** - Audit SPF, DKIM, DMARC, and alignment, then re-verify the list to strip invalids and spam traps. Done when all three authentication results pass on a test message and the list is re-verified.
5. **Clear blacklists after the cause is fixed** - Request delisting through each list's own process; Spamhaus and Barracuda matter most. Delisting only sticks once the behavior that got you listed has stopped. Done when delisting is confirmed and the cause is fixed.
6. **Warm back up slowly** - Restart with automated warm-up, not campaigns. Begin at 5 to 10 warm-up emails per day, then add about 5 per day each week. Done when you have two clean weeks.
7. **Resume at scale** - Wait for at least two clean weeks before increasing volume more aggressively. Done when inbox placement is stable at your prior volume.

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.

> **Tip:** The denominator check is your first move, not your last
>
> Before you act on any complaint rate, confirm whether it is measured on inbox-delivered mail and whether your engagement is falling. A low rate with falling opens is a placement failure wearing a healthy dashboard.

## 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.

**Automated pause-trigger rule**

```
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
```

*Adapt the inbox and segment names to your platform; keep the daily read, because Gmail computes the spam rate per day.*

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.

#### Before you resume sending

- [ ] The tripped signal was read against inbox-delivered volume, not total sent
- [ ] The spam rate was checked on the daily chart, not the monthly average
- [ ] Bounce was reviewed per inbox, not just per campaign
- [ ] SPF, DKIM, and DMARC all show pass on a live test message
- [ ] The list was re-verified and spam traps and invalids were stripped
- [ ] Any blacklist delisting was requested only after the root cause was fixed
- [ ] Warm-up started at 5 to 10 emails per day and ramped ~5 per day weekly
- [ ] At least two clean weeks passed before scaling back to prior volume
- [ ] All monitoring points at Postmaster Tools v2, not retired v1 endpoints

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.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/sending-domain-health-reference*