Dynamic Email: Personalization, Gmail and Campaign Testing

A newsletter can show a local event to one subscriber and an online option to another. A receipt can list the items someone actually bought. Dynamic email makes that possible by changing the message according to recipient data or an event.

For marketing teams, dynamic email content usually means personalized fields and conditional sections assembled before sending. Gmail also uses "dynamic email" for interactive messages that let readers complete actions inside an email. The two meanings need different tests.

Dynamic content and Gmail's dynamic email setting

In an ordinary personalized campaign, your email service provider (ESP) fills in names, chooses blocks and builds the message for each recipient. Once delivered, those particular values are part of that message. Turning a Gmail setting off does not remove the name your ESP already inserted.

Gmail's dynamic email feature is an interactive format. Readers may respond to an invitation or complete another supported action without leaving the message. Google explains the setting under Complete tasks without leaving a message. On Gmail's desktop settings page, it appears under Settings > See all settings > Dynamic email.

Building those interactive messages involves AMP for Gmail, its requirements and the associated application behavior. A screenshot can show appearance; completing an interactive action needs a separate functional test. For a conventional newsletter with different offers or languages, start with the recipient and content checks below.

The four places content can change

Personalized fields insert individual values, such as a first name, account name or appointment date. Your ESP's merge tags or template variables tell it where to put each value. Syntax differs between providers; copying a tag from another tool can leave the literal tag in the message.

Conditional blocks choose content based on a rule. A customer might see renewal details while a trial user sees setup help. Test both who should receive the block and who should never receive it.

Event data describes what just happened: the purchased items, a changed booking or an overdue invoice. The correct template can still contain the wrong event's data, so verify the values against the test event.

Content loaded when the message is viewed can behave differently from text assembled at send time. Remotely hosted images, for example, may be cached by mail clients or intermediaries. Do not assume an image refresh will update every previously delivered email at the same moment.

The email template variables guide covers the application side. For campaign review, the immediate job is simpler: identify what changes and which received messages will demonstrate those choices.

Build a small set of meaningful test contacts

One complete contact with a short name will make almost any template look easy. Add cases that exercise the campaign's actual rules.

For an illustrative renewal campaign, a useful set might include:

1. A customer due to renew: renewal date and account link appear; the new-customer offer is absent.
2. A customer who already renewed: the reminder is excluded or the intended thank-you content replaces it.
3. A contact without a first name: the fallback greeting reads naturally and no raw merge tag remains.
4. A contact with a long account name: the heading and button remain readable on a phone.
5. A contact in another supported language or region: date, currency, wording and destination match that contact's settings.

Adapt these cases using controlled contacts and data you are authorized to process. Keep the test audience separate from ordinary subscribers and unrelated automations.

For each conditional block, include one contact that meets the rule and one that does not. Where rules overlap, test the overlap too. That is how you catch a paid customer receiving a trial-only discount even though both individual branches look correct.

Preview real contact data in your ESP

Start inside the campaign builder and select the intended contact or event for each version. Check the subject and preview text as well as the body. Personalization can fail in any of them.

Mailchimp documents an important distinction: ordinary test emails do not populate contact-specific merge tags and dynamic content as a live audience send would. Use its live merge-tag preview or a small controlled test segment for those checks. The current Mailchimp preview and test instructions explain both paths.

A generic test send that displays a placeholder therefore needs investigation before you edit the template. Conversely, a successful generic test is not evidence that every subscriber will receive the correct conditional offer.

If you use Klaviyo, the Klaviyo device-rendering guide shows how to choose preview data before sending the message. Use the provider's own contact and event controls rather than manually replacing all the variables in a separate copy.

Render the versions that can break differently

After checking the data, send the representative messages to MailSlurp. Create a device render, select the supported clients that matter to your audience and copy its render address. Use the appropriate ESP test or controlled-contact send so the resulting message contains the intended data.

Our Mailchimp walkthrough shows the receive-and-render sequence. Its ordinary test-send path is useful for layout; use the contact-aware path described above when merge behavior is what you need to prove.

Compare the longest version, the shortest fallback and any version that changes the page structure. Review Gmail, Outlook and Apple Mail targets alongside iPhone and Android, including relevant light and dark modes. Look for:

• a long name pushing a heading or button beyond the available width;
• an omitted block leaving a large gap or separating text from its action;
• extra items making the message much longer than the version already approved;
• a translated label wrapping inside a narrow button;
• a regional logo or image becoming hard to see in dark mode.

Match the client and display mode when comparing a correction with the previous render. A desktop result cannot confirm that the narrow mobile version was repaired.

Check the offer behind the button

A button can look correct and still open the wrong page. Follow the received message's tracked link using the corresponding test account and check the destination, language, offer eligibility and environment.

MailSlurp Email Audit helps find broken links and images in the message. A reachable page still needs your content check: a valid URL for last month's promotion is the wrong result. The campaign link-testing guide explains that distinction.

For password resets, magic links and other account actions, continue through the actual test workflow. Confirm the intended account changes and that an invalid or expired action is rejected. Keep those deeper checks with the email integration tests.

Review the fallback as its own message

When a value is missing, a useful fallback should leave the reader with a clear next step. A generic greeting may be fine; an invented price or a wrong account link is not.

Read the plain-text email version too. It can retain an old offer or raw variable after the HTML has been corrected. If the campaign contains an optional image or personalized section, check that the remaining text still makes sense without it.

For placement checks, send the representative campaign through its normal provider to a MailSlurp inbox placement test. A placement sample addresses inbox versus spam outcomes; it does not replace checking that each contact received the right content.

Do I need to render every subscriber's email?

Start with every distinct content branch and the data values likely to change layout. You can then broaden coverage where campaign complexity warrants it. Thousands of contacts with the same short greeting do not add the same information as one untested conditional section.

Can one missing field affect more than the greeting?

Yes. That field might also control a section, subject line or link. Test how the whole message behaves when the value is absent, rather than repairing just the visible blank.

When should I test again?

After changing a condition, data source, fallback, tracking setting or template. Send a fresh representative message and check the result that subscribers will actually receive.