The good news is that "no HTML mode" doesn't mean "no HTML emails." There are three reliable ways to send a fully designed HTML email from a regular Gmail account, and none of them require an ESP. This guide walks through all three — the manual browser trick, the Send HTML in Gmail Chrome extension, and the Postdrop workflow — plus the Gmail-specific gotchas that bite people regardless of which method they pick. If you're still building the template itself, start with our guides to responsive HTML email templates and how Gmail renders HTML differently from Outlook and Apple Mail, then come back here to actually get it out the door.

Why Pasting HTML Into Gmail Doesn't Work

It's worth understanding the failure before the fix. Gmail's compose window is a rich-text (WYSIWYG) editor: what you see in the window is what the recipient gets. When you paste text into it, Gmail treats that text as content, not as markup to be parsed. So if you paste <h2>Big Sale</h2>, your recipient literally reads "<h2>Big Sale</h2>" — Gmail even helpfully escapes the angle brackets so they display correctly as characters.

Our partner site htmlemail.io has an excellent long-running guide, How to Send HTML Emails in Gmail, that demonstrates this exact failure with a sample snippet — pasted straight into compose, it arrives as a wall of raw code. Their conclusion is the key insight behind every method in this post: you can't give Gmail HTML source, but you can absolutely give it rendered HTML, because the compose window preserves the formatting of rich content you paste into it.

Method 1: The Browser Copy-Paste Trick

The zero-install approach, straight from the htmlemail.io playbook:

1. Save your template as a .html file. Make sure your editor saves plain HTML with a real .html extension — not .txt, not rich text with formatting baked in. If the extension is wrong, the browser will show you raw code instead of a rendered page.
2. Open the file in a browser. Right-click → Open With → Chrome (or any browser). You should see your email rendered exactly as designed. If you see markup, re-check how the file was saved.
3. Select everything and copy. Ctrl+A / Cmd+A, then Ctrl+C / Cmd+C. You're copying the rendered output — the formatted text, images, and table structure — not the source behind it.
4. Paste into Gmail's compose window and send. The formatting survives the paste, and the email arrives looking the way it looked in your browser.

This works because the clipboard carries rich content between the browser and Gmail's editor. It's quick, free, and fine for occasional sends. Its weaknesses show up at volume: it's a manual dance every single time, it's easy to grab a stale file, and complex layouts can pick up small paste artifacts along the way.

Method 2: The Send HTML in Gmail Chrome Extension

If you send HTML from Gmail regularly, the copy-paste dance gets old fast. That's exactly the gap the Send HTML in Gmail Chrome extension closes. Built by the htmlemail.io team, it adds a small panel to Gmail itself: open a compose window, paste your raw HTML source into the extension's textarea, click Inject HTML, and the rendered result appears directly in the message body — no saving files, no browser round-trip, no separate tabs.

A few practical notes from real use:

• It takes source, not a rendered page. Unlike the manual method, you paste actual HTML code — the extension handles the rendering and injection for you. That makes it the natural endpoint of a developer workflow: build, test, copy source, inject, send.
• It works with Google Workspace. Custom-domain accounts behave the same as personal Gmail, so branded sends from you@yourcompany.com work fine.
• It's actively maintained. The current release (v1.2.1, updated April 2025) has 10,000+ users on the Chrome Web Store, and it's free.
• Your HTML still needs to be Gmail-ready. Injection solves the getting-it-into-Gmail problem, not the rendering problem — inline CSS and hosted images (covered below) are still on you.

Method 3: Build, Test, and Copy from Postdrop

Both methods above assume you already have finished, Gmail-safe HTML. That's the part Postdrop.io covers. Paste an existing template into Postdrop's editor — or generate one with its AI — and you get a live preview alongside your code, automatic CSS inlining, and client renders for Gmail, Outlook, and Apple Mail before anything gets sent. It's the missing pre-flight step for either sending method.

The Postdrop-to-Gmail workflow, end to end:

1. Bring in your template. Paste your HTML into the editor, pick one of the free starter templates, or describe what you need and let the AI generate a first draft.
2. Edit with live feedback. Adjust copy, colors, and layout with the preview updating as you type. Keep your CSS in a normal <style> block — Postdrop inlines it for you, which matters enormously for Gmail (see below).
3. Check the renders. Preview across clients and dark mode so you're not surprised after sending — the pre-send routine from our email testing guide.
4. Copy the right thing. If you're using the manual method, select and copy from Postdrop's preview pane — the rendered email, not the code — and paste that into Gmail's compose window, as the htmlemail.io guide recommends. If you're using the Send HTML in Gmail extension, export or copy the inlined source instead and paste it into the extension's textarea.

The Gmail Gotchas That Bite Every Method

However your HTML gets into the compose window, these four constraints still apply:

• Images must be hosted online, publicly. Gmail won't embed your local image files into the layout — anything not referenced by a public URL ends up as an attachment instead of appearing in place. Upload images to your own server, object storage, or a CDN, reference them with absolute https:// URLs, and confirm they load in an incognito window (auth-protected links will be broken for everyone but you).
• Inline your CSS. Pasted rich content keeps element-level formatting, but <style> blocks in the head don't survive the trip — and Gmail strips or ignores much of what does. Every style that matters needs to live in a style="" attribute on the element itself. This is tedious by hand, which is why an automatic CSS inliner should be part of the workflow, not an afterthought.
• Stay under the ~102KB clip. Gmail truncates messages larger than about 102KB behind a "View entire message" link — and clipping also hides whatever sits at the bottom of your email. Keep the HTML lean: no unused styles, no base64-embedded images, no leftover commented-out blocks.
• Send a test first. Always. Send to yourself and at least one other client before the real audience. Check it on mobile, check it with images blocked, click every link. Two minutes of testing catches what an hour of building missed.

Which Method Should You Use?

A quick decision guide:

• One-off send, no installs allowed: the browser copy-paste trick. Save, open, select all, copy, paste.
• Regular sends from Gmail or Workspace: the Send HTML in Gmail extension — paste source, inject, send, done.
• Anything where the template isn't finished yet: build and verify in Postdrop first, then hand off to either method above.
• Real campaigns to a list: Gmail is the wrong tool — it has no unsubscribe handling, no analytics, and sending limits. Move the finished template into a proper ESP; our guide to exporting HTML emails to Mailchimp, HubSpot, and Klaviyo covers that path.

Bottom Line

Gmail hiding its HTML editor isn't the end of designed email from your own inbox — it just moves the rendering step somewhere else. Render in a browser and paste the result, inject source directly with the Send HTML in Gmail extension, or build and verify in Postdrop and copy out whichever form your sending method needs. Whatever route you take, the fundamentals don't change: host your images publicly, inline your CSS, stay under the clip limit, and send a test before you send the real thing. Do that, and "just send it from my Gmail" goes from an eye-roll to a five-minute job.

References: htmlemail.io's guide to how to send HTML emails in Gmail, the Send HTML in Gmail extension on the Chrome Web Store, and Postdrop.io. Internal: our guides to inlining CSS in HTML emails, Gmail vs Outlook vs Apple Mail rendering differences, testing HTML emails before sending, and exporting HTML emails to Mailchimp, HubSpot, and Klaviyo.

The good news: accessible email is mostly a set of habits, not a rewrite. Many of the same techniques that make an email work for assistive technology — semantic structure, strong contrast, real text instead of text baked into images — also make it render better across clients, survive image blocking, and adapt to dark mode and small screens. This is a practical, code-level walkthrough of the changes that matter most, roughly in the order you should apply them. If you build on top of solid responsive HTML email templates, most of this slots straight in.

Why Accessibility Is an Email Problem, Not Just a Web Problem

On the web, accessibility has had two decades of standards, tooling, and legal pressure to mature. Email lags badly. The rendering engines are more fragmented, the layout is still built on tables, and most ESP templates were never designed with assistive technology in mind. That combination means the average marketing email is less accessible than the average web page — a screen reader user navigating a typical promotional email often hears a wall of "table, row, cell, blank, blank" before reaching any actual content.

There's also a business case that's easy to miss. Accessible emails degrade gracefully: they stay readable when images are blocked, when the text is resized, when the client forces its own dark theme. So the work you do for the screen reader user quietly improves the experience for the commuter reading on a cracked phone in bright sunlight, too. Accessibility and robustness are the same investment.

Start With Real Structure: Presentation Tables and Semantic Content

Email layout is built with tables — that's not going away, because it's the only reliable cross-client layout mechanism. The problem is that screen readers try to interpret every table as a data table, announcing its dimensions and reading it cell by cell. When the table is really just there to position a logo next to a headline, that's pure noise.

The fix is one attribute. Mark every layout table as presentational so assistive technology skips its structure and reads the content inside as normal flow:

<table role="presentation" cellpadding="0" cellspacing="0" border="0">
  <tr>
    <td>...</td>
  </tr>
</table>

Then use real semantic tags for the actual content. Headings should be genuine <h1> through <h3> elements, not <span>s styled to look big — screen reader users navigate by heading, and a document with no headings is a document with no signposts. Body copy belongs in <p> tags, lists in <ul> and <ol>. One <h1> per email, describing the core message, gives every reader — assistive or not — an instant sense of what they're looking at.

Set the Language and a Descriptive Preheader

Two small additions punch above their weight. First, declare the document language on the root element so screen readers use the correct pronunciation engine:

<html lang="en" xmlns="http://www.w3.org/1999/xhtml">

Without lang, a reader set to French may attempt to pronounce your English copy phonetically in French — comprehensible to no one. Second, write a real preheader (the hidden preview text pulled into the inbox summary). It's the first thing announced, so make it a meaningful sentence, not leftover boilerplate. Keep it visually hidden but available to the reader rather than stripped out entirely, and never leave it as the default "View this email in your browser."

Write Alt Text That Actually Helps

Every informative image needs alternative text that conveys what the image communicates — not a filename, and not a keyword dump. If a hero image says "50% off, this weekend only," the alt text should say that, because for a screen reader user (and for anyone whose client blocks images) the alt text is the image. Ask yourself: if this image vanished, what would the reader need to know? That's your alt text.

The counterintuitive part: decorative images should have empty alt text — alt="", present but blank. A spacer, a divider flourish, or a background texture carries no information, and an empty alt attribute tells the screen reader to skip it silently. Omitting the attribute entirely is worse: some readers will then read out the image URL. So the rule is binary — describe it meaningfully, or mark it empty.

Get Your Color Contrast Above the Line

Low contrast is the single most common accessibility failure in email, and it's entirely preventable. The Web Content Accessibility Guidelines set the widely-adopted bar: body text needs a contrast ratio of at least 4.5:1 against its background (level AA), and large text — roughly 18pt, or 14pt bold — needs at least 3:1. The stricter AAA level asks for 7:1. That trendy light-grey-on-white caption almost certainly fails, and so do plenty of "brand color" buttons with white labels.

You don't have to guess. WebAIM's free Contrast Checker lets you paste a foreground and background color and instantly tells you the ratio and whether it passes AA and AAA for normal and large text.

Check your body text, your links, your button labels, and — critically — your footer, where the unsubscribe link and legal text so often disappear into pale grey. If a color pairing fails, darken the text or lighten the background until it passes. It's a two-minute fix that changes who can read you.

Never Rely on Color Alone

Related to contrast but distinct: don't use color as the only way to convey meaning. A link that's distinguished from body text purely by being a slightly different shade is invisible to a colorblind reader — and roughly 8% of men have some form of color vision deficiency. Underline your links, or make them unmistakably bolder. If you flag a sale price in red, pair it with a word like "Sale" or a strikethrough on the old price. The information should survive being rendered in greyscale.

Know the Standard You're Building Toward

Email has no accessibility law of its own, so the industry borrows the web's. WCAG 2.2 — the current W3C Recommendation — is the reference point, and its success criteria map cleanly onto email: 1.4.3 (contrast), 1.4.4 (resize text without loss of content), 1.4.5 (avoid images of text), and 1.3.1 (info and relationships, i.e. real semantic structure) are the ones you'll hit most often.

You don't need to memorize the spec. Treat it as the "why" behind the checklist: when someone asks why a caption needs 4.5:1 contrast or why the CTA can't be an image, the answer is a specific, referenceable success criterion, not a matter of taste.

Type Size, Tap Targets, and the Trap of Text-in-Images

Three layout-level habits matter for readers with low vision or motor impairments:

• Body text at 14px minimum, 16px ideally. Anything smaller is a strain, and iOS Mail will auto-zoom text under about 13px, breaking your careful layout. Set a comfortable base size and let the design breathe.
• Tap targets at least 44×44px. A link or button that's a thin line of text is nearly impossible to hit for someone with a tremor or on a moving train. Give buttons generous padding so the tappable area is large. (WCAG 2.2's minimum is 24×24px; 44px is the friendlier, widely-recommended target.)
• Don't bake body text into images. Text inside a JPG or PNG can't be read by a screen reader, can't be resized, can't be recolored for dark mode, and vanishes entirely when images are blocked. Keep text as live HTML text. Reserve images for actual imagery — this is WCAG 1.4.5 in practice, and it's also just more robust email.

Mind the Reading Order

Screen readers read source order, top to bottom — not the visual order your CSS produces. If you use alignment or absolute-ish tricks to make a column appear on the right while it sits first in the HTML, a screen reader user hears it first. The safest structure for accessibility is also the safest for mobile: a single-column layout where source order and visual order are identical. When you do stack columns, make sure the HTML order tells the story correctly on its own, because that's the order assistive technology will narrate.

Dark Mode Is an Accessibility Feature

For many people with light sensitivity or certain visual conditions, dark mode isn't an aesthetic preference — it's what makes reading comfortable or even possible. An email that inverts into an unreadable mess in dark mode (black logo disappearing on a dark background, low-contrast text getting worse) is failing those readers specifically. Handling dark mode deliberately, rather than letting each client force its own inversion, is part of accessible design. Our guide to dark mode email design covers the techniques; treat it as a sibling of this checklist, not a separate concern.

Test It — With Tools and With People

Accessibility can't be eyeballed from the design comp. Automated tools catch a large share of issues fast: WAVE, from WebAIM, evaluates a page for accessibility problems — missing alt text, low contrast, structural issues — and shows them inline. You can render your email as a standalone HTML page and run it through WAVE to catch the obvious failures before you send.

But automation only goes so far. It can tell you an image lacks alt text; it can't tell you the alt text is unhelpful. The real test is turning on a screen reader — VoiceOver on macOS or iOS, NVDA on Windows — and listening to your own email. It's humbling the first time, and it's the fastest way to internalize what good structure sounds like. Pair that with cross-client rendering checks so you know the accessible markup you wrote actually survives in Gmail, Outlook, and Apple Mail; tools like Postdrop.io let you preview across clients in the browser, and our guide on testing HTML emails before sending folds accessibility checks into a normal pre-send routine.

Bottom Line

Accessible email isn't a specialist discipline bolted on at the end — it's a handful of defaults that, once they're in your template, cost you nothing per send. Mark layout tables as presentational and use real headings. Set the language and a meaningful preheader. Write alt text that carries the image's meaning, and blank it for decoration. Clear the 4.5:1 contrast bar, and never lean on color alone. Keep text as text, size it generously, and make buttons easy to hit. Then test with WAVE and with an actual screen reader. Do that, and you stop quietly losing one in six of your subscribers on every campaign — while shipping email that's more robust for everyone else, too.

References: the WCAG 2.2 specification from the W3C, WebAIM's Contrast Checker, and the WAVE evaluation tool. Internal: our guide to dark mode email design, the complete guide to responsive HTML email templates, and how to test HTML emails before sending.

This is the walkthrough that bridges that gap. We'll cover what p=none actually does, how to read the aggregate reports it generates, how to find and fix every legitimate sending source, and the staged rollout — none → quarantine with a percentage ramp → reject — that gets you to enforcement without a deliverability incident. If you need a refresher on what SPF, DKIM, and DMARC each do, start with our SPF, DKIM, and DMARC explainer; this post assumes you've got the basics and want to move from "published" to "enforced."

What p=none Really Is (and Isn't)

The single most common misconception about DMARC is that p=none protects you. It doesn't. p=none is monitor mode: it tells receiving mail servers to take no action on messages that fail DMARC, but to send you reports about what they're seeing. A domain sitting at p=none can still be spoofed freely — the policy explicitly says "deliver failures anyway." What p=none buys you is visibility, and that visibility is the entire point of the phase.

The official DMARC specification, RFC 7489, frames DMARC as a mechanism for senders and receivers to collaborate: senders publish a policy and a reporting address, receivers honor the policy and report back. The reporting half is what makes a safe rollout possible — you get a census of everything sending under your domain before you ever start blocking.

The reason most domains languish at p=none for years isn't laziness — it's fear, and the fear is rational. Modern organizations send mail from far more places than anyone remembers: the marketing ESP, the helpdesk platform, the invoicing system, the HR tool, the CRM, the "no-reply" notifications from three different SaaS products, and the CEO's newsletter that goes through a fourth. Flip to p=reject before all of those are authenticated and aligned, and you will silently bounce real, wanted mail. The walkthrough below is how you de-risk that.

Step 1: Publish a Reporting-Ready p=none Record

If you don't already have a DMARC record, start here. Publish a TXT record at _dmarc.yourdomain.com that requests aggregate reports:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r

The pieces that matter for the rollout:

• p=none — monitor only; nothing gets blocked yet.
• rua=mailto:… — the address that receives aggregate (RUA) reports, the daily XML summaries from each mailbox provider. This is the data that drives the entire rollout. Without it, you're flying blind.
• adkim=r and aspf=r — relaxed alignment to start. Relaxed allows a subdomain to align with the organizational domain; you can tighten to strict (s) later if you need it, but relaxed is the right default.
• fo=1 — request failure reporting for any mechanism that fails, useful where providers still send forensic data.

Verify the record is live and well-formed before you rely on it. A DMARC record checker — like dmarcian's free inspector — parses your published policy and flags syntax problems, which is worth doing because a malformed record is treated as no record at all.

Step 2: Read the Aggregate Reports

Within a day or two of publishing, RUA reports start arriving — as gzipped XML attachments, one per provider per day. Raw, they're unreadable. Do not try to parse them by hand. Feed them into a DMARC reporting service that aggregates and visualizes them: Postmark's free DMARC weekly digest, dmarcian, Valimail, or any equivalent. Point your rua address at the service (or forward to it) and let it do the parsing.

What you're looking for is a source inventory: every IP and sending service that is putting your domain in the From address, and whether each one passes SPF, DKIM, and — critically — alignment. A free tool like Postmark's makes this legible at a glance.

Read the dashboard in two buckets, exactly as Postmark splits them:

• Known / your sources — services the tool can tie back to your DNS. For each, check the SPF and DKIM pass columns. A source passing DKIM at 100% but SPF at 0% (common with ESPs using a shared Return-Path) is usually fine for DMARC as long as DKIM aligns — DMARC passes if either SPF or DKIM passes and aligns.
• Other / unverified sources — senders claiming to be your domain that the tool can't verify. This bucket is the heart of the exercise. Some are legitimate services you forgot about; some are forwarders mangling your mail; and some are genuine spoofers. Your job over the next few weeks is to empty this bucket: authenticate the legitimate ones, and leave only the abusers — who are exactly who p=reject will eventually block.

Step 3: Identify and Fix Every Legitimate Source

This is where the weeks go, and where rushing causes outages. Go through every source in your reports and classify it. The DMARC.org overview describes the core idea well: DMARC works by checking whether a message "aligns" with what the receiver knows about the sender, so your goal for each legitimate source is to make it both authenticate and align.

For each legitimate sending service:

1. Add it to SPF. Include the service's SPF mechanism in your domain's SPF record (e.g. include:_spf.theservice.com). Watch the 10-DNS-lookup SPF limit; if you're near it, lean on DKIM for alignment instead and consider SPF flattening.
2. Enable and align DKIM. Have the service generate a DKIM key and publish the provided selector._domainkey.yourdomain.com record. DKIM alignment is the more robust path because, unlike SPF, it survives forwarding. Prefer DKIM as your primary alignment mechanism wherever a service supports it.
3. Fix the From / Return-Path domain. Many SaaS tools default to sending from their own domain (e.g. notifications@theirapp.com). For DMARC on your domain to matter, mail that represents you should use your domain in the visible From, with a custom Return-Path or DKIM signing domain that aligns. If a tool can only send from its own domain, that's fine — it just won't (and needn't) be covered by your DMARC policy.
4. Re-check the reports. Wait a few days and confirm the source has moved into the "passing and aligned" column. Only when a source is consistently green is it safe to enforce against the rest.

A note on forwarding: mailing lists and forwarders can break SPF (the forwarding server isn't in your SPF) and sometimes DKIM (if they modify the message). This is why DKIM-first alignment matters, and why senders whose mail is forwarded should also support ARC so authentication results survive the hop. Don't let a known forwarder scare you off enforcement — it's expected, and well-aligned DKIM handles most of it.

Step 4: The Staged Rollout to Enforcement

Once your reports show all legitimate sources authenticating and aligning — and the only remaining failures are forwarders you understand or spoofers you want blocked — you start tightening the policy. The golden rule: move in stages, and use the pct tag to ramp gradually. The pct tag tells receivers to apply your policy to only a percentage of failing mail, so you can dip a toe into enforcement instead of cannonballing in.

A sensible, conservative schedule:

Stage A — quarantine 10%

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r

Now 10% of failing mail goes to spam instead of the inbox. Watch your reports and your support channels for a week. If something legitimate was missed, you'll catch it affecting a small slice of mail rather than all of it.

Stage B — quarantine 50%, then 100%

If a week at 10% is clean, raise pct to 50, watch again, then to 100 (drop the pct tag entirely, which defaults to 100%). At p=quarantine with no percentage cap, all failing mail is quarantined — but quarantine is still recoverable: it lands in spam, not the void. Sit here for two to four weeks until you're confident.

Stage C — reject

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r

This is enforcement. Mail that fails DMARC for your domain is now rejected outright — spoofers can no longer put your domain in the From and reach an inbox. Keep the rua reporting on permanently; enforcement isn't "set and forget." New tools get added, vendors change infrastructure, and you want to see a new unauthenticated source the day it appears, not the day a spoof campaign succeeds.

Optionally, set a separate subdomain policy with sp= if your subdomains have a different risk profile, and tighten adkim/aspf to strict (s) only if your sending setup genuinely needs it — most senders are fine on relaxed.

How Long Should This Take?

For a simple domain with one or two sending services, you can responsibly reach p=reject in three to four weeks. For a large organization with a dozen sending sources and active forwarding, two to three months is normal and nothing to apologize for. The timeline is driven by one thing: how long it takes your reports to show a clean source inventory. Don't rush the percentage ramp to hit a deadline — the entire value of the staged approach is that it surfaces problems while they're small.

Resist two tempting shortcuts. First, don't skip p=quarantine and jump from none straight to reject; quarantine is your recoverable safety net, and skipping it converts "some mail went to spam" into "some mail bounced." Second, don't camp at p=none forever telling yourself you're "monitoring." Monitoring without ever enforcing gives you zero spoofing protection and, increasingly, falls short of what bulk-sender programs expect.

What's Next After Enforcement

Reaching p=reject is the milestone, but authentication keeps evolving. The IETF's DKIM working group adopted DKIM2 in March 2026, which is designed to address exactly the forwarding-and-replay weaknesses that make DMARC rollouts fiddly today. If you've just been through this exercise and felt the friction around forwarders breaking alignment, our DKIM2 explainer is the natural next read — it's where this part of the stack is heading.

And remember that authentication only gets your mail accepted. Whether it then renders correctly, loads its images, and presents a working unsubscribe link across Gmail, Outlook, and Apple Mail is a separate problem — the one our guide to testing HTML emails before sending covers, and the one Postdrop.io is built to solve. Get to p=reject and your domain is protected; pair it with clean, well-tested HTML and your mail both arrives and looks right.

Bottom Line

DMARC enforcement isn't a config change — it's a project, and the project is mostly discovery. Publish p=none with aggregate reporting, read the reports until you have a complete inventory of who sends as you, authenticate and align every legitimate source, then ramp through quarantine with the pct tag before committing to reject. Done in that order, you reach enforcement without ever blocking a single wanted message. Done in a hurry, you find out which of your own systems you forgot about — the hard way. Take the staged path; it's slower by design, and that's the whole point.

References: the DMARC specification RFC 7489, the DMARC.org overview, dmarcian's DMARC Record Checker, and Postmark's free DMARC monitoring. Internal: our SPF, DKIM, and DMARC explainer, the 2026 deliverability rules, the DKIM2 authentication upgrade, and our guide to testing HTML emails before sending.

This post is that rulebook, consolidated. If you send any meaningful volume of email — and especially if you cross the 5,000-messages-per-day threshold that triggers the strictest tier at Google, Yahoo, and Microsoft — this is the single checklist to measure yourself against. We'll go provider by provider, then distill it into one set of actions. Throughout, the throughline is the same one our Apple MPP retrospective kept returning to: when engagement signals get noisy, the controllable fundamentals — authentication, list hygiene, reputation — become the load-bearing parts of deliverability.

How We Got Here: The 2024–2025 Convergence

The modern requirements era opened in October 2023, when Google and Yahoo jointly announced new rules for bulk senders, effective February 2024. For the first time two of the largest mailbox providers published an aligned, enforced list of requirements rather than vague "best practices." Microsoft followed: in April 2025 it announced new requirements for high-volume senders to Outlook.com, hotmail.com, and live.com, with enforcement beginning May 5, 2025. Apple, which has never published a Gmail-style bulk-sender table, nonetheless enforces SPF, DKIM, and DMARC checks on inbound mail to iCloud Mail and increasingly penalizes unauthenticated senders.

The practical upshot: the four environments that dominate the consumer inbox now want the same things. The differences are at the margins — thresholds, ramp dates, exact wording — not the substance. That's why a consolidated checklist finally makes sense.

The Universal Baseline (Every Sender, Any Volume)

Before the volume-gated rules, there's a baseline that applies to everyone sending to these providers, regardless of how much you send:

• Authenticate with SPF or DKIM. At minimum, every sender must publish and pass at least one of SPF or DKIM. This is the floor; bulk senders need both plus DMARC (below).
• Valid forward and reverse DNS (PTR records). Your sending IP must have a PTR record, and that hostname must resolve back to the IP. Mismatched or missing reverse DNS is one of the oldest and still most common reasons mail gets throttled.
• Use a TLS connection. Transmit mail over TLS. Google added this to its sender guidelines in December 2023, and it is now an explicit expectation across providers.
• Keep your "From" honest. Don't impersonate Gmail, Yahoo, or any domain you don't control in the From header. Gmail began rejecting mail that spoofs gmail.com From addresses, and provider-impersonation is treated as abuse everywhere.
• Format messages to RFC 5322. Well-formed headers, a valid Message-ID, and a real, resolvable sending domain are table stakes.

If you've worked through our SPF, DKIM, and DMARC explainer, none of this is new — but the difference in 2026 is that these are enforced requirements, not advisory tips. Falling short doesn't mean a lower score; it can mean outright rejection.

Gmail (and the Google Bar)

Google's Email sender guidelines are the canonical reference, and they split into two tiers: requirements for all senders, and stricter requirements for anyone sending roughly 5,000 or more messages per day to personal Gmail accounts.

For bulk senders (5,000+/day to Gmail), Google requires all of the following:

• SPF, DKIM, and DMARC. All three, not one. Your domain needs a DMARC policy published — even p=none satisfies the requirement to have a policy, though you should be working toward enforcement.
• DMARC alignment. The domain in the visible From header must align with either your SPF domain or your DKIM domain. Alignment is the part that trips people up; passing SPF or DKIM isn't enough if it doesn't align with From.
• One-click unsubscribe (RFC 8058). Marketing and subscribed messages must include a working List-Unsubscribe header supporting one-click unsubscribe, plus a clearly visible unsubscribe link in the body. You must process unsubscribe requests within two days.
• Spam complaint rate below 0.3%. Keep your Postmaster Tools reported spam rate under 0.30% at all times, and ideally under 0.10%. Spikes above 0.3% lead to throttling or junking; sustained high rates damage domain reputation durably.

Google's own guidelines stress monitoring with Postmaster Tools — it's the only place you see your Gmail-reported spam rate and domain reputation, and it's effectively mandatory instrumentation for any serious sender.

Yahoo (and AOL)

Yahoo was Google's co-author on the 2024 requirements, and its Sender Hub publishes a near-identical list covering Yahoo Mail and AOL. The requirements mirror Gmail's: authenticate with SPF and DKIM, publish DMARC with alignment, support one-click unsubscribe for bulk mail, and keep complaints low.

One detail worth calling out: Yahoo explicitly references the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) Senders Best Communications Practices as the foundation for its expectations. The providers aren't inventing these rules in isolation — they're codifying an industry consensus, which is exactly why they line up so cleanly across mailboxes.

Microsoft: Outlook.com Joins the Club (2025)

For a while, Microsoft was the conspicuous holdout — Outlook.com had its own postmaster guidance but no equivalent enforced bulk-sender list. That changed in 2025. Microsoft announced new requirements for high-volume senders (those sending more than 5,000 messages per day) to consumer domains: outlook.com, hotmail.com, and live.com.

Microsoft's requirements are deliberately aligned with Google and Yahoo: SPF, DKIM, and DMARC, with proper alignment, for high-volume senders. The enforcement approach is graduated — initially, non-compliant high-volume mail is routed to the Junk folder rather than rejected outright, giving senders a remediation window before harder enforcement. The signal is unambiguous, though: the same three authentication standards are now the price of admission to all three of the biggest consumer mail platforms.

Apple / iCloud Mail

Apple is the one major environment without a published Gmail-style requirements table, which leads some senders to wrongly assume it's lax. It isn't. iCloud Mail evaluates SPF, DKIM, and DMARC on inbound mail, factors authentication into placement, and has tightened its handling of unauthenticated and poorly-reputed senders over time. Because Apple Mail is the dominant client (as our MPP retrospective documented), and iCloud Mail is a large and growing mailbox, treating Apple as an afterthought is a mistake.

The practical guidance for Apple is simply the universal baseline plus the bulk-sender authentication trio. There's no separate Apple checklist to learn — meeting the Gmail/Yahoo/Microsoft bar satisfies iCloud Mail too. That's the entire point of convergence.

The Standards Under the Standards: M3AAWG

Both Yahoo and the broader industry point to M3AAWG as the source of the underlying best practices. M3AAWG is the cross-industry working group — mailbox providers, ESPs, security vendors — that publishes the consensus documents the providers' rules are built on.

Why does this matter to a working sender? Because it tells you where the puck is going. M3AAWG documents — on TLS for mail, on sender best communications practices, on cold email — preview the requirements that providers later enforce. The clearest current example is authentication's next chapter: DKIM2, which the IETF DKIM working group adopted in March 2026. If you want to be ahead of the next round of requirements rather than scrambling when they land, our DKIM2 explainer is the place to start.

The Consolidated 2026 Checklist

Here is everything above, distilled into one actionable list. Work top to bottom; the first group is non-negotiable for everyone, the second is required once you cross ~5,000 messages/day to any of the big consumer providers.

Every sender, any volume

1. Publish and pass SPF or DKIM (do both — it costs nothing extra and you'll need both for bulk anyway).
2. Set valid PTR / reverse DNS that resolves back to your sending IP.
3. Send over TLS.
4. Use an honest, resolvable From domain — never impersonate a provider's domain.
5. Format to RFC 5322 with a valid Message-ID.

Bulk senders (~5,000+/day to Gmail, Yahoo, or Outlook.com)

1. SPF + DKIM + DMARC, all three, with a published DMARC policy.
2. DMARC alignment — From domain aligns with the SPF or DKIM domain.
3. One-click unsubscribe (RFC 8058) in the List-Unsubscribe header, plus a visible body link, processed within two days.
4. Keep spam complaints under 0.3% (target under 0.1%) as reported by Google Postmaster Tools.
5. Support ARC if your mail is forwarded, so authentication survives the hop.
6. Monitor with Postmaster Tools (Gmail) and the equivalent provider dashboards; watch reputation and complaint trends continuously.

One operational note: meeting these on paper isn't the same as your email actually rendering and loading correctly in the inbox. Authentication gets you delivered; whether your remote content loads and your unsubscribe link works still depends on your HTML behaving across clients. Our guide on testing HTML emails before sending covers that side, and Postdrop.io lets you preview across Gmail, Outlook, Apple Mail, and the rest before you send.

What's Different About 2026

The single biggest mindset shift is that these are requirements, not optimizations. In 2020, a missing DMARC record was a deliverability risk you might get away with. In 2026, for a bulk sender, it's a reason your mail gets junked or rejected at the door. The providers have stopped grading on a curve.

The second shift is convergence. You no longer need a separate playbook per provider. Meet the consolidated checklist above and you are simultaneously compliant with Gmail, Yahoo, AOL, Outlook.com, and iCloud Mail. The fragmentation that defined deliverability for two decades has, on the requirements side at least, largely collapsed.

And the third — the one our other deliverability coverage keeps hammering — is that authentication and hygiene are the controllable core. With opens compromised by privacy proxies and inboxes increasingly mediated by AI, the things you fully control (your DNS records, your list quality, your complaint rate) are worth more than ever. This checklist is the controllable part. Get it right and you've built deliverability on the part of the system that won't shift under you.

Bottom Line

For the first time, "what do I need to do to get delivered?" has a single, mostly-consistent answer across the major mailbox providers. Authenticate with SPF, DKIM, and DMARC; align your From domain; offer one-click unsubscribe; keep complaints under 0.3%; sort out your reverse DNS and TLS; and monitor with Postmaster Tools. Do that and you clear the bar at Gmail, Yahoo, Microsoft, and Apple at once. The era of provider-by-provider folklore is over — the rules are written down now, and they're the same rules everywhere.

References: Google's Email sender guidelines, the Yahoo Sender Hub, Microsoft's high-volume sender requirements announcement, and M3AAWG's published best practices. Internal: our SPF, DKIM, and DMARC explainer, the DKIM2 authentication upgrade, the Apple MPP retrospective, and our guide to testing HTML emails before sending.

Nearly five years on, we have enough distance to ask the more useful question: what actually happened? Not the panic, not the predictions — the real, settled state of open rates, engagement signals, and sender behavior in 2026. This is that retrospective. If you run lifecycle, retention, or deliverability programs, this is the honest accounting of what MPP changed, which workarounds stuck, and what "a real open" even means now.

A Quick Refresher: What MPP Actually Does

Mail Privacy Protection is a setting in Apple Mail — on by default-prompt — that does two things when a message arrives for a user who has it enabled. First, it preloads remote content (including your tracking pixel) through Apple's proxy servers, regardless of whether the user ever opens the message. Second, it routes that fetch through a proxy that masks the user's IP address, so you can't derive their location or link the open to their other activity.

The consequence for senders is the one everyone fixated on in 2021: an "open" from an MPP-protected recipient tells you almost nothing. The pixel fired because Apple's infrastructure pre-fetched it, often within minutes of delivery, frequently in the middle of the night, whether or not the recipient ever looked at the message. The open event is real in the technical sense — a request hit your server — but it's decoupled from human behavior.

MPP was framed as one piece of a broader privacy push. The same iOS 15 announcement bundled it with App Tracking Transparency follow-ons, iCloud Private Relay, and Hide My Email — Apple's consistent positioning that tracking should be opt-in and identity should be the user's to share.

Change #1: Open Rates Are Permanently Inflated — and Everyone Knows It

The first and most durable change: aggregate open rates jumped, and they never came back down. Once Apple's proxy started pre-fetching pixels for a large share of recipients, those automatic fetches got counted as opens. Reported open rates across the industry rose by anywhere from a handful of points to more than double for Apple-heavy lists, depending on audience mix.

The number that matters here is how much of your list is on Apple Mail, because that's the slice of your "opens" that's now mostly machine-generated. And that slice is large. According to Litmus's ongoing email client market share tracking — calculated from over a billion opens a month — Apple Mail (across iPhone, iPad, and Mac) has been the dominant email environment for years, consistently sitting at or near the top of the rankings well ahead of Gmail.

The practical reality in 2026: aggregate open rate is a vanity number for most senders. It's not zero-value — a sudden drop in opens can still flag a deliverability problem, because if Apple's proxy stops fetching your pixels, something is routing you to spam or blocking your images. But the absolute level is meaningless for comparison across audiences, and open-rate "lift" from a subject-line test is now mostly noise unless you've carefully isolated non-Apple recipients.

Change #2: The Workarounds Sorted Themselves Out

In 2021–2022 every ESP and consultancy published an "MPP survival guide," and they all proposed roughly the same menu of workarounds. Five years later we can grade them. Here's what stuck and what didn't.

What stuck: clicks as the primary engagement signal

The single biggest behavioral change is that mature programs migrated their definition of "engaged" from opens to clicks (and downstream conversions). Clicks still require a genuine human action — Apple's proxy doesn't click your links — so they survived MPP intact. Re-engagement campaigns, sunset policies, and "active subscriber" segments were rebuilt around click and conversion recency rather than open recency. This is now table stakes; if your sunset flow still keys off "hasn't opened in 90 days," you're sunsetting a lot of engaged Apple users who simply never trip your pixel honestly.

What stuck: segmenting Apple MPP opens out of your metrics

The other durable workaround is detection. MPP opens have a recognizable fingerprint — they come from Apple's proxy IP ranges, fire suspiciously fast after send, and often arrive in tight clusters. Most serious ESPs now classify opens as "machine" vs. "likely human" and let you report on them separately. The good ones surface a clean human-open estimate. If your platform doesn't, you're flying with a contaminated number.

What faded: panic about "the death of the open"

The apocalyptic framing didn't survive contact with reality. Opens didn't die; they got noisier. Senders who had a balanced measurement strategy — clicks, conversions, revenue per recipient, list growth, complaint rate, inbox placement — barely flinched, because opens were never their only signal. The teams that struggled were the ones who had quietly let "open rate" become a proxy for the entire health of their program.

What faded: trying to "beat" the proxy

A few vendors floated clever tricks to distinguish real opens from proxy fetches via timing heuristics, unique-pixel-per-recipient gymnastics, or fingerprinting the fetch. These mostly haven't held up. Apple has continued to refine the proxy behavior, and chasing it is a losing arms race against a company that has no incentive to let you win. The mainstream consensus by 2026 is: don't fight the proxy, change what you measure.

Change #3: Deliverability Fundamentals Got More Important, Not Less

Here's an underappreciated second-order effect. When opens became unreliable as an engagement signal, mailbox providers' own internal signals — which we can't see — became relatively more important to deliverability. Gmail, Outlook, Yahoo, and Apple were never relying on your tracking pixel to decide inbox placement; they use their own engagement data (genuine opens, replies, "not spam" marks, deletes-without-reading, time-in-inbox). MPP didn't touch any of that.

So the providers' bar didn't move, but our ability to approximate their view using opens degraded. That made the unglamorous fundamentals — authentication, list hygiene, sending reputation — the load-bearing parts of a deliverability program. If you can't trust opens, you lean harder on the things you can control and verify.

That's also why the 2024 Gmail and Yahoo bulk-sender requirements, and the authentication tightening that followed, landed on an industry that was already primed to take authentication seriously. If you haven't revisited the basics recently, our explainer on SPF, DKIM, and DMARC is the place to start, and the forthcoming DKIM2 upgrade is worth understanding now rather than scrambling later. Authentication is the part of your reputation you fully control — in a post-MPP world, control is scarce and valuable.

Change #4: The Measurement Stack Matured

Vendors and in-house teams spent the last few years rebuilding measurement around signals that survive MPP. The State of Email research that deliverability and lifecycle teams lean on now treats "open rate" with explicit caveats rather than as a headline metric.

The concrete shape of a 2026 measurement stack for an Apple-heavy list looks like this:

• Clicks and click-to-conversion as the primary engagement KPI. Human-driven, MPP-immune, tied to revenue.
• Human-open estimate (proxy opens filtered out) used as a directional secondary signal and a deliverability smoke alarm, never as a primary success metric.
• Revenue per recipient / per email as the business-level scoreboard, which never cared about pixels in the first place.
• List health metrics — complaint rate, spam-trap hits, bounce rate, unsubscribe rate, inbox placement from seed testing — as the deliverability dashboard.
• Inbox placement and reputation monitoring from a dedicated tool, since you can no longer infer placement from a clean open-rate trend.

What "A Real Open vs. an MPP Open" Looks Like in 2026

Let's be concrete about the state of the art. For a typical consumer list today, a large share of recorded opens are machine-generated proxy fetches. The exact ratio depends entirely on your Apple Mail penetration — a B2C lifestyle brand with a young, iPhone-heavy audience might see the majority of opens come from MPP, while a B2B list dominated by Outlook-on-Windows recipients sees relatively few.

The honest 2026 framing is that you should stop thinking about it as "real opens vs. fake opens" and start thinking about it as two different measurements:

• Proxy opens tell you the message was delivered, accepted, and your remote content wasn't blocked. That's a deliverability signal, and a useful one — if proxy opens collapse, investigate placement immediately.
• Human opens (estimated) tell you something closer to attention, but with meaningful error bars. Use them for trend, not for precision, and never for the kind of single-digit A/B-test conclusions people used to draw from open rate.

Neither of these is "the open rate" of 2020. That metric is gone, and the sooner a program internalizes that, the healthier its decision-making.

Where This Connects to the Next Wave: AI in the Inbox

MPP was the first big shock to email measurement, but it won't be the last layer that sits between you and your subscriber. The same dynamic — an intermediary acting on the recipient's behalf, obscuring or transforming what the human actually sees and does — is now arriving via AI. Gmail's AI features and the broader move toward AI-summarized, AI-triaged inboxes mean even more of the gap between "delivered" and "perceived by a human" is mediated by software you don't control. We covered this shift in detail in our Google I/O 2026 AI Inbox writeup, and the strategic lesson is identical to the MPP lesson: when an intermediary changes what "engagement" means, you adapt your measurement rather than wishing the intermediary away.

If MPP taught the industry one transferable skill, it's resilience to exactly this kind of disruption. The programs that handled MPP gracefully — diversified signals, click-and-conversion-centric, authentication-solid — are the same ones best positioned for the AI-inbox era.

A Practical 2026 Checklist for Senders

If you want to pressure-test your own program against five years of MPP reality, run through this:

1. Audit every automation that triggers on opens. Re-engagement, sunset, lead scoring, "engaged segment" definitions. Anything keyed on opens is keyed on noise for your Apple recipients. Migrate to clicks, conversions, or a filtered human-open estimate.
2. Confirm your ESP separates machine opens from likely-human opens. If it doesn't, your reported open rate is contaminated and you should stop quoting it in QBRs.
3. Make clicks and conversions your primary engagement KPI. If your dashboards still lead with open rate, reorder them.
4. Treat a sudden open-rate drop as a deliverability alarm, not an engagement story. A collapse in proxy opens often means image blocking or a spam-folder placement issue.
5. Lock down authentication. SPF, DKIM, DMARC alignment, and a path toward DKIM2. This is the controllable part of reputation.
6. Add inbox placement monitoring via seed lists or a dedicated tool, since you can no longer read placement off a clean open trend.
7. Don't try to defeat the proxy. It's a losing arms race. Change what you measure instead.
8. Test what subscribers actually see. Whether your remote content even loads through Apple's proxy depends on your HTML rendering correctly. Our guide on testing HTML emails before sending still applies — and tools like Postdrop.io let you preview across Apple Mail and every other major client before you send.

Bottom Line

Five years in, the verdict on Apple Mail Privacy Protection is anticlimactic in the best way: the sky didn't fall, but the rules genuinely changed and they're not changing back. Open rates are permanently inflated and decoupled from human behavior. Apple Mail's dominance means this affects almost everyone. The workarounds that stuck were the boring, durable ones — measure clicks, filter machine opens, lean on authentication and list hygiene. The clever proxy-beating tricks faded, and the panic faded with them.

The senders who came through this best are the ones who treated MPP not as a metrics problem to patch but as a signal that single-metric thinking was always fragile. That's the real lesson, and it's the one to carry into the next disruption — because in a world of privacy proxies and AI inboxes, there will always be a next one.

References: Apple's Mail Privacy Protection user guide, Apple's June 2021 iOS 15 privacy announcement, Litmus email client market share, and the Litmus State of Email report. Internal: our guides on SPF, DKIM, and DMARC, the DKIM2 authentication upgrade, the Google I/O 2026 AI Inbox shift, and testing HTML emails before sending.

This post is the corrected version: the four dates that actually matter between now and 2029, what each one breaks, and how your cross-client testing matrix needs to evolve. If you build, test, or send HTML email — read this, then go fix whatever calendar reminder you set in April.

The Four Dates That Matter

Here's the corrected timeline, sourced directly from Microsoft's announcements (links and screenshots throughout). Tape this to your wall.

The single most common misread is conflating row 1 (EWS retirement, server-side) with row 3 (classic Outlook cutover, client-side). They're different events, different audiences, and different impact on your email-development work. Let's go through them in order.

October 1, 2026: EWS Goes Away

The actual October 2026 date is the retirement of Exchange Web Services in Exchange Online, announced by the Exchange team back in September 2023 and confirmed again in March 2025. From that day forward, EWS requests against Microsoft 365 mailboxes will be blocked at the service layer. EWS on on-premises Exchange Server is unaffected — this is purely a cloud thing.

For most front-end HTML email developers, EWS retirement is a non-event — your authoring stack doesn't talk to Exchange directly. But two downstream effects do touch email work:

• Legacy Outlook for Mac stops working against M365 mailboxes. The legacy Mac client uses EWS for sync. After October 1, 2026, users on legacy Outlook for Mac who still have M365 accounts will see their mailboxes fail to sync. Microsoft has been pushing the migration aggressively — over 95% of Mac M365 users have already moved to the new Outlook for Mac — but the long tail still exists, particularly in academic and enterprise IT environments.
• Any email-related tooling on EWS needs to move to Microsoft Graph. If your team built internal scripts that bulk-send test mails, archive sent campaigns, or pull engagement data via EWS, those break on October 1, 2026. The replacement is the Microsoft Graph REST API, which has had years of feature parity work and is the documented forward path.

The takeaway: this date matters, but as a backend/IT date, not a "we have to rewrite all our email templates" date. If your testing pipeline doesn't call EWS, you keep moving.

March 2027: Opt-Out (Quietly Delayed From April 2026)

This is the date that was the headline until very recently. Microsoft originally planned to enter the "opt-out" phase for enterprise tenants in April 2026 — meaning new Outlook would have flipped to the default, with classic still toggleable. In late February 2026, Microsoft updated the Microsoft 365 Admin Center notice (message ID MC949965) to push that to March 2027, giving organizations 12 months of additional lead time.

For email developers, this is the date when "new Outlook on Windows" stops being a niche concern and becomes the default behavior your enterprise recipients see. The toggle back to classic stays available — but a non-trivial percentage of recipients will end up on new Outlook simply by not changing the default.

No Earlier Than March 2028: The Real Classic-to-New Cutover

This is the date your testing matrix actually pivots on, and it's now nearly two years further out than the headlines suggested. Microsoft's current commitment: at least 12 months notice before "cutover", with cutover meaning the toggle disappears and classic Outlook is no longer launchable from a tenant.

Given the opt-out phase starts March 2027 and the 12-month minimum runway, the earliest plausible cutover is March 2028. In practice, given how often Microsoft has slipped these dates already, planning for "sometime in 2028, possibly into 2029" is the right posture.

Q2 2029: End of Life — Security Patches Stop

The final date: Microsoft's current commitment is to support classic Outlook with security and compatibility updates through at least 2029 for customers with Microsoft 365 subscriptions and Office LTSC perpetual licenses. After that, classic Outlook is unsupported software — no security patches, no compatibility fixes, no nothing.

For most senders, this is the date by which you can finally stop targeting classic Outlook in your QA matrix with confidence. Until then, the long tail (especially in regulated industries, government, and enterprise IT with extended-support contracts) will still be using it.

What This Means for Your Testing Matrix

The biggest mistake email teams are making right now is treating this as a binary: "we'll deal with new Outlook when classic dies." That's wrong on two counts.

First, the timeline above is staggered, not a single cliff. Every quarter between now and 2029, a larger fraction of your Outlook-on-Windows recipients is on new Outlook (WebView2/Chromium) and a smaller fraction is on classic (Word engine). Your QA matrix needs to handle both for the next ~3 years, with the weight shifting gradually toward new Outlook.

Second, the rendering differences between classic and new Outlook are dramatic. New Outlook is essentially Chromium — modern CSS, flexbox, grid, web fonts, border-radius, gradient backgrounds, all the things classic Outlook silently dropped for 19 years. An email that looked acceptable in classic might look wrong in new Outlook if you've been compensating for classic's quirks with hacks (e.g., spacer GIFs, table-only layouts) that render strangely when a real browser engine takes them at face value.

The bifurcated testing matrix

Concretely, for the next ~3 years your Outlook-on-Windows test row should split into two:

• Classic Outlook (Word engine) — still the default for many enterprises through at least March 2027, and present in the long tail through 2029. Continue testing for: collapsed multi-column layouts, missing border-radius, missing CSS background images, ignored web fonts, and the rest of the well-documented classic-Outlook fail modes. The classic-Outlook quirks guide remains relevant.
• New Outlook (WebView2 / Chromium) — small share today, materially larger by mid-2027, dominant by 2029. Tests here look more like "does this render correctly in Edge" — modern CSS works, but the email layer still imposes its own restrictions on top of Chromium (no JavaScript, restricted CSS in some contexts, the still-developing add-in story).

Tools like Postdrop.io, Litmus, and Email on Acid have been adding "new Outlook" as a separate preview target through 2025 and 2026 — make sure both are in your pre-send checklist, not just "Outlook."

What You Can — And Can't — Stop Doing

The temptation is to say "classic Outlook is dying, I can finally delete my VML background-image hacks." Don't. Not yet. Here's the honest read:

Code you can't delete yet

• VML for background images — Still required for classic Outlook. Will be required until at least 2027 for enterprise, longer for the long tail. Keep it.
• <!--[if mso]> conditional comments — Still parsed by classic Outlook. Useful for targeted overrides. Keep them.
• Table-based layouts — Even ignoring Outlook, Gmail's Android client still has historical issues with non-table layouts. Tables remain the safest structural primitive. Keep them.
• Inline CSS — Still required by Gmail regardless of Outlook. Not even in scope to delete. Keep it. (See our inlining guide.)

Code you can experiment with

• Progressive enhancement for modern Outlook — Where classic Outlook would have ignored or broken a feature, you can now add it for new Outlook recipients with the expectation it'll render correctly. border-radius, subtle CSS animations, web fonts (via the standard @import or <link> approach) — all worth A/B testing on Outlook traffic now that a growing slice of it can handle them.
• Reducing the number of <!--[if mso]> branches — As classic Outlook share drops, the maintenance cost of each conditional branch becomes harder to justify. Audit your templates for fixes that are only there for very old classic Outlook versions and consider whether the carve-out is still worth the bytes.

The Community Read

The Hacker News discussion on the new Outlook for Windows has been ongoing for years — and the threads consistently surface the same email-developer perspective: cautious optimism, paired with the lived experience that Microsoft has missed Outlook deadlines before.

The most-upvoted email-dev take from a recent thread, paraphrased: "I'll believe classic Outlook is gone when my enterprise QA matrix can drop it. Until then I'm shipping VML." That's the right operational posture.

A Six-Step Transition Test Plan

Concretely, here's how to evolve your QA workflow over the next 18 months:

1. Add new Outlook (Windows) as a separate preview target in your testing tool now, alongside classic Outlook. Treat them as independent rows in your QA matrix.
2. Run your top 10 most-sent templates through both renderers and document the diffs. You'll find some surprises — both improvements and new regressions in new Outlook.
3. Build a "modern Outlook" progressive enhancement layer for things like rounded corners, gradients, and tighter typography. Wrap them so classic Outlook degrades gracefully (e.g., a flat rectangle instead of a broken rounded one).
4. Audit your engagement data for any user-agent or rendering-engine signals that distinguish new vs. classic Outlook recipients. Some ESPs surface this in opens data; check yours.
5. If you maintain internal tooling on EWS, port it to Microsoft Graph this year. October 1, 2026 is real and final for the API; you don't want to discover this the morning of.
6. Re-test in Q3 2026 and Q1 2027 as the new-Outlook share grows. The renderer mix is changing under you whether you re-test or not; periodic re-baselining keeps you from drifting.

What This Means for Tooling Like Postdrop

The email-preview tools ecosystem is in the middle of the same transition. Postdrop.io, Litmus, and Email on Acid have all been expanding their Outlook coverage to render both classic and new as distinct targets through 2026. The practical reason: a single "Outlook" preview is no longer a meaningful answer to "how does this look in Outlook?" because the answer is now genuinely different depending on which Outlook your recipient is using.

This is also why a single screenshot of "Outlook desktop" is no longer enough for stakeholder sign-off. Get into the habit of sharing previews from both renderers when you ship a template review, the same way you'd share both Gmail web and Gmail mobile.

Bottom Line

The headlines compressed a complicated, staggered migration into a misleading single date. Here's the real version, one more time:

• October 1, 2026: EWS retires in Exchange Online. Backend tooling concern; legacy Outlook for Mac stops working against M365.
• March 2027: New Outlook becomes the default for enterprise tenants (toggle still available).
• No earlier than March 2028: Classic Outlook cutover. Toggle disappears.
• Q2 2029: End of security updates for classic Outlook.

For email developers, the operational answer is the same regardless of how the dates slip: test both renderers, today, in parallel. Don't delete your VML yet. Don't ignore new Outlook either. The bifurcation in your testing matrix is the cost of the next three years; the payoff is that by 2029 you'll be writing HTML email that targets a modern browser engine and a single recently-updated client, instead of fighting Word's idea of HTML.

References: Microsoft Exchange Team Blog on EWS retirement, Microsoft 365 Roadmap (Outlook), Microsoft Support on getting started with new Outlook, and caniemail.com Outlook coverage. Internal: our existing guides on cross-client rendering differences, why Outlook breaks your HTML email, and previewing React Email templates across clients remain the foundation this post builds on.

This isn't a "future of email" think piece. AI Overview conversation summaries started rolling out at I/O this week, free for everyone. If you sent a campaign yesterday, some non-trivial slice of your Gmail subscribers already saw your email mediated by a Gemini summary instead of opening the body. Below: what changed, why it matters for deliverability and engagement, and the specific changes worth making to your templates and program this quarter.

What Google Actually Shipped

AI Overviews for email — free, rolling out now

When a Gmail user opens a thread with multiple replies, Gemini now synthesizes the whole conversation into a concise summary at the top — the same pattern as AI Overviews in Google Search. Free for all users, no AI Pro/Ultra subscription required. The ability to ask freeform questions of the inbox ("when's my flight?") is gated to AI Pro and Ultra, but the summary itself is universal.

For senders, this is the big one. Long-form newsletters, multi-section transactional emails, and any campaign that buries the action below the fold now get a Gemini-written précis as their first impression. If the summary captures your value prop, great. If it picks up on a secondary CTA, an unsubscribe footer line, or boilerplate ("View this email in your browser"), worse.

AI Inbox — now in AI Pro and AI Plus

The AI Inbox view — a single-pane overview that surfaces "tasks and items needing attention" extracted from across the inbox — has expanded from AI Ultra-only to AI Pro and AI Plus subscribers. The user base on these tiers is materially larger than Ultra-only.

What this means in practice: messages your recipient previously opened in chronological order are now ranked and filtered by Gemini's importance heuristics. The Promotions tab was a coarse classifier. AI Inbox is a much finer one, and what it surfaces is partly a function of language patterns Gemini learns from each user's behavior — but also a function of how cleanly your email's intent comes through in the first 200 characters.

Gmail Live — voice-conversational inbox search

Gmail Live lets users ask the inbox questions out loud and follow up conversationally. "When is my flight?" → "What gate?" → "Is that the same one as last time?" — and Gemini stays oriented across the turns. AI Ultra subscribers get it first this summer, then AI Pro. This is more interesting as a directional signal than an immediate disruption: most senders won't see Gmail Live affecting their numbers in Q3, but the architecture it depends on — Gemini reasoning over your message contents — is the same architecture powering AI Overviews and AI Inbox today.

What Email Senders Should Actually Do

The temptation with announcements like this is to do nothing and wait. Don't. The summary layer is already live for every Gmail user — which means changes you make now compound into how your program performs for the rest of 2026.

1. Rewrite your first 200 characters as a TL;DR

AI Overviews lean heavily on the opening of the message body when generating summaries. If your first paragraph is "Hey {first_name}, we hope this email finds you well…" — that's literally the line Gemini will distill your campaign down to. Lead with the actual point. The Bonjoro/Loom/Notion patterns of "Here's what's new, in one sentence: …" are now better than ever.

2. Move boilerplate out of the body

"View this in your browser," "Add us to your contacts," accessibility statements, multi-line addresses — these belong in the footer, not above the fold. If they're in the body, they're candidates for Gemini's summary. Tighten the header zone to: identity, headline, action.

3. Cut redundant repetition

Many transactional templates repeat the same fact three times (subject line, hero headline, opening paragraph). For human readers that's reinforcement; for an AI summarizer it's noise that crowds out detail. Say it once, well, and use the space you save for specifics that distinguish this email from the last ten of the same type.

4. Make sure your HTML body actually contains the message

If your "email" is a single hero image with a CTA button and almost no real HTML text, the AI summary will be either generic or wrong — and the AI Inbox classification will be a coin flip. The same image-only templates that have always tanked accessibility scores will now also tank AI-mediated discovery. Real, semantic HTML body copy is now a triple win: accessibility, deliverability, AI-summary fidelity.

5. Test what Gemini actually does with your email

For now there's no public "show me Gemini's summary" API. The practical workaround is: send the email to a Gmail account on AI Pro, open the thread, look at the AI Overview. Do this before every major campaign. The summary is the new preheader — and it's auto-generated whether you participate or not.

6. Don't panic about Gmail Live yet

Voice search of the inbox is novel, but the volume that touches your campaign through Gmail Live in 2026 will be small. The optimization that matters is the visible AI Overview surface — Gmail Live is downstream of the same Gemini reasoning, so optimizing for one helps the other.

The Deliverability Angle

None of the I/O announcements changed sender-authentication requirements. SPF, DKIM, DMARC, ARC, and the DKIM2 transition are unchanged. But two things are worth flagging:

• Engagement signals matter more, not less. AI Inbox uses Gmail's existing per-user engagement signals as input. If your subscribers ignore, archive, or report your messages, you're more likely to land in the buried portion of the AI Inbox view (or be filtered out of it entirely). The fix is the same as it always was — segment, prune disengaged users, and earn opens by being relevant — but the consequences are now amplified.
• List hygiene matters more, not less. The same per-user behavior signals feed into how aggressively Gemini summarizes vs. surfaces your full body. Lists with strong open and reply rates get better treatment.

What the Community Is Saying

The Hacker News thread on the Gmail announcements hit the front page within hours of the I/O keynote. The split was roughly: enthusiasm for AI Overviews from heavy inbox users ("I get 200 emails a day, give me the summary"), wariness from privacy-minded folks (Gemini is now reading every message Google holds for you), and frustration from email developers who pointed out that the entire optimization surface they've spent years tuning — subject lines, preheaders, hero images — is now mediated by an AI layer that can rewrite it on the way to the reader.

The r/emaildevelopers thread split similarly. The most upvoted advice from a deliverability lead at a large ESP: "Treat the AI Overview as the new subject line. The line of text you used to obsess over is no longer the line of text that decides whether your email gets engaged with."

One More Thing: The Security Story

Buried in the same week's news: Microsoft disclosed CVE-2026-42897, an Exchange Server vulnerability where a crafted email can execute arbitrary JavaScript in Outlook Web Access — added to the CISA Known Exploited Vulnerabilities catalog on May 15 with a federal patching deadline of May 29. And Microsoft's threat intel team detailed a 35,000-user phishing campaign that ran April 14–16, using "polished, enterprise-style HTML templates" mimicking HR communications.

The connecting thread: sophisticated, well-formatted HTML is now table stakes for both legitimate senders and attackers. The AI inbox layer Google just shipped is, among other things, a defensive measure — Gemini summarizing a phishing email side-by-side with a legitimate one makes the surface differences more visible. As a legitimate sender, the more your templates look like the carefully-built, on-brand, semantically-clean HTML you'd expect from a real company, the better you fare in this environment.

Bottom Line

The shape of inbox attention has shifted. Subject line and preheader still matter, but they're no longer the only thing the recipient sees before deciding to open. The first 200 characters of your body copy now matter as much as the subject line ever did, because that's what Gemini reads to write the summary your subscriber sees first.

The work is unglamorous and worth doing: tighten openings, move boilerplate to footers, make sure your HTML actually contains the message instead of just hosting a hero image. Test campaigns in a Gmail account that has AI Overviews on, and look at what Gemini writes about your email before you ship it. The senders who do this work in May will compound through Q3 and Q4. The senders who wait will keep tuning a surface their subscribers no longer see first.

References: Google's Gmail product blog, TechCrunch's I/O 2026 coverage, HN discussions of the Google announcements, and the CISA KEV catalog for the parallel Exchange CVE. Internal: our take on the underlying SPF/DKIM/DMARC stack and the DKIM2 transition still applies — none of the I/O changes touched authentication.

I spent the last week migrating a small React Email project from 5.x to 6.0 and integrating the new editor into an internal admin panel. Here's what's actually different, what to watch for in the upgrade, and the parts of the workflow where you still need a cross-client testing tool.

What's Actually New in 6.0

An open-source visual editor you can embed

The standout feature is @react-email/editor — an open-source WYSIWYG editor you install separately and drop into your own app with a few lines of code:

import { EmailEditor } from "@react-email/editor";

export default function MyEditor() {
  return <EmailEditor />;
}

The editor outputs the same semantically correct, table-based HTML that the React components produce. The point is not to replace the developer authoring loop — it's to let your marketing team tweak copy, swap images, and adjust layouts on templates a developer originally built in code, without round-tripping through engineering for every microcopy change.

This is a meaningful gap closer. Most engineering-led teams using React Email today either lock marketers out of the templates entirely or maintain a parallel set of templates in their ESP for the marketing side to edit. Neither is great. An embedded editor that produces the same HTML the code produces is the bridge.

One package to import from

The component library is now unified into a single react-email package. The pre-6.0 setup with @react-email/components, @react-email/render, and a separate preview-server is collapsed:

// Before (v5)
import { Button, Container, Html } from "@react-email/components";

// After (v6)
import { Button, Container, Html, Heading, Tailwind } from "react-email";

What was @react-email/preview-server is now @react-email/ui. The render function still lives at @react-email/render for now and is unchanged — your existing render scripts (like the one in last week's cross-client testing guide) keep working with no edits.

A new template collection

React Email 6 ships with a new set of starter templates designed by Character Studio, covering authentication flows, e-commerce sequences, and onboarding. They're available both as React Email components and as Figma source files — useful if your designer wants to iterate in Figma and hand off to engineering with a clean baseline.

Growth signal: 2M weekly downloads

The framework now does ~2M weekly npm downloads and counts 196 open-source contributors. For context, that's roughly a doubling since the previous major release in late 2025. Whatever you think about React Email as a tool, it's now the dominant authoring framework for transactional email at React-shop SaaS companies, and that gravity will only grow.

The Upgrade Path from 5.x

The good news: the v5 → v6 path is mechanical for most projects. Here's the playbook.

1. Swap the imports

Run a project-wide find-and-replace from @react-email/components to react-email. The component APIs themselves are unchanged, so a clean string swap usually does it.

npm uninstall @react-email/components @react-email/preview-server
npm install react-email@latest @react-email/ui@latest

2. Update the preview-server scripts

If you had email dev wired up via the old preview-server package, the binary now comes from @react-email/ui. Most package.json scripts will need a one-line update — check the docs for the exact command for your setup.

3. Don't install the editor yet if you don't need it

The editor is a separate install (@react-email/editor). It pulls in additional dependencies and is only worth adding if you actually plan to expose template editing to non-developers. For pure code-authoring teams, skip it and your bundle stays the same size as v5.

4. Test the rendered HTML, not just the dev preview

This is the bit that bites people on every React Email upgrade. The component implementations get small tweaks between major versions — usually for the better — but those tweaks change the output HTML in ways that can render differently in Outlook, Gmail dark mode, or older Apple Mail. The dev server's Chromium preview won't show you any of those changes. Run your render() script and diff the output HTML between v5 and v6 before deploying. Then preview the v6 output in actual client renderers.

What 6.0 Doesn't Solve

The new editor is a real step forward, but it doesn't change the fundamental rendering reality of email: every client interprets your HTML differently, and a tool that compiles to HTML — no matter how good — can't see the inside of the client's renderer. A few specific things React Email 6.0 still won't do for you:

It still can't show you Outlook desktop

The editor and the preview server both render in Chromium. Classic Outlook on Windows uses the Word rendering engine, which strips most modern CSS. If your template uses border-radius, gradient backgrounds, web fonts, or any of the dozen properties Outlook silently drops, the editor will show you the polished Chromium rendering and Outlook will show your subscribers something completely different. The caniemail.com scoreboard is a useful reality check on which clients support which features:

It still can't catch dark-mode inversions

Apple Mail and Outlook both auto-invert email colors in dark mode using heuristics that vary by client and OS version. A grey background you chose for hierarchy can flip to dark grey while the dark text on top stays dark — leaving an unreadable block your editor preview never showed. You need to test in actual dark mode in actual clients to catch this.

It still can't simulate image-blocking

Many corporate Outlook installs and the Gmail web preview block images by default. The editor shows you the fully-loaded version. Your alt text, fallback text colors on image backgrounds, and the readability of the email-without-images need to be tested separately.

It still can't show real client market share

Editor previews are Chromium. They don't tell you that Apple Mail handles ~55% of opens globally, that Gmail is ~30%, and that Outlook desktop is a much smaller (but stickier) ~5–8%. Knowing which renderers matter most for your specific audience is what lets you triage rendering bugs sensibly.

How This Fits With Your Existing Workflow

For most teams using React Email today, the upgrade-and-deploy story should look like this:

1. Upgrade the package on a feature branch. Mechanical import rewrites + dependency swap.
2. Re-render every template with your existing render script. Diff the output HTML against your v5 baseline.
3. Visually QA the v6-rendered HTML in Postdrop or your tool of choice across Gmail, Outlook (classic and new), Apple Mail, and any clients with material share for your audience. The output is going to be slightly different — make sure "different" is also "still correct."
4. Decide on the editor separately. If you have a marketing or lifecycle team that owns template copy, set up a small admin route with @react-email/editor and let them iterate without engineering as a bottleneck. If you don't, skip it.
5. Re-snapshot in CI. If you're running snapshot tests against your rendered HTML (and you should be), accept the new baseline once you've manually verified the v6 output. From there, future regressions surface in code review.

Bottom Line

React Email 6.0 is an unambiguously good release: a thoughtful editor, a cleaner package surface, and useful new templates. For React-stack teams, it lowers the barrier to letting non-developers safely touch email templates — which has been one of the longest-standing pain points in the workflow.

What it doesn't do, and what no authoring framework can do, is render your HTML in the actual clients your subscribers use. The editor's Chromium preview is the same Chromium preview the dev server has always shown — and it's still not Outlook. Pair the upgrade with a real cross-client testing step and you'll catch the regressions before your customers do. Skip the testing step and 6.0 just gives you faster, prettier ways to ship the same Outlook bugs.

References: React Email 6.0 announcement, React Email docs, caniemail.com for per-feature client support, Litmus' email client market share, and React Email on GitHub.

It's a genuinely better authoring experience than MJML, Maizzle, or hand-rolled tables. But there's one thing the React Email dev server doesn't do: tell you whether the HTML it produces will actually render correctly in the inboxes your users are reading.

This guide walks through why that gap exists, what specifically breaks, and the testing workflow we recommend before shipping any React Email template to production.

Why the React Email Preview Isn't Enough

When you run npm run dev in a React Email project, you get a local preview at localhost:3000 that renders each .tsx template as it would appear in a Chromium browser. That's useful for iterating on layout and copy — but Chromium is not where your emails will be opened.

The actual rendering engines your users see include:

• Apple Mail (macOS, iOS, iPadOS) — uses WebKit. About 55% of opens globally, per Litmus' email client market share data.
• Gmail web — uses Blink, but strips a long list of CSS properties and rewrites your HTML structure on receipt.
• Gmail iOS / Android apps — different rendering quirks from Gmail web, especially around dark mode color inversion.
• Outlook on Windows (2016, 2019, 365) — still uses the Microsoft Word HTML rendering engine, which doesn't support flexbox, grid, or most modern CSS.
• New Outlook (Windows + Mac) — based on the web version, much better support but with its own quirks.
• Outlook.com — yet another renderer with its own CSS support matrix.
• Yahoo Mail, ProtonMail, Thunderbird, Samsung Email — long tail with surprising bugs.

The React Email components are well-engineered to produce table-based HTML that tries to be compatible across these clients. But "tries" is not "verified." We've seen production templates that look perfect in the React Email preview and break in three of the eight clients above.

The Real Failure Modes

Here are the actual bugs we see most often when teams ship React Email templates without cross-client testing:

1. Tailwind classes that don't survive Outlook

React Email's Tailwind integration inlines your utility classes into style attributes at build time. That works for most properties — but Outlook on Windows ignores border-radius, box-shadow, linear-gradient backgrounds, and any rgba() color with transparency. Your beautifully rounded button becomes a sharp rectangle. Your subtle gradient header becomes a flat solid color (or worse, transparent).

2. Custom fonts that fall back unevenly

If you import a Google Font in your React Email <Head> with <Font>, Apple Mail and the iOS Gmail app will use it. Outlook will not, and Gmail web only honors web fonts when the user is signed in to a Google Workspace account. Your fallback font stack matters more than the primary font — and the React Email preview won't show you what each client actually picks.

3. Dark mode inversions you didn't ask for

Apple Mail and Outlook automatically invert colors in dark mode based on heuristics that vary by client. A light-grey background you chose for visual hierarchy can flip to dark grey while the text on top stays dark — leaving an unreadable pane your preview never showed you.

4. img elements without explicit width/height

React Email's <Img> component requires you to pass dimensions, but it's easy to forget on logos or icons. Without explicit attributes, Outlook ignores the natural image size and renders at the source dimensions — meaning a 1024×1024 logo blows out your layout the moment Outlook receives it.

5. Conditional content for retina/high-DPI

If you're using 2x images for retina displays, you need to know which clients honor srcset (almost none) versus which respect explicit width/height on a high-resolution source (most). Getting this wrong means blurry logos in Gmail and oversized hero images in Outlook.

The Workflow We Recommend

Here's a four-step loop that catches the issues above before they ship to users.

Step 1: Author and iterate in React Email's dev server

Use the React Email preview for fast layout iteration, copy changes, and prop-driven variants. This is what the local dev server is good at — instant feedback on the React side.

Step 2: Render the production HTML

React Email exposes a render() function that returns the final HTML string for a given component. Add a small script to your project that renders each template and writes the output to disk:

// scripts/render-emails.ts
import { render } from "@react-email/render";
import fs from "node:fs/promises";
import WelcomeEmail from "../emails/welcome";
import OrderConfirmation from "../emails/order-confirmation";
import PasswordReset from "../emails/password-reset";

const templates = [
  ["welcome", <WelcomeEmail name="Test User" />],
  ["order-confirmation", <OrderConfirmation orderId="1234" />],
  ["password-reset", <PasswordReset resetUrl="https://example.com/r/abc" />],
] as const;

await fs.mkdir("./out", { recursive: true });
for (const [name, element] of templates) {
  const html = await render(element, { pretty: true });
  await fs.writeFile(`./out/${name}.html`, html);
  console.log(`✓ ${name}`);
}

This is the HTML that will actually go on the wire when Resend or your ESP sends the message — including all of React Email's table compilation and CSS inlining. It's what you need to test, not the React preview.

Step 3: Visually QA the rendered HTML across real clients

Paste each rendered HTML file into Postdrop to see how it actually renders in Gmail, Outlook, Apple Mail, Yahoo, and the other clients that matter for your audience. This is the step most teams skip — and it's where the bugs above get caught.

For a more in-depth breakdown of how the major clients differ, our guide to email rendering differences walks through the specific quirks per client. The Outlook-specific ones are covered in why Outlook breaks your HTML email.

Step 4: Wire it into CI

Once your React Email templates are stable, you can prevent regressions by:

• Running the render script as part of your build (catches templates that fail to render at all).
• Snapshot-testing the output HTML so any unintended change to the rendered markup shows up in a code review.
• Running tools like html-validate against the rendered output to catch invalid markup that some clients will choke on.

The full visual cross-client check still requires human eyes (or Postdrop's preview) — but the structural checks can be fully automated.

What About Sending Test Emails to Yourself?

The traditional approach — sending a real email to your own Gmail and Outlook accounts — works, but it's slow and incomplete. You can't easily test in clients you don't have accounts on (most teams don't have a Yahoo Mail or ProtonMail account sitting around). You're at the mercy of your sending reputation and provider quirks. And iteration is brutal: change a class, send a new email, wait for it to land, refresh, repeat.

It's worth doing once before launch as a final sanity check, but it shouldn't be your primary feedback loop.

Bottom Line

React Email is the best authoring experience email development has ever had. But it's a build tool, not a QA tool — and the preview server is showing you Chromium, not your users' actual inboxes.

The fix is a tight render-to-static-HTML script, a visual QA step against real client renderers, and basic structural validation in CI. Build that workflow once and every future template benefits from it. Skip it, and you'll keep finding out about Outlook bugs from your customers instead of from your own dev environment.

References: React Email docs, caniemail.com for the per-feature client support matrix, and Litmus' email client market share tracker for prioritizing which clients matter most for your audience.

That's about to change. On March 18, 2026, the IETF DKIM Working Group formally adopted a successor specification: DKIM2. The first official working-group draft, draft-ietf-dkim-dkim2-spec-01, was published on April 20. And according to deliverability researchers tracking the proposal, the first mailbox providers will start signing with DKIM2 within months — with major providers expected to follow before the end of 2026.

Here's what's actually different, and what you need to know before it lands.

The Problem DKIM2 Is Solving

DKIM works by signing a hash of the message body and selected headers with a private key. The receiver fetches the public key from DNS, recomputes the hashes, and verifies. If the message hasn't changed in transit, the signature passes. If a single byte of the body has changed — even a trailing newline — it fails.

That's a problem because the modern mail system constantly changes messages in transit:

• Mailing lists prepend [list-name] to the subject and append unsubscribe footers.
• Security appliances rewrite URLs through their own click-tracking domains.
• Forwarding rules strip or rewrite headers.
• Antivirus gateways mutate MIME structure to neutralize attachments.

Every one of these breaks DKIM. And when a sender publishes p=reject in their DMARC policy — as Yahoo and Google now effectively require for bulk senders — broken DKIM means the message is rejected outright, not just sent to spam.

Why ARC Didn't Fix It

ARC (Authenticated Received Chain) was the previous attempt to solve this. The idea: each forwarder adds an ARC seal stating "when I received this, the authentication was valid." Receivers could then trust the chain of seals back to the original sender.

It didn't work in practice. As Laura Atkins of Word to the Wise recently summarized, "most receivers tell us they can't use or trust ARC signatures." The problem is that ARC asks you to trust the intermediary's claim about what happened, without giving you any way to verify it. Worse, an ARC seal doesn't tell you what the intermediary changed — only that they vouched for it. The IETF DMARC working group is now actively working on a draft to deprecate ARC.

How DKIM2 Actually Works

DKIM2 takes a fundamentally different approach: document the modifications, don't just trust the modifier.

The originator signs the message with a DKIM2-Signature header that includes i=1. When a forwarder modifies the message, instead of just resealing the new version, it records exactly what changed (the added footer, the rewritten URL, the new subject prefix) and adds a new signature with i=2. The next forwarder adds i=3, and so on.

The result is a fully linked chain of custody from sender to recipient. The receiving server checks the highest-numbered signature first, then walks the chain backwards. Because each modification is documented, the receiver can undo the changes step by step and verify the original signature on the unchanged message — exactly as the sender wrote it.

Three things follow from this design that ARC couldn't deliver:

• Forwarding stops breaking authentication. Mailing lists, forwarding rules, and security gateways can modify messages freely as long as they document what they did. The original signature still validates.
• Replay attacks get harder. Each signature is bound to the recipient address of the previous hop. A signature stolen from one delivery can't be replayed to a different address — the chain won't link.
• Backscatter goes away. Bounces and delivery status notifications must travel back along the same signed chain. A bounce can only go to a domain that actually sent the message, and can only come from a domain that received it. Forged bounces — the bane of every postmaster — stop working.

What You Need to Do (Spoiler: Almost Nothing, Yet)

DKIM2 is still a draft. The current revision, -01, expires October 22, 2026, and full RFC publication is years away. There are no DKIM2 toggles in Gmail, Outlook, or any major ESP yet. Don't change anything in production today.

What you should do this quarter:

1. Get DKIM1 right. If you're still relying on shared signing domains from your ESP, move to a custom signing domain that aligns with your From address. Senders who haven't sorted DKIM1 alignment by the time DKIM2 ships will be in worse shape, not better.
2. Tighten your DMARC policy. If you're still on p=none or p=quarantine, plan a path to p=reject. DKIM2 makes p=reject safer to maintain because forwarding stops breaking your messages.
3. Plan to publish DKIM2 keys alongside DKIM1. The two protocols are designed to coexist. Early adopters will sign with both. Make sure your DNS provider supports the additional TXT records you'll need.
4. Watch your ESP. If you send through a major provider, ask them when they plan to support DKIM2 signing. The big players are tracking the spec — Yahoo, Google, and Fastmail all have engineers on the author list (Richard Clayton, Wei Chuang, and Bron Gondwana respectively).

The Bigger Picture

DKIM2 is the first significant change to email authentication infrastructure since DMARC was published in 2015. The fact that engineers from Yahoo, Google, and Fastmail co-authored it together — and that the working group reached consensus on adoption within seven months of the first draft — signals that the major mailbox providers see this as overdue. ARC's failure to deliver on the forwarding promise has been a quiet pain point for everyone running modern mail infrastructure.

If the timeline holds and major providers ship DKIM2 support before the end of 2026, the practical effect for HTML email developers will be subtle but real: the long tail of "weird deliverability bugs" caused by intermediate forwarders will start to shrink. Mailing lists will work again. Auto-forwarders will stop trashing your password resets. The cases where you ship a perfectly authenticated message and it still ends up in spam because someone in the delivery path touched a header — those will start going away.

Bottom Line

DKIM2 isn't shipping in your account dashboard tomorrow. But the foundation just got laid this month, and it's the most consequential authentication change in a decade. If you've been ignoring the slow build-up around DKIM2, this is the moment to start paying attention.

For developers actively shipping HTML email, the immediate priority is the same as it's always been: get the basics right. Use a custom signing domain. Align From, SPF, and DKIM. Move toward p=reject. Test your templates rigorously across clients (we built Postdrop for exactly that). And if you want a refresher on how authentication works today before DKIM2 lands, our SPF, DKIM, and DMARC explainer covers the current model end-to-end.

Further reading: the official IETF draft, Laura Atkins' DKIM2 explainer at Word to the Wise, and the All About Email newsletter's DKIM2 update with a useful timeline of provider rollout expectations.

On April 16, 2026, partway through Cloudflare's Agents Week, the company quietly graduated its Email Sending product from private to public beta. The announcement was framed as a feature for AI agents, but the implications go much further than that. For the first time, Cloudflare offers a full bidirectional email platform — receive in a Worker, process it however you want, then send a reply — without leaving the Cloudflare network and without integrating a separate ESP.

For HTML email developers, this is the most significant infrastructure shift since Resend launched in 2023. It changes the math on what's worth building yourself, where transactional sends should originate, and how authentication is configured. This post walks through what's new, what it means for the existing email stack, and what to watch out for.

What Cloudflare Email Service Actually Is

Cloudflare Email Service is now an umbrella for two products that used to live separately:

• Email Routing — the inbound product that's been generally available since 2022. You point your MX records at Cloudflare and incoming mail is forwarded, dropped, or piped into a Worker via the email handler.
• Email Sending — the new outbound product, now in public beta. Send transactional email from a Worker through a native binding (no API key in code) or from any other platform via a REST API with TypeScript, Python, and Go SDKs.

Combined, they form a complete send-and-receive loop. You can build a workflow where a customer emails support@yourcompany.com, a Worker classifies the message with Workers AI, queries your database, and sends back a personalized reply — all in a single Cloudflare account, with one billing relationship and one set of authentication records.

The Big Shift: From Receive-Only to Full Bidirectional

Until this week, building a real email-driven application on Cloudflare meant receiving in a Worker and then handing off to SendGrid, Postmark, Resend, or Mailgun for the reply. That worked, but it meant juggling two providers, two billing accounts, two sets of DNS records, and two debugging surfaces when something went wrong.

The native send binding eliminates that handoff. Here's what a minimal echo Worker looks like with the new API:

export default {
  async email(message, env) {
    const reply = new EmailMessage({
      from: "agent@yourdomain.com",
      to: message.from,
      subject: `Re: ${message.headers.get("subject")}`,
      contentType: "text/html",
      body: `<p>Thanks for your message. Here's our response.</p>`,
    });

    await env.SEND_EMAIL.send(reply);
  },
};

No API keys. No secrets in environment variables. The SEND_EMAIL binding is configured in wrangler.toml and authenticated using Cloudflare's internal trust between Workers and the Email Service. For developers who've accidentally committed an ESP API key to GitHub at least once in their career (so, all of us), this is a meaningful security improvement.

The REST API for Everything Else

If your application doesn't run on Workers — say it's a Python service in another cloud, a desktop coding agent, or a Rails app on Heroku — you can use the REST API instead. The shape is conventional and looks similar to other transactional email APIs:

curl -X POST https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/email/send \
  -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "noreply@yourdomain.com",
    "to": ["user@example.com"],
    "subject": "Welcome to Acme",
    "html": "<h1>Welcome</h1><p>Glad you joined.</p>",
    "text": "Welcome. Glad you joined."
  }'

The TypeScript, Python, and Go SDKs wrap this and add helpers for things like attachment handling and reply-routing tokens. There's nothing radically new in the API surface — what's new is the integrated authentication layer underneath, plus the absence of a per-message overhead premium for sending from a different region than your application.

SPF, DKIM, and DMARC — Auto-Configured

This is the feature that will quietly save the most engineering hours over the long run. Email authentication is one of those topics where the spec is straightforward but the implementation is fragile. A misconfigured SPF record bounces your transactional emails. A missing DKIM key sends your password resets to spam. A DMARC policy of p=reject with the wrong alignment kills deliverability overnight.

When you add a domain to Cloudflare Email Service, all three records are configured automatically. SPF is generated to include Cloudflare's sending infrastructure. A DKIM keypair is created and the public key is published as a TXT record. DMARC is set up with sane defaults that you can tighten over time. If you've already covered authentication in our SPF, DKIM, and DMARC explainer, you'll appreciate just how much manual DNS work this collapses.

The catch: this only works automatically if your domain's DNS is on Cloudflare. If your DNS lives at Route 53 or Namecheap, you'll need to copy the records over manually — but Cloudflare provides the exact values to paste in.

Why "Built for Agents" Is More Than Marketing

The Agents Week framing isn't a stretch. There are two genuinely agent-specific features in the new release that don't have direct equivalents at traditional ESPs.

HMAC-signed reply routing. When an agent sends an email and expects a reply, you can sign the routing headers with HMAC-SHA256. The reply, when it comes back, is cryptographically guaranteed to land at the same agent instance that sent the original message. This prevents a class of attacks where someone forges email headers to route a reply to an arbitrary agent — a real concern when your agent has access to internal systems.

The onEmail hook in the Agents SDK. If you're building on Cloudflare's Agents SDK, your agent class can declare an onEmail method that fires whenever a message arrives. The agent can take its time — process for an hour, query other systems, wait for human approval — and then send a reply through the same SDK. Previously, the agent could receive but could only reply synchronously or to other Cloudflare account members. With Email Sending, that constraint is gone.

Open-Source Reference: Agentic Inbox

Cloudflare also open-sourced a reference application called Agentic Inbox. It's a complete email triage app built on the new platform: Email Routing for inbound, Email Sending for outbound, Workers AI for message classification, R2 for attachment storage, and the Agents SDK for stateful conversation logic. There's even a built-in MCP server so external agents (Claude Code, Cursor, Copilot) can draft outgoing messages for human review before sending.

Even if you're not building an agent, Agentic Inbox is worth reading as a working example of how the pieces fit together. Most ESP documentation gives you isolated snippets — Agentic Inbox gives you a full app where you can trace a real message from inbound classification to outbound reply.

What This Means for the Existing Email Stack

The honest comparison: Cloudflare Email Service isn't going to displace SendGrid for marketing email or Postmark for high-volume transactional in the near term. Those products have a decade of deliverability tuning, IP warmup automation, suppression lists, bounce handling, and analytics dashboards that the Cloudflare offering doesn't yet match.

What it does displace, immediately, are the small-to-medium use cases where you were using a generic ESP because you needed something for outbound mail:

• App password resets and account verification emails — high-trust, low-volume, deliverability-sensitive but not deliverability-extreme. The auto-configured authentication is a meaningful win here.
• Webhook-style notifications — order confirmations, billing receipts, deployment alerts. If your app already runs on Workers, the latency advantage is real.
• Internal tools — anything that emails your own team. Signing up for SendGrid to send "deploy finished" notifications was always overkill.
• AI agents and chatbots that need an email channel — exactly the use case the launch was designed for.

For high-volume marketing campaigns, dedicated IPs, sophisticated suppression management, or compliance-heavy industries with audit requirements, the established ESPs still win on feature depth. But the bar for "what justifies a third-party ESP" just got higher.

Pricing and What's Still Unknown

Cloudflare hasn't published final pricing. The blog post confirms that Email Sending will require a paid Workers subscription and that pricing will be per-message, but the specific dollar amounts are still being finalized. Cloudflare has committed to notifying users before charges begin. Email Routing remains free for inbound.

A few things to watch over the next few weeks:

• Bounce and complaint handling — the public docs are thin on what happens when a recipient bounces or marks your message as spam. Established ESPs have rich APIs here; we'll see what Cloudflare ships.
• Suppression list management — there's no mention yet of a centralized suppression list that prevents repeated sends to a hard-bounced address.
• Reputation isolation — when you send from shared IPs, your deliverability is partially a function of every other sender on those IPs. Cloudflare hasn't said much about how they're segmenting tenants.
• Region pricing — Cloudflare emphasizes low latency anywhere in the world, but it's unclear whether sends from different regions cost the same.

How to Test Emails Sent From Cloudflare Workers

The biggest practical question for HTML email developers: how do you actually preview what a Worker is going to send before you ship it?

The straightforward approach is to render your HTML email template once locally — either in a Node script or in a Storybook story — and paste the output into Postdrop.io to see how it renders across Gmail, Outlook, Apple Mail, and the rest of the major clients. This is the same workflow you'd use for any HTML email, but it's especially important for Worker-sent messages because:

1. Workers run in a stripped-down V8 isolate — there's no jsdom or Puppeteer available to render and screenshot your output before sending. You have to test the HTML separately.
2. Cloudflare's auto-configured DKIM means messages will be authenticated correctly out of the gate — but DKIM tells you nothing about whether your dark-mode CSS works in Outlook 2019. That's still on you.
3. The Email Service doesn't currently include a built-in preview tool — Cloudflare ships the infrastructure for sending, not the visual QA layer.

A reasonable pre-send test loop looks like:

// 1. Render your template
const html = renderEmail({ name: "Test User", orderId: "1234" });

// 2. Send to Postdrop for visual QA (paste HTML in dashboard)
//    Verify rendering across Gmail, Outlook, Apple Mail, etc.

// 3. Once visual QA passes, deploy the Worker
//    The Worker's send() call uses the same exact HTML

await env.SEND_EMAIL.send(new EmailMessage({
  from: "noreply@yourdomain.com",
  to: recipient,
  subject: "Your order #1234",
  contentType: "text/html",
  body: html,
}));

If your email template lives in a shared file that both your test harness and the Worker import, you get a single source of truth. The HTML you previewed in Postdrop is exactly what gets sent — no drift between staging and production.

Bottom Line

Cloudflare Email Service moving to public beta isn't just a new ESP option. It's a sign that email infrastructure is consolidating into the same platforms that already host your application code, your edge logic, and your AI agents. The friction of "send an email" is dropping toward zero for anyone already on Cloudflare.

For HTML email developers, the practical takeaways are:

• If you're already on Workers, try Email Sending for your next transactional use case. The DX is genuinely better than wiring up a third-party ESP.
• Don't migrate marketing campaigns yet. Wait for the deliverability story and suppression management to mature.
• Authentication is now a solved problem at the platform layer — but rendering, accessibility, and cross-client compatibility are still your job.
• Keep your visual testing workflow tight. Worker-sent email goes out fast, and a broken template reaches all your users in seconds.

The launch post is at blog.cloudflare.com/email-for-agents and the docs are at developers.cloudflare.com/email-service. If you ship anything interesting on the new platform, we'd love to hear about it.

If you work in email design or development — whether at an agency, in-house, or as a freelancer — you've probably experienced the approval workflow that goes like this: you finish an email template, send a test to the client, the client opens it on their phone in Gmail, sees something that doesn't quite look right due to a font fallback, and replies that "the font looks different from the mockup." Then begins a back-and-forth where you're trying to understand what they're seeing, they're struggling to describe it, and you're not sure if it's a real bug or a client-side rendering difference that doesn't affect real subscribers.

This workflow has several fundamental problems:

• Context collapse: The client sees the email in one specific client (whatever they use), not the full cross-client picture. A broken render in Outlook goes undetected because the client doesn't use Outlook.
• Slow iteration: Every change requires a new test send. Even small copy edits mean another email in their inbox.
• Inbox pollution: Multiple test emails clutter the client's inbox and make it hard to know which version is current.
• Unrepresentative feedback: Clients give feedback based on their personal device and email setup, not on how real subscribers will see it.
• Professionalism signals: Receiving a barrage of half-finished test emails makes your work process feel disorganized, even if the final result is excellent.

The solution is shareable preview links — a direct URL that shows cross-client renders of your email to anyone with the link, no account required.

What Makes a Good Email Preview Link

Not all preview links are equal. A useful client-facing preview link should:

• Show multiple email clients simultaneously — not just one. The client can see how it looks in Gmail, Outlook, Apple Mail, and mobile clients all at once, giving them a realistic picture of what their subscribers will experience.
• Include both desktop and mobile renders — most email opens happen on mobile. A preview that only shows desktop is missing half the story.
• Require no account or login to view — friction for the client means delayed feedback. They should be able to click the link and immediately see the renders without creating an account.
• Show the current version — if you update the email, the preview link should either update or clearly show the version date so everyone knows they're looking at the right thing.
• Load quickly — clients have short patience. A preview that takes 30 seconds to load will be abandoned.

How Postdrop.io Makes This Effortless

This is the workflow where Postdrop.io is at its best. Here's how the process works:

1. Build or paste your email in Postdrop.io. The integrated editor gives you a live preview as you code, and handles CSS inlining automatically.
2. Generate cross-client renders. Postdrop renders your email across Gmail (web, iOS, Android), Outlook (multiple versions), Apple Mail, iOS Mail, Samsung Mail, and other major clients. The renders update in real time as you make changes.
3. Click "Share Preview" to generate a shareable link. One click creates a public URL that shows all your cross-client renders to anyone who visits it — no login, no account required.
4. Send the link to your client. Paste it in an email, a Slack message, a project management tool — anywhere. The client clicks the link and sees exactly how the email renders across all the clients you've chosen to include.

The client sees the same cross-client render panel you see. They can toggle between email clients, switch between desktop and mobile, and give specific, informed feedback: "The CTA button looks great in Gmail but can you check Outlook 2019?" That's far more useful feedback than "the font looks different."

Building an Approval Workflow Around Preview Links

A structured approval workflow built around preview links looks like this:

Phase 1: Design Review

Send the preview link when the email is visually complete but before any copy review. Ask specifically for visual feedback: "Does this match the brand guidelines? Does the layout work on mobile? Any visual changes before we finalize?"

By separating visual review from copy review, you avoid getting entangled in both simultaneously. Clients tend to focus on copy when they see it in a realistic email context — setting up a dedicated design review stage first keeps the feedback focused.

Phase 2: Copy Review

Share a preview link (or a Google Doc) for copy review. Mark this round explicitly: "This is copy review only — please focus on the text and messaging, not the layout or design, which were approved in the previous round."

Phase 3: Final Approval

Send a final preview link with all changes incorporated. Request explicit written approval ("Does this look good to send?") rather than assuming silence means approval. The preview link serves as a record of exactly what was approved and when.

When to Use Test Sends

Preview links replace most test sends, but test emails remain useful for specific checks:

• ESP-specific rendering: After importing your HTML into Mailchimp or Klaviyo, send a test within the ESP to catch any issues introduced by the import (tracking link wrapping, CSS re-processing, etc.).
• Personalization verification: Confirm that merge tags render correctly with real subscriber data, not just placeholder values.
• Link checking: Click every link in a test send to verify they all redirect correctly through your ESP's tracking system.
• Final pre-send check: One test email to yourself or a team member immediately before the real send, as a final sanity check.

Communicating Preview Links to Clients

When sending a preview link, provide context that helps the client review it effectively:

Hi [Client],

Here's the preview of the June newsletter across email clients:
[Postdrop.io preview link]

Things to check:
- How it looks on mobile (toggle to iOS Mail or Gmail iOS in the preview)
- The CTA button at the bottom — does the color match your brand guidelines?
- Any copy you'd like to adjust

Please reply with feedback by [date] and I'll have the final version ready for send by [send date].

Thanks,
[Your name]

Providing specific things to check focuses their review and surfaces the feedback that actually matters. Without guidance, clients tend to give vague feedback ("looks good" or "can we change something but not sure what"). Specific prompts lead to specific, actionable responses.

The shift from test-email-based approvals to preview-link-based approvals is one of the highest-leverage workflow improvements available to email developers and designers. It saves time, reduces friction, produces better feedback, and presents your work professionally. If you're still doing approval rounds via test emails, try the Postdrop.io preview link workflow on your next project — the difference is immediately apparent.

Responsive web design has been standardized for over a decade. Every modern browser supports media queries, flexbox, grid, and the full modern CSS toolkit. You write clean CSS, test in three browsers, and ship. The responsive web paradigm is well-understood.

Responsive email is messier. You're working with a rendering environment that includes clients that ignore media queries entirely (Gmail on Android), clients that process HTML through a word processor (Outlook), and clients that inject their own reset styles that override yours. The modern CSS tools that make responsive web development elegant are either unsupported or unreliable in email.

This guide covers the approaches and techniques that work — tested against the current email client landscape — and explains the tradeoffs between them.

The Three Responsive Email Approaches

Approach 1: Fixed Width (600px)

The simplest approach: design your email at a fixed 600px width and don't try to make it responsive. On mobile, the email client scales the entire email down to fit the screen width, and subscribers can pinch-zoom to read it.

This works for simple, text-heavy emails but fails for anything with small text, touch targets, or images that need to be a specific size on mobile. It's no longer considered best practice but remains appropriate for simple transactional emails where mobile readability isn't critical.

Approach 2: Fluid Layout

Fluid layouts use percentage-based widths instead of fixed pixels. A 50/50 two-column layout uses width: 50% on each column, so they naturally resize as the viewport changes. This produces a somewhat responsive email without requiring media query support.

The limitation: fluid layouts are hard to control at small screen sizes. A 50% width column at 375px viewport is only 187px — too narrow for most content. Fluid layouts work well for simple single or double-column structures but become unwieldy with more complex layouts.

Approach 3: Responsive with Media Queries (Recommended)

The standard modern approach: design a desktop layout (typically 600px wide) and use CSS media queries to override the layout at mobile breakpoints. Columns collapse from side-by-side to stacked, font sizes increase for readability, and padding is adjusted for touch interaction.

This requires client support for <style> block CSS and media queries — which means it won't work in Gmail on Android or clients that strip <style> blocks. The solution is to ensure your desktop/default layout degrades acceptably in those clients, then use media queries to enhance the experience in clients that support them.

The Hybrid / Spongy Technique

The "spongy" or hybrid technique bridges the gap between fluid and media query approaches. It combines percentage widths with max-width constraints and uses the display: inline-block trick to create columns that collapse gracefully even without media query support.

Here's the structure:

<table width="100%" cellpadding="0" cellspacing="0" border="0">
  <tr>
    <td align="center">
      <!--[if mso]>
        <table width="600" cellpadding="0" cellspacing="0" border="0">
        <tr><td width="285">
      <![endif]-->
      <div style="display: inline-block; width: 100%; max-width: 285px; vertical-align: top;">
        <!-- Column 1 content -->
      </div>
      <!--[if mso]></td><td width="285"><![endif]-->
      <div style="display: inline-block; width: 100%; max-width: 285px; vertical-align: top;">
        <!-- Column 2 content -->
      </div>
      <!--[if mso]></td></tr></table><![endif]-->
    </td>
  </tr>
</table>

The display: inline-block columns sit side-by-side when there's enough horizontal space, and naturally stack vertically when the viewport is narrower than their combined max-widths. Outlook uses the conditional comment tables for a fixed layout. Clients without media query support get a reasonable fluid behavior.

Media Query Responsive Patterns

For clients that do support media queries, add this pattern to your <style> block:

@media only screen and (max-width: 600px) {
  .two-col {
    width: 100% !important;
    display: block !important;
    max-width: 100% !important;
  }
  
  .desktop-only {
    display: none !important;
  }
  
  .mobile-only {
    display: block !important;
  }
  
  .email-container {
    width: 100% !important;
  }
  
  h1 {
    font-size: 26px !important;
    line-height: 1.3 !important;
  }
  
  .cta-button {
    width: 100% !important;
    box-sizing: border-box !important;
  }
  
  td {
    padding: 12px 16px !important;
  }
}

Key patterns:

• width: 100% !important — Forces columns to full width on mobile
• display: block !important — Stacks inline-block elements vertically
• !important throughout — Overrides inlined base styles

Typography for Mobile

Minimum Font Sizes

Body text should be at least 14px, ideally 16px, in mobile email. iOS Mail and some Android clients automatically increase font size below 13px, which can break your layout. Specify 16px for comfortable mobile reading and explicitly set -webkit-text-size-adjust: 100% to prevent automatic size adjustment.

Line Height

Set line-height as a unitless value (e.g., line-height: 1.6) rather than pixels, so it scales proportionally with the font size. Minimum 1.4 for body text, 1.2 for headings.

Heading Hierarchy

A clear heading hierarchy (H1 for the main subject, H2 for section headers) improves scannability on mobile, where subscribers often skim content. Make H1 large and bold (28-32px on desktop, 24px on mobile), H2 clearly secondary (20-22px).

Images in Responsive Email

Make Images Fluid

Add max-width: 100% and height: auto to all images so they scale down on small screens:

<img src="..." width="600" height="300" 
     style="width: 100%; max-width: 600px; height: auto; display: block; border: 0;" 
     alt="Description">

The HTML width and height attributes preserve the aspect ratio when CSS is stripped. The max-width prevents the image from exceeding its natural size on large screens. The inline width: 100% makes it fluid.

Retina Images

On retina displays, 1x images appear blurry. Use 2x images (twice the pixel dimensions of the display size) for hero images, logos, and any imagery where quality is important. A hero image displayed at 600px wide should be 1200px wide at 2x resolution.

Hero Image Alternatives

Use descriptive alt text on all images for when images are blocked. For hero images, consider whether the text content of the email still makes sense without the image — it should. For decorative images, use alt="" to signal to screen readers that the image can be skipped.

Touch Targets for Mobile

Apple's Human Interface Guidelines recommend a minimum tap target size of 44x44 points. For email buttons, this means a minimum height of 44px and enough horizontal padding that the text isn't crammed in a tiny space. On mobile, make CTA buttons full-width (100%) so they're easy to tap with a thumb. Stack multiple CTAs vertically rather than side-by-side.

Testing Responsive Email

Test at multiple breakpoints: 320px (small phones), 375px (standard iPhone), 414px (large phone), and your desktop width (typically 600px). Use Postdrop.io to preview mobile renders across Gmail iOS, Gmail Android, Apple Mail, and Samsung Mail simultaneously.

Pay special attention to Gmail on Android — it's the client most likely to ignore your media queries and render the desktop layout on a small screen. Your desktop layout should be readable at mobile viewport sizes even without the responsive CSS applying. If the desktop layout is a disaster at 375px, your Android Gmail subscribers are having a bad experience regardless of your media query work.

Responsive email is harder than responsive web, but the fundamentals are the same: design for the constraints of the environment, test on real devices and real clients, and iterate until it works well everywhere that matters for your audience.

You can have the most beautifully designed HTML email in the world — perfectly rendered in every client, precisely targeted to your audience, with copy that converts at industry-best rates — and none of that matters if the email lands in spam. Email authentication is the infrastructure layer that tells mailbox providers your email is legitimate, not a phishing attempt or spam campaign hijacking your domain.

SPF, DKIM, and DMARC are the three authentication standards that comprise modern email authentication. Each addresses a different angle of the "is this email really from who it claims to be from?" question. Understanding all three is essential for anyone serious about email deliverability.

This guide explains each standard in plain language, walks you through configuration, and describes how to verify your setup is working correctly.

SPF: Sender Policy Framework

What Is SPF?

SPF allows you to specify which mail servers are authorized to send email on behalf of your domain. It works through a DNS TXT record that lists the IP addresses and hostnames permitted to send from your domain.

When a receiving mail server gets an email claiming to be from you, it looks up your SPF record and checks whether the sending server's IP address is on the authorized list. If it is, SPF passes. If it's not, SPF fails — which is a signal that the email may be spoofed or unauthorized.

How to Set Up SPF

An SPF record is a DNS TXT record published at your domain (or subdomain). Here's a typical SPF record:

v=spf1 include:_spf.google.com include:_spf.mailchimp.com ~all

Breaking this down:

• v=spf1 — identifies this as an SPF record
• include:_spf.google.com — authorizes Google's mail servers (if you use Google Workspace)
• include:_spf.mailchimp.com — authorizes Mailchimp's servers (if you send via Mailchimp)
• ~all — "soft fail" for anything not on the list (use -all for a "hard fail")

Get the correct include value from each service you send email through. Every ESP provides documentation with their SPF include mechanism. Add an include for each ESP, transactional email service, or mail server that sends on behalf of your domain.

SPF Limitations

SPF has a lookup limit of 10 DNS queries. Include too many services and SPF lookups start failing. If you send through many services, consolidate where possible or use an SPF flattening service that resolves all includes to direct IP ranges.

SPF also only validates the sending server's IP against the "envelope from" domain — not the "From" address displayed to the user. This distinction matters for DMARC alignment, discussed below.

DKIM: DomainKeys Identified Mail

What Is DKIM?

DKIM adds a cryptographic signature to your emails that proves the email content hasn't been altered in transit and that it originated from a server authorized by your domain. It works using public key cryptography:

• You publish a public key as a DNS TXT record at a designated subdomain of your domain.
• Your mail server signs outgoing emails with the corresponding private key.
• Receiving servers verify the signature using your public key from DNS.

If the signature verifies correctly, DKIM passes. If the email has been tampered with in transit, or if it wasn't signed by an authorized server, DKIM fails.

How to Set Up DKIM

DKIM setup is done through your ESP or mail server — they generate the key pair and provide you the DNS record to publish. For example, in Google Workspace:

1. Go to Admin console > Apps > Google Workspace > Gmail > Authenticate email
2. Click "Generate new record" to create your DKIM key pair
3. Google provides a DNS record like: google._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=[public key]"
4. Add this TXT record to your domain's DNS
5. Wait for DNS propagation (up to 48 hours), then click "Start Authentication"

Each service you use to send email should have its own DKIM signature. Follow the DKIM setup instructions for each ESP individually. Mailchimp, Klaviyo, HubSpot, and SendGrid all have straightforward DKIM configuration documentation.

DKIM Record Structure

A DKIM record is published at a "selector._domainkey.yourdomain.com" subdomain. The selector is usually provided by your ESP (e.g., "mandrill" for Mandrill, "k1" for Klaviyo). The record itself contains the version, key type, and the public key value.

DMARC: Domain-based Message Authentication Reporting and Conformance

What Is DMARC?

DMARC builds on top of SPF and DKIM to give you explicit control over what happens when authentication fails, and to send you reports about authentication activity for your domain.

A DMARC policy tells receiving mail servers: "If an email claiming to be from my domain fails authentication, here's what to do with it — nothing, quarantine it (spam folder), or reject it entirely." It also specifies where to send aggregate and forensic authentication reports.

DMARC Alignment

DMARC requires "alignment" — the domain in the visible From: header must match (or align with) the domain that passed SPF or DKIM. This closes the loophole where a spammer could use a legitimate mail server (passing SPF) but put a spoofed domain in the From: field.

DMARC Policy Options

• p=none — Monitor mode. Receive reports but take no action on failures. Start here.
• p=quarantine — Failing emails go to the spam folder.
• p=reject — Failing emails are rejected and never delivered.

Setting Up DMARC

Publish a DNS TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; sp=none; adkim=r; aspf=r;

Start with p=none and review the aggregate reports (rua) for 2-4 weeks. The reports show you who is sending email on behalf of your domain, whether their SPF and DKIM are passing, and from which IP addresses. Once you're confident all legitimate sending sources are properly authenticated, move to p=quarantine, then eventually to p=reject.

DMARC Reporting Services

DMARC aggregate reports come as XML files, which aren't human-readable. Free services like Postmark's DMARC tool, dmarcian, or Valimail parse these reports and present them in a usable dashboard. Sign up for one before enabling DMARC reporting to actually make use of the data.

Verifying Your Setup

After configuring SPF, DKIM, and DMARC, verify they're working:

• MXToolbox: Free tools at mxtoolbox.com to check SPF, DKIM, and DMARC records. Run "SuperTool" on your domain to see all email-related DNS records.
• Google Postmaster Tools: If you send to Gmail addresses, Google's Postmaster Tools shows your authentication pass rates, spam rates, and domain reputation. This is perhaps the most valuable tool for diagnosing deliverability issues.
• Send a test email and check headers: Send a test email to a Gmail or Yahoo address and view the raw headers. Look for "dkim=pass", "spf=pass", and "dmarc=pass" in the "Authentication-Results" header. If any show "fail", there's a misconfiguration to investigate.

Your email design and content matter — but if your authentication isn't properly configured, even the best HTML email won't reliably reach inboxes. Get these fundamentals right first, then focus on the experience you're delivering to subscribers who actually receive your messages.

Dark mode in web browsers is relatively straightforward: you respond to the prefers-color-scheme: dark media query and provide alternative color variables. Email is significantly more complex because different email clients implement dark mode in fundamentally different ways — some give you control, some don't, and some will forcibly modify your email's colors whether you want them to or not.

Without explicit dark mode handling, your carefully designed email with a white background and dark text might arrive looking like photographic negatives: dark background, bright white text, vivid neon images. For subscribers who live in dark mode (an increasingly large segment), this is an unpleasant experience. For branded emails where color consistency matters, it can be genuinely damaging to perception.

Understanding how each major client handles dark mode — and how to respond to each — is the key to supporting dark mode well.

How Email Clients Handle Dark Mode

Apple Mail and iOS Mail

Apple Mail is the most developer-friendly when it comes to dark mode. It supports the @media (prefers-color-scheme: dark) media query and respects the color-scheme CSS property and meta tag. If you provide explicit dark mode styles, Apple Mail will use them.

If you don't provide dark mode styles, Apple Mail will perform "partial color inversion" — it inverts light backgrounds and light text to their dark equivalents, but attempts to leave images and already-dark elements unchanged. The results are inconsistent but generally acceptable.

Gmail

Gmail's dark mode behavior differs by platform. On iOS and Android, Gmail respects the system dark mode preference and performs its own automatic color transformation on emails that don't have explicit dark mode support. The transformation algorithm attempts to preserve the email's visual hierarchy, but it can produce unexpected color combinations.

Gmail on the web (desktop) doesn't apply dark mode transformations to email content — emails render as-coded regardless of the system setting. This means your light-mode design is always preserved in Gmail web, but mobile Gmail subscribers may see an automatically transformed version.

Outlook

Outlook on Windows does not support dark mode transformations for email content. Emails render in light mode regardless of the system dark mode setting. Outlook for Mac and Outlook on iOS do apply dark mode transformations, similar to Apple Mail.

Samsung Mail

Samsung Mail aggressively applies dark mode transformations. It inverts backgrounds and text colors but attempts to leave images untouched. Like Gmail, it can produce surprising results when it encounters unusual color combinations.

The Three Dark Mode Implementation Strategies

Strategy 1: Ignore Dark Mode

Some organizations choose not to implement explicit dark mode support, accepting that their emails will display in the automatic transformation of each client. This is the simplest approach and reasonable for high-volume transactional emails where design polish isn't the priority.

The risk: clients that perform aggressive automatic inversion (Samsung Mail, mobile Gmail) may produce results you'd consider embarrassing for a marketing email. Test the automatic behavior before committing to this strategy.

Strategy 2: Prevent Dark Mode Transformations

You can tell email clients to render your email in light mode only, preventing automatic dark mode transformations:

<meta name="color-scheme" content="light">
<style>
  :root { color-scheme: light; }
</style>

This preserves your light mode design for all subscribers, including those in dark mode. It's a legitimate choice for emails where color accuracy is critical and you don't have time to build a full dark mode version. The tradeoff: dark mode users may find a bright white email jarring in a dark environment.

Strategy 3: Build an Explicit Dark Mode Version

The best outcome: a genuinely designed dark mode version of your email that looks good in dark mode without sacrificing light mode quality. This requires more development time but delivers the best subscriber experience.

The implementation uses the @media (prefers-color-scheme: dark) media query alongside the color-scheme meta tag:

<meta name="color-scheme" content="light dark">
<style>
  :root { color-scheme: light dark; }
  
  @media (prefers-color-scheme: dark) {
    .email-body { background-color: #1a1a2e !important; }
    .email-container { background-color: #16213e !important; }
    .email-text { color: #e0e0e0 !important; }
    .email-heading { color: #ffffff !important; }
    .email-link { color: #a78bfa !important; }
    .light-only { display: none !important; }
    .dark-only { display: block !important; }
  }
</style>

Dark Mode Design Principles

Avoid Pure Black and Pure White

In dark mode, a pure black (#000000) background creates harsh contrast that causes eye strain. Use very dark grays (#0f0f0f, #1a1a2e, #111827) for backgrounds. Similarly, pure white (#ffffff) text on dark background is too harsh — use off-whites (#e5e5e5, #f3f4f6) instead.

Reduce Saturation for Background Colors

Vivid, saturated colors that look great on white backgrounds can appear garish against dark ones. When translating brand colors to dark mode, slightly desaturate and increase brightness. Your brand's primary blue might be #2563eb in light mode but #60a5fa (lighter, slightly less saturated) in dark mode.

Use Logo Variants

If your logo is a dark wordmark on a transparent background, it will be invisible in dark mode. Use the .light-only / .dark-only pattern (above) to swap logo variants. Maintain a light version of your logo specifically for dark mode use.

Maintain Sufficient Contrast

The WCAG minimum contrast ratio is 4.5:1 for normal text. In dark mode, light text on dark backgrounds needs to be light enough to maintain this ratio. Use a contrast checker to verify your dark mode color combinations meet accessibility requirements.

Test Images on Dark Backgrounds

Photos with white backgrounds become particularly problematic in dark mode — the white bleeds into the dark email background. Use images with transparent backgrounds where possible, or consider adding a subtle background container behind images that works in both modes.

Testing Dark Mode

Dark mode testing requires seeing your email in both modes across multiple clients. Postdrop.io includes dark mode preview toggles for each client render, so you can see exactly what your email looks like in Apple Mail dark mode, Gmail dark mode, and others — without setting up a device for each. This dramatically speeds up the iteration cycle when fine-tuning dark mode colors.

Pay particular attention to Apple Mail (which fully respects your dark mode CSS) and Gmail on iOS and Android (which applies its own transformation unless you use color-scheme: light to prevent it). These are the highest-impact clients for dark mode subscribers.

If you build custom HTML emails — rather than using your ESP's visual drag-and-drop builder — you'll need to export your finished HTML into your sending platform. Each major ESP handles custom HTML differently, with different import interfaces, different levels of support for modern HTML, and different ways they process your code before sending.

This guide covers the specific steps for the three most widely used ESPs — Mailchimp, HubSpot, and Klaviyo — along with the common issues you'll encounter and how to solve them.

Before You Export: Prepare Your HTML

Regardless of which ESP you're importing into, do these steps first:

1. Inline Your CSS

Most ESPs apply their own CSS processing when you import HTML, and they often strip <style> block content or handle it inconsistently. Inline your CSS before importing to ensure your styles survive the import process unchanged. Tools like Postdrop.io inline CSS automatically — export the inlined version for importing into your ESP.

2. Host Your Images

Image URLs in your HTML must be absolute URLs pointing to a hosted image (not relative paths or base64-encoded strings). Most ESPs will upload your images to their CDN during import, but some need them pre-hosted. The safest approach: host images on your own CDN or image hosting service before importing, so the URLs remain stable regardless of how your ESP processes the import.

3. Test Your Email First

Use Postdrop.io or a similar tool to verify cross-client rendering of your HTML before importing. Once you're inside an ESP's editor, making substantial HTML changes is more difficult. Catch rendering issues at the HTML level, not after import.

4. Add Merge Tags

Each ESP uses its own template merge tag syntax for personalization (first name, etc.). If your email uses personalization, add the correct merge tags for your target ESP before importing. See the ESP-specific sections below for the correct syntax.

Importing into Mailchimp

Classic Builder vs. New Builder

Mailchimp has two email builders — the Classic Builder and the newer drag-and-drop builder. Custom HTML import behaves differently in each:

Classic Builder: When creating a new campaign, choose "Code Your Own" from the template selection screen. This opens a full HTML editor where you paste your code directly. The Classic Builder preserves your HTML with minimal processing, making it the preferred option for custom-coded emails.

New Builder: The new builder is designed for visual editing and is less suited to custom HTML. It wraps your HTML in its own layout structure, which can interfere with your template's design. Stick to the Classic Builder for custom HTML templates.

Mailchimp Merge Tags

Mailchimp uses *|FNAME|* syntax for merge tags:

<p>Hi *|FNAME|*, ...</p>

Other common tags: *|EMAIL|* (subscriber email), *|UNSUB|* (unsubscribe link — required by law).

Mailchimp-Specific Processing

Mailchimp automatically adds tracking parameters to links. It also requires an unsubscribe link in the email footer. If your HTML doesn't include one, Mailchimp will add it — potentially in an ugly default style that clashes with your design. Include a styled unsubscribe link in your template before importing: <a href="*|UNSUB|*">Unsubscribe</a>.

Importing into HubSpot

Creating a Custom HTML Email in HubSpot

HubSpot handles custom HTML emails through its email editor. When creating a new email, choose the "Drag and drop" editor, then look for the option to "Edit HTML source" or switch to the HTML editor. In older versions of HubSpot, select a "Custom" template type, which gives you direct HTML access.

Alternatively, HubSpot supports custom template modules — reusable HTML email templates stored in the Design Manager. This is the more powerful approach for teams who send many emails using the same template. Upload your HTML template to the Design Manager, then use it as the base for campaigns.

HubSpot Merge Tags

HubSpot uses its own HubL templating language for personalization:

<p>Hi {{ contact.firstname }}, ...</p>

Other tokens: {{ contact.email }}, {{ unsubscribe_link }}.

HubSpot CSS Handling

HubSpot processes CSS differently than raw import. It applies its own email reset styles that can conflict with your custom styles. Inline all CSS before importing. Pay particular attention to font declarations — HubSpot's default font stack may override yours if you rely on <style> block font rules.

Importing into Klaviyo

The HTML Block Approach

Klaviyo's email editor uses a block-based structure. For custom HTML, use the "Custom HTML" block type in the email builder. This embeds your custom HTML within Klaviyo's email wrapper. For full control over the entire email structure, use a "Full HTML" template instead, which gives you complete control over the email's HTML without Klaviyo's wrapper.

To create a Full HTML template: go to Templates in Klaviyo, click "Create Template," and choose "HTML Editor." Paste your full HTML here. This is the cleanest approach for completely custom templates.

Klaviyo Merge Tags

Klaviyo uses Django template syntax:

<p>Hi {{ first_name }}, ...</p>

Built-in variables: {{ email }}, {{ unsubscribe_url }}.

Klaviyo Image Hosting

Klaviyo automatically uploads and re-hosts any images with relative paths or URLs it can't access. For reliable image delivery, host your images on your own CDN and reference them with absolute HTTPS URLs. Klaviyo also offers its own image library where you can upload assets to keep them accessible across templates.

Common Import Issues and Fixes

Styles Get Stripped

If your styles disappear after import, the ESP likely stripped your <style> block. Inline your CSS before importing. This solves 90% of style-stripping issues.

Images Break After Import

Broken images after import usually mean either: the image URL was relative (not absolute), the image host blocked the ESP's CDN from fetching it, or the image was embedded as a base64 string that the ESP didn't handle correctly. Use absolute HTTPS URLs pointing to publicly accessible images.

Layout Looks Different in the ESP Preview

ESPs add their own wrapper HTML around your template, which can affect layout. Test with a real send (to a test address) rather than relying solely on the ESP's preview tool. The send is always the most accurate representation of what subscribers will see.

Tracking Links Break Your HTML

ESPs wrap all links with tracking redirects. This can sometimes introduce encoding issues or break special characters in URLs. Always send a test before the actual campaign and click every link to confirm they redirect correctly.

Building and testing your email in Postdrop.io before importing gives you a clean, tested HTML baseline. Export the fully inlined HTML, add your ESP's merge tags, then import — this workflow minimizes import-time surprises and keeps your source files separate from your ESP's processing.

Email testing tools exist to answer one question: "Will my email look right in my subscribers' inboxes?" The three most used tools — Postdrop.io, Litmus, and Email on Acid — all answer that question, but through different approaches, at different price points, and with different tradeoffs that matter depending on your use case.

This comparison is written to help you make an informed decision. All three are legitimate, professional tools. The right choice depends on your team size, workflow, budget, and what you value most.

The Contenders

Postdrop.io

Postdrop.io is an AI-powered HTML email editor and testing platform. It's designed for developers and email designers who want to build, test, and share HTML emails in one place. Beyond cross-client previews, it includes an integrated HTML editor, one-click CSS inlining, dark mode preview, and shareable preview links that let you share render results with clients without sending test emails.

Litmus

Litmus is the longest-established email testing platform. Founded in 2005, it offers email previews across 90+ clients, email analytics (tracking opens by client), spam testing, a visual builder, and team collaboration features. It's positioned as an enterprise platform and is widely used at large organizations with dedicated email teams.

Email on Acid

Email on Acid (acquired by Sinch in 2019) offers cross-client previews, checklist-based pre-send testing, accessibility checks, and campaign precheck tools. It's particularly strong on the QA checklist side, guiding users through a structured review process before sending.

Features Comparison

Email Client Coverage

All three tools offer previews across the major email clients. The breadth of client coverage matters less than it appears in marketing materials — the top 10 clients (Gmail web, Gmail iOS, Gmail Android, Apple Mail, Outlook 2016–2021, iOS Mail, Samsung Mail, Yahoo Mail) account for well over 90% of email opens. Difference between 90 clients and 60 clients rarely affects real-world quality.

HTML Editor

Postdrop.io is the strongest here. It's built around an integrated HTML editor, letting you write and test in one workflow. Litmus has a basic code editor but it's not the primary workflow. Email on Acid has a paste-and-test interface primarily.

Shareable Preview Links

This is where Postdrop.io stands out most clearly. One click generates a shareable link showing all your cross-client renders — no account required for the viewer. For agencies and freelancers sharing work with clients, this eliminates a painful back-and-forth. Litmus has a sharing feature but requires recipients to have a Litmus account. Email on Acid has preview sharing, but it's less prominent in the workflow.

CSS Inlining

Postdrop.io inlines CSS automatically as part of the build process. Litmus has a CSS inliner as a separate tool. Email on Acid does not include CSS inlining.

Spam Testing

Litmus and Email on Acid both offer spam score analysis. Postdrop.io focuses on rendering quality and HTML tools rather than spam analysis — for spam testing, you'd use a dedicated tool like Mail-Tester alongside Postdrop.

Analytics

Litmus stands alone here with its email analytics product, which shows client breakdown of opens (which percentage of opens came from each email client). This data is valuable for prioritizing which clients to test and optimize for. Neither Postdrop.io nor Email on Acid offers this.

Accessibility Checks

Email on Acid has the strongest automated accessibility checking, flagging issues with alt text, color contrast, and semantic structure. Litmus also has accessibility checking. Postdrop.io focuses on visual rendering quality.

Pricing

Postdrop.io

Postdrop.io offers a free tier that covers basic usage with cross-client previews. Paid plans are priced for individual developers and small teams at a significantly lower price point than Litmus. This makes it accessible for freelancers and smaller agencies who need professional-quality testing without enterprise pricing.

Litmus

Litmus is the most expensive of the three. Pricing starts at several hundred dollars per month for the basic plan and scales to thousands for enterprise. The pricing reflects its enterprise positioning — large email programs with multiple team members, analytics needs, and deep integrations. For a solo developer or small team, the cost can be hard to justify.

Email on Acid

Email on Acid is positioned between Postdrop.io and Litmus on price. Individual plans are in the $80-100/month range. Team plans scale up from there. The pricing is more accessible than Litmus for smaller operations.

Ease of Use

Postdrop.io has the simplest, most modern interface. The learning curve is minimal — paste or write your HTML, previews appear immediately. The workflow is designed around developer speed.

Litmus has a more complex interface with many features, which means more power for advanced users but a steeper learning curve. The platform has been around since 2005, and some parts of the UI show that age.

Email on Acid's checklist-driven approach is well-organized and clear, particularly for teams that value structured QA processes. The guided workflow helps ensure nothing is missed.

Integrations

Litmus

Litmus has deep integrations with most major ESPs (Mailchimp, Hubspot, Salesforce Marketing Cloud, Klaviyo, and others). These integrations allow you to send from your ESP directly into Litmus for testing, then push back. For enterprise teams already committed to one of these platforms, the native integration is a significant workflow advantage.

Postdrop.io

Postdrop.io focuses on the build-and-test workflow rather than deep ESP integration. It exports clean, tested HTML that you then import into your ESP of choice. This approach is less friction for developers who manage their own templates, though it lacks the seamless ESP workflow of Litmus.

Email on Acid

Email on Acid has integrations with several major ESPs and offers an API for incorporating pre-send testing into automated workflows and CI/CD pipelines.

Which Tool Should You Choose?

Choose Postdrop.io if:

• You're a developer or designer who writes custom HTML emails
• You need shareable preview links for client approval workflows
• You want an integrated editor + testing workflow
• Budget is a consideration — you need professional quality without enterprise pricing
• You value a fast, modern UI without unnecessary complexity

Choose Litmus if:

• You need email client analytics to understand your audience's client distribution
• Your team is large with complex collaboration requirements
• You need deep native integration with Salesforce Marketing Cloud, Marketo, or other enterprise ESPs
• Budget is not a constraint and you want the most comprehensive feature set

Choose Email on Acid if:

• Your workflow is checklist-driven and you want guided pre-send QA
• Accessibility testing is a priority
• You need an API for automated pre-send testing in a CI/CD pipeline
• You want something more affordable than Litmus with stronger QA structure than most tools

For most developers and small email teams, Postdrop.io's combination of an integrated editor, fast cross-client previews, shareable links, and accessible pricing makes it the best starting point. Try it free at postdrop.io and see how it fits your workflow.

Every email developer eventually faces the same moment of confusion: they've written clean, valid HTML and CSS that looks perfect in Gmail and Apple Mail, but Outlook renders it as a broken mess of overlapping elements and collapsing columns. Understanding why requires understanding one strange historical decision.

In 2007, Microsoft switched Outlook's HTML rendering engine from Internet Explorer's Trident to Microsoft Word's rendering engine. This was an enterprise decision — Word is deeply integrated into Microsoft's productivity suite and the engineering cost of maintaining two separate rendering stacks was significant. But the consequence for email developers has been severe: Outlook now renders HTML email through a word processing engine that predates modern CSS, ignores most of the HTML4 spec's layout properties, and has been only incrementally updated since.

This affects every version of Outlook from 2007 through Microsoft 365 (Office 365) on Windows. Outlook on Mac uses WebKit and renders well. The new Outlook app for Windows 11, shipping gradually in 2024, uses a web rendering engine. But in corporate environments — where Outlook market share is highest — the Word-based renderer remains dominant.

Column Layouts: The Most Common Break

The Problem

Multi-column layouts built with display: flex, display: grid, or CSS float don't work in Outlook. These properties are simply ignored. All elements fall into a single vertical stack, destroying any side-by-side layout you intended.

The Fix: HTML Tables

Use HTML tables for any layout that requires elements to sit side by side. This is the fundamental rule of Outlook-compatible email development: structure with tables, style with CSS.

<table width="600" cellpadding="0" cellspacing="0" border="0">
  <tr>
    <td width="300" valign="top">
      <!-- Left column content -->
    </td>
    <td width="300" valign="top">
      <!-- Right column content -->
    </td>
  </tr>
</table>

Yes, it's 1999 web development. This is the reality of email. The table-based layout stays intact in Outlook because Word has always supported basic HTML tables from its document editing roots.

Background Images: VML to the Rescue

The Problem

Outlook ignores CSS background images. background-image: url() on a div or table cell is stripped entirely. This breaks hero sections, decorative backgrounds, and any layout that relies on background imagery.

The Fix: VML Backgrounds

Vector Markup Language (VML) is an XML-based vector graphics format Microsoft developed in 1998. It's the only way to render background images in Outlook. Here's the pattern:

<!--[if mso]>
<v:rect xmlns:v="urn:schemas-microsoft-com:vml" fill="true" stroke="false" 
  style="width:600px;height:200px;">
  <v:fill type="frame" src="https://example.com/header-bg.jpg" color="#6b21a8" />
  <v:textbox inset="0,0,0,0">
<![endif]-->
  <!-- Content overlaid on the background -->
<!--[if mso]></v:textbox></v:rect><![endif]-->

The <!--[if mso]> wrapper ensures this VML code only runs in Outlook. Other clients render the regular CSS background from the element's style attribute.

Margin and Padding: Unreliable by Default

The Problem

Outlook applies margins and padding inconsistently, particularly on <div>, <p>, and <img> elements. A margin: 0 auto to center a block element often doesn't work. <p> tags have a default Word margin-bottom that adds unexpected whitespace.

The Fix

For spacing, use padding on <td> elements rather than margin on divs — table cell padding is reliable in Outlook. Reset default <p> margins explicitly:

<p style="margin: 0; padding: 0 0 16px 0;">Your text here.</p>

For image spacing, add display: block to images to remove the default inline baseline gap, and set border: 0 to prevent Outlook from adding a border to linked images.

Buttons: The Bulletproof Technique

The Problem

CSS-styled anchor tags that look like buttons break in Outlook. display: inline-block with padding produces a text link with no visual padding. border-radius on the button is ignored.

The Fix: VML Buttons

The most reliable approach is the VML button (also known as the "bulletproof button"). It uses VML to render the button shape in Outlook while using regular HTML/CSS for other clients:

<!--[if mso]>
<v:roundrect xmlns:v="urn:schemas-microsoft-com:vml" 
  href="https://postdrop.io" 
  style="height:44px;v-text-anchor:middle;width:180px;" 
  arcsize="10%" stroke="f" fillcolor="#6b21a8">
  <w:anchorlock/>
  <center style="color:#ffffff;font-family:sans-serif;font-size:14px;font-weight:bold;">
    Start Building Free
  </center>
</v:roundrect>
<![endif]-->
<!--[if !mso]><!-->
<a href="https://postdrop.io" style="background-color:#6b21a8;border-radius:4px;color:#ffffff;display:inline-block;font-family:sans-serif;font-size:14px;font-weight:bold;line-height:44px;text-align:center;text-decoration:none;width:180px;">
  Start Building Free
</a>
<!--<![endif]-->

Web Fonts: Use System Font Stacks

The Problem

Outlook doesn't support web fonts loaded via @font-face or Google Fonts. It falls back to the default font — typically Times New Roman on Windows — which almost never matches your design intent.

The Fix

Define a comprehensive fallback font stack that degrades gracefully:

font-family: 'Your Webfont', -apple-system, BlinkMacSystemFont, 'Segoe UI', 
  Arial, sans-serif;

Segoe UI is the Windows system font and looks excellent in Outlook. If your design requires a specific brand font, check whether the font is a standard Windows system font (like Calibri or Trebuchet MS) that Outlook will render natively.

DPI Scaling Issues in Outlook

On high-DPI Windows displays (typically 125% or 150% scaling), Outlook scales your email layout proportionally. A 600px wide email at 125% DPI becomes 750px wide, which can overflow containers and break responsive breakpoints.

The fix: add this meta tag to your HTML <head>:

<meta name="viewport" content="width=device-width, initial-scale=1">

And for Outlook specifically, target the correct width using an Outlook-specific conditional style:

<!--[if mso]>
<style type="text/css">
  body, table, td, a { font-size: 14px !important; }
  table { mso-table-lspace: 0pt; mso-table-rspace: 0pt; }
</style>
<![endif]-->

Line Spacing and Paragraph Spacing

The Problem

Word adds default spacing between paragraphs. In Outlook, a <p> tag gets the same spacing that Word's "Normal" paragraph style defines — typically 8–10px of spacing below each paragraph, in addition to whatever CSS you specified. This creates visible gaps between elements that you didn't design.

It also affects line spacing. line-height set in CSS may be partially overridden by Word's internal line spacing rules, producing tighter or looser text than expected.

The Fix

Explicitly set mso-line-height-rule: exactly for elements where line-height precision matters:

<p style="line-height: 24px; mso-line-height-rule: exactly; margin: 0 0 16px 0;">
  Your paragraph text here.
</p>

The mso-line-height-rule: exactly property is Outlook-specific and tells Word to use the exact line-height value rather than Word's minimum line spacing calculation. Combine this with explicit zero top-margin and controlled bottom-margin on paragraphs to eliminate unexpected gaps.

Table Gaps and Spacing

The Problem

Outlook can add unintended spacing between table cells. This is usually caused by the default table cellspacing value or Word's interpretation of CSS border spacing. A 2px gap appearing between adjacent table cells can misalign a carefully designed layout.

The Fix

Always set cellpadding="0", cellspacing="0", and border="0" on every table. Also add the Outlook-specific MSO table spacing properties:

<table width="600" cellpadding="0" cellspacing="0" border="0" 
  style="border-collapse: collapse; mso-table-lspace: 0pt; mso-table-rspace: 0pt;">

The mso-table-lspace and mso-table-rspace properties set Outlook's internal table spacing to zero, closing the gaps. Add these to every structural table in your email.

Image Width Issues

The Problem

Outlook resizes images based on their CSS width property, but it doesn't always respect percentage widths or max-width. A full-width hero image with width: 100% may render at its natural pixel dimensions in Outlook, overflowing a 600px container and causing horizontal scrolling.

The Fix

Always specify explicit pixel dimensions in both the HTML width and height attributes and the CSS style attribute. For responsive images that need to shrink on mobile, use the HTML attribute for Outlook's fixed width and CSS for the responsive behavior in other clients:

<img src="hero.jpg" width="600" height="300" 
  style="width: 100%; max-width: 600px; height: auto; display: block; border: 0;"
  alt="Hero image">

Outlook respects the HTML width="600" attribute for a fixed 600px render. Other clients use the CSS width: 100%; max-width: 600px for fluid responsive behavior.

Testing Outlook Fixes

Every Outlook fix should be tested in the specific Outlook version you're targeting. Outlook 2016, 2019, and Microsoft 365 have different behaviors in subtle ways — a VML background that renders correctly in Outlook 2019 may have a slight vertical offset in Outlook 2016. Testing across multiple Outlook versions used to require maintaining separate Windows installations with each Office version installed.

Postdrop.io renders previews across multiple Outlook versions simultaneously in your browser, making it practical to verify your fixes work across versions without the overhead of managing multiple Windows setups. Iterate on your code and see the render update across Outlook 2016, 2019, and 2021 at the same time.

The golden rule of Outlook development: never assume an Outlook fix works until you've seen it rendered in Outlook. What looks like correct source code often surprises you when Word processes it. The conditional comment pattern (<!--[if mso]>) is your most reliable tool — use it to inject Outlook-specific overrides without affecting other clients, and test every conditional comment path explicitly.

Outlook is genuinely difficult, but it's a solvable problem. The table-based layout foundation, VML for backgrounds and buttons, explicit spacing resets, and MSO-specific properties give you everything you need to build emails that look right even in the most restrictive versions of Outlook. Master these patterns once and they become muscle memory.

When you build a website, you write CSS in separate .css files or <style> blocks in the <head> of your HTML. The browser reads those stylesheets and applies the rules to matching elements. This is clean, maintainable, and has worked reliably for decades.

Email clients don't work this way. Gmail strips everything in a <style> block. Yahoo Mail does the same. Outlook is inconsistent about which rules it respects from <head> styles. The result: if you send an HTML email with styles in a stylesheet rather than inline on each element, most of your styles simply won't apply.

Inline CSS — styles written directly in the style attribute of each HTML element — is the only formatting that works reliably across all major email clients. But maintaining inline CSS by hand is tedious, error-prone, and results in bloated HTML that's nearly impossible to update.

CSS inlining tools solve this: you write normal CSS in a <style> block, then run the inliner, which processes your selectors and converts them to inline styles before you send. The output is compatible with even the most restrictive email clients, while your source file remains maintainable.

How CSS Inlining Works

A CSS inliner parses your HTML, reads the CSS rules in your <style> block, finds every element that matches each selector, and writes the computed style directly into that element's style attribute. The <style> block is either removed or left in place (depending on the tool's settings).

For example, this source code:

<style>
  .button {
    background-color: #6b21a8;
    color: #ffffff;
    padding: 12px 24px;
    border-radius: 6px;
    text-decoration: none;
    font-weight: bold;
  }
</style>
...
<a href="https://postdrop.io" class="button">Try Postdrop</a>

After inlining, becomes:

<a href="https://postdrop.io" 
   style="background-color:#6b21a8;color:#ffffff;padding:12px 24px;border-radius:6px;text-decoration:none;font-weight:bold;"
>Try Postdrop</a>

The original class attribute remains (it's harmless), but the visual styling is now fully portable across email clients.

What Doesn't Get Inlined

Not all CSS properties can be inlined. Certain constructs fundamentally can't work as element-level inline styles:

Media Queries

Media queries require a <style> block — there's no way to express a breakpoint condition as an inline style. A well-configured inliner preserves media queries in the <style> block rather than trying to inline them. For clients that strip <style> blocks (Gmail Android), this means responsive behavior won't work — an acceptable compromise since those clients typically don't need responsive layout anyway, as they already resize content to fit.

Pseudo-Classes and Pseudo-Elements

:hover, :focus, :first-child, and similar selectors can't be inlined. Many email clients support basic pseudo-class CSS in <style> blocks, so inliners typically leave these in place rather than stripping them.

Dark Mode Rules

The @media (prefers-color-scheme: dark) block must stay in the <style> tag. Any dark mode overrides you define in this block are preserved by inliners that support this pattern.

CSS Specificity After Inlining

CSS specificity becomes interesting once everything is inlined. Inline styles have the highest specificity — they override anything in a <style> block. This is actually what you want for the base styles. But it means that if you're relying on <style> block rules to override inline styles (for responsive behavior or dark mode), those won't work as expected.

The solution: use !important declarations in your media query overrides to ensure they win over the inlined base styles. This sounds like a hack, but it's the accepted pattern in email development:

@media only screen and (max-width: 600px) {
  .two-col {
    width: 100% !important;
    display: block !important;
  }
}

The !important ensures the mobile width override wins against the inlined desktop width, even though inline styles normally take precedence.

CSS Inlining Tools

Postdrop.io

Postdrop.io handles CSS inlining automatically as part of its workflow. When you build or paste your email HTML in the editor, it inlines your styles before generating client previews and before you export. You get the benefits of writing maintainable stylesheet CSS while the output is fully inlined for client compatibility.

Juice

Juice is the most popular open-source Node.js CSS inlining library. It's the engine under the hood of many inlining tools. You can use it as a command-line tool or integrate it into your build pipeline.

Premailer

Premailer is a Ruby gem (and web service) that pioneered CSS inlining for email. It handles specificity conflicts well and preserves media queries. The web interface at premailer.dialect.ca accepts HTML or a URL and returns inlined HTML.

Mailchimp's CSS Inliner

Mailchimp provides a free web-based CSS inliner at templates.mailchimp.com/resources/inline-css/. It's straightforward: paste your HTML, click a button, get inlined output.

Practical Inlining Workflow

Here's a workflow that keeps your source files maintainable while producing inlined output for sending:

1. Write your email in a template file with a <style> block containing all your CSS. Organize styles by component (header, body, button, footer) for readability.
2. Keep responsive CSS in media queries in the <style> block. Use !important on properties that need to override inlined values.
3. Run the inliner (or build Postdrop.io into your workflow) to generate the send-ready HTML.
4. Test the inlined output — not the source file — because that's what subscribers will receive. Verify it looks correct in your target clients.
5. Never edit the inlined output directly. Make all changes in the source file and re-inline. If you edit the inlined HTML, you'll lose those changes the next time you inline.

Common Inlining Mistakes

Using Shorthand Properties

Some email clients don't support shorthand CSS properties like font: bold 16px/1.5 Arial. Prefer individual properties: font-weight: bold; font-size: 16px; line-height: 1.5; font-family: Arial. Inliners may or may not expand shorthands, so it's safer to avoid them in your source.

Forgetting About Email Client CSS Resets

Some email clients inject their own stylesheets that affect your content. Gmail adds default link colors. Outlook adds default line heights. After inlining, verify that these injected styles aren't overriding your carefully applied inline values.

Inlining Everything Including Width

Inlining pixel widths on <table> elements is correct. But don't inline percentage widths — they won't work in Outlook. Use the HTML width attribute for percentage widths on table cells that need to be percentage-based, alongside the inline style for pixel widths.

CSS inlining is one of the less glamorous parts of HTML email development, but getting it right is the foundation everything else builds on. Once you have a reliable inlining step in your workflow — whether that's using Postdrop.io's automatic inlining or running Juice in your build script — your cross-client compatibility improves dramatically, and you can focus on writing good CSS rather than debugging why styles aren't applying.

If you've ever built a responsive website, you're familiar with cross-browser testing — but the differences between Chrome, Firefox, and Safari are minor compared to the rendering chasm between Gmail, Outlook, and Apple Mail. Email clients evolved in isolation, without the coordination that eventually brought browser vendors toward standards compliance. The result is a landscape where three of the most popular email clients use fundamentally different rendering engines with wildly different CSS support levels.

Understanding how each client works — and what it breaks — is prerequisite knowledge for any developer writing HTML email code.

Gmail: The CSS Stripper

Gmail serves more than 1.8 billion users and consistently ranks as the most popular email client worldwide. It's also one of the most restrictive when it comes to CSS support.

How Gmail Renders Email

Gmail strips most CSS that isn't inlined. In the web version, it removes anything in a <style> tag in the <head>. On Android, it also strips <style> blocks, meaning media queries for responsive layout won't work. It wraps all email content in its own div, which can inherit Gmail's own styles and create specificity conflicts.

What Gmail Doesn't Support

• External stylesheets: Always stripped. Inline all CSS.
• Most @media queries on Android: The Gmail Android app ignores media queries entirely on older versions.
• Web fonts via @font-face: Gmail blocks external font loading. Fallback to system fonts.
• CSS custom properties (variables): Not supported. Use literal hex/rgb values.
• CSS Grid and Flexbox: Inconsistently supported. Use table-based layouts for structural elements.
• Background images via CSS: Stripped in many contexts. Use bgcolor attribute for colored backgrounds.

Gmail Clipping

Gmail clips emails larger than 102KB with a "View entire message" link. Subscribers who don't click that link see a truncated email. Keep your HTML under 100KB by removing unnecessary whitespace, comments, and unused styles. If your email is large, consider loading images from a CDN rather than embedding them as base64 strings.

Writing for Gmail

The safest approach: inline all CSS using an inliner tool, use table-based layout for multi-column structures, avoid web fonts (specify a strong fallback stack), and test with image blocking enabled. Tools like Postdrop.io show you exactly what your email looks like in Gmail web and Gmail mobile before you send.

Outlook: The Word Processor Problem

Outlook is the most notorious email client in the developer community — and for good reason. Versions 2007 through 2019 (including Microsoft 365 on Windows) use Microsoft Word as their HTML rendering engine. Not a browser engine. A word processor.

Why Word Is a Terrible HTML Renderer

Word was designed to render formatted documents, not HTML. It treats HTML email as a document to be word-processed, which means it applies Word's own layout rules rather than following CSS specifications. The results are often catastrophic for anything beyond simple single-column text emails.

What Breaks in Outlook

• CSS floats: Completely ignored. Columns built with floats collapse into a single vertical stack.
• CSS position: Position: relative, absolute, and fixed are not reliably supported.
• Background images via CSS: Stripped entirely. You must use VML (Vector Markup Language) for background images, which is an XML format Microsoft invented in the late 1990s.
• Margin and padding on div elements: Inconsistent, often ignored. Use table cells for spacing.
• max-width: Not respected on <table> elements in some versions.
• CSS border-radius: Not supported. All rounded elements become rectangles.
• Video: <video> tags are stripped. Use a fallback image.

Outlook Conditional Comments

The standard approach for Outlook-specific fixes is conditional comments — special HTML comment syntax that only Outlook reads:

<!--[if mso]>
  <!-- Outlook-only code here -->
<![endif]-->

Use these to inject Outlook-specific table structures, VML background images, or layout overrides that would break other clients if included unconditionally.

The New Outlook (Windows 11)

Microsoft is shipping a new Outlook application for Windows 11 built on web technology rather than Word. This version has significantly better CSS support. However, the old Outlook (Word-based) remains dominant in corporate environments, so you'll need to support both for the foreseeable future.

Apple Mail: The Permissive One

Apple Mail on macOS and iOS Mail are the most standards-compliant major email clients. They use WebKit, the same rendering engine as Safari, which means they support a much wider range of modern CSS than Gmail or Outlook.

What Apple Mail Supports Well

• Web fonts: Apple Mail supports @font-face and will load custom fonts.
• CSS Grid and Flexbox: Supported and functional.
• CSS animations: Basic CSS animations work in Apple Mail.
• Background images: CSS background images render correctly.
• SVG: Inline SVG is supported.
• Media queries: Fully supported for responsive design.

Apple Mail Dark Mode

Apple Mail was one of the first clients to implement dark mode for emails. It supports the prefers-color-scheme media query and the color-scheme meta tag, giving developers control over how their email appears in dark mode. Without explicit dark mode handling, Apple Mail will forcibly invert colors, which can make your email look completely different — and often worse — than intended. Our guide on dark mode email design covers this in detail.

Apple Mail Auto-Link Detection

Apple Mail automatically detects phone numbers, dates, addresses, and certain keywords and converts them to interactive links. This can inadvertently style content you didn't intend to be interactive. Suppress this behavior where needed with x-apple-data-detectors="false" attributes.

Other Clients Worth Knowing

Yahoo Mail

Yahoo Mail strips CSS from the <head> (similar to Gmail) but supports some inline CSS that Gmail doesn't. It has unique whitespace behaviors that can add unexpected margins around table cells. Yahoo Mail also converts some URLs to tracking URLs, which can affect click data.

Samsung Mail (Android)

Samsung Mail has its own rendering quirks, including unique handling of large images and table borders. It's worth including in your test matrix given Samsung's market share in Android devices.

HEY and Basecamp

Newer email clients like HEY and the Basecamp email interface are built on modern web technology and generally render HTML email well, but they may have opinionated styling that overrides your own — particularly around typography and link colors.

The Cross-Client Testing Imperative

Given how differently these clients render the same HTML, testing across all of them is essential. The practical approach: build for the lowest common denominator (Outlook's constraints), then use conditional CSS and progressive enhancement to deliver a better experience to more capable clients.

A solid mental model for prioritization: fix Outlook first (most constraints), then Gmail (most users), then make it beautiful in Apple Mail (most permissive). Use Postdrop.io to get live previews across all three simultaneously as you build, rather than toggling between separate accounts. The real-time feedback loop dramatically reduces the number of iteration cycles before you have a cross-client solution.

Client Support Comparison Table

Sending an HTML email without testing is a bit like deploying code without running a test suite — something will break, and you won't know until a subscriber replies to tell you their email looks like a wall of unformatted text. Unlike the web, where browsers have largely agreed on how to render HTML and CSS, email clients remain a fragmented, sometimes hostile rendering environment.

Outlook 2016 still uses Microsoft Word's rendering engine. Gmail aggressively strips most CSS that lives outside inline styles. Apple Mail is permissive but has its own quirks around dark mode. Yahoo Mail has unique whitespace behaviors. If you send an email to a list of 50,000 subscribers without testing, you're sending a different experience to every major client — and not all of those experiences will be good.

Testing is how you close that gap. This guide covers everything you need to know: what breaks, how to catch it, and what tools give you the fastest feedback loop.

What Can Go Wrong Without Testing

Let's start with the concrete failures you're trying to prevent:

Layout Collapse

Multi-column layouts built with CSS floats or flexbox will collapse in Outlook, which doesn't support either. A two-column product grid becomes a single vertical column, and your carefully designed hierarchy disappears. The fix requires table-based layouts for structural elements — but you can only confirm the fix works by testing in Outlook itself.

Missing Background Images

Gmail and some versions of Outlook strip CSS background images entirely. A hero section with a full-bleed background photo becomes a blank block. For Outlook specifically, you need VML (Vector Markup Language) fallbacks to render background images. Without testing, you won't know the background image is missing until after you've sent.

Broken Fonts

Web fonts (Google Fonts, custom typefaces loaded via @font-face) are supported by Apple Mail, iOS Mail, and some Android clients — but not Gmail or Outlook. When the web font fails to load, the email client falls back to the generic system serif, which is usually Times New Roman. If your design depends on a sans-serif typeface, this fallback can make your email look completely different from your intentions.

Responsive Design Failures

Media queries work in most email clients, but Gmail on Android has historically ignored them. Mobile Gmail clips emails wider than 600px. Without testing on mobile Gmail, you might ship a layout that forces users to scroll horizontally just to read your content.

Image Blocking

Many corporate email clients block images by default, showing empty boxes with alt text (or nothing at all). Your email needs to communicate its core value proposition even when every image is hidden. Testing with image blocking enabled shows you whether your alt text, text hierarchy, and structure hold up on their own.

Building a Pre-Send Testing Checklist

Before every send, go through this checklist:

1. HTML Validation

Valid HTML is a prerequisite. Run your source code through the W3C HTML validator. Unclosed tags, improperly nested elements, and missing attributes can cause wildly different rendering behaviors across clients.

2. CSS Inlining

Your CSS needs to be inlined for maximum compatibility. Rules sitting in a <style> block in the <head> will be stripped by many clients. Use an automated CSS inliner to convert stylesheet rules to inline styles before sending. We cover this in detail in our guide on how to inline CSS in HTML emails.

3. Link Testing

Check every link in the email. This sounds obvious, but link rot happens: staging URLs that never got replaced, UTM parameters that got mangled, anchor fragments that lead nowhere. Click every call-to-action and confirm it goes to the right destination.

4. Image Testing

Verify that all images load correctly. Check file sizes — images over 1MB slow load times and can trigger spam filters. Confirm every image has descriptive alt text. Then disable images in your email client and review what the email looks like without them.

5. Client Preview Testing

Test in at least these clients: Gmail (web, iOS, Android), Outlook 2016 and later, Apple Mail, iOS Mail, and Samsung Mail. These cover the vast majority of your subscriber base. Tools like Postdrop.io render live previews across all major email clients in your browser, which is dramatically faster than maintaining test accounts in each app.

6. Spam Score Testing

Run your email through a spam score checker like Mail-Tester. Common spam triggers include: high image-to-text ratio, certain spammy phrases, missing or misconfigured authentication records (SPF, DKIM, DMARC), and large file attachments. Catching spam score issues before sending can mean the difference between inbox and junk folder.

7. Plain Text Version

Every HTML email should have a plain text alternative. Some email clients display only the plain text version. Some anti-spam systems look for a matching plain text alternative as a trust signal. Make sure yours is well-formatted, contains all the key content, and actually reads well as text.

8. Rendering on Real Devices

Emulators are useful, but nothing replaces testing on a physical iPhone running Apple Mail or a Galaxy on Gmail. Dark mode rendering, font scaling at system accessibility settings, and touch target sizes for CTAs all behave differently on real hardware. Keep a small device lab — even two or three phones — for final checks on important sends.

The Right Tools for Email Testing

Manual testing across devices is thorough but slow. For fast iteration, you need tools designed for email.

Postdrop.io

Postdrop.io is an AI-powered HTML email editor and testing platform. Paste or build your email directly in the editor, and instantly preview how it renders across Gmail, Outlook, Apple Mail, and dozens of other clients — without setting up separate test accounts. Postdrop also handles CSS inlining automatically and generates shareable preview links so you can share renders with clients or teammates for review before sending.

Mail-Tester

Mail-Tester provides a temporary email address you can send to. After sending, visit the results page to see a detailed spam score, authentication check results, and content quality analysis. It's free for casual use and an excellent addition to any pre-send workflow.

ESP Previews

Most major email service providers (Mailchimp, Klaviyo, HubSpot, Campaign Monitor) have built-in preview tools. These are useful for a final sanity check after importing your HTML, but they don't render as many clients as dedicated testing tools and can't show you the full cross-client picture.

Testing Cadence: When to Test

You don't need to run every test on every email. Here's a sensible cadence based on risk:

• New template: Full testing across all clients before the first send. Invest the time upfront so you can reuse the template with confidence.
• Template update: Re-test any clients where you changed layout or CSS. Text-only content changes don't require a full client sweep.
• Routine send (unchanged template): Spot-check three to five clients, run a spam score, and confirm all links. Skip the full suite if the template is proven.
• Critical campaign (launch, revenue-impacting): Full testing regardless of template age. Stakes justify the time.

Embedding Testing Into Your Workflow

The teams that ship consistently high-quality emails make testing automatic, not heroic. Build a staging step into your email production process: every email goes through preview checks before it reaches the send queue. Tools like Postdrop.io make this fast enough that it's not a bottleneck — you can get full cross-client previews in under a minute.

If you're working with a team, use shareable preview links to get sign-off from stakeholders on how an email looks across clients, not just on a single screenshot. This closes the feedback loop and prevents surprises after the send button is pressed.

Testing is the last line of defense between your work and your subscribers' inboxes. Make it a habit and your email quality will be consistently high — regardless of which client your audience uses.