Rehearse an Email Platform Security Patch Before Production

Apply an urgent email-platform security build through a focused rehearsal: inventory dependencies, freeze queued work, verify required URL permissions, patch and restart a representative environment, run one controlled delivery through the complete path, then promote with explicit rollback and stop conditions.

Editorial disclosure: Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Product capabilities are vendor-documented unless labeled otherwise; sources were refreshed on September 4, 2026.

Adobe’s Campaign Classic v7 latest-release page was updated September 3, 2026. It lists release 7.4.4 build 9401, calls for external delivery-content and attachment domains to be placed on the approved allow list by September 5, and documents security and restart requirements across recent builds. Follow Adobe’s current security guidance and support path for the exact deployment.

Freeze a patch manifest#

Scroll table →

Field	Record
Current build and topology	on-premise, hybrid, or hosted responsibility
Target build and checksum	exact approved artifact
Vendor advisory revision	URL and access timestamp
Required restart	services, order, expected outage
Database and runtime prerequisites	supported versions and migration steps
Connectors	analytics, SMTP, storage, identity, custom code
Queued work	campaigns, workflows, imports, exports, retries
URL permissions	discovered domain, purpose, owner, expiry
Backup and restore point	configuration, database, keys, custom packages
Rollback decision	supported path and maximum decision time

Do not use “latest” as the target value. Preserve the exact build and advisory used for approval.

Inventory external URLs from real artifacts#

Adobe’s URL-permissions documentation explains the relevant control surface. Build the allow list from actual templates, attachments, landing pages, tracking domains, personalization data, and custom workflows—not memory.

Classify each domain:

Scroll table →

Domain use	Validation
Image and asset host	HTTPS, ownership, stable path, expected redirects
Landing/tracking domain	redirect chain, query handling, TLS, brand ownership
Attachment source	access control, size, content type, expiry
Personalization lookup	authentication, timeout, fallback, data classification
Analytics connector	API version, endpoint, credentials, rate limits
Webhook/integration	request direction, signature, retry, failure policy

Approve the narrowest required hosts. A wildcard can turn a deadline into long-lived unnecessary authority. Give temporary entries an owner and removal date.

Drain or pin queued work#

Before restart, enumerate messages in draft, scheduled, prepared, queued, retrying, or mid-workflow states. Choose per class:

drain before maintenance;
hold and resume under the same idempotency identity;
cancel and recreate with explicit reconciliation;
pin to the old environment until completion.

Capture counts immediately before shutdown and after recovery. A missing queue item and a duplicate send are both patch failures.

Rehearse the whole restart path#

In a representative non-production environment:

restore from the same backup mechanism production would use;
install the exact target build;
restart services in the documented order;
confirm schema and configuration migrations;
verify credentials and connector versions;
load the URL permissions;
run health checks and inspect logs;
execute a controlled campaign fixture;
validate delivery, tracking, bounce, unsubscribe, and reporting;
exercise rollback before declaring it available.

A successful process start is not an email-system test.

Canary the final delivery path#

Use internal, consented test recipients and a message containing every critical dependency: hosted image, tracked link, attachment where applicable, personalization fallback, unsubscribe, and expected analytics event.

Verify:

sender authentication and full received headers;
asset and attachment retrieval through the new allow list;
redirects and destination query parameters;
personalization success and timeout fallback;
final HTML and plaintext;
delivery, bounce, complaint-test substitute, and unsubscribe event flow;
reporting and analytics connector ingestion;
no duplicate send across restart or retry.

Migma’s deliverability guidance separates authentication, audience, message, and monitoring. Use the same layered thinking here: a patched server can still deliver a broken link or send to an ineligible audience.

Promotion stop conditions#

Stop when the build or checksum differs, backup restoration is unproven, a required host is missing or unexpectedly broad, queued-work counts do not reconcile, a connector uses an unsupported API, the canary fails, monitoring cannot see the new build, or rollback exceeds the approved window.

Security urgency raises the cost of delay, but it does not make an unexplained production state safe. Escalate through the vendor’s supported emergency path when the rehearsal exposes a blocker.

Post-change evidence#

Retain target build, installation logs, restart timestamps, configuration diff, URL-permission diff, queue reconciliation, canary message ID and received source, authentication results, integration results, monitoring screenshot, approver, and rollback expiry. Review temporary permissions after the incident window.

Evidence limits#

Marketing Wiki did not assess a vulnerability, inspect an Adobe instance, apply build 9401, or run a delivery. Adobe’s current release and permission pages govern the concrete requirements. This runbook is general change-control guidance and cannot replace vendor instructions or a security team’s topology-specific assessment.