Resources / Reputation
Sender Reputation - What It Actually Is
Reputation is not a single score you own - it is each receiver's prediction, built from your sending history, of how their users will react to your next message. This page explains what feeds that prediction, why it lives on both your IP and your domain, and why it is far easier to damage than to rebuild.
Last checked: June 22, 2026
Most “improve your sender reputation” advice treats reputation like a credit score: one number, held centrally, that you slowly raise. That model is wrong in three ways that matter. Reputation is not one number (your IP and your domain are scored separately), it is not central (every receiver computes its own), and it is not stable (it decays with time and reacts faster to bad signals than to good ones). Spamhaus puts the definition plainly: reputation is “a shorthand way of saying ‘how recipients reacted to mail you’ve sent in the past predicts how they will react to mail you send in the future.’”
This page is the conceptual hub. The companion pages go deep on the IP-versus-domain split, the Spamhaus blocklists, the DNSBL directory, the URI/domain blocklists, and the M3AAWG sending best practices that keep all of it healthy. Blocklists and content filters are where this reputation gets applied - see the spam-filtering overview - and the day-to-day hygiene that protects it lives in suppression and consent.
The 60-second version
- Reputation is a prediction, not a grade. It estimates how this receiver’s users will react to your next message, based on how they reacted before.
- It is per-receiver. Gmail, Microsoft, and Yahoo each build their own. A good reputation at one says nothing certain about another.
- It is split across identities. Receivers score the sending IP and the sending domain separately, and increasingly weight the domain. Authentication (SPF/DKIM/DMARC) is what ties a message to those identities.
- It is built from behaviour: spam-trap hits, complaint volume, engagement (opens/clicks/replies), bounce and invalid-address handling, consistency of volume, and correct authentication.
- It decays. Reputation is established during warmup and maintained by consistent sending; quiet senders and inconsistent (“bursty”) streams lose ground.
- It is asymmetric. Spamhaus: “It is much, much easier to drive reputation down than it is to fix a damaged one - this behavior was created by design, and there is no override!”
- Allow-listing is not a backdoor. Spamhaus: “The days of ‘whitelisting’ are long gone; we are unaware of any ISP that offers allow listing in any form today.”
What reputation is actually predicting
A receiving mail system does not know in advance whether your next message is wanted. It has to guess, in milliseconds, and it guesses from history. Spamhaus frames good reputation simply: “Good reputation means that recipients like your mail. Many email filters use ‘reputation’ as one piece of their decision making process.”
Two consequences follow from “prediction from history”:
- New senders have no history, so receivers are cautious until one accumulates - this is why warmup exists.
- The signals receivers trust are the ones recipients generate, not the ones you assert. You can claim your mail is wanted; only recipient behaviour confirms it.
Reputation systems are also indifferent to your business. Spamhaus: “They do not care about business models. They do care about end-user engagement. They do care whether or not mail is authenticated correctly.”
What feeds the prediction
Spamhaus categorises the components of reputation explicitly. These are the levers - everything else is downstream of them.
| Factor | What the receiver is measuring | Why it moves reputation |
|---|---|---|
| Spam-trap hits | Mail reaching addresses that should never receive it | Direct evidence of a permission or hygiene failure |
| Complaint volume | Recipients marking mail as spam (via FBL) | One of the most heavily weighted negative signals |
| Engagement | Opens, clicks, replies, purchases | The strongest positive signal that mail is wanted |
| Bounce / invalid handling | Whether you keep mailing dead addresses | Sending to invalids signals a stale, unpermissioned list |
| Consistent volume | Steadiness of your daily send | Sudden swings look like a hijacked or rented stream |
| Authentication | Valid SPF, DKIM, DMARC | Required to even attach reputation to you reliably |
A few of these deserve emphasis because senders routinely misjudge them.
Complaints carry weight, but the threshold is secret. Spamhaus: “The number of complaints generated by a given IP is given significant weight by receivers, though ISPs will not reveal the threshold as it is part of their spam filtering recipe and will vary from ISP to ISP.” Do not chase a magic complaint number - there isn’t a published one, and it differs per receiver. Spamhaus does add that “a good reputation allows slightly more forgiveness than a poor one,” which is the whole point of building reputation in the first place.
Spam traps are a symptom, not the disease. A trap hit means an address with no real consent is on your list. Spamhaus is blunt: “We strongly urge people to view spamtraps as proof of a data collection or hygiene issue and not be misled into conducting a hunt for spamtraps. Attempting to locate and remove traps only treats the symptom and not the underlying problem.” (The Spamhaus blocklists page covers the trap taxonomy in detail.)
Authentication does not buy placement. SPF and DKIM are, in Spamhaus’s words, “a must - and are required in any modern email marketing infrastructure,” and their absence “will damage reputation and affect deliverability.” But authentication only identifies you so reputation can be attached. It “does not allow senders to bypass spam filters.” See the authentication references for the mechanics.
Engagement is the dominant positive signal - and it has two sides. Adobe’s deliverability guide is blunt about the shift: “Engagement has become the single most important factor impacting inbox placement decisions. Over the years, ISPs have shifted focus from content-related filters to a behavioral model.” Positive engagement is opens, clicks, forwards, and replies; negative engagement is “deleting without opening, ignoring, unsubscribing, marking as spam.” Two practical cautions follow. First, the signal is relative: the same campaign sent to your most engaged segment looks great and sent to a stale segment looks like spam - which is why warmup and reactivation target highly-engaged recipients first. Second, opens are now a noisy proxy. Apple’s Mail Privacy Protection pre-fetches images, so opens no longer reliably indicate a human read the message; Spamhaus notes this degraded click/open reliability directly. Lean on the harder signals - clicks, replies, and the absence of complaints - rather than open rate alone.
Complaint rate has a rough industry ceiling, even though receivers hide their exact thresholds. No mailbox provider publishes its trigger, but the widely-cited operational target is to keep complaints “less than 0.1 percent overall” (Adobe). Google Postmaster Tools surfaces a spam-rate figure of the same order. Treat 0.1% as a “do not exceed” guardrail, not a goal - a healthy permissioned program sits well below it.
Why it is per-receiver
There is no global reputation authority. Each mailbox provider observes only the mail its own users receive and react to, and builds its model from that. This is why a sender can sit cleanly in the Gmail inbox while struggling at Microsoft: different user populations, different engagement, different internal weighting.
Public blocklists (Spamhaus, SURBL, URIBL) are the closest thing to a shared signal, because many receivers query the same lists. But even there, the receiver decides what to do with a listing. Spamhaus describes the two options an administrator has on a hit: “(a) Reject the email in real-time, with an appropriate delivery code, or (b) Accept the message and tag it for additional filtering.” A listing is an input to each receiver’s policy, not a universal verdict - and the lists themselves differ enormously in reach. Spamhaus: “A listing on the Spamhaus Blocklist (SBL) has enormous reach, whereas you can happily ignore a listing by SPEWS.”
Why it is time-decaying
Reputation is not a permanent record; it is a rolling impression that must be continually refreshed.
- It is established during warmup. Spamhaus: “Reputation is established during the IP or domain warmup/ramp-up phase - this makes the preparation for the warmup process critical.” First impressions stick: “It is very much like going on a first date: first impressions matter a great deal and linger for a long time.”
- It is maintained by consistency. Bursty sending erodes even an established reputation. Spamhaus: “‘Bursty’ email streams will degrade even well-established reputation with the major freemail ISPs.” M3AAWG ties consistency directly to the score: “Consistency of volume, whether high or low, plays an integral part in the determination of IP reputation and deliverability outcomes.”
- It is earned in steps, not on a calendar. Warmup volume should be gated by results, not a fixed schedule: “Increasing rates of volume and speed should depend on the results of each previous deployment.”
What moves it - up and down
| Direction | Driver | Source |
|---|---|---|
| Down (fast) | Spam-trap hits, complaint spikes, sending to invalids, volume bursts | Spamhaus eBook |
| Down (fast) | Missing or broken authentication | Spamhaus eBook |
| Up (slow) | Sustained engagement from a clean, permissioned list | Spamhaus eBook |
| Up (slow) | Consistent volume over time; disciplined warmup | Spamhaus eBook, M3AAWG BCP |
| Up (slow) | Prompt bounce + complaint suppression, list hygiene | M3AAWG BCP |
The asymmetry is the single most important property to internalise. You can lose months of reputation in a single bad send, and there is no appeal: “there is no override!” That is by design - it is what makes reputation a usable defence for receivers.
How recovery actually works
Because the damage is asymmetric, recovery is not “wait and it heals” - it is a deliberate re-earning of trust, mechanically identical to warmup. The sources converge on a path:
- Stop the cause first. Whatever drove the drop - a bad segment, a purchased list, a compromise - has to end before anything else helps. Suppressing the symptom (the trap address, the one complainer) without fixing collection just invites a relisting.
- Fall back to your most-engaged recipients and rebuild from there. Recovery sends should look like a clean warmup: target only highly-engaged users so the early signal is positive, then let “increasing rates of volume and speed… depend on the results of each previous deployment.” Volume is earned by results, not a calendar.
- Reactivate on the platform you already use, not a fresh IP. Adobe is explicit that inactive or risky audiences should be re-engaged on your current infrastructure; spinning up new IPs to “escape” is both ineffective for domain-side damage and a snowshoe signature (see IP vs domain reputation).
- Suppress the chronically unengaged. A standing policy of removing recipients “who remain chronically unengaged or non-deliverable” (M3AAWG) is what keeps the recovered reputation from sliding again. The mechanics live in suppression and consent.
- Watch the blocklists and FBLs as you climb. A listing on an automated list often clears on its own once the behaviour stops - SpamCop, for instance, auto-delists about 24 hours after reports cease - but only if you have genuinely stopped. The DNSBL directory covers which listings to act on.
The timescale is weeks, not hours, and it is rarely a full restoration to the prior peak. That is the whole point of the asymmetry: prevention is dramatically cheaper than repair.
A worked example
Consider a sender with a solid Gmail reputation who imports a two-year-old segment from an acquired brand and includes it in the next campaign to “reactivate” it.
- Day 0 - the send. The old segment contains recycled spam traps and many recipients who never consented to this sender. Trap hits register immediately, complaints spike above the ~0.1% guardrail, and a wave of hard bounces hits invalid addresses.
- Days 0-2 - the fast drop. Gmail’s behavioural model reacts to the complaint and trap signals; mail to Gmail starts landing in the spam folder. The bursty volume to a stale audience erodes the established reputation - exactly the “‘bursty’ email streams will degrade even well-established reputation” effect Spamhaus describes. An automated IP list (say SpamCop, fed by the trap hits) lists the sending IP.
- The realisation. Inbox rate craters and a blocklist monitor flags the listing. Note which identity is hit: if complaints attach to the domain via DKIM, switching IPs will not help - the domain reputation is the wounded asset.
- Recovery. The sender removes the imported segment entirely, fixes the acquisition gap (confirmed opt-in going forward), and suppresses bounces and complainers. They resume sending only to their proven-engaged Gmail recipients, at reduced volume, increasing only as each send shows clean opens/clicks and near-zero complaints. The SpamCop listing clears automatically within about a day once the trap reports stop; the Gmail reputation climbs back over the following weeks, not days, and may settle below its former peak.
The lesson is the asymmetry made concrete: one send to one bad segment cost weeks of rebuilding, and no allow-list or “delisting service” could have shortcut it.
Common confusion
- “Reputation is a score I own.” No. Each receiver computes its own prediction from the mail it saw. You influence it; you do not hold it.
- “Good authentication means good reputation.” No. Authentication is the prerequisite that lets reputation attach to you correctly. It is necessary, not sufficient, and “does not allow senders to bypass spam filters.”
- “I can get allow-listed to skip filtering.” Not in 2026. Spamhaus states it is “unaware of any ISP that offers allow listing in any form today.”
- “A clean IP guarantees delivery.” No. Domain reputation and content (linked domains) are scored too - see the IP-vs-domain and URI blocklist pages.
- “Once I recover, I’m fine.” Recovery is slow and partial by design. Prevention is cheaper than repair by a wide margin.
What this means for you, and what Egressif does
Reputation rewards exactly one thing over time: consistently sending wanted mail to people who asked for it, from correctly authenticated identities, with dead addresses and complainers removed promptly. There is no shortcut, no allow-list, and no override on the way back down.
Egressif operates owned IP space rather than renting transient addresses, so the IP-side history we build stays attached to us and is not diluted by unknown neighbours. We monitor the major blocklists (Spamhaus and the URI lists covered in these references) so a listing surfaces as an alert we act on, not a silent placement drop discovered weeks later. And we handle complaints and suppression as a standing process - feedback-loop complainers and hard bounces come off the stream promptly, because those are the signals receivers weigh most heavily against you. We do not promise the inbox; no honest operator can. We make the inputs receivers actually measure as clean as they can be, and keep them that way.
Related references
- IP vs Domain Reputation Receivers score the sending IP and the sending domain as two different identities. This page draws the line precisely - what lives where, how shared and dedicated IPs differ, why domain reputation is overtaking IP reputation, and exactly what does and does not survive when you change IPs.
- Spamhaus Blocklists - SBL, XBL, PBL, CSS, DBL, ZEN A precise field guide to the Spamhaus blocklists - what each of SBL, CSS, XBL, PBL, DBL and the combined ZEN lists, the DROP/ASN-DROP and AuthBL datasets, the 127.0.0.x return codes, the RFC 5782 query mechanics and usage rules, and how listings and (always-free) delistings actually work.
- DNSBL Directory - Blocklists and How to Use Them DNS-based blocklists (DNSBLs) are the closest thing email has to a shared reputation signal. This page explains the standard query model from RFC 5782, the operational practices of RFC 6471, and gives a neutral, verified directory of the major lists - what each one lists, how to read its return codes, and how to get delisted - with strong guidance on using them as a score rather than a hard block.
- URI Blocklists - SURBL and URIBL URI blocklists judge the domains linked inside your message, not the IP you sent from. This page explains how SURBL and URIBL work, why a spotless sending IP gets filtered on one bad link, and how shorteners and tracking domains pull you onto someone else's reputation.
- Deliverability frameworks and industry guidance Deliverability best practice is not owned by any single authority - it is a remarkably consistent consensus across standards bodies, blocklist operators, mailbox providers, and the ESPs. This page is the annotated map of who publishes what, which document is best for which question, and why they all say the same six things. For the actionable playbook those documents add up to, see our sending best-practices guide.
Tell us what you run today.
Domains, rough volume, current providers, and what hurts. You will get a straight answer on fit, and a real number, in one conversation.