Email Delivery, Volume 2: Reputation, Deliverability, and Encryption

Jun 29, 2026 9 min read Technical Guides

A while back I wrote a guide to email delivery: SMTP, the DNS plumbing, the different kinds of email, and a first look at authentication. That post answered “how does a message physically get from me to you, and how do I prove it is really me.”

This is Volume 2, and it picks up where that left off. Proving who you are (authentication) is necessary but not sufficient. A perfectly authenticated email can still land in spam, still bounce, still be read by the wrong people in transit. So this post covers the parts that decide what happens after authentication passes: reputation, deliverability, and encryption. I will start with a tighter retelling of authentication, because it is the foundation everything else rests on, and then move into the new ground.

Part 1: Authentication, retold with Alice and Bob

When Alice mails a paper letter to Bob, trust is baked into the envelope: a return address, recognizable handwriting, a postal service that knows which mailbox it came from. Email keeps none of that. The “From” line is just text, and anyone can type From: [email protected] without being Alice. That is spoofing, and three protocols exist to rebuild the missing trust signals.

SPF (Sender Policy Framework) is Alice telling the post office which mailboxes are allowed to send on her behalf. She publishes a list of authorized mail servers in DNS, and Bob’s server checks that the message arrived from one of them.

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

DKIM (DomainKeys Identified Mail) is a wax seal only Alice can make. Her server signs each message with a private key, publishes the matching public key in DNS, and Bob’s server verifies the signature. If it holds, the message was not tampered with, and unlike SPF the proof survives forwarding.

DMARC is the note Alice hands Bob in advance: what to do if the mailbox check or the seal fails (deliver, quarantine, or reject), and please send reports. Its quietly crucial job is alignment, requiring that the domain passing SPF or DKIM matches the domain shown in the “From” line. That is what closes the gap SPF alone leaves open.

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

You need all three because each covers the others’ blind spots. If you want the long version, I turned the whole topic into a structured course on email delivery, with a full chapter on the Alice and Bob authentication walkthrough. The rest of this post assumes authentication is handled and asks: now what?

Part 2: Reputation, the credit score of email

Here is the uncomfortable truth that authentication does not solve on its own. You can pass SPF, DKIM, and DMARC perfectly and still have your mail filed under spam. Authentication proves who sent the message. It says nothing about whether that sender is trustworthy. That second question is reputation.

Think of email reputation as a credit score. Banks use a credit score to decide whether to lend to you. Mailbox providers like Gmail, Outlook, and Yahoo use a reputation score to decide whether to trust you with their users’ inboxes. And just like a credit score, it is built slowly, damaged quickly, and follows you around.

There are two reputations in play, and they are tracked separately.

IP reputation

This is the trustworthiness of the specific IP address your mail leaves from. The main factors:

Sending volume and consistency. A steady, predictable flow looks human. A sudden spike looks like a compromised account or a spam run.
Complaint rate. How often recipients hit “mark as spam.” This one is brutal; the threshold for trouble is low.
Bounce rate. Both hard bounces (the address does not exist) and soft bounces (temporary failures).
Spam trap hits. Sending to addresses that exist only to catch senders with dirty lists.
Recipient engagement. Whether people open, reply, and keep your mail.

Domain reputation

This is the trustworthiness of your sending domain regardless of which IP it goes out on. As providers increasingly filter by domain, this matters more every year. Its factors overlap with IP reputation but add:

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

Notice that authentication is a factor in domain reputation. This is the link back to Part 1: setting up SPF, DKIM, and DMARC does not just stop spoofing, it is also one of the inputs to whether providers trust your domain in the first place.

Shared versus dedicated IP

One practical decision shapes your IP reputation from day one: do you send from an IP shared with other senders, or one that is yours alone?

A shared IP pools many senders onto 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 the other senders on that IP. A neighbor sending garbage can drag you down.

A dedicated IP is used only by your organization. It suits high volume, corporate needs that require whitelisting, and well-maintained lists. The trade-off is that you own the reputation entirely, which means a new dedicated IP starts with no reputation and must be warmed up: volume increased gradually over days or weeks so providers learn to trust it, rather than dumped all at once.

Monitoring it

You cannot manage what you cannot see. A few tools make reputation visible:

Google Postmaster Tools reports spam rates, authentication results, and delivery errors for mail sent to Gmail.
Talos Intelligence gives IP and domain reputation data.
Sender Score rates an IP from 0 to 100.
Blacklist monitoring services tell you if you have landed on a blocklist.

The improvement playbook is unglamorous and effective: authenticate properly, use double opt-in so people actually want your mail, keep sending volumes consistent, clean your lists regularly, watch your bounce rate, and write content people engage with.

Part 3: Deliverability, the sum of everything

Deliverability is the bottom line: the ability to consistently land in the inbox rather than the spam folder or a rejection. It is not a single setting you flip. It is the culmination of the technical setup, the reputation, the content, and the hygiene of your recipient list. A few mechanics deserve their own attention.

Bounces, and why you must handle them

A hard bounce is a permanent failure: the address is invalid or the domain does not exist. Remove these from your list immediately. Continuing to send to them is a fast way to look like a spammer who never cleans house.

A soft bounce is temporary: a full mailbox, a server briefly down. Retry, but if it keeps failing across several attempts, drop it too.

The rough thresholds to stay under: hard bounces below 2 percent, total bounces below 5 percent. Cross those and providers start treating you with suspicion.

Feedback loops

Most large providers (Gmail, Yahoo, Microsoft, AOL, and others) offer feedback loops. When a recipient marks your message as spam, the provider notifies you, so you can remove that person from your list. Register for them. The target to stay under is a complaint rate of 0.1 percent, which is one complaint per thousand emails. It sounds tiny because it is; complaints are expensive.

Throttling

Sending too much too fast trips rate limits at receiving servers, causing temporary blocks or deferrals. Throttling, deliberately pacing your sends, avoids overwhelming the far end, reduces the chance of being flagged, and gives you cleaner delivery data to monitor. It is also exactly how you warm up a new IP: start slow, raise volume gradually, and adjust to each provider’s limits.

Part 4: Encryption, because authentication is not privacy

This is the part the first guide did not cover at all, and it is worth being clear about: authentication and reputation are about trust and delivery, not secrecy. A message can be perfectly authenticated and still be readable by anyone who intercepts it. Email, left alone, faces real threats: tampering by anyone with access to a mail server, eavesdropping on unsecured connections, and plaintext copies sitting in backups.

There are three layers of protection, increasing in strength and in effort.

TLS: the encrypted tunnel

Transport Layer Security wraps the connection between mail servers in an encrypted tunnel, so the message is protected in transit. It is the baseline. It is 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 the mail lands, it 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 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. The cost is that 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 set up keys, which is why it stays niche outside technical circles.

Both rely on the same underlying idea: a public key anyone can use to encrypt a message to you, and a private key only you hold to decrypt it. In practice, systems combine asymmetric encryption (to exchange a key securely) with faster symmetric encryption (for the actual message body).

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

The sensible default: use TLS everywhere as a baseline, and add S/MIME or PGP for the communications that genuinely need end-to-end secrecy. Pair that with the unglamorous basics: strong passwords, two-factor authentication, up-to-date clients, and users who know why this matters.

The whole picture

If Volume 1 was “how email works and how to prove it is you,” Volume 2 is “how to make sure it arrives, and arrives safely.” The pieces stack:

Authentication (SPF, DKIM, DMARC) proves who you are and feeds your domain reputation.
Reputation decides whether providers trust you enough to deliver.
Deliverability practices (clean lists, bounce handling, feedback loops, throttling) protect that reputation over time.
Encryption (TLS, S/MIME, PGP) keeps the contents private along the way.

None of these is a one-time setup. Reputation drifts, lists rot, keys expire, and providers keep changing the rules. But understood together, they turn email from something you hope arrives into something you can actually reason about.