Skip to content

How email consent and opt-out enforcement work

This page explains how MapleGather tracks whether a member has agreed to receive marketing emails, what happens when they opt out, and how the system enforces those preferences at send time — automatically, on every send.

MapleGather stores a consent record per member per email category. Before dispatching any marketing-class email, the system checks each intended recipient’s consent state. Members who have opted out are automatically excluded. You can’t override this per send.

MapleGather maintains an append-only log of consent events for each member. Every time a member opts in or out, or an admin updates their preferences on their behalf, a ConsentEventLog row is written. This log is permanent — records are kept even if a member is archived.

A member’s current opt-in state for each category is derived from the most recent event in their log for that category.

Marketing emails are organized into categories — for example, Newsletter, Event invitations, and Donation appeals. Members control each category independently from their email preferences page. Opting out of Newsletter doesn’t opt them out of Event invitations.

Transactional emails (receipts, membership notices, and similar) aren’t subject to opt-out. They always send to every member.

Opt-out enforcement happens automatically at the moment a broadcast or automation dispatches — not when you compose it. This means:

  • A member who opts out after you compose a blast but before it dispatches is excluded.
  • There’s no way to override this check. The system enforces consent on every send.
  • Members excluded for this reason appear as Suppressed in the per-recipient log.

Members can opt out in several ways:

  • Toggle categories on or off from Email preferences in the member portal.
  • Select the unsubscribe link in any marketing email footer.
  • Use Unsubscribe from all marketing emails to opt out of every marketing category at once.
  • Toggle off Renewal reminders in the Reminders section (this is the only transactional automation with a member-controlled opt-out).

When a member contacts support to opt out (or opt back in), an admin can update their preferences from the member’s Email preferences tab. This requires attestation — the admin chooses a source reason (for example, “Recorded via support call”), which MapleGather records in the consent log alongside the admin’s name.

If you’ve added a member manually and have evidence of their consent, you can record it using Record consent on behalf on their record. You must confirm you have that evidence before the system writes the consent row.

For signup sources where extra confirmation is valuable — like newsletter signups — you can require double opt-in. With double opt-in on, a new member receives a confirmation email with a magic link before they’re added to the marketing list. Members who don’t click the link within the configured window (default: 7 days) are not added.

You configure this per signup source in Settings > Email > Opt-in policy.

The append-only consent log is a compliance requirement. If a member or regulator asks “when did this member consent, and who made changes to their preferences?”, the log provides a complete, tamper-evident answer.

Enforcement at dispatch time — not compose time — ensures the system is always acting on the member’s most recent stated preferences. A compose-time check could silently send to someone who opted out after you queued the blast.

The category model gives members granular control. Some members want event invitations but not donation appeals; forcing a binary all-or-nothing choice is a worse experience and leads to more total unsubscribes.

  • Archived members: Consent history is preserved read-only for archived members. Preferences can’t be edited while the member is archived.
  • No consent record: A manually-added member with no consent record is treated as neither opted in nor opted out. They won’t receive marketing emails until consent is recorded.
  • Admin-on-behalf changes: When an admin updates a member’s preferences, the change is recorded with source=admin_override and the admin’s identity in the consent log.