Whether you’re sending password reset emails, invoices, verification links, support replies, newsletters, or transactional notifications, email is often the most visible part of your application.

Yet many teams only test one thing:

“Did the email send?”

Unfortunately, that’s only the beginning.

Modern emails involve HTML rendering, plain-text fallbacks, SMTP delivery, authentication records, MIME structures, headers, tracking links, attachments, and dozens of small details that can affect whether an email reaches the inbox—or whether users trust it once it does.

This checklist covers everything you should verify before shipping an email to production.

1. Verify the Content

Before looking at technical details, read the email like a user.

Check:

• Subject line is clear
• Preview text makes sense
• Sender name is correct
• From address is correct
• Reply-To address is correct
• Company branding is consistent
• Grammar and spelling
• Personalization variables are populated
• Dates and currency are formatted correctly
• No placeholder values remain

Example problems:

❌ Hello {{first_name}}

❌ Click here to verify your account (without explaining why)

❌ Broken company logo

2. Verify Both HTML and Plain Text Versions

Every production email should contain both:

• HTML
• Plain text

Many email clients still rely on the plain-text version.

The text version is also important for accessibility, spam filtering, and automated systems.

Check that:

• The text version exists
• Links are readable
• Paragraph spacing is correct
• Important information isn’t lost

3. Inspect the HTML

HTML emails are very different from normal web pages.

Things to verify:

• Images load
• Fonts degrade gracefully
• Tables render correctly
• Buttons are clickable
• Inline styles are present
• Mobile layout works
• Dark mode is acceptable

Avoid:

• External CSS
• JavaScript
• Modern layout techniques unsupported by email clients

4. Test Across Email Clients

Never assume an email that looks good in one client looks good everywhere.

Test in:

• Gmail
• Apple Mail
• Outlook
• Thunderbird
• Yahoo Mail
• Mobile clients

Things to watch:

• Font rendering
• Image scaling
• Button alignment
• Spacing
• Dark mode
• Responsive layout

5. Check Every Link

Broken links are surprisingly common.

Verify:

• CTA buttons
• Footer links
• Privacy Policy
• Terms of Service
• Unsubscribe links
• Password reset URLs
• Verification URLs
• Social media icons

Also confirm:

• HTTPS is used
• UTM parameters are correct
• Links aren’t expired

6. Verify Attachments

If your email includes attachments:

• Correct filename
• Correct MIME type
• Opens successfully
• File isn’t corrupted
• File size is reasonable
• Downloads quickly

Examples include:

• PDFs
• CSV exports
• Invoices
• Reports
• Images

7. Check SMTP Delivery

Once the email leaves your application, SMTP becomes important.

Verify:

• SMTP connection succeeds
• Correct sender is used
• Correct recipient is used
• Server accepted the message
• Provider returned a successful response
• No retries occurred
• No unexpected delays

Understanding the SMTP conversation often makes diagnosing delivery problems much easier.

8. Verify Email Headers

Headers contain valuable information for debugging.

Some important headers include:

• From
• To
• Date
• Subject
• Message-ID
• Reply-To
• Return-Path
• MIME-Version
• Content-Type

Authentication headers are equally important:

• Authentication-Results
• DKIM-Signature
• SPF results
• DMARC results

Many delivery problems can be diagnosed simply by inspecting headers.

9. Verify Authentication

Modern email depends heavily on authentication.

Ensure:

✅ SPF passes

✅ DKIM passes

✅ DMARC passes

Also verify alignment between:

• Envelope sender
• From address
• DKIM domain

Authentication failures are one of the biggest causes of spam filtering.

10. Inspect the MIME Structure

Every email is actually a MIME document.

A typical transactional email contains:

• multipart/alternative
• Plain-text body
• HTML body
• Attachments (optional)
• Inline images (optional)

Malformed MIME structures often cause strange rendering issues.

11. Verify Deliverability

Sending an email successfully doesn’t guarantee inbox delivery.

Check:

• Spam folder placement
• Blacklists
• SPF alignment
• DKIM alignment
• DMARC policy
• Reputation
• Sending domain
• Bounce reports

Deliverability should be tested continuously—not just once.

12. Test Accessibility

Emails should be usable by everyone.

Check:

• Alt text on images
• Logical heading structure
• Sufficient color contrast
• Readable font sizes
• Descriptive link text

Avoid:

Click here

Prefer:

View your invoice

13. Validate Tracking

If your emails include analytics:

Verify:

• Open tracking
• Click tracking
• Tracking pixels load
• Analytics events fire
• UTM parameters are correct

Also ensure tracking doesn’t interfere with deliverability.

14. Perform a Final Manual Review

Before shipping, send the email to yourself.

Read it as a real user would.

Ask yourself:

• Would I trust this email?
• Is everything easy to read?
• Does it look professional?
• Does every button work?
• Does every link work?
• Does it render well on desktop?
• Does it render well on mobile?

Small issues become much easier to spot when viewing the final email instead of the template.

How Kurrier Helps

Many of these checks require switching between multiple tools.

With Kurrier, they’re available in one place.

You can inspect:

• Preview — See exactly what the recipient will receive.
• HTML — Review the rendered HTML source with syntax highlighting.
• Plain Text — Verify the text alternative.
• Raw Message — Inspect the complete RFC 5322 email.
• Headers — Analyze SMTP and authentication headers.
• SMTP — Review SMTP conversation details and delivery information.
• JSON — Inspect the normalized email object.
• Delivery — Follow the complete delivery timeline.

Whether you’re debugging a production issue, validating a new transactional email, or reviewing a customer’s reported problem, having every part of the message available in a single interface makes troubleshooting dramatically faster.

Email remains one of the most important communication channels for modern applications, yet it’s often one of the least tested.

A thorough review isn’t just about making an email look good - it ensures messages are delivered, trusted, accessible, and easy to debug when something goes wrong.

Before your next release, walk through this checklist from top to bottom. Spending a few extra minutes validating your emails can save hours of debugging later - and provide a much better experience for your users.

We’re building Kurrier to make email observable—not just deliverable.

Email has become critical infrastructure

Whether you’re running a SaaS product, an ecommerce store, a bank, or an internal platform, email is one of the most important parts of your application.

Password resets.

Invoices.

Deployment notifications.

Security alerts.

Support conversations.

Authentication codes.

Every one of these depends on email working correctly.

Yet when something goes wrong, most teams end up jumping between multiple tools trying to answer one simple question:

What actually happened to this email?

The current workflow is broken

A missing email usually sends developers and support teams down a rabbit hole.

You might check:

• your application logs
• your SMTP provider
• SES or Mailgun dashboards
• raw email source
• message headers
• SPF/DKIM/DMARC
• customer support tickets
• Slack conversations
• browser email clients

Each tool answers a small piece of the puzzle.

None of them tell the complete story.

We think email deserves observability

Infrastructure teams have observability.

Applications have observability.

Databases have observability.

Email rarely does.

Instead of simply showing that an email was “sent,” we want to answer questions like:

• What did the recipient actually receive?
• Which SMTP server handled the message?
• Which route did it take?
• Did authentication pass?
• Was it delayed?
• Was it modified?
• Why did it bounce?
• Who investigated it?
• Was it replayed?

Introducing Kurrier IO

Kurrier started as a collaborative email workspace.

That foundation is still there.

But over the past year we’ve been building something much larger.

Kurrier IO is becoming a workspace for understanding every email.

Instead of switching between five different dashboards, you can inspect everything in one place.

For every message you can view:

• Rendered preview
• HTML
• Plain text
• Raw source
• Headers
• SMTP metadata
• Structured JSON
• Delivery timeline
• Attachments
• Team activity

Built on top of your existing providers

Kurrier isn’t another email provider.

It doesn’t ask you to migrate.

Whether you use:

• Amazon SES
• Mailgun
• Postmark
• SMTP
• Google Workspace

Kurrier works alongside your existing infrastructure.

Your providers stay exactly where they are.

Kurrier simply provides the visibility and tooling that has traditionally been missing.

Built for the people who solve email problems

Kurrier is designed for:

• Developers
• Support engineers
• Platform teams
• DevOps
• Customer support
• Email operations

The people who are asked:

“The customer didn’t receive the email.”

Collaboration when you need it

Sometimes investigating an email is a solo task.

Sometimes it becomes a team effort.

That’s why Kurrier also includes:

• Assignments
• Priorities
• Internal comments
• Activity history
• APIs
• Webhooks
• Automation

Because understanding an email is only half the job.

The other half is resolving the issue.

This is just the beginning

Over the coming months we’ll continue expanding Kurrier’s observability capabilities with richer delivery diagnostics, identity and provider health, replay tooling, and more ways to understand the journey every email takes.

We believe email deserves first-class tooling.

And we’re excited to share what we’re building.

Try Kurrier today → https://www.kurrier.io

Email remains one of the most important communication protocols on the internet, yet the software around it has become increasingly fragmented. One service sends email, another receives it, another stores attachments, another syncs calendars, and another provides a webmail interface. Integrating these pieces often means stitching together multiple providers, APIs, and databases before you can build even a basic email application. We started Kurrier with a simple goal: to bring these capabilities together into a modern, open-source platform that developers can self-host, extend, and build upon.

Why another email platform?

Email is one of the oldest and most successful open standards ever created. SMTP, IMAP, POP3, CalDAV, CardDAV, JMAP, and WebDAV have enabled billions of people and businesses to communicate across providers for decades. The protocols themselves aren’t the problem.

The problem is the developer experience.

If you want to build anything beyond sending an email, you quickly find yourself stitching together multiple products. You might use Amazon SES or Postmark for outbound mail, IMAP for reading messages, CalDAV for calendars, CardDAV for contacts, object storage for attachments, Redis for queues, and several databases to tie everything together. Each component solves a small piece of the puzzle, but very few solutions provide a cohesive platform that developers can build upon.

For most teams, this means spending weeks integrating infrastructure before writing the features that actually matter to their users.

What is Kurrier?

Kurrier is our attempt to change that. Rather than replacing the protocols that already work, we’re building a modern platform around them. Kurrier acts as the glue between SMTP providers, IMAP servers, calendars, contacts, object storage and developer APIs, exposing them through a consistent interface that can be self-hosted or extended as needed.

Whether you’re building an internal company mailbox, a transactional email platform, a customer support inbox, or a complete webmail experience, the underlying infrastructure should already exist. Developers should focus on their application, not on wiring together half a dozen independent systems.

Built on open standards

One of Kurrier’s core design principles is that it should work with the infrastructure you already have.

If your organization already uses Amazon SES, Postmark, Mailgun, SendGrid, Gmail, Microsoft 365, or a traditional SMTP server, Kurrier doesn’t ask you to migrate. Instead, it connects to your existing providers and builds a modern developer platform on top of them.

The same philosophy extends to every other part of the stack. Existing IMAP servers become searchable mailboxes, existing CalDAV servers become calendars, CardDAV servers become contacts, and object storage providers become attachment storage. Rather than inventing new protocols, Kurrier embraces the standards that have proven themselves over decades.

This means you remain in control of your infrastructure while gaining a unified API, a modern web interface, and a consistent data model across every service.

A Modular Architecture

Kurrier is intentionally modular.

Every component can be replaced, extended, or disabled depending on your deployment. Need to use Amazon SES for outbound mail? That’s fine. Prefer your own SMTP server? That works too. Want to sync Gmail, Exchange, or a self-hosted IMAP server? They’re simply different providers behind the same interface.

Internally, Kurrier treats email, calendars, contacts, storage, identities, providers, and APIs as independent services connected through a shared workspace model. This allows developers to build anything from a lightweight webmail client to a complete collaboration platform without being locked into a particular vendor.

At the same time, the entire stack can be self-hosted, making it suitable for organizations that require complete control over their infrastructure and data.

What can you build with Kurrier?

Kurrier isn’t just another webmail client. It’s an application platform for email.

Because every service shares the same workspace, identity, permissions, and API model, developers can build products that would normally require integrating half a dozen different systems.

Some examples include:

• Modern webmail with threading, search, attachments, multiple identities, and shared inboxes.
• Transactional email platforms backed by Amazon SES, Postmark, Mailgun, or your own SMTP infrastructure.
• Customer support systems with routing, labels, assignments, and conversation history.
• Team collaboration tools combining email, calendars, contacts, and file storage.
• Internal company mail systems for organizations that need complete control over their infrastructure.
• Developer platforms exposing every resource through APIs, webhooks, SDKs, and automation.

Whether you’re building an internal tool or the next generation of email software, Kurrier provides the foundation so you can focus on your application rather than rebuilding email infrastructure.

Why open source?

Email is critical infrastructure. We believe infrastructure should be transparent.

Every line of Kurrier is developed in the open. You can inspect the code, deploy it yourself, extend it with plugins, or contribute improvements back to the community.

Open source also means you’re never locked into a hosted service. You own your data, your infrastructure, and your deployment model.

If you simply want a hosted version, we’ll provide that too - but the software itself will always remain available for developers who want full control.

Self-hosted or Hosted - Your Choice

Kurrier is, and will remain, open source. You can deploy it on your own infrastructure, connect it to your existing providers, and customize every aspect of the platform.

For developers and organizations that don’t want to manage their own deployment, we’re also building KurrierMail our fully managed hosted service. It provides the same modern experience without the operational overhead of maintaining servers, updates, backups, or infrastructure.

Whether you choose to self-host with Kurrier.io or use KurrierMail, the goal is the same: give you complete control over your email stack without vendor lock-in.

Learn more about the open-source project at Kurrier.io, or join the waitlist for the hosted platform at KurrierMail.

The Road Ahead

Kurrier is still in active development, but the vision has remained the same from day one: make building modern email applications dramatically simpler.

Over the coming months we’ll be publishing deep dives into the architecture, implementation details, design decisions, and engineering challenges behind the project. We’ll also document how features like Gmail synchronization, IMAP support, full-text search, threading, workspace permissions, CalDAV, CardDAV, and JMAP are implemented.

If you’re interested in building on open standards - or simply curious about how modern email systems work - we’d love for you to follow along.

Welcome to Kurrier.