The default use case
Every project starts with a default use case. Here is what it is for, why its emails carry the unsubscribe footer, and what happens to a send that names no use case.
Every email you send through NevarMail belongs to a use case — the "why" behind the message (order receipts, a weekly digest, sales outreach). Use cases live inside a project. When you create a project, NevarMail creates its default use case with it, named General, so there is never a moment when a project exists but has nowhere to file a send.
What the default use case is for
- It is the use case a send lands in when you don't name one. A send that carries no
use_case_idbut runs inside a project (a key scoped to that project, compose inside the project, a list send, a sequence) is attributed to that project's default use case. A send with no project to run in, such as one from an organization-wide API key, must name its use case. Every send is therefore traceable to a use case — nothing is ever "unfiled". - It is the starting point for a new project. Onboarding's first email goes out under it. You can keep using it, rename it, or make another use case the default later.
- There is exactly one per project. Making a different use case the default swaps it within that project only; other projects keep theirs.
Why its emails carry the unsubscribe footer
The default use case is suppressable: recipients can opt out of it. Any email sent under a suppressable use case carries the compliance footer — an unsubscribe link and your postal address — and the List-Unsubscribe headers that let mail clients offer one-click unsubscribe.
That is deliberate. A send that names no use case is a send NevarMail knows nothing about. Treating it as opt-out-able is the safe default: a recipient who did not want it can always stop it, and you are never the sender of a message with no way out. If you have mail that genuinely must not be opt-out-able — password resets, receipts, security alerts — create a use case for it, switch off Suppressable, and name it on those sends. That is the explicit choice; the default is the careful one.
The default use case cannot be made non-suppressable, and a non-suppressable use case cannot become the default.
One consequence: an email under a suppressable use case cannot carry cc or bcc. One message carries one unsubscribe identity, minted for the to address, so a copied recipient's unsubscribe click would opt out the primary recipient instead of themselves. That rule already applied to marketing sends; it now applies to every send under a suppressable use case, including the default. Send each recipient their own message, or name a non-suppressable use case for mail that genuinely needs copies.
What you need before the first send
The footer states who sent the email, so NevarMail needs your postal address before it can send anything under a suppressable use case. Every project has its own postal address: your organization's address (set during onboarding, editable in Settings → Marketing) is copied into each new project, and the footer uses the address of the project the email is sent from. To give one project a different address, change it in the project's Project Settings. Saving a new organization address only fills projects that don't have one yet — it never overwrites a project's own. A send under the default use case with no address on file is refused with COMPLIANCE_ADDRESS_REQUIRED — nothing goes out without the footer.
You do not need to switch on marketing sending for this. That switch is about sending emails typed marketing; the footer on a suppressable use case only needs the address.
The System use case
Alongside the default, every project gets a System use case that is not suppressable and is never the default. NevarMail's deliverability probe files its mail there. A send from your own code never lands in it unless you name it.
Conversation mail
Some mail is part of a conversation rather than something you send to a list: replies from your inboxes, an inbox's Forward to, inbound forwards from a routing rule, and chat relays. NevarMail sends these as conversation mail, which names no use case:
- No unsubscribe footer and no
List-Unsubscribeheader, andccis allowed. - A recipient's list opt-out does not stop it: they unsubscribed from your lists, not from replies to mail they wrote. A bounce, a spam complaint or a manual suppression still blocks it.
- It shows in your send history with no use case, under the project it was sent from.
Inbox replies and inbox forwards count toward your inbox outbound usage; routing-rule forwards and chat relays count as ordinary outbound email.
Sends that name no use case
| Where the send comes from | Which use case it lands in |
|---|---|
POST /api/v1/email/send, /schedule without use_case_id, with a key scoped to a project | that project's default use case |
| The same with an organization-wide key | refused with 422 USE_CASE_REQUIRED: name the use case |
POST /api/v1/email/send-to-list without use_case_id | the default use case of the list's project |
The SDK (@bernierllc/nevarmail) and MCP tools without a use case | same as above |
| A sequence created without a use case | the default use case of its project |
| Compose inside a project, without picking a use case | that project's default use case |
Naming a use case explicitly (use_case_id) always wins. It is also the only way a send is trusted to name its list for the suppression check: a send filed under the default because you named nothing honors every list opt-out the recipient has made in that project.
Related pages
- Set up what you send, and why — the onboarding step where the default use case is first used.
- Unsubscribes and compliance — what the footer and suppression actually do.
- Sending email — the
use_case_idfield on every send endpoint.
Set up what you send, and why
Use cases organize your sending by purpose. Here is how the first one gets created, and why your first email can only go to you.
Set up SPF, DKIM and DMARC for your domain
Why mailbox providers need your domain verified, what records to add, and how to tell when it has worked.