Mailbox providers keep a score on the IP that connects and the domain in the From address. This lesson covers the signals you control, how to read a bounce, and what PostShiba already stops before a bad address can count twice.
Drag bounce rate, spam reports, and the deferral trend below. Each provider keeps its own verdict.
How healthy is your sending?
Bounce, spam, and deferral rates decide the next step.
Deferrals vs yesterday
Thresholds from the PostShiba warm-up guide.
What reputation is
IP reputation is the score on 198.51.100.10 or whichever address the capsule uses to talk to Gmail, Yahoo, or Outlook. Bounce it, collect spam reports on it, or go quiet, and the score drops.
Domain reputation is the score on mail.example.com. It moves with the From domain and the aligned return-path. It survives an IP change and follows you onto shared IPs. That is why SPF, DKIM, and DMARC have to be right before you grow volume.
Gmail, Yahoo, and Outlook each keep their own view. A clean day at Gmail does not save you at Yahoo. Raise or hold each provider on its own, the same way you warm a new IP.
Shared IPs share a reputation with other senders on the cluster. Dedicated IPs and pools give a stream or a customer a score of their own. Either way the domain still has a history. A cold domain on a warm IP can still get deferred.
Signals you control
PostShiba does not track opens or clicks. Watch what providers do with your mail, and the list you feed them. Divide each count by processed, provider by provider. Analytics groups by mx_provider and sending_ip.
The rates you can hold are bounces and spam reports. Import the suppression list before the first send, and do not mail a purchased list. Engagement is mail people want. Receipts, replies, and people who signed in this week belong first. You see that in your product. Consistent volume keeps an IP from looking like a spammer. An address that is busy one week and silent the next loses trust. Take IPs out of a pool rather than spreading less mail over the same addresses.
| Signal | Healthy | If it rises |
|---|---|---|
| Bounces | Under 2% | Hold the ramp. Check where the addresses came from and import any suppressions you missed. |
| Spam reports | Under 0.1%. Gmail and Yahoo act at 0.3%. | Cut that provider's share 25 to 30%. Find the stream or customer causing them and pause it. |
| Deferrals | About the same as the day before | Cut that provider's share 25 to 30% until it settles, then grow more slowly. |
A day with 400 processed at Yahoo and 31 deferred is not a green light. Deferrals are almost 8%. Hold Yahoo. Let Gmail keep growing.
Hard bounces and soft failures
When a destination refuses a message, PostShiba records a bounce or a deferred event. The difference is whether the address is gone, or the server asked you to wait.
A hard bounce means the mailbox or host does not exist, or the mailbox has moved. PostShiba records a bounce event and adds the address to the sending tenant's suppression list, reason Bounce. Later sends skip it. A send to only that address returns 403 suppressed.
A soft failure is temporary. A full mailbox is the usual case. PostShiba records deferred while it retries, for up to two days. The address is not suppressed. A message that expires before delivery becomes a bounce with reason expired, still without a suppression.
A spam report is not a bounce. The recipient marked the message as spam. That fires spamreport and suppresses the address, reason Spam report.
SMTP replies tell you which case you are in. A 4xx reply is temporary. The receiving server asked PostShiba to try again later. Delivery continues. That is a deferral. A 5xx reply is permanent. The server refused the message. That is a bounce. The event's type is bounce when the address is bad, and blocked when the message was refused for another reason.
How to read an SMTP reply
A typical permanent reply looks like this.
Three parts sit on one line. The basic code is 550. The first digit is the class. 4 means try later. 5 means stop. 2 means accepted. The enhanced status code is 5.1.1. Providers use this to say why. 5.1.1 is a mailbox that does not exist. 4.7.0 is often a request to slow down. The text is user unknown. That is the human-readable part, and the part that names a blocklist when one is involved.
The event page shows the SMTP code, the enhanced code, the classification, and a plain explanation you can paste to a customer. See How do I read a bounce reason?. Temporary failures and policy blocks do not suppress unless the sentence says they do.
Pick or paste a reply below.
Decode a bounce.
Read the code, then decide whether to retry.
Deferrals are the early warning
A rising deferral rate means that provider has seen enough from this IP for now. Delivery still continues. Do not answer it with more volume. Cut that provider's share 25 to 30%, wait a day, then grow more slowly. Warm-up uses the same hold. PostShiba already slows delivery to a provider that defers, and keeps retrying. Your job is to stop feeding it more mail while it catches up.
Blocklists
A blocklist is a shared list of IPs or domains that mailbox providers consult before they accept mail. A Spamhaus-style list is a public or subscriber list that marks an address as a source of spam or abuse. Landing on one makes many providers defer or refuse you at once.
Bounces that mention a blocklist mean the IP or the domain was listed. Stop raising volume. Find the stream or customer that caused it. Contact PostShiba support and request delisting. Once the address is delisted, restart the ramp lower.
Do not keep sending through a listed IP hoping the percentage will fall.
Delivered means accepted
delivered means the recipient's mail server accepted the message. It does not tell you where the server filed it. The message can still land in spam, a tab, or a filter. Ask the recipient to search those places. A spamreport after delivered means they marked it as spam. See Delivered but not in the inbox.
What PostShiba does
Permanent bounces, spam reports, and unsubscribes go on the suppression list automatically. Plus tags are ignored when matching, so user+promo@example.com matches user@example.com.
When a provider defers because an IP is moving too fast, PostShiba slows delivery to that provider and keeps retrying. At Yahoo, if one tenant keeps hitting the limit, PostShiba pauses that tenant's Yahoo mail for an hour, and everyone else keeps sending. When a problem can be contained to one sending domain, PostShiba pauses that domain and works with you on recovery.
The email firewall checks every recipient before a message is queued. Every check starts off. Turn on temp mail at least. Never-send-to blocks listed domains. A blocked REST send returns 403 firewall. SMTP returns 550 firewall. Those recipients never become bounces on the new IP.
Subscribe to delivery webhooks before you send real traffic. PostShiba emits seven events: processed, delivered, deferred, bounce, dropped, spamreport, and unsubscribe. A new endpoint subscribes to all seven. It does not emit open or click events. Endpoints accept those names for SendGrid compatibility and never send them. Judge reputation with what providers do. The event types page lists every field.
Check what stuck.
A few questions. Two right marks the lesson done.
You finished this lesson.
Lesson complete.
Do this in PostShiba.
The docs walk through each step in the dashboard and the API.
- Email bounces Hard bounces suppress the address. Events stay on the cluster.
- Bounce explanations Classified pasteable sentences from Events.
- Why did an address land on suppressions? Hard bounce, spam report, unsubscribe, or a manual add.
- Delivered but not in the inbox Delivered means the destination accepted the message.