Operations
Running email software with a durable record for every campaign
Run email software through controlled intake, evidence, testing, approval, release, exception, recovery and review stages with clear ownership.
Email marketing software operations should move each proposed message through recorded states: intake, evidence review, configuration, testing, approval, controlled release and post-send closure. A platform can execute a send, but it cannot decide whether the recipient population, claim, tracking method or risk is acceptable.
The operating context is an organisation based in England. Most cited privacy and electronic-marketing material is UK-wide, advertising sources cover UK non-broadcast marketing, and the accessibility guide addresses service providers in Great Britain. Research closed on 5 September 2026. A named specialist must review the real workflow before publication or use.
What to take away
- Open one version-controlled record before anyone builds the message and link evidence rather than copying conclusions.
- A status change should record who made it, when, why and which evidence version they saw.
- Privacy and PECR approvals are separate and neither compensates for the other.
- A passed preview is not a passed audience test, and a clean rendering does not settle claims.
- Approval records must name the exact content, data snapshot, configuration and test pack.
Give every campaign a durable record
Open one version-controlled record before anyone builds the message. It should identify the business purpose, recipient population, message classification, data source, controller, operator, proposed release window and accountable service owner. Link evidence rather than copying conclusions into an untraceable comment.
The record can live in a version-controlled document store, an issue tracker or a structured spreadsheet, provided every entry is dated, attributable and linked to the evidence version it reviewed. A campaign record for Mailchimp, Klaviyo, Brevo, HubSpot or Dotdigital should carry the same core fields: campaign ID, business purpose, message classification, recipient population and query version, data source, controller and operator, approved sender and sending domain, gate decisions, test pack, thresholds, release window, incident notes and closure date. The platform's own campaign archive is not a substitute, because it does not hold the reasoning behind a decision.
Use a small set of states with entry and exit conditions:
| State | Evidence needed to enter | Event that permits exit |
|---|---|---|
| Draft | named purpose, population and owner | complete evidence pack |
| Evidence-ready | data, permission, claims and content records | specialist decisions recorded |
| Configured | approved content and versioned settings | acceptance tests pass |
| Approved | every mandatory gate signed | release owner authorises schedule |
| Released | immutable release version and send log | monitoring and reconciliation complete |
| Paused | defect, objection, incident or expired evidence | documented remedy and fresh approval |
| Closed | outcomes, complaints, costs and exceptions reconciled | retention or deletion action assigned |
A status change should record who made it, when, why and which evidence version they saw. Editing the content, population, tracking or sending domain after approval returns the campaign to the relevant earlier state.
Start with purpose and recipient classification
The intake owner describes what the message is intended to do. Genuine service information, requested material, research and direct marketing are not interchangeable labels. In the UK the channel rules sit in the Privacy and Electronic Communications (EC Directive) Regulations 2003 (PECR), where regulation 22 governs unsolicited electronic mail marketing, including the soft opt-in. The ICO's electronic-mail guidance explains that subscriber type and circumstances affect the PECR analysis. Its planning guidance also keeps purpose, responsibility, lawful basis and channel rules as separate questions, and most controllers also need a current entry on the ICO's register of fee payers.
Record the intended population before extraction. Note inclusion and exclusion logic, geography, acquisition route, notice or consent evidence where relevant, suppression sources and the query version. A privacy reviewer should assess UK GDPR matters, while a PECR reviewer examines the channel and subscriber facts. Neither approval compensates for the other.
Freeze data and protect suppressions
Build the release population from an authorised snapshot. Reconcile counts through each join and deduplication step without turning the count into a quality claim. Test a known suppressed fixture and a record that changed status after the source extract. The send stays paused if either can re-enter the audience.
The ICO's preference guidance describes the use of suppression lists and the need to screen new marketing data. The operating record should therefore preserve the objection source, effective time, systems checked, exception owner and correction evidence. Do not treat deletion from one campaign list as proof that connected systems are safe.
Tracking needs its own inventory. List every pixel, redirect, link decoration, cookie or similar mechanism and record purpose, recipient effect and enablement state. The ICO's storage and access technology guidance applies to the actual technology and use. A vendor toggle is evidence of configuration, not a legal conclusion.
Prove the content version
The content owner keeps copy, subject line, sender identity, landing page, creative assets and claims evidence together. CAP's substantiation advice says objective claims need documentary evidence held before publication, which mirrors CAP Code rule 3.7, and its recognition rules require marketing communications to be obviously identifiable, set out in CAP Code rule 2.1. The claims reviewer should record which evidence supports which words and when that evidence expires.
Accessibility is a separate release gate. Check reading order, link purpose, plain-text content, colour use, zoom, keyboard operation and relevant assistive-technology behaviour across the message and destination against the Web Content Accessibility Guidelines (WCAG) 2.2, and expect public-sector buyers to ask about EN 301 549. The Government Equalities Office guide for service providers explains anticipatory reasonable-adjustment duties in Great Britain, but it does not certify a particular email. Record the environments tested and unresolved limitations.
Configure against a signed specification
The operator should not infer settings from an old campaign. A configuration sheet names the approved sender, reply route, authentication domain, audience query, exclusions, tracking state, frequency controls, send window, fallback content and rollback action. Export the final settings or take a system-generated record where the product permits it.
NCSC email-security guidance describes SPF, DKIM and DMARC as distinct controls. Stage changes and monitor them; a successful authentication result neither proves marketing permission nor guarantees inbox placement. NCSC's SaaS guidance keeps customer access, configuration, logging and recovery responsibilities in view even when a supplier runs the service.
Apply least privilege to publishing and audience-export functions. Separate drafting from final release where the organisation's risk warrants it. Review temporary access and remove it after the job. Supplier statements, scoped assurance reports and buyer tests belong in different evidence fields.
Monitor deliverability, not just authentication
Authentication is the floor, not the ceiling. Publish a DMARC record with a policy of none, quarantine or reject, and progress from none to quarantine and then to reject only once the reports show that legitimate mail is aligned; DKIM also needs a current key and a published selector. Read the aggregate reports the DMARC record generates, and check reputation and delivery signals in Google Postmaster Tools and Microsoft SNDS. Run seed-list tests across the major mailbox providers, monitor blocklists such as Spamhaus, and process feedback-loop and complaint data rather than waiting for the next campaign. The operating record should state the sending domain, the DMARC policy in force, the reporting addresses, the reputation trend, the seed-test result and any blocklisting event with its removal date, so that a later reviewer can see what was known at the time of the send.
Run acceptance tests before approval
Use synthetic records and authorised test inboxes. The test pack should cover population inclusion and exclusion, suppression propagation, personalisation fallback, links, sender and reply handling, tracking state, plain text, layout, accessibility, authentication evidence, logging and rollback. Store expected result, observed result, tester, environment, timestamp and defect disposition.
A passed preview is not a passed audience test. A clean visual rendering does not settle claims or privacy. Where a test cannot represent the production condition, state the gap and give the appropriate reviewer authority to delay release.
Make the go/no-go decision explicit
The release owner checks that each gate has a current decision. Privacy, PECR, accessibility, cyber, content and claims, commercial, finance and supplier-contract gates are non-compensating. A favourable cost forecast cannot override a failed suppression test, and legal review does not excuse a broken recovery route.
The approval record names the exact content, data snapshot, configuration and test pack. Any later material change invalidates the affected approval. Avoid generic sign-offs such as "looks fine" because they do not identify scope or reviewer authority.
Control the release and watch the first signals
Release in a bounded way that the organisation can stop. The release owner confirms the final version, schedule and maximum exposure, then watches system errors, complaints, suppression updates, unexpected replies and supplier notices. Do not invent an acceptable defect rate or delivery threshold. Set internal thresholds from risk, contract terms, tested capability and qualified judgement, then record them before launch.
If an error reaches recipients, preserve logs and stop further automation where proportionate. Correcting copy may require a fresh claims review; changing the audience may reopen the privacy and PECR decisions. The incident lead should choose the route from the facts rather than label every problem a personal data breach.
The ICO's personal-data-breach guide covers assessment, documentation and notification, including the 72-hour reporting requirement where the threshold is met. The page is marked for review following legal change, so publication-day verification and qualified advice are required.
A report goes to the ICO through its online personal data breach reporting form; keep the assessment, the decision and the filing together in the same record.
Prepare continuity and exit before they are needed
Keep an offline contact route for the supplier, a current access list, configuration baseline, protected suppression source and tested export procedure. Define how urgent service messages will be assessed and sent if the marketing platform is unavailable. Do not silently move marketing recipients into another tool without repeating the permission and suppression checks.
Contracts should support the operational model. ICO processor-contract guidance covers instructions, security assistance, sub-processors, audit and end-of-contract data among other terms. It is under review, and it does not settle service levels, liability or business continuity. Legal and commercial reviewers must assess the offered terms and actual roles.
Retention and deletion follow the purpose and record type. Keep the minimum evidence needed to prove decisions and respect objections, but do not assign one period to campaign content, consent evidence, logs, complaints and supplier backups without analysis. At closure, name the disposal action, system owner, deadline and exception.
Review the operating system, not just the send
Post-launch review compares the approved record with what happened. Reconcile the audience, final content, configuration, tests, supplier events, complaints, incidents, internal effort and unresolved defects. Separate platform-reported delivery from independent evidence and do not convert either into a claim of commercial effect.
Give each action an owner, due date, evidence requirement and restart condition. Update the workflow when a law, ICO or CAP page changes; a supplier changes controls or terms; an incident exposes a weak hand-off; or repeated rework shows that a state definition is unclear.
The practical next step is modest: take one planned email and attempt to move it from draft to approved using the seven states above. Any missing owner, evidence item or stop authority is an operating defect to fix before the release is scheduled.
Before you act
- Open a version-controlled campaign record before building the message.
- Record the intended population before extraction.
- Test a known suppressed fixture before release.
- List every tracking mechanism and its purpose.
- Run acceptance tests with synthetic records and authorised inboxes.
- Record internal thresholds before launch.
Common questions
What happens if content or population changes after approval?
Editing the content, population, tracking or sending domain after approval returns the campaign to the relevant earlier state. Any later material change invalidates the affected approval, so the release owner must check that each gate has a current decision before proceeding.
Why is a passed preview not enough to approve a send?
A passed preview is not a passed audience test, and a clean visual rendering does not settle claims or privacy. Where a test cannot represent the production condition, the gap must be stated and the appropriate reviewer given authority to delay release.
How should internal defect and delivery thresholds be set?
Do not invent an acceptable defect rate or delivery threshold. Set internal thresholds from risk, contract terms, tested capability and qualified judgement, then record them before launch. The release owner confirms the final version, schedule and maximum exposure before watching system errors and complaints.
In this guide
- Six steps that take an email campaign from open job to recorded closureMove an email campaign through six steps: intake, audience freeze, evidence hand-off, tests, approval and closure, with PECR, DMARC and ICO breach checks.
- Quality checks to run on suppression, claims and rollback before an email releaseCheck audience logic, suppression, claims, accessibility, tracking, authentication, rollback and evidence properly before an email software release.
- Who owns what when a team runs email softwareAllocate accountable email software roles for service ownership, data, content, accessibility, security, release, contracts and incident handling.
- Email service standards a buyer can own, with a clock and an exclusion listDefine buyer-owned email service measures with a population, unit, clock, exclusions, evidence, threshold method, owner and escalation route.
- Email marketing software launch gates before publicationAn email marketing software launch gate framework for testing claims, accessibility, authentication, security and contract terms before publication.
