What recipient data does NevarMail actually store?

NevarMail minimizes the recipient data it holds and keeps what it can in your own systems — your provider account, or your own database. But it is not zero, and the honest headline is this: every email you send through NevarMail is recorded in a send log that includes the recipient address and the message body. That log is what makes delivery status, analytics and support possible. Beyond it, recipient storage is narrow and named: suppression enforcement, and abuse/fraud handling. This page lists what's stored, feature by feature.

What does NevarMail store when it imports my templates?

When you import a template from your provider (a dynamic template or a design), NevarMail stores the template's own content — its name, subject line, HTML and plain-text bodies — plus the names of any merge fields it finds (like {{first_name}}), never the values that would fill them in. Two things providers commonly attach to a template are explicitly dropped and never read: sample/test data used to preview the template, and hosted thumbnail preview images, either of which can carry real recipient values baked in from a past preview.

What does NevarMail store when it imports my tracking settings?

Onboarding can read your provider's tracking configuration (open tracking, click tracking, Google Analytics tracking, subscription tracking) so you can review it in one place — see Tracking for what each setting means. That import is read-only (it only ever issues GET requests to your provider) and it stores only the on/off flag for each setting, plus the names of your sending IP pools for read-only context. No recipient email addresses, message content, or send history come along with it.

What does NevarMail store when I send an email?

A send log row per message, and it contains recipient data. When a send succeeds, NevarMail writes a row to its emails table holding the to address, any cc and bcc, the subject, and both the HTML and plain-text bodies, alongside the provider's message id and delivery status. Engagement events (delivered, opened, clicked, bounced) are recorded against it.

This is the exception to everything else on this page, and it is the largest one. It exists because delivery status, analytics and "what exactly did we send this person" support questions are not answerable without it. It is not optional today and it is not something you can turn off.

Erasure on request works, and the record says exactly what it covered. An admin submits a request with POST /api/compliance/gdpr/erasure (a signed-in browser session — API keys get 403 SESSION_ONLY). For that address, NevarMail then:

• Send log rows where the address was the primary recipient — to and the subject become [redacted]; cc, bcc, the HTML body, the plain-text body and metadata are cleared. The row survives in that form so aggregate delivery stats stay intact.
• Send log rows where the address was only cc'd or bcc'd — that one address is removed from the cc/bcc list, matched as a whole address and case-insensitively. The rest of the row is another recipient's mail and is left alone.
• Analytics events for the address are deleted outright.
• Local subscriber lists — any row for the address in lists you keep in NevarMail is deleted.
• Activity log entries that mention the address have it redacted in place; the entry itself stays, because it is your operational record.
• Scheduled sends that have not gone out yet — including retries of failed ones — are cancelled if the address is the recipient or is copied on them. A copied recipient cancels the whole send, because there is no way to send it without them.
• A do-not-contact suppression is created for the address if a global one does not already exist (an opt-out scoped to a single use case does not count), and it is kept. This is what stops the address being mailed again if a list is re-imported later.
• Consent records are kept, not erased. The request records a revocation, and the address stays on the opt-out record — that is the evidence that this person asked not to be mailed, which a sender is expected to retain.
• Kept as evidence, and named as such: the send audit log (who sent what to whom) and the erasure request itself both keep the address, so you can show the request was honoured.
• Not touched, and named as such in the erasure record: your connected database (if you have one), your connected inbox database, and your email provider's own logs and suppression lists. Two NevarMail-side stores are also named as not yet covered: mail received by an Agent Inbox (messages and conversations) and test recipient lists. Under GDPR you are the controller for your recipients' data; NevarMail erases what NevarMail holds and does not reach into stores you own.

But there is no automatic retention purge. Rows persist until an erasure request touches them. If your compliance posture needs a defined retention window rather than erasure-on-request, ask — do not assume one is running.

If that is more than your compliance review can accept, say so before you build on NevarMail. It is a deliberate product tradeoff, not an oversight, and we would rather have that conversation early than have you discover it in an audit.

What does NevarMail store about unsubscribes and suppression?

This is the one place NevarMail stores recipient addresses by design, and it's a narrow, necessary exception: an email address, why it's suppressed (unsubscribe, hard bounce, spam complaint, or manual), and when. This exists so NevarMail can guarantee it will never mail that address again — see Unsubscribes and compliance for how that works. It's the kind of data protection law expects a sender to retain specifically to honor an opt-out, not data collected for any other purpose.

Can I keep recipient data entirely in my own systems?

For your contact and list data, yes. Under Settings → BYO Database you can connect your own Postgres database, and NevarMail pushes a subscriber schema there — contacts, lists, and list memberships, including suppression state — and reads and writes that data on your own database instead of NevarMail's infrastructure. Your connection string is tested and encrypted before it's stored, and used only to talk to your own database.

Two things you can move to your own database, and one you cannot:

Delivery itself hands your provider the recipient address, and that happens on your own provider account. But the send-log row for that message — address and body — is written to NevarMail's infrastructure regardless of which databases you have connected. Neither BYO Database nor a customer-owned inbox database moves it.

What about test mode and my first sends?

Onboarding's own test sends never touch anyone but you: the recipient is resolved server-side from your signed-in account and the request has no field to name anyone else. See Test mode and safe send for the full explanation of why your first emails are restricted.

Why does NevarMail store anything about recipients at all?

Four reasons, and only these four:

• Recording what was sent — the send log above: delivery status, analytics, and answering "what did this person actually receive".
• Honoring opt-outs and blocking bad addresses — the suppression list above.
• Fraud and abuse prevention — protecting the shared infrastructure NevarMail's managed-sending customers use.
• Legal compliance — retaining what a sender is required to retain, no more.

Outside of those, the product principle is to keep recipient data where it already lives: your provider account, or a database you control.

What if a feature doesn't say what it stores?

Ask before assuming. NevarMail's provider integrations are deliberately narrow — each one names exactly the endpoints it calls and this page is kept honest against that code, not against intentions. If you're evaluating NevarMail for a compliance review and a data flow isn't covered above, that's a gap in this page, not a gap in scrutiny — reach out and we'll get you a straight answer.

Related pages

• Template import — the full detail on what's imported from your provider's template library.
• Tracking — the privacy tradeoffs of each tracking setting you can turn on.
• Unsubscribes and compliance — how suppression and preferences work end to end.
• First use case — how onboarding avoids touching real recipient data.