Bounces for organizations' sending domains reach EmailService through postfix-k3m1-inbound

FeatureKlusterServices
Shipped
September 16, 2026 at 8:15 PM UTC
Author
Kamo
Commit
11053b3

A campaign sent through the shared relay has its From at the organization's sending domain as its envelope sender, and that domain is a CNAME to contact.kamocrm.com, whose MX is 47.181.8.86 — this pod. So a receiving server that accepted a message and could not deliver it after all writes its delivery report here, and until now it was refused. - The sending domains come from EmailService (relay-senders?format=domains: VERIFIED and FAILING), read at start and every minute. Only plain host names ever reach a table, and an unanswered fetch keeps the last list. - Each domain takes the null sender only, i.e. bounces and servers checking that the address exists. Anyone else gets 550 "This address sends email but does not receive it". - What is taken goes to a `bounces` pipe (the main postfix's spool command, with its own spool) and a bounces-mail sidecar, the main postfix's unsubscribe_mail.py with INCLUDE_RAW, posts it to **************** - stack.loans, mail.stack.loans and contact.kamocrm.com work exactly as before, and nothing here sends to the internet. Tested in a throwaway alpine pod with the same script: null sender 250, a person 550, postmaster@ and abuse@ 250, other and look-alike domains 554, a DSN spooled with its token and the queue empty, a list change applied within a minute, and an unanswered fetch keeping the last list.

All changes

Like what you see shipping?

All of it arrives in your workspace on its own. Start on the free plan and read this page again in a month.

Start Free ForeverView Pricing