Skip to content
RECURRING · CANCEL ANYTIME

Bounce processing, properly granular.
50+ categories with the right action per category, from €29/month.

MailWizz and PowerMTA process bounces at a basic level: 4 to 6 buckets, blunt suppression rules. That's fine when volumes are small and your mistakes don't compound. Past certain thresholds, bounce-handling granularity matters because the difference between "this address doesn't exist" and "this mailbox is temporarily full" affects whether you suppress or retry, which affects reputation over time.

We classify bounces into 50+ categories, apply appropriate per-category action (suppress now, retry-with-backoff, investigate), ingest FBL complaints in real-time, and update your suppression list automatically. Setup with major receivers' FBL programs included. €29/month, cancel anytime, no contract.

Subscribe on Telegram → See bounce taxonomy
price €29 / month
categories 50+ specific
FBL handling Real-time
commitment none
why granularity matters

The cost of treating "bounce" as a single thing.

A 550 SMTP response from a receiver has dozens of distinct meanings. "User does not exist" is permanent and warrants immediate suppression. "Mailbox full" is usually temporary and warrants retry over a few days. "Spam content rejected" is content-specific and warrants investigation, not suppression of the recipient. "Sender reputation rejected" is reputation-side and warrants infrastructure investigation, not suppression at all. MailWizz and PowerMTA's basic bounce handling treats most 550 responses identically, which means they either over-suppress (lose deliverable contacts) or under-suppress (keep dead addresses that damage reputation on next campaign).

The damage from poor bounce handling compounds over time. Address that should have been suppressed gets re-mailed in next campaign, generates another 550, accumulates more reputation damage. Address that should have been retried gets immediately suppressed, you lose the deliverable contact, your engagement metrics decline because you're deliberately removing valid addresses. Both errors hurt deliverability long-term; granular categorization avoids both.

FBL (Feedback Loop) handling is a separate but related discipline. When a recipient marks your mail as spam at Gmail, Outlook, Yahoo, etc., the receiver sends a complaint notification to your FBL inbox if you've registered with their program. Most senders haven't registered for FBL programs because the setup is bureaucratic; complaints accumulate at receivers without you knowing. We register your domains with major FBL programs and ingest complaints in real-time so you can suppress complainers and protect reputation.

The honest counter-argument: small operations don't generate enough bounce volume for granular processing to matter. Under 5K daily, MailWizz's basic handling covers the cases that actually appear. Past 20-50K daily, the volume of edge cases (mailbox full, temporary failures, content-side rejections, FBL complaints) reaches a level where systematic handling pays back. Below that threshold, this product isn't necessary; basic MTA bounce handling suffices.

50+ categories grouped

Bounce categorization taxonomy.

Click each bucket to see specific categories within it and per-category action policy. The granularity is what differentiates effective bounce handling from blunt suppression rules.

bucket detail

Hard bounces, permanent failures

Permanent delivery failures. Address doesn't exist, domain doesn't exist, mailbox permanently disabled. Default action: suppress immediately and permanently. Re-mailing these addresses generates more bounces and damages reputation.

550 user does not exist SUPPRESS
550 no such mailbox SUPPRESS
550 mailbox unavailable (permanent) SUPPRESS
5.1.1 bad destination address SUPPRESS
5.1.10 recipient address rejected SUPPRESS
5.4.4 unable to route (domain) SUPPRESS DOMAIN
DNS resolution failure (NXDOMAIN) SUPPRESS DOMAIN
No MX record for domain SUPPRESS DOMAIN
Mailbox disabled by user SUPPRESS
Mailbox closed by provider SUPPRESS
Address syntactically invalid SUPPRESS
Recipient on global blacklist SUPPRESS
FBL ingestion process

How complaints flow from receivers to suppression.

Click each step. The flow looks simple but the discipline matters: each step has a way to break that lets complaints accumulate at receivers without your knowledge.

→ → → → →
step 1 of 6

Recipient marks as spam

Recipient at Gmail, Outlook, Yahoo, Apple iCloud, AOL, Comcast clicks "spam" or "report junk" on your message. This is the trigger event for FBL handling. Without recipient action, no FBL notification gets generated; this is recipient-driven feedback rather than receiver algorithm signal.

Industry baseline: complaint rate of 0.1% is healthy for opt-in marketing. 0.3% is the Gmail bulk-sender threshold for "this needs attention." Above 0.3% sustained, receivers throttle and reputation degrades fast.

does this pay back for you?

Cost-of-mishandled-bounces calculator.

Set your volume and bounce rate. The calculator estimates the reputation damage from poor bounce handling vs €29/mo subscription cost. Honest math; some operations don't benefit at this scale.

50,000 daily

Total daily volume across all sending streams. Bounce handling impact scales with volume; small operations see less benefit.

3.0% bounce rate

Industry baseline: 1-2% is clean opt-in lists. 3-5% is typical commercial. 5%+ suggests list quality issues. Cold outreach often runs 5-15%.

€0.020 per message

Marketing: €0.005-0.05. Transactional: €0.05-0.50. Cold outreach: €0.10-2.00 per delivered.

damage from poor processing

Annual reputation damage

Daily bounces 1,500
Monthly bounces 45,000
Mishandled rate (DIY) ~30%
Annual damage estimate €3,800

Damage from re-mailing bad addresses (reputation accumulation), under-suppressing FBL complainers (compound complaint signal), losing valid contacts to over-suppression.

subscription cost

Annual fee

Monthly subscription €29
Annual cost €348
Pre-paid 12-month rate €313

Pre-paid 12-month subscription saves 10%. Monthly billing also available with no commitment.

verdict

Pays back well

Net annual savings €3,452

For your sending profile, bounce processing is economically positive. Subscription cost recovers from avoided reputation damage. Subscribe.

Subscribe on Telegram →

Math caveats: damage estimate assumes 30% mishandled-bounce rate from DIY MailWizz/PowerMTA basic categorization (real rate varies by operation), 0.5% per-mishandled-bounce reputation impact translating to 0.05% delivered-volume reduction over time. Real impacts differ; the simulator uses observed averages from customer operations. For low-volume operations under 10K daily, basic MTA bounce handling typically suffices and this product doesn't pay back.

honest fit assessment

Who subscribes, and who shouldn't.

good fit
  • Operations past 20K daily volume where bounce volume reaches a level that granular handling pays back. Basic MTA categorization isn't enough at this scale.
  • Cold outreach operations with high bounce rates (5-15%). Mishandling at high bounce volumes compounds quickly; granular handling is operational hygiene.
  • Multi-stream operations needing per-stream suppression list management. Transactional vs marketing vs cold outreach benefit from segmented suppression rules.
  • Operations with FBL complaints accumulating at receivers because FBL programs aren't registered. Missing FBL registration is one of the most common causes of silent reputation damage we encounter.
  • Recovery customers post Reputation Recovery who want to maintain clean bounce hygiene as part of preventing future damage.
  • Compliance-driven sending where documented bounce handling and complaint suppression provide audit trail.
poor fit
  • Low-volume sending under 10K daily. Bounce volume too small for granular handling to materially affect outcomes. Basic MailWizz/PowerMTA categorization suffices.
  • Operations with bounce rates over 15%. Bounce processing won't fix the root cause; you need List Audit (€299) to identify list quality issues. Process clean list first, then add bounce processing.
  • You expect this to fix bad sending practices. Granular bounce handling is hygiene, not remediation. Aggressive cold outreach will still accumulate complaints; bounce processing handles them, doesn't prevent them.
  • SaaS ESP users (Mailgun, AWS SES, SendGrid). Vendor handles bounce processing already. This product is for self-hosted operations.
  • Single-stream low-complexity sending. Opt-in transactional under 30K daily rarely needs this. Save the spend for actual deliverability work.
  • You haven't set up authentication yet. DNS Authentication Setup (€99) first. FBL programs require working DKIM/SPF; processing bounces without authentication is putting cart before horse.
scope of processing

What's in the €29/month.

01

50+ category bounce classification

Bounces parsed from MTA bounce data and classified into specific categories. Hard bounces (12 categories), soft bounces (10), policy bounces (8), content bounces (6), authentication failures (7), connectivity issues (5), mailbox state issues (8). Each with appropriate per- category action policy.

Classification logic refined across 200+ customer operations. New bounce patterns added as receivers introduce them (Gmail, Outlook update bounce response formats periodically). Classifier accuracy validated quarterly against bounce sample audits.

02

Per-category action policy

Suppress permanently (hard bounces, FBL complaints). Retry with exponential backoff (mailbox full, temporary failures). Hold for investigation (content bounces, policy bounces). Route to FBL handler (specific complaint categories). Action policy applied automatically based on classification.

Override capability: if you want different action for specific categories (e.g., never suppress contacts even on hard bounces (relevant for some compliance cases), policy customisable per customer at intake.

03

FBL inbox setup

Major receivers' FBL programs registered for your sending domains: Gmail (Postmaster Tools complaint feed), Outlook (SNDS complaint reports), Yahoo CFL, Apple iCloud FBL, AOL Postmaster, Comcast FBL, plus smaller FBLs we have direct relationships with.

Setup takes 7-14 days because receiver-side approval varies. Some receivers approve same-day on registration; others require validation periods. We track each registration and report status weekly during setup phase.

04

Real-time FBL ingestion

Complaints arrive at FBL inboxes; parser ingests and categorizes in real-time (median latency under 60 seconds from receiver-side complaint to suppression list update). Per-domain segmentation when traceable through campaign identifiers in headers.

Anti-loop: if same complainer fires multiple FBL events from different campaigns (mass-mark-as-spam scenario), we suppress on first event and mark recipient for investigation. Prevents repeat-suppression noise while catching anomalous complaint patterns.

05

Suppression list automation

Hard bounces and FBL complaints added to suppression immediately. Soft bounces added to retry queue with exponential backoff; permanently suppressed if retry window exhausts (typically 14 days or 5 attempts, whichever comes first).

Reactivation: addresses that resolve (e.g., previously- full mailbox now has space) can re-enter sendable list after retry succeeds. Reactivation rules per category prevent re-adding addresses that should stay suppressed.

06

Per-domain segmentation

Suppression lists isolated per sending domain when appropriate (multi-tenant operations, multi-brand isolation, regulatory compliance for separate streams). Consolidated when shared suppression makes sense (single-brand multi-stream operations).

Segmentation strategy decided at intake based on your sending architecture. Can be adjusted later if architecture changes.

07

Weekly bounce report

Trends analysis: bounce rate over time, category distribution, anomaly flags. Per-domain breakdown if multi-domain. FBL volume by receiver. Recommended actions (e.g., "increased 'mailbox full' suggests recipients on longer-than-typical absences; consider extended retry window for specific list segments").

Report delivered via Telegram weekly. Detailed historical analysis available in customer portal. Audit-ready format for compliance reviewers when needed.

08

What's NOT included

List cleaning before sending (your responsibility or third-party validation tools), content optimization (consulting), reputation monitoring (separate Monitoring product), strategic deliverability decisions, custom categorization rule development beyond standard 50+ categories.

For full deliverability strategy including bounce processing as one component, our Recovery Pack bundle combines this with related products at a discount.

questions before you subscribe

Frequently asked.

Doesn't MailWizz / PowerMTA already process bounces?

They process bounces at a basic level. MailWizz: ~4 categories (hard, soft, internal, FBL). PowerMTA: ~6 categories with more granularity but still coarse. Our service categorises into 50+ specific categories with appropriate per-category action.

The granularity matters at scale. Treating "550 mailbox full" the same as "550 user does not exist" damages reputation when temporary issues get permanently suppressed (lost contacts) and permanent issues stay in your sendable list (re-mailing damages reputation). Granular handling avoids both errors.

What's in scope vs out of scope?

In scope: bounce categorization, FBL ingestion, suppression list updates, FBL inbox setup with major receivers, weekly reporting.

Out of scope: list cleaning before sending (your responsibility), content optimization (consulting), reputation monitoring (separate Monitoring product), strategic deliverability decisions, custom categorization rule development.

Why do FBL programs take 7-14 days to register?

Receiver-side approval varies. Some receivers (Gmail Postmaster, Outlook SNDS) approve same-day on properly- authenticated submissions. Some (Yahoo CFL, AOL Postmaster) require manual validation periods of 3-10 days. Some smaller FBLs require waiting for next batch approval cycle.

We submit registrations day 1; track approvals weekly; most domains reach full FBL coverage within 14 days. Bounce processing for non-FBL bounces (the bulk of volume) begins immediately on existing data.

How does this integrate with my existing setup?

We integrate with MailWizz, PowerMTA, Postfix, or your custom MTA stack. Integration patterns: bounce data ingested from MTA bounce queue or pickup directory, suppression updates pushed back to your sending system via API or database update.

Setup completes during onboarding (1-3 days for integration, 7-14 days for FBL registration to fully complete). Bounce processing for new bounces begins during integration; historical bounce backlog processed after integration completes.

What happens to my existing suppression list?

Imported during onboarding. Existing suppression entries re-categorized using our taxonomy where source data allows; entries without category metadata stay suppressed with default "imported_legacy" tag. No suppressed addresses get reactivated without your explicit consent.

For operations wanting to clean stale suppression entries (addresses that may have become valid again over years), cleaning service available as one-time work (€199 flat for under 100K entries). Not included in monthly subscription.

Can I customise categorization rules?

Yes. Standard taxonomy covers 50+ categories with default actions; customisations supported at customer level. Common customisations: never auto-suppress (you want to review all bounces manually), specific category routing (route "mailbox full" to retry queue managed by your team), integration with external CRM for suppression sync.

Standard customisations included in base subscription. Custom rule development beyond standard taxonomy bills separately at consulting rates.

What about IPv6 bounces or unusual receivers?

IPv6 bounces parsed identically to IPv4. Major receivers covered for FBL; smaller regional providers (Mail.ru, Yandex, GMX, ProtonMail, regional Asian providers) have limited or no FBL programs available; their bounces still categorize but FBL-style complaint feedback isn't available.

For unusual sending patterns (custom protocols, non-SMTP routing, specialised infrastructure), case-by-case at intake. We work with whatever infrastructure you run.

How does cancellation work?

Cancel anytime via Telegram. Subscription ends at month boundary. Final-month handover: existing suppression list exported, FBL inbox handover documented, integration removal guidance provided.

After cancellation, FBL inboxes can either continue forwarding to your destination (you handle parsing yourself) or be deactivated entirely. Most customers retain FBL inboxes after cancellation since registration has long-term value even without active processing.

How does payment work?

Monthly billing in advance. €29 charged on subscription anniversary. Payable in any of our 11 supported cryptocurrencies via self-hosted BTCPay. Pre-paid 6-month subscription: €159 (5% discount). Pre-paid 12-month: €313 (10% discount).

also relevant

Related services and references.

recurring

Deliverability Monitoring

FBL ingestion overlaps with monitoring; combined coverage. About 50% of customers run both.

→ one-time

Deliverability Audit

If high bounce rate suggests list quality issues, audit identifies root causes. €299.

→ one-time

DNS Authentication Setup

Required for FBL program registration. Setup before bounce processing if not yet done. €99.

→ recurring

MailWizz Managed

Bounce processing complements operational management. Common pairing.

→ bundle

Recovery Pack

Recovery + monitoring + bounce processing bundled at discount. Common post-recovery path.

→ per hour

Consulting

For custom categorization rule development or list-cleaning strategy.

→

Bounce processing infrastructure architecture

Production bounce processing infrastructure handles three distinct workloads: real-time bounce capture from MTA delivery attempts, classification of bounces by category (hard, soft, transient), and suppression management across the sending operation. Each workload has specific operational requirements that the architecture needs to address.

The capture layer: MTA produces bounce events as messages flow through delivery attempts. PowerMTA writes accounting files with per-message disposition; Postfix logs delivery outcomes; other MTAs have equivalent mechanisms. The capture pipeline ingests these events with minimal latency, typically under 60 seconds from MTA event to bounce processing.

The classification layer: each bounce event is categorized based on SMTP response code, response text patterns, and receiver-specific rules. The classification produces hard/soft/transient categories that drive different downstream handling. Misclassification produces operational problems: hard-bounced addresses that should not be retried but get retried damage reputation; soft-bounced addresses that should be retried but get suppressed shrink the legitimate audience.

The suppression layer: hard bounces produce permanent suppressions; the suppression list propagates to all sending infrastructure within 24 hours. Soft bounces enter retry queues with exponential backoff up to a maximum retry window (typically 24-72 hours). The infrastructure tracks per-recipient state across the sending operation, preventing repeat sending to suppressed addresses regardless of which sending source attempts delivery.

Our managed bounce processing handles all three layers as an integrated service. The customer-side integration is typically through the existing ESP control plane (MailWizz, Acelle, custom) with our infrastructure operating as the bounce-processing backend. The integration is operationally transparent to the customers normal workflow.

Receiver-specific classification rules that production needs

Standard SMTP code-based classification produces correct outcomes for most bounces but misses receiver-specific patterns that require explicit rules. The patterns below capture what production bounce processing needs to handle correctly.

Gmail: returns 421-4.7.32 for DMARC alignment failures, which are functionally permanent failures for the affected recipient (alignment will not start working without configuration change). Code-based classification treats 4xx as soft and retries; correct handling treats 421-4.7.32 as hard for that recipient.

Microsoft consumer: returns various 4xx codes for what are effectively long-term blocks. Code-based classification retries; correct handling identifies the specific 4xx codes Microsoft uses for long-term blocking and treats them as hard.

Microsoft 365 commercial: returns 550 5.7.515 for non-compliant bulk mail. The 5xx code maps to hard correctly, but the operational handling should also flag the underlying compliance issue rather than just suppressing the recipient because the same compliance issue will affect all bulk sending to Microsoft 365 properties.

Yahoo: returns 421-4.7.0 for greylisting which is genuinely transient. Standard retry behavior produces correct outcomes. The classification rule should distinguish 421-4.7.0 from 421-4.7.32 (the Yahoo version of DMARC failure) because they require different handling despite similar codes.

Corporate gateways: vary substantially in their response code conventions. Common patterns include returning 4xx codes for what are effectively permanent reputation blocks, returning 5xx codes for what are temporary capacity issues, returning unusual extended status codes that require receiver-specific interpretation. Our classification ruleset handles the major gateway vendors (Mimecast, Proofpoint, Barracuda, Cisco IronPort) with documented per-vendor rules.

Bounce processing pricing and tier structure

Bounce processing service comes in three tiers reflecting operational complexity and volume. The standard tier at EUR 39 monthly covers operations sending up to 1M monthly with standard bounce classification and suppression management. The tier handles the typical sender with single-domain operations and moderate volume.

Professional tier at EUR 119 monthly covers operations sending 1M to 10M monthly with advanced classification (receiver-specific rules), per-segment suppression policies (different categories with different bounce tolerance), pattern analysis to identify list-quality decay trends. Suitable for operators running diversified sending programs with multiple categories.

Enterprise tier at EUR 349 monthly covers operations sending above 10M monthly or running multi-tenant infrastructure. The tier adds custom classification rules per customer, per-customer suppression isolation, integration with customer-facing dashboards, dedicated incident response on bounce-rate anomalies.

The tier choice should match operational complexity rather than aspiring to higher tier. Most operations stay at standard tier indefinitely; operators upgrade when their operational requirements outgrow the standard tier capabilities rather than as a default progression.

Integration patterns with common ESP control planes

Integration with MailWizz: bounce processing service replaces the built-in MailWizz bounce handler. Configuration involves pointing MailWizz delivery server configurations to use our bounce-processing endpoints, plus configuring suppression list synchronization between our infrastructure and the MailWizz subscriber database. The integration typically completes within 24-48 hours of engagement start.

Integration with Acelle Mail: similar pattern to MailWizz, with bounce handler replacement plus suppression synchronization. Acelles plugin architecture makes the integration somewhat simpler than MailWizz in some respects; the integration timeline is similar.

Integration with custom ESP control planes: case-by-case based on the specific control plane architecture. The standard integration interface is a webhook-based API that the control plane calls for bounce events and suppression queries; we have integrated with several custom platforms through this pattern.

For operators uncertain about integration feasibility, the diagnostic conversation typically takes 30 minutes through Telegram and produces a clear answer: yes the integration is straightforward, yes it is possible but requires custom development, or no the architecture mismatch is too large to bridge cleanly. The directness saves operators from extended scoping conversations that lead to negative outcomes.

Ready to handle bounces properly?

Telegram subscription takes 15 minutes. Onboarding within 1-3 days for MTA integration. FBL registrations complete within 14 days. Bounce processing on existing bounces begins immediately on integration. Cancel anytime, no contract.

Subscribe on Telegram → Submit ticket

# Median Telegram response: 12 minutes during operating hours