# Sender reputation

> The running score mailbox providers keep on every sending domain, mailbox, and IP — what feeds it, how fast it moves, and how it is repaired.

**Every mailbox provider keeps a private, continuously updated score for each sending domain, mailbox, and IP address. Engagement raises it; spam reports, bounces, and volume spikes lower it. The score decides inbox placement before content is even read. Reputation builds slowly, collapses quickly, and recovers only through weeks of consistent good behavior.**

_Status: Reviewed — human-edited, facts not yet confirmed against the product._

## What it is

Sender reputation is the score a receiving provider assigns to the identities behind a
message: the sending **domain**, the individual **mailbox**, and the **IP address**. There
is no single public number — Gmail, Outlook, and Yahoo each keep their own, and each sees
only the traffic you send to them.

## Why it works this way

Providers need a cheap early signal before doing expensive content analysis. Identity
history is that signal. The main inputs:

| Input | Direction | Weight |
| --- | --- | --- |
| Replies and forwards | Up | Strongest positive |
| Opens and "not spam" rescues | Up | Moderate |
| Spam reports | Down | Strongest negative |
| Hard bounces | Down | Strong — signals a bought or stale list |
| Volume consistency | Up | Steady patterns read as legitimate |
| Volume spikes | Down | Read as compromise or abuse |
| Authentication failures | Down | See [SPF, DKIM, DMARC](/learn/spf-dkim-dmarc) |
| Spam-trap hits | Down | Severe — proves the list was not opt-in |

## How it behaves in practice

- **Asymmetric speed.** Weeks to build, days to destroy. A single mass send to a bad list can undo a quarter of careful sending.
- **Scoped but leaky.** Mailbox reputation sits under domain reputation; burning one mailbox stains the domain, which is why cold outreach uses separate sending domains.
- **Per-provider.** A domain can be clean at Gmail and burned at Outlook, because each provider scores only what it observes.
- **Postmaster tools show a shadow of it.** Google Postmaster Tools reports domain reputation in coarse bands (High/Medium/Low/Bad) — directional, not real-time.

## Common misconceptions

| Belief | Reality |
| --- | --- |
| "New domain = clean slate forever" | A new domain has *no* reputation, which is itself suspicious until warmed |
| "Reputation belongs to the tool" | It belongs to your domain, mailboxes, and IPs — it follows you between tools |
| "Low volume means safe" | Low volume to bad lists still hits spam traps and reports |
| "One spam report is fatal" | Providers work in rates, not single events — the bulk-sender ceiling is around a 0.3% spam rate |

## How Reply implements this

Reply protects reputation with per-mailbox [daily limits](/how-to/configure-sending-limits)
(at most 400 emails per day per account on paid plans, 200 on trial), randomized delays
between individual sends, [schedule windows](/behavior/sending-schedules), and ramp-up
mode — active by default for every newly added email account — which grows daily volume
gradually instead of spiking it. Warm-up runs through MailToaster
([deliverability capability](/capabilities/deliverability)). Automatic
[bounce handling](/behavior/bounce-handling) pauses a sequence's email steps for the day
when its bounce rate crosses 8% — the sequence toggle warns at 4% — and
[reply detection](/behavior/reply-detection) stops follow-ups once a reply is detected,
converting the strongest positive signal into an automatic stop rule. The Spam Monitor
tab reads your domain's Gmail spam-report rate from Google Postmaster Tools directly
inside Reply.

## Where this breaks down

Reputation repair has no shortcut: once a provider distrusts a domain, only reduced
volume, high engagement, and time move the score. Monitoring is also partial — providers
expose coarse dashboards at best, so real reputation is always inferred, never read.

## Related

- [Email deliverability](/learn/email-deliverability)
- [Email warm-up](/learn/email-warm-up)
- [Deliverability in Reply](/capabilities/deliverability)
- [Mailbox selection rules](/behavior/mailbox-selection)

## Build with Reply

- REST API: [docs.reply.io](https://docs.reply.io/api-reference/introduction) — email account health fields
- MCP: [agents.reply.io/mcp](https://agents.reply.io/mcp) — warm-up status operations