Suppressions, Bounces, and Deliverability
Manage your suppression list, understand bounce handling, and protect your sender reputation.
Why It Matters
Sending emails to bad addresses damages your sender reputation. Reputation damage means more of your emails land in spam — not just outreach, but every email your domain sends. Kit’s suppression list and bounce handling protect your reputation by automatically preventing re-contact with addresses that bounced, unsubscribed, or opted out.
Suppression List
The suppression list is account-level — it applies across all campaigns. Navigate to Outreach > Suppressions to view and manage it.
Emails are stored as SHA-256 hashes for privacy. An address gets suppressed automatically when:
- A hard bounce is detected (the recipient’s server permanently rejects the address itself, or a bounce notification confirms it)
- A prospect clicks the unsubscribe link in an outreach email
- A prospect is marked as opted out by your team
You can also manually add email addresses to the suppression list to prevent future contact, or remove an address if it was suppressed in error.
When importing prospects via CSV, Kit checks each email against the suppression list and skips matches automatically.
Bounce Handling
Kit classifies bounces by severity and source:
| Type | SMTP Code | Action |
|---|---|---|
| Hard bounce | 5xx in reply to RCPT TO with a recipient-address status code: 5.1.1, 5.1.2, 5.1.3, 5.1.4, 5.1.6, 5.1.10, 5.2.1, or 5.4.1
|
Immediate suppression — the address is invalid, disabled, or no longer exists |
| Policy rejection | 5xx with a 5.7.x status code (spam filter, DMARC, blocklist) |
Message fails; the address is not suppressed, because the rejection is about your sender reputation, not the address |
| Other permanent failure | Any other 5xx — before RCPT TO, without an enhanced status code, or with a sender, quota, or protocol code |
Message fails for operator review; the address is not suppressed |
| Soft bounce | 4xx (temporary failure) | Retry with backoff — the mailbox may be full or the server temporarily unavailable |
Bounce confirmations come from SMTP or DSN notifications:
| Source | How It Works |
|---|---|
| SMTP | The sending server rejects the message at delivery time with an error code |
| DSN | A Delivery Status Notification email arrives after sending (delayed bounce) |
An AI bounce classification alone does not change delivery state or suppress an address. Those actions require SMTP or DSN evidence.
Hard bounces suppress the address immediately; policy rejections and other permanent failures do not, so a valid prospect is never burned over a reputation problem. Safe-to-retry soft failures are retried; when all attempts are exhausted, the message moves to Attempts exhausted for an operator decision.
Delivery Review
Open Outreach > Deliverability to work through messages Kit intentionally stopped:
- Delivery unknown means the SMTP connection ended after submission began and Kit cannot prove whether the provider accepted the email. Inspect the attempt evidence and provider logs using the RFC Message-ID before deciding. Absence from Sent alone does not prove that the email was not sent.
- Attempts exhausted means a known pre-submission temporary failure used all safe retries. Fix the sender or provider issue before authorizing another attempt.
- Failed means Kit received a known authentication, sender, content, or policy failure. Correct that specific cause before authorizing another attempt; otherwise close the review without sending.
A member who can manage the campaign can confirm an unknown delivery was sent, confirm it was not sent based on provider evidence, authorize a retry after fixing an exhausted or failed delivery, or close any review without sending. Kit records the decision, resolver attribution while retained, origin, timestamp, and an optional encrypted note. A retry is queued only for an outcome that explicitly authorizes it.
Inspect the latest attempt before deciding: SMTP stage, response and enhanced status codes, timestamps, diagnostic, and RFC Message-ID form the review evidence. The resolution preview is bound to that exact attempt and evidence. When a retry is possible, it is also bound to the reviewed recipient, sender identity, subject, and body. If the attempt, evidence, or delivery content changes before confirmation, Kit rejects the stale confirmation and requires a new preview.
Approval Confirmation Guard
If an approved recipient, sender identity, subject, or body changes before SMTP starts, Kit moves the message to Review required and does not open a delivery attempt. Review the current message and approve it again. The outreach.message.confirmation_expired webhook lets connected systems distinguish this safe pre-send stop from an SMTP failure.
Unsubscribe Compliance
By default, Kit adds RFC 8058 unsubscribe headers to every outreach email:
- List-Unsubscribe header with a one-click unsubscribe URL
- List-Unsubscribe-Post header for RFC 8058 one-click POST support
- Unsubscribe tokens expire after 6 months for security
You can disable these headers in Outreach > Settings if you’re sending personalized 1:1 cold email where the headers may signal bulk mail to ESPs. The unsubscribe page, suppression list, and opt-out flows continue to work regardless of this setting.
When a prospect clicks unsubscribe, Kit immediately suppresses their email and updates the prospect’s status to unsubscribed. No further emails are sent.
Deliverability Tips
| Practice | Why It Helps |
|---|---|
| Use a dedicated sending domain | Isolates outreach reputation from your primary domain |
| Warm up gradually | Start with 10–15 emails/day and increase over 2–4 weeks |
| Respect the daily cap | The default is 50 emails/day per account, configurable up to 500 in SMTP settings |
| Monitor bounce rate | Keep hard bounces below 2% — clean your lists regularly |
| Write relevant emails | Spam complaints drop when prospects recognize why you’re reaching out |
| Include a clear signature | Recipients who can identify the sender are less likely to report spam |
| Use a custom tracking domain | If you enable engagement tracking, set up a custom tracking domain so pixel/redirect URLs match your sending domain |
Webhook Events
Kit fires webhook events for key outreach activities. Subscribe to these in Integrations > Webhooks to sync outreach data with external systems.
| Event | Fired When | Payload Model |
|---|---|---|
outreach.prospect.drafted |
AI finishes drafting an email for a prospect | Prospect (ID, campaign_id, company_name, display_name, status) |
outreach.message.approved |
A draft is approved for sending | Message (ID, campaign_id, prospect_id, step_number, subject, status, timestamps) |
outreach.message.sent |
An email is successfully sent via SMTP | Message |
outreach.message.bounced |
An email receives a confirmed hard bounce | Message (includes last_error_code) |
outreach.message.failed |
Sending fails due to an SMTP error | Message (includes last_error_code) |
outreach.message.deferred |
A known pre-submission temporary failure exhausts all delivery attempts | Message (includes last_error_code) |
outreach.message.delivery_unknown |
Kit cannot prove whether SMTP accepted the email and stops automatic resend | Message (includes last_error_code) |
outreach.message.confirmation_expired |
Reviewed delivery inputs changed before SMTP started, so Kit stops for fresh approval | Message |
outreach.message.delivery_resolved |
A member who can manage the campaign records an audited decision for a stopped delivery | Delivery resolution (message, attempt, outcome, origin, resolver, timestamps) |
All payloads follow the standard webhook envelope. See Webhook Events Reference for envelope format and signature verification.
Note: Prospect and message email addresses are excluded from webhook payloads because they are encrypted at rest. The full SMTP diagnostic and delivery-resolution note are excluded for the same reason — both can contain copied recipient details. Message webhooks carry the parsed last_error_code only; to read the full diagnostic or note, open the message in Kit.
Quick Checklist
- Review your suppression list at Outreach > Suppressions
- Verify your sending domain has SPF, DKIM, and DMARC records
- Monitor bounce rates — investigate if hard bounces exceed 2%
- Consider a dedicated sending domain for outreach
- Subscribe to outreach webhook events if you integrate with external tools
Next Steps
- Setting Up Email Delivery — SMTP and IMAP configuration
- Webhook Events Reference — full payload documentation for all event types
- MCP Tools Reference — manage outreach programmatically via AI assistants