# The Email Specification — checklist Source: https://specification.email/checklist/ ## Foundations - [ ] **Internet message format** _(required)_ — Every message must use the standard header and body structure, valid line endings, and legal field syntax before it enters SMTP. https://specification.email/spec/foundations/message-format/ - [ ] **Required message header fields** _(required)_ — Each message needs a valid Date, From, and globally unique Message-ID, with recipient and subject fields that match its purpose. https://specification.email/spec/foundations/header-fields/ - [ ] **MIME multipart structure** _(required)_ — Use valid MIME types, boundaries, transfer encodings, and multipart nesting so every client can select a safe representation. https://specification.email/spec/foundations/mime-multipart/ ## Authentication - [ ] **Sender Policy Framework (SPF)** _(required)_ — Publish one bounded SPF policy that authorizes legitimate envelope senders without exceeding DNS lookup limits or permitting the world. https://specification.email/spec/authentication/sender-policy-framework/ - [ ] **DomainKeys Identified Mail signatures** _(required)_ — Sign outgoing mail with DKIM using aligned domains, protected private keys, rotating selectors, and canonicalization that survives normal transit. https://specification.email/spec/authentication/dkim-signatures/ - [ ] **DMARC alignment and policy** _(required)_ — Publish DMARC, collect reports, align SPF or DKIM with the visible From domain, and move to enforcement only after legitimate flows pass. https://specification.email/spec/authentication/dmarc-policy/ ## Deliverability - [ ] **Reverse DNS and sending identity** _(required)_ — Every sending IP needs stable forward-confirmed reverse DNS, an SMTP greeting that matches it, and an operational domain identity. https://specification.email/spec/deliverability/reverse-dns/ - [ ] **Recipient list hygiene** _(required)_ — Send only to expected recipients, remove permanent failures, suppress complainers, and stop mailing addresses that never engage or consent. https://specification.email/spec/deliverability/list-hygiene/ - [ ] **Spam complaint handling** _(required)_ — Subscribe to available feedback loops, connect complaints to recipients safely, suppress them promptly, and monitor complaint rates by message stream. https://specification.email/spec/deliverability/complaint-handling/ ## Accessibility - [ ] **Semantic email structure** _(required)_ — Use headings, paragraphs, lists, tables, and landmarks according to meaning so assistive technology can navigate the message. https://specification.email/spec/accessibility/semantic-structure/ - [ ] **Alternative text for email images** _(required)_ — Every informative image needs concise equivalent alt text, while decorative images need an empty alt attribute and no repeated meaning. https://specification.email/spec/accessibility/image-alt-text/ - [ ] **Email color contrast and cues** _(required)_ — Text, controls, and meaningful graphics need sufficient contrast, and color must never be the only way the message communicates state. https://specification.email/spec/accessibility/color-and-contrast/ ## Rendering - [ ] **Robust email layout tables** _(recommended)_ — Use a simple presentation-table scaffold where client support requires it, without leaking table semantics into the reading experience. https://specification.email/spec/rendering/table-layout/ - [ ] **Inline CSS and safe fallbacks** _(recommended)_ — Inline critical presentation, keep selectors simple, and design fallbacks for clients that remove style blocks or ignore unsupported properties. https://specification.email/spec/rendering/inline-css/ - [ ] **Responsive email layout** _(required)_ — Messages must fit narrow screens, preserve readable type, and keep controls usable even when media queries or viewport hints are ignored. https://specification.email/spec/rendering/responsive-layout/ ## Privacy - [ ] **Tracking pixels and remote images** _(recommended)_ — Treat open tracking as unreliable personal data collection, disclose it, minimise retention, and never make essential behavior depend on it. https://specification.email/spec/privacy/tracking-pixels/ - [ ] **Recipient data minimisation** _(required)_ — Put only necessary personal data in message bodies, headers, links, logs, and provider metadata, with explicit retention for each copy. https://specification.email/spec/privacy/data-minimisation/ - [ ] **Consent and subscription provenance** _(required)_ — Keep verifiable evidence of how and when each recipient subscribed, what they expected, and which message purposes that choice covered. https://specification.email/spec/privacy/consent-provenance/ ## Internationalisation - [ ] **UTF-8 message content** _(required)_ — Encode international text consistently as UTF-8 across headers and bodies, with MIME declarations and transfer encodings that preserve every character. https://specification.email/spec/internationalisation/utf-8-content/ - [ ] **Message language and text direction** _(required)_ — Declare the message language and mark bidirectional runs so pronunciation, punctuation, numerals, and reading order remain correct. https://specification.email/spec/internationalisation/language-direction/ - [ ] **Internationalized email addresses** _(recommended)_ — Accept and preserve Unicode mailbox addresses only when every validation, storage, SMTP, and support path handles SMTPUTF8 safely. https://specification.email/spec/internationalisation/international-addresses/ ## Lifecycle - [ ] **One-click list unsubscribe** _(required)_ — Bulk subscription mail needs authenticated one-click unsubscribe headers that complete without login, redirects, confirmation pages, or extra choices. https://specification.email/spec/lifecycle/one-click-unsubscribe/ - [ ] **Delivery status and bounce handling** _(required)_ — Classify SMTP and delivery-status failures, stop permanent retries, back off temporary failures, and connect outcomes to the correct recipient. https://specification.email/spec/lifecycle/bounce-handling/ - [ ] **Retry strategy and message expiry** _(required)_ — Retry transient SMTP failures with backoff, cap queue lifetime, and expire time-sensitive messages before delayed delivery becomes harmful. https://specification.email/spec/lifecycle/retry-expiry/ ## Security - [ ] **Email header injection prevention** _(required)_ — Treat every header value as structured data, reject line breaks from untrusted input, and let a mail library serialize addresses and fields. https://specification.email/spec/security/header-injection/ - [ ] **Safe and trustworthy email links** _(required)_ — Link text, visible domains, redirects, and destination context must agree, while sensitive actions require fresh server-side authorization. https://specification.email/spec/security/safe-links/ - [ ] **Dangerous active email content** _(avoid)_ — Do not depend on scripts, forms, embedded credentials, or untrusted active content; sanitise generated HTML and provide safe web fallbacks. https://specification.email/spec/security/dangerous-content/ ## Automation - [ ] **Calendar invitation interoperability** _(recommended)_ — Calendar mail must include valid iCalendar data, stable event identifiers, correct methods, time zones, and updates that replace prior versions. https://specification.email/spec/automation/calendar-invitations/ - [ ] **Machine-readable email actions** _(optional)_ — Add structured actions only as progressive enhancement, bind them to visible content, and keep the ordinary website workflow complete. https://specification.email/spec/automation/machine-readable-actions/ - [ ] **Safe and usable email attachments** _(recommended)_ — Attach only necessary files with accurate media types, safe names, bounded size, malware controls, and an accessible alternative where possible. https://specification.email/spec/automation/attachments/