SendReady
← Blog
email-developmentdeliverabilitychecklist

The Email Developer's Pre-Send Checklist

April 25, 2026

Sending a broken email to your list is one of the most visible mistakes in marketing. Unlike a bug on a web page you can hotfix in seconds, a sent email can’t be recalled. This checklist covers everything worth checking before you hit send, from HTML structure through to deliverability signals.

HTML structure

Doctype and encoding

  • <!DOCTYPE html> is present
  • <meta charset="UTF-8"> is in the <head>
  • <meta name="viewport" content="width=device-width, initial-scale=1.0"> is present for mobile scaling

Table structure (for Outlook compatibility)

  • Structural layout uses tables, not flexbox or CSS Grid; Outlook’s Word rendering engine doesn’t support modern layout
  • All tables have cellpadding="0", cellspacing="0", and border="0" to reset default browser spacing
  • Width is set as an HTML attribute (width="600") on the outer container, not just in CSS

Outlook conditional comments

  • Ghost tables and MSO fallbacks are wrapped in <!--[if mso]>...<![endif]--> conditional comments
  • Conditional comments are intact. Run through an email-aware HTML minifier, not a generic one that strips comments

Images

  • All <img> tags have an alt attribute; even decorative images should have alt=""
  • Images have explicit width and height attributes set
  • Images are hosted on a reliable CDN, not local paths or your ESP’s staging environment
  • Image file sizes are reasonable. Large images slow load times on mobile

CSS

Inlining

  • All styles are inlined: <style> block CSS has been converted to inline style attributes
  • Run through a CSS inliner before uploading to your ESP
  • Media queries are preserved in a <head> <style> block (can’t be inlined)

Font fallbacks

  • Web font declarations have a system font stack fallback: font-family: 'Your Font', Arial, sans-serif
  • Email clients that don’t load web fonts will render the fallback. Verify it still looks acceptable

Color

  • All color values are in hex (#333333); some email clients don’t support rgb() or CSS variables
  • Link colors are explicitly set. Outlook and other clients apply blue link styling by default

File size

  • Full HTML file is under 102KB. Gmail clips emails that exceed this and shows a “View entire message” link, cutting off your footer and unsubscribe link
  • Run through the HTML Minifier to reduce size without breaking email-specific markup
  • Large images are compressed before hosting

Content and deliverability

Copy

  • Subject line is scanned for spam trigger words. Use the Spam Word Scanner
  • Preheader text is set (the preview text after the subject line in the inbox)
  • No broken merge tags. Check for unclosed {{variable}}, *|MERGE|*, or <%= tags
  • Plain text version is included (most ESPs handle this automatically, but verify)

Links

  • All links have been tested and point to the correct destination
  • Unsubscribe link is present and working, as required by CAN-SPAM and GDPR
  • Link text is descriptive. Avoid “click here” as both a spam signal and an accessibility issue
  • UTM parameters are applied if you’re tracking campaign performance

Sending

  • From name and from address are set correctly
  • Reply-to is configured if replies should go to a different address than the sender

SPF

Sender Policy Framework (SPF) is a DNS record that lists the mail servers authorized to send email on behalf of your domain. Without it, receiving servers have no way to verify the email actually came from you, making messages more likely to land in spam or be rejected. Add an SPF record through your domain registrar or DNS provider; it looks like v=spf1 include:mailprovider.com ~all, where mailprovider.com is your ESP’s sending infrastructure. If you send from multiple providers, include each one. Validate your SPF record with MXToolbox.

  • SPF record is present and includes all sending services (ESP, CRM, transactional providers)
  • Record ends with ~all (softfail) or -all (hard fail), never +all

DKIM

DomainKeys Identified Mail (DKIM) attaches a cryptographic signature to every outgoing message. Receiving servers use it to verify the message wasn’t tampered with in transit. Your ESP generates a key pair and gives you a DNS TXT record to add to your domain. Most major ESPs (Mailchimp, Klaviyo, Campaign Monitor) have step-by-step DKIM setup instructions for custom sending domains. As of 2024, Gmail and Yahoo require DKIM for bulk senders; it’s no longer optional if you’re sending at volume. Verify your DKIM configuration with MXToolbox’s DKIM lookup.

  • DKIM is enabled and the DNS record is published for your sending domain
  • Key length is 1024-bit minimum; 2048-bit preferred

DMARC

DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receiving servers what to do when a message fails SPF or DKIM checks. Start with p=none to collect reports without blocking mail, then move to p=quarantine (sends failures to spam) or p=reject (blocks them entirely) once you’ve confirmed your legitimate mail is authenticating cleanly. Gmail and Yahoo require a DMARC record for bulk senders. The record belongs in DNS as a TXT record on _dmarc.yourdomain.com. Check your policy with MXToolbox’s DMARC checker.

  • DMARC record is present with at least p=none
  • A rua= reporting address is set so you can monitor authentication failures

Domain warm-up

A new sending domain has no reputation with inbox providers. Blasting a large list from a cold domain is one of the fastest ways to trigger spam filters and damage your sender reputation, possibly permanently. Warm up gradually: start with your most engaged subscribers, keep volume low in the first few weeks, and increase slowly over 4–8 weeks. Most ESPs publish a warm-up guide specific to their platform. If you’re migrating from another ESP or domain, your engagement history doesn’t transfer. Treat it as a new domain regardless.

  • Sending volume is appropriate for the domain’s age and reputation
  • Initial sends target your most engaged segment, not your full list

Testing

  • Rendered in Outlook (Windows), the most common source of unexpected breakage
  • Rendered in Gmail (web) and Gmail (mobile)
  • Rendered in Apple Mail
  • Rendered at both mobile and desktop widths
  • Dark mode appearance is acceptable. At minimum, the email is readable; ideally it’s styled for dark mode

The quick pre-send workflow

  1. Scan copy → Spam Word Scanner for deliverability risks
  2. Inline CSS → CSS Inliner for client compatibility
  3. Minify HTML → HTML Minifier for file size
  4. Test render → Outlook, Gmail, Apple Mail
  5. Send a seed → Send to yourself or a test account before your full list

All three SendReady tools are free, browser-based, and require no account. Your HTML never leaves your machine.