Strategy
Part of Email marketing software strategy: campaign governance
The evidence file behind a ninety day email software plan
What an email marketing software ninety day plan must keep on file: one record per window, what does not count as evidence, and the day-90 decision record.
A ninety day plan for email marketing software is only as good as the file behind it. Keep one record per window, so a reviewer who was not there can rebuild why each gate passed or paused. The plan should not promise a launch by day 90.
The sequence is for organisations operating in England, while the legal guidance it cites is UK-wide. It reports no campaign results of its own. The campaign decision the file supports starts from a written strategy framework, so that part is not repeated here.
What to take away
- Keep one record per window, and let a stranger rebuild each gate from it.
- An imported status with no history, or a sales assurance alone, is not evidence.
- SPF, DKIM and DMARC need a technical owner, but they cannot supply consent or guarantee delivery.
- Keep test records on synthetic or authorised data, never live prospects.
- Record who noticed, paused and approved restart in the failure rehearsal.
- File the day-90 outcome, proceed, revise, extend or stop, with its evidence.
One file with six sections
Each window ends with a gate and adds one section to the file. If a section is empty or holds only what the last column lists, the plan stays in that window rather than borrowing time from the next one.
| Days | File section | Entries that pass | Entries that do not count |
|---|---|---|---|
| 1 to 15 | Decision log | Purpose, population, acquisition route, owner, stop authority | A population described as "all contacts", or a source that cannot be traced |
| 16 to 30 | Permission record | Subscriber type, lawful basis, PECR analysis, notice, objection route, suppression source | A status imported with no history |
| 31 to 45 | Supplier and domain record | Contract terms, sub-processors, exports, deletion, named technical owner | A sales assurance on its own |
| 46 to 60 | Build and test record | Rendered checks, keyboard and assistive technology results, suppression sync | A required fix still open |
| 61 to 75 | Rehearsal record | Who noticed, paused and approved restart | A rehearsal where nobody owns restart |
| 76 to 90 | Recheck and decision record | Rechecked eligibility, notices, claims, accessibility, authentication, mailbox rules | Earlier evidence that has lapsed |
Days 1 to 30: purposes and permissions on file
The decision log names one purpose and one recipient population, with an intended action, an acquisition route, a message classification, an operating owner and a person authorised to stop the work. Research invitations, service information, requested material and direct marketing stay in separate records.
The ICO's direct-marketing planning guidance says organisations should consider the information used, planned activity, responsibilities and lawful basis before marketing begins. Link the log to source evidence rather than a tick beside a software setting. Remove promotional modules from service messages unless the revised purpose and permissions are approved.
The permission record covers subscriber type, the UK GDPR lawful basis and the separate PECR analysis. If consent or a soft opt-in is proposed, store the actual wording, the collection event and the conditions that apply. A named UK-qualified legal adviser and the data-protection lead review it, and their names and the review date go in the file.
Days 31 to 60: supplier, domain and build records
The supplier record maps the platform, integrations, sub-processors, support route, exports, deletion process and exit owner. The ICO's controller and processor contract guidance is marked under review, so confirm the current position and assess commercial terms separately.
For each shortlisted platform, the record can follow the same fields, so options are compared on one basis.
| Field | What to record |
|---|---|
| Pricing basis | Contact count or send volume |
| Contract and exit | Contract term, exit and export terms |
| Data residency | Where the data is held |
| Suppression | How suppression lists and global holds are handled |
| Exports | Contacts, tags, segments, templates and automations |
| Integration | API and integration coverage |
| Sending domain | How a custom sending domain and DKIM keys are set up |
Assign SPF, DKIM and DMARC to a technical owner. The NCSC explains that DMARC also generates reports you can use to understand how your email is being handled, so the file should hold each review the owner makes. Log the domain, the record values and the date of each check.
Google's sender guidelines and Yahoo's bulk sender requirements both expect a custom sending domain with SPF and DKIM aligned to a DMARC record, one-click unsubscribe as set out in RFC 8058, and a monitored complaint rate. Microsoft exposes sender reputation through SNDS. Record the date each provider's current requirements were confirmed, before the first live send.
The build record lists the eligible query, suppression sync, sender identity, reply route, unsubscribe path and failure alerts. Attach rendered checks of the message and linked journey, with keyboard and assistive technology results. The W3C's accessible-writing tips support clear instructions and meaningful links, but testing must cover the organisation's own content and users.
Run it on synthetic fixtures or properly authorised test data. Do not email live prospects merely to prove the workflow, and keep the build on hold while a required fix is open.
Days 61 to 75: the rehearsal record
Fix the metric before anyone views results: population, numerator, denominator, unit, period, timezone, source, exclusions and uncertainty, plus the stop events. The GOV.UK guidance on defining success is written for public services, but it ties metrics to the problem a service is meant to solve.
Then run a dry rehearsal with three injected faults: a suppression failure, an expired claim and an authentication alert. For each one, the record shows who noticed, who paused the work and who approved restart. Pick further faults from the risk scenarios that fit the chosen platform and population.
A rehearsal that nobody can score, because nobody was named in advance, counts as a failed gate and repeats before day 76.
Days 76 to 90: the decision record
Repeat the earlier checks on fresh evidence: audience eligibility, notices, claims, accessibility, authentication, mailbox requirements and supplier changes. If approval is given, limit the first live activity to the scope the reviewers accepted.
Record what was observed without calling association causation and without comparing it with an invented benchmark. The day-90 meeting then picks one outcome and files it with the decision, evidence, owner and next review trigger.
| Outcome | It fits when | Record |
|---|---|---|
| Proceed | Every gate passed and reviewers accepted the scope | Decision, evidence, owner, next review trigger |
| Revise | A gate failed in a way a changed design can fix | The failed gate and the change required |
| Extend | Evidence is missing but the design stands | The missing item, its owner and a new date |
| Stop | The purpose, permission or supplier cannot be supported | The reason and who authorised the stop |
A delayed launch with intact controls is preferable to a deadline met by overriding them.
Before you act
- Name one purpose, one population and a stop authority.
- Document lawful basis, consent wording and suppression source.
- Map supplier terms, sub-processors and exit routes.
- Assign SPF, DKIM and DMARC to a technical owner.
- Test content with keyboard use and assistive technology.
- Rehearse suppression, expired claim and authentication failures.
Common questions
What should the first section of the file hold?
A decision log naming one purpose, one recipient population, the intended action, the acquisition route, the operating owner and the person authorised to stop the work. The owner must be able to state who is eligible, why the message exists and which evidence could justify proceeding.
Why can email authentication not justify sending?
SPF, DKIM and DMARC are technical controls that the NCSC guidance says must be assigned and monitored. Authentication cannot supply consent or promise delivery, so permission and lawful basis are settled separately through documented evidence.
What counts as an acceptable outcome on day 90?
Proceed, revise, extend or stop. The decision, evidence, owner and next review trigger must be documented. A delayed launch with intact controls is preferable to a deadline met by overriding them, and a first live activity should stay within the scope reviewers accepted.
