Marketing vs Transactional

Every sending domain on your account is either marketing or transactional. This is a property of the domain, not of the individual message — you cannot switch it with a header. It is configured per domain in the UI; see domain detail.

The distinction changes which compliance headers we add to your messages, and in a few cases whether a header you supply yourself is kept or replaced. If you send both kinds of mail, use two domains.

Which one do I need?

Marketing is for mail a recipient can opt out of — newsletters, campaigns, promotions, product announcements. These messages must carry a working unsubscribe mechanism, and mailbox providers increasingly enforce that.

Transactional is for mail sent in response to something the recipient did — password resets, receipts, order confirmations, security alerts. These are not unsubscribable, because the recipient needs them.

Sending marketing mail from a transactional domain is a deliverability and compliance risk. If you are unsure, ask support rather than guessing.

What changes

	Marketing	Transactional
Precedence	Always set to bulk; a supplied value is replaced	Always removed; the delivered message carries none
Message-Category	bulk/newsletter	transaction/commercial
Custom Message-Category	One of the four bulk/ values; anything else is replaced	One of the four transaction/ values; anything else is replaced
List-Unsubscribe	Added automatically	Only if you supply one
List-Unsubscribe-Post	Added alongside List-Unsubscribe	Added only if you supplied a List-Unsubscribe
List-Help	Not added	Added, when you supply no List-Unsubscribe
Feedback-ID / APR-Info	Carry bulk	Carry txn

The List-* headers apply to the email channel only — they are not added to SMS.

Message categories

Message-Category describes what kind of mail the message is, so receivers can classify it. The header takes a closed set of values — it is not a free-text field, and a value outside the set is not a category even if it reads like one.

You may override our default with any value from the column matching your domain's kind:

Marketing domain	Transactional domain
bulk/newsletter (default)	transaction/commercial (default)
bulk/political-campaign	transaction/optin-request
bulk/legal	transaction/password-reset
bulk/other	transaction/other

Anything else — an undefined subtype such as bulk/promotional, or a value from the other column — is replaced with your domain's default rather than rejected. The header is advisory, so a misclassification is corrected quietly instead of failing the message; check what you send rather than relying on it arriving unchanged.

Capitalisation does not matter, but the delivered header is always lowercase.

The specification also defines system/* and private/* categories. Neither is accepted on submission: system/* describes mail we generate ourselves, such as delivery status notifications, and private/* describes person-to-person mail rather than mail sent through an ESP.

Precedence is set by us, not by you

On a marketing domain we always send Precedence: bulk, replacing any value you supply. On a transactional domain we remove the header entirely, including one you supplied yourself.

The header is not standardised — RFC 3834 describes it as a field whose "use and interpretation vary widely in the wild" — but the one behaviour receivers implement consistently is that bulk, list and junk suppress vacation auto-responders.

That is exactly right for marketing mail and exactly wrong for transactional mail. A password reset or a receipt marked bulk tells the receiving system to treat time-critical mail as something it may quietly set aside — usually the result of a marketing template being reused. Absent is what ordinary individually-addressed mail looks like, so that is what we send.

Unsubscribe handling

On a marketing domain we add List-Unsubscribe and List-Unsubscribe-Post (RFC8058 one-click) to every message, so your mail meets the bulk sender requirements of the major mailbox providers.

If you supply your own List-Unsubscribe, we replace it with ours and carry your URL inside it, so the recipient still reaches your page after the unsubscribe is recorded. Your mailto: is not carried — the address in the delivered header is always ours.

On a transactional domain we add List-Help instead, pointing at our abuse contact.

Supplying List-Unsubscribe on a transactional domain

If you supply the header on a transactional domain, it is rewritten to an Omnivery unsubscribe URL and List-Unsubscribe-Post is added — and List-Help is not added. In other words a transactional message can carry a working unsubscribe link if you ask for one. If that is not what you want, do not send the header.

Unsubscribe links in the body

On either kind of domain you can place an unsubscribe link in the message body with any of these placeholders, in any capitalisation:

[unsubscribe]    [signout]    %unsubscribe_url%    [unsubscribe_url]

Each is replaced with a link unique to that recipient:

<a href="[unsubscribe]">Unsubscribe</a>

See sending email for merge tags and the full header reference.