Under the GDPR and CASL alike, you must be able to demonstrate that a person consented to receive your email. Not assert it — demonstrate it. The burden is on the sender, and "they are on our list" is not evidence of anything except that they are on your list.
A defensible consent record is five fields. Four of them are obvious and one is the field everyone discovers they need at exactly the wrong moment.
The five fields
1. Identifier. The email address, plus any internal subscriber ID.
2. Timestamp. When consent was given, stored in UTC. A local timestamp with no time zone is a problem you will not notice until you need to correlate it with something else.
3. Source. Where it happened, specifically. Not "website" — the exact form URL, or "import from 2024 trade show list", or "API, integration name". Specific enough that you could reconstruct the circumstances.
4. Method. Single opt-in, confirmed opt-in, verbal, written, or imported. If confirmed, store the confirmation click timestamp separately from the original submission, because those are two different events and the second is the one that proves intent.
5. The wording shown at the time. This is the one people miss.
Why the wording field matters most
Your signup form copy changes. You rewrite it, you A/B test it, you add a checkbox, you move the privacy link. Two years later a regulator or a complainant asks what someone agreed to in March 2024, and the honest answer is that nobody knows, because the form now says something different.
Storing a live link to your form is not a record — the form has changed. What you need is a version reference: a short identifier for the consent wording in force at that moment, plus an archive mapping each identifier to the exact text.
The implementation is simple. Give every version of your consent wording an identifier — consent-v3 — store that identifier on the subscriber record, and keep a versioned file of the wording in your repository or your documentation. Increment it whenever the wording changes.
This costs almost nothing to set up and is impossible to reconstruct later, which is the definition of a thing to do now.
For CASL, add two more
CASL distinguishes express consent, which does not expire, from implied consent, which does — two years from a purchase or contract, six months from an enquiry. So Canadian records need:
6. Consent type. Express or implied.
7. The triggering event and its date, if implied, so the expiry can be computed.
Then age out implied consent automatically. A rule that stops mailing someone 24 months after the purchase that created their implied consent is the only reliable implementation; a periodic manual review is a control that fails the first time someone is busy.
Where to store it
On the subscriber record, in your email platform, as custom fields. Not in a spreadsheet somewhere, and not only in the source system.
The reason is practical: when you need to answer a question about one subscriber, you need the answer next to the subscriber. A consent record held in a CRM that no longer syncs, or a form tool you stopped using, is a record you cannot produce.
Most platforms support arbitrary custom fields, so this is a matter of deciding to do it rather than of capability. In IGSendMail you can set them at signup through the API or push them in bulk through the MCP server as part of an import.
How long to keep it
For as long as you process the data, plus long enough afterwards to defend a complaint. Limitation periods vary; keeping consent records for a few years after someone unsubscribes is the common approach, and it is worth noting that a consent record is not the same as marketing data — you are keeping proof of a lawful basis, which is itself a legitimate purpose.
Your suppression list is separate and permanent. It should never be deleted, because the only way to honour an unsubscribe forever is to remember it forever.
What to do about a list you inherited
If you have subscribers with no consent record — an old list, an acquisition, an import from a system nobody documented — you have three options and only one of them is comfortable.
Re-permission them. Send one campaign asking people to confirm they want to keep hearing from you. You will lose most of them to inattention rather than intent, and the ones who remain are provably consented.
Rely on legitimate interest, where available, having done and documented a balancing test. This works for some B2B situations and does not cover the ePrivacy consent requirement for unsolicited marketing in the EU.
Suppress them. Least appealing and sometimes correct, particularly for addresses that have never engaged, which are costing you inbox placement anyway.
The commercial and the compliance answers usually agree here, which is the useful thing about list hygiene: the addresses with no consent record are largely the same addresses that never open. See how to clean your email list.
This is general information rather than legal advice.
Frequently asked questions
What information does a GDPR consent record need?
Who consented, when, how, from what source, and the exact wording they were shown. The last is the one most senders cannot produce later, because form copy changes and no version was recorded at the time.
How long should I keep email consent records?
For as long as you process the person's data, plus a period afterwards long enough to defend a complaint — commonly a few years. Suppression records for people who unsubscribed should be kept permanently, since that is the only way to honour the request.
Do I need consent records for a list I bought or inherited?
You need a lawful basis, and without records you cannot demonstrate one. Either re-permission the list, document a legitimate-interest assessment where that applies, or suppress the addresses. Purchased lists have no defensible consent record by definition.
Where should consent records be stored?
On the subscriber record in your email platform, as custom fields, so the evidence sits next to the person it concerns. A record held only in a source system you may stop using is a record you may not be able to produce.
