HTML Email: Format Choices, Testing, and Reliable Measurement
Published:
Last Updated:
Category: Marketing Glossary
Authors: Shusaku Yosa
HTML email uses HTML to organize a message with headings, images, buttons, and other presentation elements. Plain-text email focuses on text. Choose a format according to the purpose, audience, receiving environment, and measurement conditions. A more elaborate appearance does not guarantee better outcomes.
A practical sequence is purpose and audience, message and call to action, template, pre-send verification, distribution, and evaluation. Email clients do not behave like a universal web browser, so keep essential information understandable without images or advanced interaction.
HTML, plain text, and rich text are different
Outlook's Rich Text Format, or RTF, is not a subtype of HTML email. Microsoft's message-format documentation explains the distinction and environment considerations.
Format | Typical use | Check |
|---|---|---|
HTML | Organize visual or multi-part information | Client rendering, blocked images, and message size |
Plain text | Concise, text-centered communication | Limited presentation; link measurement depends on delivery implementation |
RTF | A controlled environment that supports it | Recipient compatibility and conversion |
multipart/alternative | Include equivalent text and HTML representations | One message with alternatives, not two separately sent messages |
The MIME multipart/alternative specification defines a container for alternative representations of the same information. Include the essential message and destination in the text version. Test the actual delivery and receiving environments rather than promising identical fallback behavior everywhere.
Plain-text messages can also use tracked links through a delivery service. Measurement design and message format are separate decisions; HTML is not the only format capable of click tracking.
Define the purpose and primary next action
A newsletter, event invitation, and contractual notice have different information and distribution needs. Write down what the reader should understand and do. Adding more offers does not necessarily help that purpose.
In a fictional webinar invitation, readers need the topic, intended audience, date, time zone, outline, and registration destination. See the webinar planning guide for the full process and the CTA guide for making the next action clear.
Component | Reader question | Authoring check |
|---|---|---|
Sender and subject | Who is this and what is it about? | Accurate identity and agreement with the body |
Preview text | Why should I read? | Useful wording without unwanted repeated text |
Heading and body | What do I need to know? | Essential conditions are not image-only |
Images | What does the illustration add? | Alternative text, dimensions, and images-off meaning |
CTA | What happens next? | Specific wording, intended destination, usable size |
Footer | Who sent this and how can I manage it? | Required identity and working unsubscribe routes |
Choose a template and test real receiving environments
A delivery-service template still needs testing with clients used by the audience. Gmail, Apple Mail, and Outlook differ, and newer versus classic Outlook applications can differ too. Do not assume compatibility issues occur only in older versions.
A width around 600 pixels and readable text can be starting design choices, not universal standards. Test long Japanese and English text, narrow screens, zoom, dark mode, and blocked images. The important message and CTA should remain understandable when decoration is unavailable.
Do not assume that scripts, forms, or direct video playback work in every inbox. A thumbnail and explanation linking to a video page can be more dependable than relying on embedded playback. Put complex input on an appropriately tested web page where success can be verified.
Separate source size, remote images, and attachments
HTML source, remotely loaded images, and attachments are different size components. Tracking markup, long content, and reply threads can change the delivered result. Do not present one provider's threshold as a universal limit. Check actual delivery for clipping or missing content, remove unnecessary repetition, and retain the main destination in the text alternative.
Verify authentication, permission, and unsubscribe handling
Google's email sender guidelines require SPF or DKIM for general senders to personal Gmail accounts and additional authentication, including SPF, DKIM, and DMARC, for bulk senders. Applicable bulk marketing messages also need one-click unsubscribe and a clear unsubscribe link in the body. Check the conditions against your message type and sending volume.
Authentication does not guarantee inbox placement. Review how addresses were obtained, the distribution purpose, consent and suppression management, and applicable operating requirements. Keep necessary service communications and promotional preferences appropriately managed.
Assign checks across the delivery-service owner, domain administrator, and campaign operator. Selecting a sender address in an interface does not prove authentication passed. Inspect test delivery and authentication results before accepting the release.
Use a pre-send acceptance checklist
Area | Check | Record |
|---|---|---|
Text and personalization | Names, fallback text, encoding, dates, and conditions | Approved content and fallback behavior |
Rendering | Required clients, mobile, zoom, dark mode, and images off | Environments and check date |
Links | Buttons, body links, logos, unsubscribe, and redirects | Final intended destination |
Distribution | Recipients, suppression, sender, and schedule | Conditions and responsible approver |
Authentication and unsubscribe | Delivery result, authentication, and unsubscribe behavior | Required settings and observed evidence |
Measurement | UTMs, consent, tags, duplicates, and successful actions | Observable measures and unresolved items |
Test unsubscribe behavior with authorized test addresses and an appropriate environment, not by changing a customer's subscription without permission. Follow the URL parameter guide for consistent tracking. Do not place recipients' names or email addresses in campaign URLs.
A fictional personalization test
Create test cases with a known name, missing name, long company name, Japanese text, and English text. Check that missing values produce a natural greeting and long values do not obscure the CTA. A preview is not the final delivered message, so test actual sending as well.
A provider's delivered count follows its delivery definition; it is not a count of messages read in the inbox. Record sends, bounces, delivery, opens, and clicks as separate stages, and name the denominator whenever reporting a rate.
Do not equate opens with reading
Open measurement commonly relies on remote-content requests. Images can be blocked or fetched before a person reads the message. Apple's Mail Privacy Protection explanation describes background retrieval. An open event is therefore not proof of a person reading at that moment.
Security systems can also affect click counts. Check the delivery provider's filtering and definitions. Separate total clicks, unique-recipient measures, verified form completions, and revenue. The lead nurturing guide connects evaluation to the purpose of each relationship stage.
A fictional example with explicit denominators
Suppose one message is delivered to each of 1,000 distinct recipients. Within the same cohort and period, 40 recipients have verified human clicks and eight verified form completions occur. The delivered-recipient click rate is 40 divided by 1,000, or 4%. The delivery-based completion rate is eight divided by 1,000, or 0.8%.
Eight divided by 40 is 20%, but it is a post-click completion rate only if those eight completions are verified as coming from that group of 40. Confirm success conditions, deduplication, identity matching, and the observation window. Without those conditions, record the rate as unverified rather than manufacturing a relationship.
These numbers are fictional, not industry averages or Xtrategy results. A raw registration event is not automatically a registered person. Sales handoff is another process; see SFA responsibilities and records for that stage.
Carry the findings into the next campaign
Keep the subject, audience, date, body, links, test environments, costs, results, and unresolved questions in one record. Before testing variants, define audience assignment, period, and the principal measure. Changing several elements together does not isolate the effect of one subject line or button.
Xtrategy's project management features can help coordinate the plan, owners, progress, and costs of production and review. Send the campaign through the chosen email platform, and carry verified acceptance conditions into the next production cycle.
