MailSlurp logo

guides

Email Preview Approval Workflow for Campaigns and Product Emails

Build an email preview approval workflow that reviews final delivered emails across clients, devices, links, images, and launch owners before send.

An email preview approval workflow gives teams one clear way to review, fix, and sign off an email before customers receive it.

The key is to approve the final delivered email, not only a screenshot from a design tool or a preview inside an editor. The final message may include tracking links, hosted images, merge output, dynamic blocks, sender metadata, unsubscribe content, and HTML transforms that only appear after the email is generated.

Use MailSlurp when approval needs to connect visual review with inbox receipt, device previews, links, images, and release evidence.

Quick answer

A reliable approval workflow has six steps:

  1. Send the final email from the app, ESP, or staging workflow.
  2. Capture it in a MailSlurp inbox or render address.
  3. Confirm the final content, sender, links, images, and personalization.
  4. Preview Gmail, Outlook, iPhone, Android, desktop, light mode, and dark mode.
  5. Assign owners for any defects and rerender after fixes.
  6. Record the approved result before launch.

Start with Free email render for a quick one-off review. Use device previews when approvals need repeatable render evidence.

When approval needs more than a screenshot

Simple screenshot review can work for early creative feedback. It is not enough when the send is customer-facing and the final email has changed since the design stage.

Use a fuller workflow when:

  • tracking URLs are enabled
  • images are hosted or transformed after export
  • merge tags, Liquid, smart content, or dynamic blocks are used
  • the email includes OTP, reset, billing, legal, or unsubscribe links
  • Outlook, Gmail, mobile, or dark mode defects would create support load
  • reviewers need one shared artifact instead of forwarded test emails
  • the team must prove who approved the launch version

Approving the delivered artifact keeps reviewers aligned on the same message.

Approval roles

Keep ownership explicit so feedback does not stall.

Role What they approve Common defects they catch
Campaign or product owner Message intent, audience, CTA, launch timing wrong offer, wrong environment, missing fallback copy
Designer or email producer Layout, visual hierarchy, client rendering broken spacing, image crop, dark mode contrast
QA or engineer Links, tokens, variables, inbox receipt, workflow behavior broken reset links, stale tokens, bad personalization
Deliverability owner Sender identity, auth, spam-risk, inbox placement SPF/DKIM/DMARC drift, risky headers, poor placement
Launch owner Final decision and evidence unresolved blocker, stale preview, missing sign-off

One person can own more than one role on a small team. The important part is that every required check has a named owner.

Step 1: Capture the final email

Start with the final output, not a draft preview.

For product emails, trigger the same staging or QA flow that users will trigger: signup, password reset, OTP, invoice, alert, or onboarding.

For campaigns, send the final ESP test after personalization, tracking, images, footer, preference-center links, and unsubscribe content are enabled.

Capture the message with a MailSlurp inbox or render address so the review starts from the email customers would receive.

Before visual review, confirm the basics.

  • Subject and preheader are final.
  • Sender and reply-to are correct.
  • Recipient logic is correct.
  • Personalization and fallback values render cleanly.
  • CTAs point to the right environment.
  • Reset, verification, unsubscribe, and preference links work.
  • Hosted images resolve from their final URLs.
  • Legal, footer, and support content is present.

Use email integration testing when a product flow needs API assertions for receipt, body content, links, OTP codes, attachments, or headers.

Step 3: Run client and device previews

Choose a target set that matches business risk.

Most approval workflows should include:

  • Gmail web and mobile
  • Outlook desktop or Outlook web for B2B audiences
  • iPhone and Android mobile views
  • Apple Mail or other high-volume audience clients
  • light mode and dark mode

Look for customer-visible issues: hidden CTAs, clipped content, broken tables, image crop, unreadable text, footer problems, and mobile tap-target issues.

For a reusable checklist, pair this workflow with the email rendering QA checklist.

Step 4: Record findings

Use a simple status model:

Status Meaning Next step
Pass No blocking issue on required targets Mark the check approved
Fix required A customer-visible issue blocks launch Assign owner, fix, resend, rerender
Watch Minor issue accepted for this send Record reason and revisit after launch
Not applicable Target or check does not apply Record why so it is not confused with skipped work

Avoid approving from memory. Attach the render result, inbox message, or launch note where the team tracks release decisions.

Step 5: Rerender after fixes

If the template, ESP settings, link wrapping, or image hosting changes, the old preview is stale.

Rerender after:

  • code or template changes
  • copy or personalization changes
  • image replacement
  • link or tracking updates
  • footer or unsubscribe changes
  • dark mode fixes
  • ESP approval-list or segment changes

Approval should always point to the latest delivered version.

Step 6: Keep launch evidence

The approval record does not need to be complicated. It should answer:

  • Which email version was reviewed?
  • Which clients and devices were checked?
  • Who approved the final version?
  • Which defects were fixed or accepted?
  • Where is the render or inbox evidence?

MailSlurp helps teams keep this evidence near the real email, device previews, inbox assertions, and notification workflows.

Campaign approval pattern

For a marketing or lifecycle campaign:

  1. Finish the campaign in the ESP.
  2. Send the final test to MailSlurp.
  3. Verify merge output, links, images, footer, and unsubscribe content.
  4. Run device previews for required clients.
  5. Share the result with reviewers.
  6. Rerender after any campaign change.
  7. Approve the final render before scheduling or sending.

Use ESP email preview testing for platform-specific workflows.

Product email approval pattern

For signup, password reset, OTP, billing, support, and security emails:

  1. Trigger the flow from staging or QA.
  2. Capture the email in a MailSlurp inbox.
  3. Assert subject, sender, body, links, tokens, and headers.
  4. Run device previews for the required client matrix.
  5. Store the preview result with the release check.
  6. Block release if the message fails a required check.

Pair device previews with email integration testing when the email must be correct visually and functionally.

FAQ

What is an email preview approval workflow?

It is a repeatable review process that captures the final email, checks content and links, previews key clients and devices, assigns defect owners, and records the approved result before launch.

Why approve the delivered email instead of an editor preview?

The delivered email includes final tracking, images, personalization, footer content, MIME structure, and client-specific rendering behavior. Those details can differ from the editor preview.

Who should approve email previews?

Use owners for content, design, QA or engineering, deliverability, and launch decisions. Small teams can combine roles, but each required check should still have a named owner.

Can MailSlurp support agency or client review?

Yes. MailSlurp can receive the final email, generate device previews, and give reviewers a consistent artifact for Gmail, Outlook, mobile, desktop, light mode, and dark mode checks.

Can this workflow run in CI?

Yes. Product teams can capture a real email in MailSlurp, assert the content and links, trigger device previews, and attach the result to the release gate.