Deliverability

Polite sending

Bunzzle keeps a speed per destination (per provider for Gmail, Microsoft, Yahoo and others), starting from conservative limits. When a receiver says “too many connections”, the speed is halved and held; when it says your IP is blocked, sending there pauses, then resumes with one probe email and climbs back slowly. Connections are reused. Emails sent with "lane": "bulk" never delay transactional ones: a password reset goes ahead of any queued newsletter, while bulk still gets a small guaranteed share. GET /paths (or bunzzle paths) shows each destination’s current speed, its limits and every change with the reason.

Bounces, complaints and unsubscribes

Receivers report back, and Bunzzle acts on it:

• Signed return path. Once bounce.your.domain has the MX and SPF records domains add prints, mail is sent with MAIL FROM:<b-…@bounce.your.domain>. The token is signed, so every bounce maps to the exact email, and forged bounces are refused. SPF then also aligns with your domain.
• An inbound listener (BUNZZLE_INBOUND_PORT, 25 in production) accepts bounce, unsubscribe and feedback addresses, and addresses with a route. It reads standard bounces (DSN), non-standard bounces, complaint reports (ARF, to fbl@bounce.your.domain) and ignores auto-replies. With a certificate (BUNZZLE_INBOUND_TLS_CERT_FILE, BUNZZLE_INBOUND_TLS_KEY_FILE) it offers STARTTLS, so bounces and complaints, which quote your recipients’ addresses, arrive encrypted. An address that keeps guessing recipients, sending unknown commands or idling is refused for 15 minutes; the submission ports do the same.
• Inbound routes. bunzzle routes add support@your.domain https://app.your.domain/inbound (or POST /routes) posts every message for that address, or for *@your.domain, to your app as JSON: envelope, headers, text, HTML and attachments, or the raw message with --raw. SPF, DKIM, DMARC and blocklist results are in auth, and BUNZZLE_INBOUND_REFUSE refuses failing mail. bunzzle hooks add inbound URL --max-score N sends each message for a route to a spam or virus filter before it is accepted, the same way as a scan hook, with the client’s IP in Ip and its HELO name in Helo. The score is in spam_score; at --max-score or above the message is refused with 550, and a filter that does not answer gets 451 with --on-error refuse. Requests are signed in the Standard Webhooks format with the secret shown once. 429 and 5xx answers are retried, with Retry-After honored, for about a day; any other 4xx stops at once, and bunzzle routes retry ID sends those again. Point the domain’s MX at this server.
• A suppression list, checked for every email: hard bounces stop all mail for a year, a domain that doesn’t exist for 30 days; complaints and unsubscribes stop bulk mail only, for good. Password resets still reach someone who unsubscribed from a newsletter. GET/POST/DELETE /suppressions or bunzzle suppressions.
• One-click unsubscribe (required by Gmail and Yahoo for bulk senders) is added to every "lane": "bulk" email, signed into DKIM, hosted at BUNZZLE_PUBLIC_URL/u/….
• Webhooks: email.delivered, email.delivery_delayed, email.bounced, email.complained, email.unsubscribed, email.suppressed, email.failed, email.canceled, email.opened, email.clicked, project.limit_approaching. Signed in the Standard Webhooks format. Retried for about a day. Webhook URLs that point to private networks are refused. bunzzle webhooks deliveries ID (or GET /webhooks/:id/deliveries) lists each delivery with every attempt, and bunzzle webhooks resend sends one delivery again with the same webhook-id, or queues a time range (POST /webhooks/:id/resend) that goes out in small batches at the pace the endpoint accepts.
• Event log. With BUNZZLE_EVENT_LOG=true every event also goes to local files, one JSON object per line, rotated daily and gzipped, for log shippers and grep (see docs/configuration.md).

Reputation

• IPs and warm-up. List your sending IPs in BUNZZLE_SOURCE_IPS (ip or ip=bulk for a bulk pool). Each IP’s reverse DNS is checked and its PTR name used as EHLO. A new IP warms up by itself: a daily budget per provider that doubles in week one and grows by half after, but only when yesterday was healthy (few deferrals, bounces, complaints, no blocks); trouble steps it back and alerts you. bunzzle ips shows “warming, day 6 of ~14, today’s budget 1600”. IPs in BUNZZLE_ESTABLISHED_IPS skip warm-up.
• Guards. Bulk mail for a domain is held before Gmail’s 0.3% complaint line, counted from complaint reports and, once Postmaster Tools is connected, from Gmail’s own numbers (or at 5% hard bounces), and bulk mail from an API key is held when it suddenly sends ten times its normal volume, as a leaked key would. Transactional mail keeps flowing. bunzzle holds shows why; bunzzle holds release ID reopens.
• TLS reports. Domains that ask for them (an _smtp._tls record) get a daily report (RFC 8460) on how TLS went with their mail servers: sessions, certificate problems, missing STARTTLS, per MTA-STS policy. HTTPS reports go out by themselves; emailed reports need BUNZZLE_TLSRPT_FROM.
• DMARC reports. With the inbound listener set up, the DMARC record domains add prints asks mailbox providers to send their daily aggregate reports to dmarc@bounce.your.domain. Bunzzle reads them (zip, gzip or plain XML) and GET /domains/:name/dmarc or bunzzle domains reports NAME shows, per day, which IPs sent mail as your domain and whether it passed DKIM and SPF. A server you don’t know in that list is someone sending as you.
• DANE. Recipient domains that sign their DNS and publish TLSA records for their MX hosts get TLS checked against those records, even without a public certificate. Bunzzle checks the DNSSEC signatures itself, from the root down, so no extra resolver is needed; a DNSSEC-validating resolver on the same machine (for example on 127.0.0.1) is used instead when there is one. Answers whose signatures do not check out are not used: their email waits and is retried. A server whose certificate matches none of them is never used. GET /emails/:id shows dane as the TLS status when it applied.
• MTA-STS. Recipient domains that publish an MTA-STS policy get exactly what they ask for: only their listed MX hosts, only over TLS with a valid certificate.
• REQUIRETLS. An email sent with require_tls: true (--require-tls, or REQUIRETLS on MAIL FROM over SMTP submission) goes only to a mail server found through DNSSEC or an enforced MTA-STS policy, over TLS with a verified certificate, and only if that server supports REQUIRETLS too, so the requirement travels with the email (RFC 8689). Otherwise it bounces right away (class requiretls-unsupported, the address is not suppressed); few mailbox providers support REQUIRETLS yet. BUNZZLE_REQUIRETLS=relaxed still requires TLS with a verified certificate but drops the other two checks. A TLS-Required: No header does the opposite: the email ignores the recipient’s MTA-STS and DANE policies, for reaching a server with a broken certificate.
• DKIM rotation. Keys rotate every 90 days (BUNZZLE_DKIM_ROTATE_DAYS): new keys are created and published, Bunzzle switches only after their DNS records verify and a real signature checks out against live DNS, and the old keys stay published for 7 days. With BUNZZLE_CLOUDFLARE_API_TOKEN (DNS edit for your zone), every record Bunzzle owns is published for you.
• bunzzle doctor checks the configuration, every IP’s reverse DNS and blocklist listings, every DNS record of every domain (and what to change), signs a test message and verifies it against live DNS, and lists holds, paused destinations and failing webhooks.
• bunzzle dns-test DOMAIN publishes a test record through the configured DNS provider, checks that every name server of the zone serves it, and removes it.