Agency Campaign Approval Gates Before First Send
A stage-gate checklist for audience, suppression, authentication, copy, test rendering, ownership, and recorded campaign sign-off.
Product & Engineering · September 25, 2026 · 6 min read
Before you start
A campaign should be marked GO only when every required gate has a recorded owner, artifact, timestamp, and version. Use HOLD for missing evidence and NO-GO for a failed stop condition. Approval confirms readiness for the reviewed scope; it does not certify legality or guarantee placement.
Stage-gate checklist
| Gate | Observable evidence | Owner | Result |
|---|---|---|---|
| Audience | ICP, geography, exclusions, and source recorded | Strategist | ☐ |
| Suppression | Client and required global suppressions matched | Data owner | ☐ |
| Identity | From, reply address, domain, postal address, and opt-out path checked | Delivery lead | ☐ |
| Authentication | SPF/DKIM/DMARC result and checked time attached | Infrastructure owner | ☐ |
| Copy | Exact sequence version, claims, links, and fallbacks approved | Client approver | ☐ |
| Rendering | Seed sends checked in the intended formats and devices | QA reviewer | ☐ |
| Test behavior | Reply, unsubscribe, bounce, and error paths exercised | Operations | ☐ |
| Launch | Schedule, owner, pause path, and monitoring window recorded | Delivery lead | ☐ |
Use the sequence quality checklist for message-level review and the compliance checklist for the sender's separate review obligations.
Decision rule
Any required evidence missing? → HOLD and assign an owner.
Any suppression, identity, or factual error? → NO-GO; correct and rerun affected gates.
All gates pass for the exact version and scope? → GO with timestamp and rollback path.
Record the reviewed audience file hash or version, message version, sender identity, test recipients, evidence links, approver, and expiry. If the campaign changes after approval, route it through change control rather than editing the approved artifact silently.
Governance criteria for a real decision
Treat each gate as a decision about the reviewed scope, not as a ceremonial checklist. The client approver decides whether the audience, offer, claims, and timing are acceptable for the client; the agency delivery lead decides whether the evidence is complete enough to schedule; the data owner decides whether suppression and provenance checks are reproducible; the infrastructure owner decides whether sender identity and authentication evidence match the intended stream; and the operations owner decides whether replies, opt-outs, bounces, and pauses have a tested path. A gate is PASS only when its evidence answers the question for this campaign. “Looks normal,” an old screenshot, or a different audience is not a pass. Use HOLD when the evidence is absent or stale, NO-GO when a stop condition is observed, and GO only when the client decision and operational evidence agree.
Approval record fields and stage owners
Use one approval record per launch window. At minimum, capture the client, campaign and sequence IDs; audience file name, version or hash, source date, geography, and exclusion rules; exact message and link versions; visible From address, reply mailbox, envelope identity if known, and authentication-check timestamp; suppression-list version and match result; seed recipients and rendering evidence; test message IDs; planned schedule, time zone, volume or batch boundary; approver names; delivery, data, infrastructure, QA, and operations owners; decision, rationale, timestamp, evidence URLs, expiry, and rollback action. The strategist owns audience definition, the data owner owns suppression evidence, the delivery lead owns gate coordination and launch controls, the client approver owns business acceptance, infrastructure owns DNS and authentication evidence, QA owns rendering and interaction tests, and operations owns monitoring and pause execution. One person may hold more than one role on a small team, but the record should still name each responsibility explicitly.
Change-control boundary
Approval covers only the recorded audience, sender identity, content version, links, sending path, schedule, and launch window. A typo-only correction can be re-reviewed by the designated copy reviewer if the record says what changed and why; changing a claim, offer, destination, From or reply identity, suppression logic, audience segment, provider, volume plan, or authentication record is a material change. Material changes require a new diff, affected-gate review, and fresh approval before sending. Do not edit the approved file in place and retain the old approval as if it covered both versions. Link the superseded record and mark it replaced so an auditor can reconstruct which artifact was authorized.
Failure, pause, and rollback conditions
Do not launch when a required owner is missing, the audience cannot be reproduced, a suppression match is unresolved, the visible identity or reply route is wrong, an authentication result is absent or inconsistent with the intended stream, a required link or opt-out path fails, or a test reveals an unexpected bounce, reply, or unsubscribe behavior. Pause the campaign if early monitoring shows a new identity, unintended audience, broken opt-out, misrouted replies, or a provider response that differs materially from the approved test. Roll back to the last approved audience, message, sender configuration, and schedule; disable the new batch; preserve message IDs and event evidence; and notify the client approver and delivery lead. A rollback restores the prior known state, but it does not erase messages already sent or remove the need to investigate them.
Worked example
A client approves sequence Q3-partners-v4 for 1,240 contacts, excluding 38 prior opt-outs. The data owner records the CSV hash, suppression-list version, and a zero-unresolved-match result. The infrastructure owner attaches a same-day authentication check for the approved From domain, while QA links desktop and mobile renders plus test message IDs. The client approver signs the exact copy and destination links; operations records a 50-message pilot, a two-hour observation window, the pause owner, and the prior approved sequence. During pilot review, replies route to an unmonitored alias. The result is NO-GO, not an exception: operations pauses the batch, the delivery lead records the incident, the owner fixes routing, and QA repeats the reply test. Because the reply identity changed after the original sign-off, the record receives a new version and client approval before the remaining contacts are scheduled.
Operating the gate record
Run the gates in order, but allow a reviewer to reopen an earlier gate when a later test changes the facts. The delivery lead creates the record and assigns the client approver, audience owner, suppression owner, infrastructure owner, QA reviewer, and pause operator. Record campaign ID, client, audience version or hash, message version, sender identity, planned window, time zone, evidence URLs, decision, expiry, and next review date. The client approver owns the commercial decision; the agency owners attest only to the checks they performed. A contract or approval record is not legal advice and does not guarantee delivery or inbox placement.
Use this compact decision table during the launch meeting:
| Checkpoint | PASS evidence | HOLD or NO-GO condition | Decision owner |
|---|---|---|---|
| Audience and suppression | Reproducible snapshot and matching results | Unknown source, unresolved match, or stale snapshot | Data owner |
| Identity and content | Approved version, tested links, visible sender details | Changed claim, misleading identity, or broken opt-out | Client approver |
| Technical path | Current authentication and event-route evidence | Identity mismatch, failed authentication, or missing events | Infrastructure owner |
| Pilot and monitoring | Test IDs, reply/opt-out results, pause owner | Unexpected recipient, reply route, bounce, or error | Operations |
The decision procedure is: (1) compare each artifact to the approved version; (2) mark PASS, HOLD, or NO-GO; (3) resolve every HOLD with a named owner and due time; (4) run a small approved pilot only after required gates pass; and (5) record the launch timestamp and observation window. A material edit returns the record to the affected gates through campaign change control, while the final technical review can use the pre-send deliverability checklist.
Stop immediately if an opt-out fails, a suppressed record is eligible, a sender identity is wrong, a claim cannot be substantiated, or the pilot reveals cross-client data. Disable the new batch, preserve event IDs and the reviewed files, and roll back to the last approved audience, message, identity, and schedule. Resume only after the defect owner documents the fix, QA repeats the affected test, and the client approver signs the new version. A rollback cannot unsend prior messages, so the incident record must include the affected population and notifications.
Sources
Resources in this guide
- Record the owner, scope, evidence link, status, and checked date for each control.
- Mark the item HOLD when required evidence is missing or a decision is uncertain.
- Attach the completed record to the client or incident review before proceeding.
Common mistakes to avoid
- Recording “approved” without linking to the exact version reviewed.
- Using a successful seed send as evidence that the whole audience is safe.
- Letting an urgent edit bypass suppression and identity checks.
Frequently asked questions
Who gives final approval?
The client-designated approver should own the business and audience decision; the agency delivery lead should own evidence that operational gates were run.
Can approval be permanent?
No. Approval applies to a defined audience, message version, sender identity, and launch window. Material changes require a new review.
Continue learning
Next: run the pre-send deliverability checklist
Use a final evidence pass before scheduling.