> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oximail.ch/llms.txt
> Use this file to discover all available pages before exploring further.

# Bulk sending & bounce domains

> Let a mailing-list platform send through OxiMail with a dedicated bounce address: envelope-sender domain grants (Return-Path ≠ From), DNS proof, the same-organization rule that keeps DMARC aligned, and the VERP-ready mailbox arrangement.

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.

<Note>
  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.
</Note>

## 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.

```bash theme={null}
# 1. A dedicated bounce mailbox (a normal account).
oximail account create --email bounce@bounces.example.org ...

# 2. Grant the bounce domain to the SENDING account.
oximail account envelope-domain add --email sender@example.org \
  --domain bounces.example.org
# → prints the DNS proof to publish:
#   _oximail-envelope.bounces.example.org.  IN TXT  "<token>"

# 3. Publish the TXT record, then activate:
oximail account envelope-domain verify --email sender@example.org

# 4. Inspect at any time:
oximail account envelope-domain list --email sender@example.org
```

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:

```
550 5.7.1 MAIL FROM not authorized: not an identity of this account and
its domain has no active envelope-sender grant (operator: oximail account
envelope-domain add/verify)
```

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

```bash theme={null}
oximail account envelope-domain remove --email sender@example.org \
  --domain bounces.example.org --yes
```

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](./outbound-relay#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.