Skip to main content

Reputation

Every MailSlurp account has a sending reputation. Reputation reflects how safely and responsibly you send email over time. It is driven by delivery outcomes and abuse signals, and it directly affects whether your account can keep sending.

Important usage policy

MailSlurp should not be used for marketing emailing. Only email domains you control or customers that have explicitly opted in to receiving emails and have a clear way to unsubscribe.

Reputation signals​

Reputation is primarily influenced by three outcomes:

  1. Delivery
  • A message is accepted by the recipient system.
  • Consistent successful delivery is a positive reputation signal.
  1. Bounce
  • A message is rejected by the recipient system (for example invalid address, mailbox does not exist, or recipient policy rejection).
  • Rising bounce rates over time are a strong negative signal.
  1. Complaint
  • A recipient reports your message as unwanted/abusive.
  • Complaints are the highest-risk signal and must be treated as a critical incident.

Enforcement outcomes​

  • If bounces increase over time, account sending pause can be enabled and sending blocked.
  • Any complaint can result in account freeze and permanent ban.

Build your sending workflows assuming these outcomes are enforced.

Safe sending architecture​

Use this pattern for production-grade sending:

  1. Verify recipient addresses before sending.
  2. Send with built-in recipient validation/filtering enabled.
  3. Monitor account-level bounce and delivery events via webhooks.
  4. Maintain a suppression list and never resend to bounced recipients.
  5. Investigate complaints immediately and stop all non-essential sending.
SDK and API coverage

MailSlurp supports these workflows across all major SDKs and direct HTTP API endpoints. Examples below are shown in the language where the snippet is most concise and complete.

1) Verify recipients before sending​

Check recipient validity before sending campaigns, transactional batches, or migrations.

TypeScript example:

Loading...

C# example:

Loading...

Language SDK docs:

2) Send with validation and bounce filtering enabled​

Use send options that prevent known bad recipients from being sent to.

Validate and remove invalid addresses at send time​

Loading...

Skip previously bounced recipients​

Loading...

3) Monitor reputation with account webhooks​

Use account-level webhook events to detect reputation risk immediately.

Recommended events:

  • BOUNCE: capture batches of bounced recipients.
  • BOUNCE_RECIPIENT: capture each bounced recipient individually.
  • DELIVERY_STATUS: track SMTP outcomes and trend delivery health over time.

Create an account webhook for bounce events​

Loading...

Process bounce payloads and maintain suppression​

Store bounced recipients and block them from future sends.

type ReputationEvent =
  | { eventName: "BOUNCE"; bounceRecipients: string[] }
  | { eventName: "BOUNCE_RECIPIENT"; recipient: string }
  | { eventName: "DELIVERY_STATUS"; recipients?: string[]; smtpStatusCode?: number; smtpResponse?: string };

app.post("/webhooks/reputation", async (req, res) => {
  const event = req.body as ReputationEvent;

  if (event.eventName === "BOUNCE") {
    await suppressionStore.addMany(event.bounceRecipients.map((it) => it.toLowerCase()));
  } else if (event.eventName === "BOUNCE_RECIPIENT") {
    await suppressionStore.add(event.recipient.toLowerCase());
  } else if (event.eventName === "DELIVERY_STATUS" && (event.smtpStatusCode ?? 0) >= 500) {
    await deliveryAlerts.notify(event.smtpStatusCode, event.smtpResponse ?? "delivery failure");
  }

  res.status(204).end();
});

Monitor complaints explicitly​

Complaints are critical and should be polled/triaged as part of your reputation monitoring loop.

curl -sS "https://api.mailslurp.com/bounce/complaints?page=0&size=20&sort=DESC" \
  -H "x-api-key: $API_KEY" \
  -H "accept: application/json"

If a complaint appears, stop non-essential sending immediately, suppress impacted recipients, and investigate consent and unsubscribe controls before resuming.

Gate outbound sends using suppression​

Before every send, remove suppressed recipients.

async function sendSafely(inboxId: string, recipients: string[], subject: string, body: string) {
  const allowedRecipients = await suppressionStore.filterAllowed(recipients.map((it) => it.toLowerCase()));
  if (allowedRecipients.length === 0) return;

  await mailslurp.sendEmail(inboxId, {
    to: allowedRecipients,
    subject,
    body,
    filterBouncedRecipients: true,
    validateEmailAddresses:
      SendEmailOptionsValidateEmailAddressesEnum.VALIDATE_FILTER_REMOVE_INVALID,
  });
}

4) Complaint response playbook​

Treat complaints as a stop-and-fix incident:

  1. Stop all non-essential outbound sending immediately.
  2. Remove complained recipients and adjacent non-consented segments from active lists.
  3. Confirm consent evidence and unsubscribe behavior for the affected flow.
  4. Resume only after audience hygiene and send controls are corrected.

Operational checklist​

  • Use explicit opt-in and clear unsubscribe paths.
  • Verify high-risk or imported recipient lists before sending.
  • Enable account webhooks for bounce and delivery status events.
  • Keep and enforce a suppression list for bounced recipients.
  • Review bounce and complaint trends weekly, not only after incidents.