Skip to main content

​
Overview

Email delivery is far more complex than it appears on the surface. Between the moment your application triggers a send and the moment a message appears in a recipient’s inbox, multiple servers, protocols, and checks are involved. Understanding this pipeline is essential for diagnosing delivery issues, improving inbox placement, and building reliable email-powered features. This guide walks through every stage of the journey — from API request to inbox.

​
The Email Delivery Pipeline

1

Submission

Your application sends an API request to Lettr containing the recipient address, subject, content, and any additional parameters such as headers, tags, or metadata. Lettr validates the request, checks your account and domain configuration, and accepts the message into its sending queue.
2

Message Assembly

Lettr constructs the full email message. This includes building the RFC 5322-compliant headers (From, To, Subject, Date, Message-ID), encoding the body using MIME (Multipurpose Internet Mail Extensions) to support HTML, plain text, and attachments, and cryptographically signing the message with DKIM using your domain’s private key.
3

DNS Lookup

Lettr queries DNS for the recipient domain’s MX (Mail Exchanger) records. These records specify which mail servers are responsible for accepting email on behalf of that domain and their priority order. If no MX records exist, delivery cannot proceed.
4

SMTP Connection

Lettr opens an SMTP (Simple Mail Transfer Protocol) connection to the highest-priority receiving mail server. The two servers perform a handshake, negotiate TLS encryption when available, and Lettr transmits the message envelope and content.
5

Authentication Check

The receiving mail server verifies the message’s authenticity by checking three authentication mechanisms:
  • SPF — Does the sending IP have permission to send on behalf of the From domain?
  • DKIM — Does the cryptographic signature match, proving the message was not altered in transit?
  • DMARC — Do SPF and DKIM results align with the domain owner’s published policy?
6

Content Filtering

The receiving server scans the message content for spam signals, malware, phishing indicators, and policy violations. This includes checking the sender’s IP reputation, analyzing links and attachments, evaluating engagement history, and applying the mailbox provider’s proprietary filtering algorithms.
7

Delivery Decision

Based on the results of authentication and content filtering, the receiving server makes a final placement decision:
  • Inbox — Message passed all checks.
  • Spam folder — Message is suspicious but not outright rejected.
  • Quarantine — Message is held for administrative review (common in enterprise environments).
  • Reject — Message is refused entirely, generating a bounce.
8

Feedback

After the delivery decision, feedback flows back to Lettr. This includes SMTP response codes during the connection, bounce notifications for rejected messages, and asynchronous signals like opens, clicks, and spam complaints. Lettr processes these events and makes them available through webhooks and your dashboard.

​
Key Protocols

ProtocolPurpose
SMTPThe standard protocol for transmitting email between servers. Operates on ports 25, 465, or 587.
DNS / MXMaps a recipient domain to the mail servers responsible for receiving its email.
SPFA DNS record that lists which IP addresses are authorized to send email for a domain.
DKIMA cryptographic signature embedded in email headers that proves the message has not been tampered with.
DMARCA policy layer that ties SPF and DKIM together and tells receiving servers what to do when authentication fails.
TLSEncrypts the SMTP connection between sending and receiving servers to prevent interception in transit.

​
What Can Go Wrong at Each Stage

The API request may be rejected before the message ever enters the sending queue. Common causes include invalid recipient addresses, missing required fields, unverified sending domains, or account-level rate limits. Lettr returns an immediate error response with details so your application can handle the failure.
If the recipient domain has no MX records, has misconfigured DNS, or if DNS resolution times out, Lettr cannot determine where to deliver the message. These failures typically result in a bounce with a descriptive error. Transient DNS issues may cause Lettr to retry delivery automatically.
The receiving mail server may refuse the connection or reject the message outright. This can happen due to IP blocklisting, the recipient mailbox not existing (hard bounce), or the receiving server being temporarily unavailable (soft bounce). SMTP response codes indicate the specific reason.
If SPF, DKIM, or DMARC checks fail, the receiving server may reject the message or route it to spam. This typically happens when DNS records are not configured correctly for your sending domain. Lettr provides domain verification tools to help you set up authentication properly.
Even with perfect authentication, messages can be flagged as spam based on content characteristics, sender reputation, recipient engagement patterns, or a combination of all three. Spam filtering is the least predictable stage because each mailbox provider uses proprietary algorithms.
The recipient’s mailbox may be over its storage quota or the account may be inactive or disabled. These are typically reported as soft bounces (temporary) or hard bounces (permanent) depending on the provider’s response. Lettr automatically suppresses addresses that repeatedly hard bounce.

​
Delivery vs Deliverability

These two terms are often confused but represent fundamentally different things.
TermMeaning
DeliveryThe message was accepted by the receiving mail server. It did not bounce.
DeliverabilityThe message reached the recipient’s inbox specifically, rather than the spam folder or another location.
A 100% delivery rate does not mean a 100% inbox placement rate. A message can be successfully delivered but still land in spam. Delivery is a technical outcome. Deliverability is a quality outcome.
Improving deliverability requires attention to authentication, sender reputation, list hygiene, content quality, and recipient engagement — not just ensuring messages are accepted by the server.

​
The Role of an Email Service Provider

Sending email directly from your own servers is technically possible, but introduces significant operational challenges. This is why applications use an email service provider like Lettr.

IP Reputation Management

Lettr maintains a pool of sending IPs with established reputations, and provides dedicated IP options for high-volume senders. Building and maintaining IP reputation from scratch takes weeks or months.

DKIM Infrastructure

Lettr handles key generation, rotation, and signing automatically. You configure a single DNS record and Lettr manages the cryptographic operations for every message.

Bounce Handling

Lettr parses bounce responses, classifies them by type, automatically suppresses invalid addresses, and surfaces the data through webhooks and your dashboard so your application can respond.

Compliance

Lettr enforces suppression list processing, provides unsubscribe mechanisms, and handles feedback loops with major mailbox providers — helping you stay compliant with CAN-SPAM, GDPR, and other regulations.
Even if you have the infrastructure to send email yourself, using a dedicated provider lets your engineering team focus on your product rather than on mail server operations and deliverability tuning.

​
Email Lifecycle Events

Every message that passes through Lettr generates a series of events that track its progress from submission to final outcome. These events are available through Lettr webhooks.
EventDescription
Injected / QueuedThe message has been accepted by Lettr and is queued for sending.
DeliveredThe receiving mail server accepted the message.
BouncedThe message was permanently rejected (hard bounce) or temporarily failed (soft bounce).
DeferredDelivery was temporarily delayed and Lettr will retry automatically.
OpenedThe recipient opened the message (tracked via pixel, where supported).
ClickedThe recipient clicked a link in the message (tracked via redirect, where enabled).
ComplainedThe recipient marked the message as spam via their mailbox provider’s feedback loop.
UnsubscribedThe recipient used the unsubscribe mechanism (List-Unsubscribe header or in-body link).
Open and click tracking rely on recipient behavior and client support. Some email clients block tracking pixels or pre-fetch links, which can cause under-counting or over-counting. Do not treat these metrics as exact numbers.

SPF, DKIM & DMARC

Deep dive into the three email authentication protocols and how to configure them.

Bounce Codes Reference

Complete reference of SMTP bounce codes and what they mean for your sending.

Deliverability Best Practices

Actionable strategies for maximizing inbox placement rates.

Sending with Lettr

Get started sending email through the Lettr platform.