Email Consent Records: What to Store Before You Send

Overview

Email consent records are the durable evidence that explains why a person is eligible to receive a specific class of email. A useful record answers more than 'is this address on the list?' It should show when permission was captured, what the person was told, which source or form created it, which mailstream it applies to, and whether later opt-outs, bounces, complaints, or preference changes narrowed that permission.

This is operationally important even before anyone asks for proof. The FTC's CAN-SPAM guidance requires accurate identification and honoring opt-outs for commercial email, European Commission GDPR guidance explains obligations around personal-data processing and individual rights, and Google sender guidance emphasizes wanted mail and easy unsubscribe for bulk senders. The safe engineering answer is to make consent, suppression, and audience selection part of the same send-time workflow.

Store the consent event, not just a checked box

A checked `subscribed=true` field is too weak because it overwrites history. Instead, store consent as an event or small timeline: the source that collected it, the wording or consent version shown at the time, the timestamp, the mailstream scope, and the actor if a teammate imported or edited the record. That gives operators a way to explain eligibility without reverse-engineering a spreadsheet months later.

Keep the model readable by marketers and support teams. If someone replies 'why am I getting this?', the answer should be available without a database investigation: they joined the product-updates list from a signup form, opted into lifecycle tips during onboarding, or were imported from a customer contract with a defined notice and scope.

• Use append-only consent events where possible
• Never let imports erase earlier unsubscribe or complaint state
• Separate proof of permission from the marketing profile fields that change often
• Make consent scope explicit before building segments

Scope permission by mailstream and expectation

Most consent mistakes are scope mistakes. A person who requested a product receipt did not necessarily ask for a weekly newsletter. A webinar attendee may expect event follow-up but not every sales nurture. A customer who opted into product updates may still not want partner promotions. Store the permission at the smallest useful scope, then deliberately roll it up when the promise allows it.

This also makes unsubscribe behavior sane. If the footer says 'unsubscribe from product updates', the suppression record should remove product updates. If the header or footer says 'unsubscribe from all marketing', do not keep the recipient in a near-identical lifecycle segment. Consent and suppression should share the same vocabulary.

• Do not treat one consent flag as universal permission
• Use mailstream names that match footer copy and preference-center choices
• Keep transactional/service messages separate from promotional consent
• When the scope is ambiguous, suppress rather than stretch the promise

Treat imports and re-permission as high-risk workflows

List imports are where consent systems usually break. Before importing a CSV, require the operator to declare the source, capture date range, notice given, mailstream scope, and whether the file has been cleaned against existing suppressions. The import should preview how many rows are new, already subscribed, already suppressed, invalid, role-based, or missing consent evidence before any campaign can target them.

Re-permission campaigns need the same discipline. Send them only to people with a plausible existing relationship, keep the ask clear, and suppress non-responders when the campaign is specifically intended to refresh permission. Do not use a re-permission campaign as an excuse to blast a list whose origin nobody can explain.

• A CSV is not consent; it is only a transport format
• Existing suppressions must beat every import
• Quarantine questionable rows instead of letting them into production audiences
• Make re-permission outcomes update the same consent timeline

1. Require a consent source and mailstream scope before accepting an import.
2. Normalize addresses and check them against hard bounces, complaints, unsubscribes, and manual suppressions first.
3. Reject or quarantine rows with no credible source, stale capture dates, or mismatched geography/purpose.
4. Create an import audit record with actor, file hash, row counts, exclusions, and approved send scope.
5. For re-permission, define the success action and the suppression rule for non-responders before launch.
6. Block future segments from using the imported cohort outside the declared scope.

Keep proof without hoarding personal data

Consent records sit between compliance evidence and privacy risk. You need enough information to avoid mailing someone incorrectly and explain why a send happened, but not unlimited copies of forms, raw personalization data, sales notes, or CSV exports. Store minimal structured evidence and apply access controls to anything sensitive, such as IP addresses or raw import files.

Deletion needs special care. Removing a marketing profile should not make an opted-out address eligible again after the next import. Many teams solve this by separating the contact profile from an authoritative suppression or do-not-contact record keyed by a normalized address or hashed recipient key. The operational requirement is simple: deletion should remove unnecessary profile data, not erase the safety state that prevents unwanted mail.

• Minimize raw personal data while preserving eligibility evidence
• Restrict access to import files and raw consent context
• Keep suppression durable even when profiles are deleted
• Review retention rules after incidents, not during one

Run a consent check before every campaign

The point of consent records is not to pass a future audit; it is to stop bad sends today. Add consent checks to campaign QA beside rendering, links, merge tags, unsubscribe headers, and suppression counts. The campaign builder should show who is eligible, who was excluded, and why. If a segment includes contacts with missing or mismatched permission, that should be a launch blocker, not a warning someone can ignore at volume.

Use metrics to spot drift. Watch complaint rate, unsubscribe rate, reply-based opt-outs, hard bounces after imports, and sudden drops in suppression exclusions. A campaign with high complaints may be a consent problem even when authentication passes and the template looks fine.

• Eligibility checks should be automatic, visible, and logged
• Missing consent evidence should fail closed for marketing sends
• Segment performance by consent source to find risky acquisition channels
• Consent QA belongs in the launch workflow, not a separate spreadsheet

1. Confirm the campaign's mailstream and footer promise match the selected audience.
2. Verify every recipient has active consent or another appropriate eligibility basis for that mailstream.
3. Apply hard bounce, complaint, unsubscribe, manual suppression, and role-account exclusions.
4. Review counts by source, consent age, geography, and import cohort before scheduling.
5. Send tests from the final sender domain and verify unsubscribe/preference links write the right state.
6. After launch, compare complaints, unsubscribes, bounces, replies, and conversions by consent source.

Where Mailbase fits in consent operations

Mailbase is relevant when consent records need to affect real campaign operations: MJML campaigns, scheduled sends, A/B tests, analytics, suppression/compliance controls, and a shared reply inbox. The useful layer is not legal advice; it is making eligibility, opt-outs, bounces, complaints, and replies visible before and after each send.

For teams using managed sending or BYO useSend, keep the principle the same: the sending provider accepts messages, but your workflow decides whether a recipient should have been selected. Mailbase can help operators review audience exclusions, enforce suppressions, track replies that say 'remove me', and preserve campaign history so consent decisions are part of the email operating record.

• Use suppression/compliance controls as the authoritative send-time gate
• Route reply-based opt-outs into the same workflow as footer unsubscribes
• Compare campaign analytics by consent source, not only by subject line
• Keep approval and audit history near the campaign that used the audience

Common Mistakes

• Buying lists instead of growing permission-based, engaged subscribers.
• Blasting everyone the same email instead of segmenting for relevance.
• Making unsubscribing hard, which turns opt-outs into spam complaints.
• Judging success by list size or opens instead of clicks and conversions.

Sources & Further Reading

Official docs for current setup details, pricing, and API behavior — verify specifics there, since they change.

Related guides

More on email consent records and the surrounding email marketing workflow:

FAQ

Related reading