This guide is written for operators, not lawyers, and it is not legal advice. It explains what the regulations generally require of email marketing and how SendNectar is built to satisfy it. Confirm your specific obligations with counsel — particularly if you operate across multiple jurisdictions.
Lawful basis: the question that comes first
Under GDPR you need a lawful basis to process personal data. For email marketing, four are relevant:
- Consent — the person actively agreed. The default and cleanest basis for marketing.
- Contract — processing is necessary to perform a contract with them. Covers most transactional mail.
- Legal obligation — you are required by law to process it.
- Legitimate interest — you have a genuine interest that does not override their rights. Narrow, and requires a documented balancing assessment.
The mistake is treating this as an account-level setting. Basis varies by what you are sending and to whom. SendNectar records lawful_basis on every consent event, so a contact can be on a contract basis for receipts and a consent basis for marketing, evidenced separately.
Consent has to be evidenced, not asserted
Valid consent must be freely given, specific, informed, and unambiguous — and you must be able to demonstrate it. That last requirement is what breaks a subscribed = true model.
Every consent event in SendNectar carries:
| Field | Why it matters |
|---|---|
event_type |
requested, granted, confirmed, withdrawn, migrated |
lawful_basis |
The basis relied on for this specific event |
| Brand, contact, email, topic | Consent is specific — to a brand and a topic, not to your company generally |
source |
Which form, preference centre, import, or API call produced it |
occurred_at |
When it actually happened, separate from when it was recorded |
evidence |
Structured proof, plus an optional consent document reference |
Because the history is retained, current state is derived rather than stored — and the answer to “prove this person opted in” is a query.
Specific means per topic, per brand
“Specific” is doing real work in the regulation. Consent to receive one brand’s newsletter is not consent to receive a sibling brand’s promotions.
Define subscription topics per brand, and gate marketing sends on topic consent. A contact who exists in two brands holds two independent consent states, each separately evidenced. Neither can be used to justify the other — which is exactly the behaviour a regulator expects and exactly what a single shared audience cannot provide.
Double opt-in
Not strictly mandatory everywhere, but it is the strongest evidence available and it is mandatory in some jurisdictions. It produces a confirmed event with its own timestamp and source — a record that the address holder, not just whoever typed it, agreed.
Set opt_in_mode: double on your capture forms. It is the default in SendNectar for a reason.
Withdrawal must be as easy as giving
Every marketing message needs a working unsubscribe, honoured promptly, and withdrawal must not be harder than opting in — no login walls, no support tickets.
Two mechanisms matter:
- Unsubscribe produces a withdrawal consent event and a suppression scoped to the brand or topic. It applies before any future send, and the processing cannot be disabled on any plan.
- Preference centres offer the middle ground: token-authenticated, per-topic, with frequency control. Most people who click unsubscribe want less, not nothing — a preference centre lets them say so, and records the change as a consent event either way.
Suppression, not deletion
When someone unsubscribes, deleting their record is the wrong instinct. Delete it and you lose the proof they unsubscribed and the block itself — so a later import silently re-subscribes them.
Suppressions in SendNectar are records: a hashed address, a scope (tenant, brand, or topic), a reason, a source, and an active flag. Hashing means the block persists without retaining the address in the clear. Scope means an unsubscribe from one brand does not destroy deliverability in another. And they are revocable with an audit trail, so a mistaken suppression can be corrected without rewriting history.
Data subject requests
Individuals can request access, portability, correction, or erasure, generally within one month.
SendNectar models each as a privacy request record with a type, the contact concerned, a status, a requested_at, and a due_at — so the statutory clock is tracked rather than remembered.
- Access and portability are served by exports: contacts, consent records, suppressions, and submissions, as CSV, XLSX, or JSON.
- Erasure leaves a tombstone — a record proving the deletion occurred. It is the one artefact that deliberately survives, because “we deleted it” is a claim you may need to substantiate.
- Correction is a normal update, recorded like any other.
Retention: keeping everything forever is a decision
Data minimisation means keeping personal data only as long as necessary for the purpose. Indefinite retention is a choice, usually an accidental one, and every extra year is more breach exposure and more audit scope.
Define retention policies per data category, optionally per region, with a number of days and an action:
delete— remove it.anonymize— strip identity, keep the aggregate.archive— move it out of the working set.
Record the legal_basis for the period so the choice is defensible. Policies run as scheduled background jobs, because retention that depends on someone remembering is not retention.
Legal holds override all of it. A hold with a reason, an authority, and a validity window suspends deletion for records within its scope — which is what you need when litigation or a regulatory investigation requires preservation.
Controller, processor, and the paperwork
For your own marketing you are the controller and SendNectar is a processor. That relationship needs a data processing agreement — see the DPA and the subprocessor list.
If you run email on behalf of clients, you are likely a processor for them and they are the controller. This is why brands nest under legal entities in SendNectar: each one carries its own legal name, country, postal address, and privacy contact, so the controller identity in the footer is correct per brand rather than global.
A standing checklist
- Lawful basis chosen deliberately, recorded per event.
- Double opt-in on capture forms.
- Subscription topics defined per brand, granular enough to be meaningful.
- Preference centre published for every brand.
- Suppressions imported before contacts on every migration.
- Import consent strategy chosen explicitly, never a blanket subscribed flag.
- Retention policies defined per data category, with a recorded basis.
- DPA in place; subprocessor list reviewed.
- Privacy requests tracked against their due dates.