Allowed Uses of the <link> Tag

• Stylesheets: The primary and most secure use of the <link> tag in Open Email Standards is to load external CSS stylesheets. These CSS files should come from approved libraries and frameworks (e.g., Tailwind CSS, Bootstrap, or Bulma) hosted on trusted CDNs such as jsDelivr, UNPKG, or Cloudflare CDN. This ensures both proper formatting and strong security, while also helping keep email size optimized for performance.
• Fonts: The <link> tag is also allowed for securely loading web fonts from trusted sources. For detailed guidance on font usage, including supported providers and security restrictions, see section Font Guidelines in Open Email Standards.

Example: Using <link> for CSS Loading

<!-- Include Bootstrap CSS from a trusted CDN -->
<link href="https://cdn.jsdelivr.net/npm/bootstrap@5.1.3/dist/css/bootstrap.min.css" rel="stylesheet">

<!-- Include a secondary CSS library for additional styles -->
<link href="https://cdn.jsdelivr.net/npm/animate.css@4.1.1/animate.min.css" rel="stylesheet">

Disallowed Uses of the <link> Tag

• Metadata and Icons: Tags such as rel="icon", rel="manifest", and metadata-focused links like rel="canonical", rel="alternate" or rel="sitemap" are irrelevant in the email context. These tags are meant for web browsers, handling tasks like user experience, app installations, and search engine optimization, none of which apply to email clients.

Discouraged Uses of the <link> Tag

While the <link> tag has several applications in the web context, certain uses should be avoided in emails due to performance, security, or compatibility concerns:

• Preload (rel="preload") and Prefetch (rel="prefetch"): These attributes load resources ahead of time to improve page performance, but in an email context, they add complexity, increase email size, and may cause compatibility issues.
• Recommendation: Avoid using rel="preload" and rel="prefetch" in email environments, as they may not be supported and can unnecessarily slow down email rendering.

Best Practice Guidelines

• Use Trusted Sources: External CSS files should be loaded from verified and standards-compliant CDNs to ensure security, reliability, and consistency across email clients. Using pre-approved sources prevents unauthorized code injection while maintaining proper rendering across different platforms. Recommended libraries such as Bootstrap, Tailwind CSS, and Bulma adhere to these standards and can be securely integrated via jsDelivr, cdnjs, and UNPKG.
• Ensure HTTPS: All linked resources must use HTTPS to secure the connection and prevent data interception.

The use of the <link> tag within Open Email Standards should be limited to loading stylesheets and fonts. Other uses, such as metadata, prefetch, and manifest links, are unnecessary and should be omitted to maintain security and email performance. By limiting the functionality of <link>, the email environment can remain both safe and optimized.

Inline CSS in <style> Tag

Inline CSS within the <style> tag is commonly used to include styles from libraries and frameworks. However, there are certain considerations to ensure efficient use:

• Code Size Management: Embedding large amounts of CSS can increase the size of the email, potentially leading to slower delivery and performance, especially on mobile devices or limited networks. When using inline CSS, focus on optimizing the code to reduce unnecessary size.
• Security Precautions: Ensure that all inline CSS comes from trusted libraries or sources, especially when loading custom fonts, to avoid embedding unsafe or unverified styles.

CSS Code Restrictions for Security

While CSS is generally safe, some practices should be avoided or restricted in email to prevent security risks:

• JavaScript in CSS: Any CSS code that attempts to execute JavaScript (via URL schemes like javascript: or data:) should be strictly prohibited, as it introduces security vulnerabilities like cross-site scripting (XSS).
• Base64 Encoding: Avoid embedding Base64-encoded content in CSS, such as fonts or images. It increases the email's size and can trigger spam filters or be blocked by email clients.
• Disallowed CSS Properties: The cursor property is disallowed due to its ability to load external files and potential security risks.
• External Dependencies: Only load external resources through trusted CDNs to prevent malicious content injection.

Example: Efficient Inline CSS in the <style> Tag

<style>
  body {
    font-family: 'Roboto', sans-serif;
    margin: 0;
    padding: 0;
    background-color: #f5f5f5;
    color: #333;
  }
  .header {
    text-align: center;
    color: #fff;
    padding: 10px;
  }
  .cta {
    display: block;
    margin: 20px auto;
    background: #4CAF50;
    padding: 10px;
    text-decoration: none;
    border-radius: 5px;
  }
</style>

Example: Unsafe or Disallowed CSS Usage

The following CSS patterns introduce security risks or are disallowed under Open Email Standards due to their potential for misuse.

background-image: url("javascript:alert('XSS')");
cursor: url("https://untrusted-source.com/pointer.cur"), auto;

Inline Style Attributes

Inline style attributes applied to elements like <div> or <span> must follow the same security and performance guidelines as the <style> tag. Avoid unsafe patterns, including javascript: URLs, base64-encoded content, or references to external assets from untrusted sources.

Best Practice Guidelines

• Always use <link>: Loading CSS from external files using the <style> tag ensures security and compatibility.
• Use Trusted Sources: Only load CSS from reputable CDNs and libraries such as Bootstrap, Tailwind CSS, and Foundation, using services like cdnjs, jsDelivr, or unpkg.
• Ensure HTTPS: All CSS links must use HTTPS to secure the connection and prevent data interception.
• Strip Unsafe CSS: Any CSS that attempts to execute JavaScript or relies on untrusted external resources should be stripped out to prevent security vulnerabilities.
• Minimize Inline CSS: While inline CSS is allowed, it is recommended to minimize its usage to prevent oversized emails and potential blocking by email clients.
• Client-Side Enforcement: Email clients can implement tools like ImageBlocker.js to block any external image loaded through CSS—regardless of the property used—ensuring robust content security and safeguarding user privacy.

Trusted Font Sources

To ensure secure font loading, emails should only use fonts from verified, trusted sources. One of the most popular platforms for loading external fonts is Google Fonts, which offers a wide range of fonts that can be securely embedded using a CDN. This ensures that fonts are both optimized and safe to use. Other trusted platforms include Bunny Fonts, and Fontshare, which also offer reliable, secure ways to load fonts for web and email.

Use <link> for Font Loading

This remains the most reliable, secure, and email-client-friendly approach. It ensures that fonts are loaded from a trusted, verified source, and it minimizes the risks associated with security and compatibility.

Example: Loading Roboto Font via External Stylesheet

<link href="https://fonts.googleapis.com/css2?family=Roboto:wght@400;700&display=swap" rel="stylesheet">

Limitations on <style> Tag for Font Loading

Custom fonts should not be loaded directly inside the <style> tag within the email. This practice introduces security and performance concerns, especially when using data: URLs for embedding fonts. Inline styles with embedded fonts can significantly increase email size, making them more likely to trigger spam filters or exceed client limitations. Additionally, some email clients may strip or block these styles, resulting in rendering issues.

Example 1: Prohibited Use of Base64 Encoded Font Inline

Using Base64 encoding to embed fonts via the data: scheme is explicitly prohibited under Open Email Standards. While this approach removes external dependencies, it increases the size of the email and conflicts with security guidelines that restrict the use of the data: URL scheme. Instead, rely on external, trusted CDNs like Google Fonts or Bunny Fonts for secure and efficient font loading.

<style>
  @font-face {
    font-family: 'EncodedFont';
    src: url(data:font/woff2;base64,d09GMgABAAAAAA...) format('woff2');
  }

  h1 {
    font-family: 'EncodedFont', serif;
  }
</style>

Example 2: Inline Font Face Declaration in <style> Tag

This inline <style> block attempts to load a font from an external URL, which could be untrusted. Loading fonts in this manner within emails presents security risks and might not be supported by all email clients.

<style>
  @font-face {
    font-family: 'CustomFont';
    src: url('http://untrusted-source.com/fonts/customfont.woff2') format('woff2');
  }

  body {
    font-family: 'CustomFont', sans-serif;
  }
</style>

Example 3: Loading Fonts from an External URL in <style> Tag

While this method pulls fonts from a trusted source (e.g., Google Fonts), embedding the font loading directly in the <style> tag via @import is not recommended. Using the <link> tag for font loading is a more secure and compatible approach, ensuring consistency across email clients.

<style>
  @import url('https://fonts.googleapis.com/css?family=Roboto:400,700&display=swap');

  body {
    font-family: 'Roboto', sans-serif;
  }
</style>

Best Practice Guidelines

• Always use <link>: Fonts should be loaded using the <link> tag, embedded directly in <style> tags is not recommended.
• Use Trusted Sources: Only load fonts from reputable providers like Google Fonts, Bunny Fonts, or other known, secure CDNs.
• Ensure HTTPS: Make sure the font URL uses HTTPS to secure the connection.
• Avoid Inline Font Embedding: Do not use Base64 encoding or load fonts directly in the email, as it increases the email’s size and poses security risks.