Email Delivery, End to End | Antoine Weill--Duflos

SMTP Basics

Mon, 29 Jun 2026 00:00:00 +0100

What SMTP is

The Simple Mail Transfer Protocol (SMTP) is the backbone of email. It is the standard that lets mail move between different servers and networks. Think of it as the postal service of the internet: when you send a message, your client hands it to an SMTP server, that server figures out how to route it, the message travels across the internet to the recipient’s mail server, and that server drops it into the inbox.

Just as postal workers follow set procedures to sort and deliver physical mail, SMTP servers follow standardized commands and responses.

The pieces involved

A message passes through several agents on its journey:

MUA (Mail User Agent): your email client, such as Gmail’s web app or Outlook.
MSA (Mail Submission Agent): receives mail from clients and verifies the addresses.
MTA (Mail Transfer Agent): processes and transfers mail between servers.
MDA (Mail Delivery Agent): delivers the message into the recipient’s mailbox.

SMTP itself comes in a few flavors depending on the role a server plays: originating (introducing mail to the internet), delivery (receiving mail for a local mailbox), relay (passing mail along unchanged), and gateway (passing mail and possibly transforming it).

The extensions worth knowing

ESMTP (Extended SMTP) adds features to the original protocol. It opens a session with EHLO instead of HELO and supports extra parameters.
SMTPS secures the connection with TLS or SSL, encrypting the message during transmission.
SMTP-AUTH requires a client to log in with a username and password before sending, which stops strangers from using your server as an open relay.

SMTP is a conversation

Under the hood, SMTP is a back-and-forth of commands and numeric responses, almost like dialogue:

Client: HELO example.com
Server: 250 Hello example.com, pleased to meet you
Client: MAIL FROM: <sender@example.com>
Server: 250 OK
Client: RCPT TO: <recipient@example.org>
Server: 250 OK
Client: DATA
Server: 354 Start mail input; end with <CRLF>.<CRLF>
Client: [Email content...]
Client: .
Server: 250 OK
Client: QUIT
Server: 221 Bye

Each step has a clear role: HELO/EHLO introduces the sending server, MAIL FROM names the sender, RCPT TO names the recipient, DATA carries the message body, and QUIT ends the session. This rigid structure is what makes delivery reliable across wildly different systems.

The important thing to notice for later chapters: nothing in this conversation proves the sender is who they claim to be. MAIL FROM is whatever the client types. That gap is what authentication, the next chapter, exists to close.

Authentication with Alice and Bob

Mon, 29 Jun 2026 00:00:00 +0100

The spoofing problem

When Alice mails a paper letter to Bob, trust is built into the envelope: a return address, recognizable handwriting, and a postal service that knows which mailbox the letter came from. Email keeps none of these. As the previous chapter showed, the MAIL FROM and the visible “From” line are just text the sender fills in. Anyone can write From: alice@example.com without being Alice. This is email spoofing, and it is the foundation of most phishing.

Authentication rebuilds the missing trust signals in a form machines can verify. Three protocols each recreate one physical signal:

Physical world	Email equivalent	What it answers
Approved mailboxes	SPF	Did this come from a server Alice authorized?
A unique wax seal	DKIM	Was the message tampered with in transit?
Handling instructions	DMARC	What should Bob do if a check fails?

SPF: which mailboxes may send for me

SPF (Sender Policy Framework) is Alice telling the post office to only accept letters that come from specific mailboxes. The domain owner publishes a list of authorized mail servers in DNS, and the receiver checks the connecting server against it.

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"

v=spf1 declares an SPF record.
include:_spf.google.com authorizes Google Workspace’s servers. Add more include mechanisms for more providers.
~all is a soft fail for everything else. The stricter -all rejects outright.

SPF is easy to set up and stops mail sent through unauthorized servers. Its weaknesses: it checks only the connecting server, never the content, and it breaks on forwarding, because a forwarded message arrives from the forwarder’s server rather than an authorized one.

DKIM: a seal only Alice can make

DKIM (DomainKeys Identified Mail) is a wax seal only Alice can produce. Her server signs each message with a private key and publishes the matching public key in DNS. The receiver verifies the signature.

selector1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq...IDAQAB"

If the signature verifies, two things are proven: the message came from a holder of the private key, and the signed content was not altered. Because the signature travels inside the message, DKIM survives forwarding where SPF does not. What it does not do alone is decide what happens when a message is unsigned or fails. That needs a policy.

DMARC: instructions and reporting

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the note Alice hands Bob in advance. It tells receivers what to do when SPF or DKIM fails, and it sends reports back to the domain owner.

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

p= is the policy on failure: none (monitor), quarantine (send to spam), or reject (refuse).
rua= is where aggregate reports go.

DMARC’s quietly crucial job is alignment: the domain that passes SPF or DKIM must match the domain shown in the visible “From” address. This closes the hole SPF alone leaves open, where an attacker passes SPF for their own infrastructure while still displaying your domain to the reader.

A safe rollout is to start at p=none, watch the reports until you are sure your real mail aligns and passes, then tighten to quarantine and finally reject.

Why all three

Each protocol covers a gap the others leave:

SPF confirms an authorized server but ignores content and breaks on forwarding.
DKIM confirms integrity and survives forwarding but does not dictate failure handling.
DMARC ties the first two to the visible sender, decides the outcome, and reports back.

Deploy only SPF and an attacker can still forge a convincing message showing your domain in the “From” line. Used together, the three form a layered system far stronger than any one alone. As the next chapter shows, having them configured is also one of the inputs to your domain’s reputation.

Reputation

Mon, 29 Jun 2026 00:00:00 +0100

The credit score of email

Authentication proves who sent a message. It says nothing about whether that sender is trustworthy. That second question is reputation, and it is what decides whether a mailbox provider hands your mail to its users.

Think of email reputation like a credit score. Banks use a credit score to decide whether to lend to you; providers like Gmail, Outlook, and Yahoo use a reputation score to decide whether to trust you with inbox space. Like a credit score, it is built slowly, damaged quickly, and follows you around.

There are two reputations, tracked separately.

IP reputation

The trustworthiness of the specific IP address your mail leaves from. Key factors:

Sending volume and consistency. Steady flow looks legitimate; sudden spikes look like a compromised account.
Complaint rate. How often recipients hit “mark as spam.” The tolerance is very low.
Bounce rate. Both hard bounces (address does not exist) and soft bounces (temporary failures).
Spam trap hits. Mail sent to addresses that exist only to catch senders with dirty lists.
Recipient engagement. Opens, replies, and retention.
Historical sending patterns.

Domain reputation

The trustworthiness of your sending domain regardless of which IP it goes out on. As providers move toward domain-based filtering, this matters more every year. Its factors overlap with IP reputation and add:

Whether authentication (SPF, DKIM, DMARC) is configured at all.
Content quality and relevance.
Engagement metrics.
Domain age and sending history.
Blacklist appearances.

This is the direct link back to the authentication chapter: setting up SPF, DKIM, and DMARC is not only about stopping spoofing, it is also an input to whether providers trust your domain.

Shared versus dedicated IP

One early decision shapes your IP reputation: send from an IP shared with others, or one that is yours alone?

Shared IP pools many senders on one address. It suits low volume (roughly under 100,000 emails a month), inconsistent sending, and tight budgets. The catch is that your reputation is partly hostage to your neighbors on that IP.

Dedicated IP is used only by your organization. It suits high volume (over 100,000 a month), corporate needs requiring whitelisting, and well-maintained lists. The trade-off is that a brand new dedicated IP has no reputation and must be warmed up: volume raised gradually so providers learn to trust it, rather than dumped all at once.

Monitoring and improving

You cannot manage what you cannot see. Useful tools:

Google Postmaster Tools: spam rates, authentication, and delivery errors for Gmail.
Talos Intelligence: IP and domain reputation data.
Sender Score: rates an IP from 0 to 100.
Blacklist monitoring services: alert you if you land on a blocklist.

The improvement playbook is unglamorous and effective:

Implement proper authentication (SPF, DKIM, DMARC).
Use double opt-in so recipients actually want your mail.
Maintain consistent sending volumes.
Clean your lists regularly and reduce bounces.
Work with a reputable email service provider.
Create relevant, engaging content.
Warm up new IP addresses properly.

Deliverability

Mon, 29 Jun 2026 00:00:00 +0100

The sum of everything

Deliverability is the bottom line: consistently landing in the inbox rather than the spam folder or a rejection. It is not a single setting. It is the culmination of every factor in this course working together:

Technical: authentication, infrastructure, and correct configuration.
Reputation: sender history, IP and domain reputation.
Content: message quality, relevance, and engagement.
List hygiene: clean recipient lists and proper bounce handling.

Providers constantly improve their spam filters, which is a challenge even for legitimate senders. A few mechanics deserve their own attention.

Bounces

A hard bounce is a permanent failure: an invalid address or a domain that does not exist. Remove these from your list immediately. Continuing to send to them signals a sender who never cleans house.

A soft bounce is temporary: a full mailbox or a server briefly down. Retry, but drop the address after several consecutive failures.

Keep hard bounce rates below 2 percent and total bounce rates below 5 percent to maintain good deliverability.

Feedback loops

Most large providers (Gmail, Yahoo, Microsoft, AOL, and others) offer feedback loops (FBLs). When a recipient marks your message as spam, the provider notifies you so you can remove that person from your list. Register for them.

Keep your complaint rate below 0.1 percent, which is one complaint per thousand emails. It sounds tiny because it is; complaints are expensive.

Throttling and rate limiting

Sending too much too fast trips rate limits at receiving servers, causing temporary blocks or deferrals. Throttling, deliberately pacing your sends, matters because it:

Avoids overwhelming receiving servers.
Reduces the risk of being flagged as a spammer.
Produces cleaner delivery data to monitor.
Keeps sending patterns consistent.

In practice: implement rate limiting in your infrastructure, adjust to each domain’s limits, retry temporary failures sensibly, and raise volume gradually when warming up an IP.

Best-practice checklist

Technical setup

Implement SPF, DKIM, and DMARC.
Set up reverse DNS (PTR) records.
Use consistent sending infrastructure.
Monitor blacklists and address listings promptly.
Use TLS for transmission.

List management

Use double opt-in for new subscribers.
Clean lists regularly and remove inactive subscribers after re-engagement attempts.
Process unsubscribes immediately.
Segment lists for better targeting.

Sending practices

Maintain consistent volumes and frequencies.
Warm up new IPs properly.
Test before sending to large audiences.
Use a recognizable sender name and reply-to address.

Content

Create relevant, valuable content.
Avoid spam trigger words and excessive punctuation.
Keep a good text-to-image ratio and mobile-friendly design.
Include a clear unsubscribe option.

Security and Encryption

Mon, 29 Jun 2026 00:00:00 +0100

Authentication is not privacy

Everything so far has been about trust and delivery. None of it makes a message secret. An email can pass SPF, DKIM, and DMARC and still be read by anyone who intercepts it. Left unprotected, email faces real threats:

Tampering by anyone with administrator access to a mail server.
Repudiation: a sender denying they sent a message, since mail is easy to fake.
Eavesdropping on unsecured connections.
Privacy invasion: transmission can reveal details like IP addresses.
Unprotected backups: plaintext copies sitting on servers and in backups.
Identity theft: credentials captured if servers are accessed insecurely.

Three layers of protection address these, increasing in both strength and effort.

TLS: the encrypted tunnel

Transport Layer Security wraps the connection between mail servers in an encrypted tunnel, protecting the message in transit. It is the baseline: simple to set up, the recipient needs no special configuration, and it is widely supported. Its limit is that it protects the pipe, not the stored message; once delivered, the mail sits in plaintext on the server.

S/MIME and PGP: end-to-end encryption

When the content itself must be protected end to end, you need message-level encryption.

S/MIME (Secure/Multipurpose Internet Mail Extensions) uses certificates issued by a certificate authority. It is built into many mail clients, provides both encryption and digital signatures, and is popular in corporate environments. Both sender and recipient need certificates set up.

PGP (Pretty Good Privacy) uses public and private key pairs without a central authority. It offers very strong security, has a long track record, and has good open-source options. It also requires both parties to manage keys, which keeps it niche outside technical circles.

How the encryption works

Email encryption transforms readable text into ciphertext that only the right key can decode. Two types are used:

Symmetric encryption uses the same key to encrypt and decrypt. It is fast but requires a secure way to share the key.
Asymmetric encryption uses a public key to encrypt and a private key to decrypt, removing the need to share a secret.

Most systems combine them: asymmetric encryption to exchange a symmetric key securely, then fast symmetric encryption for the message body.

Comparing the methods

Feature	TLS	S/MIME	PGP
Ease of use	High	Medium	Low
Security level	Medium	High	High
Recipient setup	Not required	Required	Required
Corporate adoption	High	High	Low
Protects stored message	No	Yes	Yes

Best practices

Use TLS for all transmissions as a baseline.
Add S/MIME or PGP for sensitive communications needing end-to-end encryption.
Verify digital signatures to confirm authenticity.
Keep private keys secure and never share them.
Use strong passwords and enable two-factor authentication.
Keep clients and security software up to date.
Train users on why encryption matters.

Implementation

Mon, 29 Jun 2026 00:00:00 +0100

From theory to DNS records

This chapter turns the previous ones into a practical setup. The goal is the same for any domain owner: configure SPF, DKIM, and DMARC correctly, protect your primary domain’s reputation, and verify everything works before tightening the rules.

A multi-domain strategy

Organizations often run several domains and more than one email provider, for example a business-mail provider like Google Workspace alongside a bulk-sending service like Mailjet or SendGrid. A sensible split:

Primary domain (for example example.co): business communications and transactional mail through your main provider.
Dedicated sending domain (for example example.com or a subdomain): mass sending (notifications, marketing) through the bulk service.
Spare domains: keep as a backup or redirect to the main domain.

Separating mass sending from your primary domain protects the primary domain’s reputation if a bulk campaign runs into trouble. Each domain needs its own properly configured SPF, DKIM, and DMARC records, even when they point at the same services.

SPF in practice

To authorize two providers on one domain, combine their includes:

example.com  TXT  "v=spf1 include:_spf.google.com include:spf.mailjet.com -all"

include:_spf.google.com authorizes Google Workspace.
include:spf.mailjet.com authorizes Mailjet.
-all is a strict policy that rejects unauthorized senders.

If a domain only sends through the bulk service, simplify it to v=spf1 include:spf.mailjet.com -all. Verify each record with dig TXT example.com or an online SPF validator.

DKIM in practice

DKIM keys are generated per provider, each with its own selector so the public keys do not collide:

selector._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Typical flow with common providers:

Google Workspace: in the Admin console, go to Apps > Google Workspace > Gmail > Authenticate email, generate the record, add it to DNS, then start authentication.
Mailjet: in Account Settings > SPF & DKIM, select the domain, copy the record (often using a mailjet selector, so the record name is mailjet._domainkey.yourdomain.com), add it to DNS, and verify.

DMARC in practice

Start in monitoring mode so you can see what is happening without affecting delivery:

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.co; pct=100;"

This monitors authentication, sends aggregate reports to your address, and applies to all traffic. For a multi-domain setup:

Put identical monitoring records on all domains first.
Analyze reports for two to four weeks to identify every legitimate sender.
Tighten the main business domain toward quarantine then reject gradually.
Move bulk-sending domains to stricter policies faster if all their sending is controlled through one service.
Consider a DMARC report analysis tool to make the reports readable.

After editing DNS, allow time for propagation (up to 48 hours) before expecting changes to take effect.

Application and CRM senders

Systems that send mail on your behalf (an ERP like Odoo, a CRM, ticketing tools) need the same care:

Route them through an authenticated provider.
Set the “From” address to match an authenticated domain, and configure Reply-To correctly.
Consider a subdomain or separate domain for automated system mail.
Test deliverability of generated mail and watch bounce and complaint rates.

Troubleshooting common issues

SPF “too many DNS lookups.” SPF allows at most 10 DNS lookups. Stacking many includes can exceed it. Flatten the record by replacing nested includes with their IP addresses.
DKIM verification failures. Check that the correct selector is used and that the DNS record has no stray line breaks or spaces.
DMARC alignment issues. Ensure the “From” domain matches the domain used for DKIM signing or SPF authentication, which is especially important when sending through third parties.
Third-party senders that cannot authenticate against your root domain. Use subdomain delegation or a dedicated sending domain.

The rollout checklist

For each domain you send from:

Publish an SPF record listing every legitimate sending source.
Enable DKIM signing on each source and publish the matching keys.
Publish a DMARC record at p=none with a reporting address.
Read the reports and confirm your real mail aligns and passes.
Tighten DMARC to quarantine, then reject.
Layer in TLS everywhere, and S/MIME or PGP where secrecy is required.

Treat this as ongoing maintenance, not a one-time task. Sending sources change, providers come and go, and the DMARC reports are what keep you honest.