Sender reputation is a trust score that mailbox providers (Gmail, Outlook, Yahoo, and others) assign to your sending domain and IP address based on how recipients and spam systems treat your mail over time. A good reputation gets your mail into the inbox. A bad one gets it filtered to spam or rejected outright.
Reputation is separate from authentication. Authentication proves you are who you say you are. Reputation is what mailbox providers think of you once they know that. You can pass every authentication check and still land in spam if your reputation is poor.
What builds or damages reputation
Mailbox providers track signals per sending domain and per IP, then combine them into an internal score you never see directly. The signals that matter most:
- Complaint rate. How often recipients hit "report spam" instead of deleting or unsubscribing. This is the single heaviest factor. A complaint rate above roughly 0.1% will start hurting you at most major providers.
- Bounce rate. Sending to addresses that no longer exist (hard bounces) signals a stale or purchased list. Keep your list clean and remove hard bounces immediately.
- Spam trap hits. Providers seed old, abandoned, or fake addresses into the ecosystem specifically to catch senders who don't manage their lists. Hitting one is a strong negative signal.
- Engagement. Opens, clicks, replies, and moving mail out of spam all count as positive signals. Mail that sits unread or gets deleted without opening does not help you.
- Volume consistency. Sudden spikes in sending volume from a domain or IP with no history look like the start of an abuse campaign, even if it's legitimate.
- Authentication. Missing or broken SPF and DKIM doesn't directly tank reputation, but it removes a provider's ability to trust that the mail is really from you, which makes every other signal weigh more heavily against you.
Domain reputation vs IP reputation
These are tracked separately and both matter.
IP reputation belongs to the server sending the mail. On shared hosting, you share that IP's reputation with every other domain on the same mail server. This is largely out of your hands beyond choosing a host that manages its outbound mail responsibly.
Domain reputation belongs to your sending domain specifically, and follows you even if the sending IP changes. This is the one your own sending behavior controls most directly, and it's increasingly what providers like Gmail weight more heavily than IP reputation alone.
Signs your reputation has taken a hit
- Mail that used to land in the inbox starts landing in spam for some or all recipients.
- Delivery delays or temporary deferrals from major providers (a 4xx SMTP response asking you to retry later).
- Outright rejections with a 5xx code referencing reputation or policy.
- A drop in email open rates that isn't explained by content or subject line changes.
How to protect it
Most reputation damage is self-inflicted and preventable:
- Only email people who asked to hear from you. Purchased or scraped lists are the fastest way to spike complaints and hit spam traps.
- Remove hard bounces after the first failure. Don't keep retrying dead addresses.
- Make unsubscribing easy and honor it immediately. A recipient who can't unsubscribe will hit "report spam" instead, which hurts far more than a lost subscriber.
- Warm up new sending domains gradually. Start with low volume to engaged recipients and increase over days or weeks rather than sending a full list on day one.
- Keep authentication correct and current: valid SPF and DKIM signing. These don't build reputation on their own, but a failure here compounds every other problem.
- Watch what you filter on the receiving end too. If you're the one fighting inbound spam, use Spam Filters instead of BoxTrapper, since challenge-response systems create their own delivery and reputation headaches for the people emailing you.
When to contact support
If your own mail is suddenly landing in spam across multiple providers, or you're seeing bounce messages that reference blocklists or reputation, open a support ticket from the portal. Include any blocklist references from the bounce so support can look into it with you.