惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

G
Google Developers Blog
博客园 - 司徒正美
Last Week in AI
Last Week in AI
Recent Announcements
Recent Announcements
Y
Y Combinator Blog
博客园 - 聂微东
M
MIT News - Artificial intelligence
博客园_首页
Jina AI
Jina AI
博客园 - 叶小钗
酷 壳 – CoolShell
酷 壳 – CoolShell
H
Hackread – Cybersecurity News, Data Breaches, AI and More
J
Java Code Geeks
F
Fortinet All Blogs
aimingoo的专栏
aimingoo的专栏
小众软件
小众软件
Vercel News
Vercel News
The Cloudflare Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
云风的 BLOG
云风的 BLOG
N
Netflix TechBlog - Medium
B
Blog
Google DeepMind News
Google DeepMind News
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
Comment: Suppressed addresses - updated 2026-05-18
Dhiraj Chatp · 2026-05-19 · via DEV Community

Hard Bounce vs Soft Bounce: The Critical Difference

Hard bounces are permanent delivery failures — the recipient address is invalid, the domain doesn't exist, or the mailbox is closed. The ISP's mail server has definitively told you: "This address will never accept mail."

Soft bounces are temporary failures — the mailbox is full, the receiving server is temporarily overloaded, or the message was flagged as too large. The ISP is saying: "Try again later."

The rule: Hard bounces must be suppressed immediately. Soft bounces require escalation logic (multiple retries → hard bounce → suppress).

Detailed Bounce Code Classification

RFC 3463 Enhanced Mail Status Codes (standardized across most MTAs):

Code Class Meaning Action
X.1.0 Hard Generic address error Immediate suppress
X.1.1 Hard Invalid mailbox Immediate suppress
X.1.2 Hard Invalid domain Immediate suppress
X.1.3 Hard Destination mailbox not found Immediate suppress
X.2.0 Soft Mailbox full Retry, escalate after 3
X.2.1 Soft Message too large Retry, reduce size
X.2.2 Soft Storage full (system) Retry, monitor
X.3.0 Soft System not accepting messages Retry later
X.4.0 Soft Network congestion Retry, backoff
X.5.0 Soft Routing error Retry, check DNS
X.6.0 Soft Delivery time expired Retry once

Bounce Rate Benchmarks by Industry

Industry Acceptable Bounce Target Bounce
E-commerce / Retail < 3% < 1.5%
SaaS / Software < 2% < 1%
Financial Services < 1% < 0.5%
Media / Publishing < 4% < 2%
Agency / Marketing < 5% < 2%

If your bounce rate exceeds 3%, stop sending immediately and investigate. Every bounce you send to a closed mailbox is a complaint signal to the ISP.


Email Verification API Integration

The most effective way to prevent bounces is to never add invalid addresses to your list in the first place. Real-time email verification catches typos, dead domains, and spam traps before they enter your queue.

Verification API Comparison

Provider Accuracy Speed Bulk API Pricing
ZeroBounce 99% < 1s Yes $0.003/verify
NeverBounce 98%+ < 1s Yes $0.01/verify
AbstractAPI 95% < 1s Yes $0.002/verify
Hunter 90% < 2s Yes $0.001/verify
MailboxValidator 95% < 1s Yes $0.005/verify

KumoMTA Bounce Processing Lua Integration

-- /etc/kumomta/bounce_handler.lua
-- Real-time bounce classification and suppression

local SUPPRESSION_LIST = {}
local BOUNCE_STATS = { hard = 0, soft = 0, processed = 0 }

-- Load suppression list from file/db on startup
local function load_suppression_list()
    local f = io.open("/var/lib/kumomta/suppression.txt", "r")
    if f then
        for line in f:lines() do
            SUPPRESSION_LIST[line] = true
        end
        f:close()
        log_info("Loaded " .. #SUPPRESSION_LIST .. " suppressed addresses")
    end
end

local function add_to_suppression(email)
    SUPPRESSION_LIST[email] = true
    -- Persist to disk
    local f = io.open("/var/lib/kumomta/suppression.txt", "a")
    if f then
        f:write(email .. "\n")
        f:close()
    end
end

local function is_suppressed(email)
    return SUPPRESSION_LIST[email] == true
end

-- Bounce code classification
local function classify_bounce(smtp_response)
    local code = tonumber(smtp_response:match("%d+")) or 0

    -- RFC 3463 bounce classes
    if code >= 500 or (code >= 400 and code < 500 and string.find(smtp_response, "user unknown")) then
        return "hard"
    elseif code >= 400 then
        return "soft"
    else
        return "unknown"
    end
end

-- Main bounce handler
kumo.on("smtp_delivery_result", function(result, meta)
    BOUNCE_STATS.processed = BOUNCE_STATS.processed + 1
    local bounce_type = classify_bounce(result.message)

    if bounce_type == "hard" then
        BOUNCE_STATS.hard = BOUNCE_STATS.hard + 1
        add_to_suppression(meta.rcpt_to)
        log_warn("Hard bounce: " .. meta.rcpt_to .. " - " .. result.message)
    elseif bounce_type == "soft" then
        BOUNCE_STATS.soft = BOUNCE_STATS.soft + 1
        -- Log for escalation tracking
        track_soft_bounce(meta.rcpt_to, result.code)
    end

    -- Report metrics
    if BOUNCE_STATS.processed % 100 == 0 then
        local bounce_rate = (BOUNCE_STATS.hard / BOUNCE_STATS.processed) * 100
        log_info("Bounce stats: " .. BOUNCE_STATS.hard .. " hard, " ..
                 BOUNCE_STATS.soft .. " soft, rate: " ..
                 string.format("%.2f", bounce_rate) .. "%")
    end
end)

-- Pre-send check
kumo.on("smtp_message_received", function(domain, meta)
    local recipient = meta.rcpt_to

    if is_suppressed(recipient) then
        log_warn("Suppressed address rejected: " .. recipient)
        kumo.reject_recipient("550 5.1.1 Address suppressed")
    end
end)

load_suppression_list()

Enter fullscreen mode Exit fullscreen mode

Pre-Send Verification with HTTP API

-- Real-time verification before accepting into queue
local function verify_email_address(email)
    local http = require("socket.http")
    local ltn12 = require("ltn12")
    local json = require("cjson")

    local response = {}
    local req = http.request{
        url = "https://api.zerobounce.net/v2/validate?email=" .. email .. "&apikey=YOUR_KEY",
        sink = ltn12.sink.table(response),
    }

    if req then
        local data = json.decode(table.concat(response))
        if data.status == "valid" or data.status == "catch-all" then
            return true
        else
            return false
        end
    end
    return true -- Fail open if API is unreachable
end

Enter fullscreen mode Exit fullscreen mode


Suppression List Architecture

A suppression list is your authoritative record of addresses that should never receive mail. It differs from a blocklist — suppression is for your own protection, not for blocking external senders.

Suppression Triggers (Automated)

Trigger Threshold Action
Hard bounce (any code 5xx with user unknown) 1 occurrence Immediate suppress
Soft bounce 3+ occurrences in 30 days Suppress
Complaint feedback loop 1 occurrence Immediate suppress
Manual unsubscribe Immediate Add to unsubscribe list
ESP-related spam trap hit 1 occurrence Immediate suppress

Suppression List File Format

# Comment: Suppressed addresses - updated 2026-05-18
bounced-user@example.com
complained-user@spamtrap.net
unsubscribed@legitimate.com
mailbox-full-123@outlook.com

Enter fullscreen mode Exit fullscreen mode

Syncing Suppression Across Platforms

If you use multiple MTAs (e.g., KumoMTA for outbound, SendGrid for transactional), synchronize suppression lists via webhook:

# Webhook receiver for bounce/complaint events
import json

def handle_webhook(event):
    if event['type'] == 'bounce':
        add_to_suppression(event['email'], reason='hard_bounce')
    elif event['type'] == 'complaint':
        add_to_suppression(event['email'], reason='complaint')

    # Propagate to all MTAs
    for mta in all_mtas:
        mta.sync_suppression(event['email'])

Enter fullscreen mode Exit fullscreen mode


PowerMTA Bounce Configuration

# /etc/pmta/config

# Bounce classification
bounce检查-level up to 2
bounce-interval 15m

# Hard bounce rules
add-parts-filter bounce-checker
match-command RCPT TO (.*) (.*)
    body-match "User unknown" do
        bounce [code] [enhanced-code]
        log-bounce
        suppress
    /match

# Soft bounce rules
match-command RCPT TO (.*) (.*)
    body-match "Mailbox full" do
        tempfail
        retry 3 times every 15 minutes
    /match

# Feedback loop processing
feedbackloop <your-company@postmaster.com>
    add-feedback-filter fbl
    class auto
    source postmaster

Enter fullscreen mode Exit fullscreen mode


List Hygiene Schedule

Proactive list hygiene prevents bounces before they happen:

Schedule Action
Real-time Verify new signups via API
Daily Remove hard bounces from active lists
Weekly Re-verify addresses inactive > 30 days
Monthly Full list re-verification via bulk API
Quarterly Engagement-based segmentation

Engagement-Based Re-Engagement Campaign

Addresses that haven't opened or clicked in 90+ days are high risk. Run a re-engagement campaign before sending your next major campaign:

  1. Send re-engagement email (clear value prop, one-click action)
  2. Non-responders after 2 emails → move to "at-risk" segment
  3. At-risk segment → 30-day cooldown
  4. Still no engagement → suppress permanently

Monitoring Bounce Rate in Real Time

Key Dashboards to Build

  1. Overall bounce rate (hard + soft, rolling 24h)
  2. Hard bounce rate by ISP (spot problematic ESPs fast)
  3. Soft bounce retry success rate (are retries working?)
  4. Bounce rate by campaign (which campaigns have worst lists?)
  5. Suppression list growth rate (is list quality improving?)

Alerting Thresholds

Metric Warning Critical Action
Overall bounce rate > 2% > 3% Pause sending
Hard bounce rate > 1% > 2% Immediate pause
Soft bounce rate > 5% > 10% Investigate ISP
Bounce rate by ISP > 5% > 10% Check authentication
Suppression growth > 10%/day > 20%/day Audit acquisition

FAQ

Q: Is a 2% bounce rate acceptable?
A: For most industries, yes. For financial services or healthcare, target < 1%. Anything above 3% risks ISP penalties.

Q: Should I delete hard bounced addresses from my database or just suppress?
A: Suppress, never delete. Suppressed addresses are flagged but retained for audit purposes. Deleted addresses might be re-registered by a new user and cause problems if accidentally re-added.

Q: How long should I retry soft bounces before suppressing?
A: 3-5 retries over 24-72 hours is standard. If the address is still failing after that, suppress as a "soft bounce exhaustion" address.

Q: Does KumoMTA handle bounces differently than PowerMTA?
A: Both handle bounce codes correctly. KumoMTA's Lua policy gives you more granular control over bounce classification and suppression logic. PowerMTA uses XML configuration for bounce rules.

Q: Can I re-send to an address I previously suppressed?
A: Only if the user re-subscribes or explicitly confirms the address is valid. Suppression exists to protect your reputation — bypassing it manually is risky.


Get Help With Bounce Rate Reduction

PostMTA provides:

  • Full bounce rate audit and root cause analysis
  • KumoMTA bounce processing configuration
  • Suppression list architecture and integration
  • List hygiene automation and verification API setup
  • Real-time alerting and monitoring dashboards

👉 Talk to a deliverability expert →

For related guides, see IP Warmup Strategies, Email Authentication Guide, and SMTP Relay Setup Guide.

References: RFC 3463 (Enhanced Mail Status Codes) | Google Postmaster Tools