Skip to main content
A mailing-list platform (MailWizz, Listmonk, Mautic…) sending through your OxiMail needs the envelope sender to differ from the visible From:
  • From: stays the human-readable address recipients see and reply to.
  • Return-Path: (the envelope MAIL FROM) is a dedicated technical mailbox that collects delivery status notifications, so bounce processing never wades through a person’s ordinary mail.
This is the standard bulk arrangement — every commercial sender works this way (Amazon SES calls it a custom MAIL FROM domain, Postmark a custom Return-Path). Out of the box OxiMail refuses it, correctly: an authenticated account may only use its own identities as MAIL FROM, and a bounce mailbox is deliberately not one of the sender’s identities. Envelope-sender domain grants open exactly this arrangement, and nothing more.
A grant widens the envelope only. The From: header keeps its own gate — it must always be an identity of the authenticated account. And a grant is not an alias: it implies no delivery and creates no identity. It is pure authorisation.

​
How it works

A grant authorises one account to use any local-part of one domain as MAIL FROM. Domain granularity is deliberate: bounce processing normally stamps a different envelope per recipient (VERP — bounce+alice=example.com@bounces.example.org), so per-address rules could never keep up. One granted domain covers every VERP variant. Two safety rails are enforced when the grant is created, not discovered later:
  1. DNS proof. The grant authorises nothing until you publish a TXT record and verify it — the same discipline as relay declared domains. The proof is re-checked periodically; if the record disappears, the grant is suspended fail-closed within one interval and sends under it start being rejected. The oximail_envelope_domain_suspended_total metric counts these suspensions.
  2. The same-organization rule. The granted domain must share its organizational domain with one of the account’s identities. bounces.example.org can be granted to sender@example.org; bounces.other.net cannot. This is the Amazon SES rule, and it is what keeps SPF aligned under DMARC by construction — a cross-organization Return-Path silently breaks DMARC at some receivers weeks later, so OxiMail makes it unrepresentable instead of documenting it as a caveat.
Grants are operator-provisioned (CLI). An account cannot grant itself the exemption that gates it.

​
Setting it up

Say the platform authenticates as sender@example.org and you want bounces collected in a dedicated mailbox.
Point the platform’s bounce processing at bounce@’s mailbox (IMAP), and set its Return-Path to an address under the granted domain. Done: the platform sends as sender@, receivers see sender@, and every DSN lands in bounce@.

​
VERP without any extra server work

If the platform stamps per-recipient envelopes (VERP), have it use a plus-tag of the bounce mailbox: bounce+<subscriber>@bounces.example.org. The grant authorises every variant (any local-part of the domain passes), and OxiMail’s plus-addressing delivers all of them into bounce@’s mailbox natively. No catch-all needed, no server-side configuration. The division of labour is deliberate, and it is how the whole industry works: the mail server authorises and keeps DMARC aligned; the list platform stamps envelopes and parses bounces. OxiMail does not generate VERP addresses and does not manage sending cadence — your platform already does both, and the receiver-side bulk rules (one-click unsubscribe, complaint-rate ceilings) are its obligations too.

​
When a send is refused

A MAIL FROM that matches no identity and no active grant is rejected at end-of-DATA:
Check the journal on the server: if a grant for that domain exists but is unverified or suspended, the log says so explicitly (“one step from done”) instead of looking like a forgery attempt — run envelope-domain verify and re-check your TXT record.

​
Removing a grant

Removal is immediate: sends under the domain start being rejected with the 550 above. --yes is required, as for every destructive verb.

​
Relation to relay accounts

If you run a smarthost, note the boundary: a role="service" relay account has its own envelope authorisation (the proven declared domains of ADR-116) and cannot receive envelope-sender grants — one mechanism per account kind. Grants are for normal accounts on a normal Primary, sending their own organisation’s list mail.