/ Learn
Technical writing on email infrastructure — IP warming, authentication, bulk sender compliance, monitoring — from the engineers who run this for a living. No marketing fluff, no listicles, no fifteen reasons your emails go to spam. Just the work.
/ Who this is for
These guides are written for the engineer, the deliverability lead, or the operator who's been handed responsibility for an email program and wants to do it correctly. They're concrete, opinionated where the evidence supports it, and honest where the answer is "it depends." Reading them shouldn't require also reading our product page.
Most of the content people find when they search these topics is either thin SEO bait or a thinly-veiled pitch for the author's own product. We aim higher than the first and we resist the second — if a guide mentions our service, it'll be at the end, clearly marked, and only where it's genuinely relevant to the topic.
/ New — Deliverability
The plain-text part is a rounding error next to reputation, authentication, and list quality — include it, then look elsewhere.
An HTML-only email trips a spam rule, but the plain-text part it's missing is a baseline signal, not a magic bullet. What MIME and multipart/alternative are, how the parts nest, what HTML-only actually costs, and what filters really penalize.
Read the guide
/ New — Authentication
The PTR is controlled by whoever owns the IP — your host or ISP, not your registrar.
Reverse DNS is checked before SPF, DKIM, or DMARC — a missing or generic PTR gets your mail rejected at the connection, layer zero of the stack. What PTR and FCrDNS are, who actually controls them, the three-way HELO match, and how to fix 550 rejections.
Read the guide
/ New — Deliverability
The middle digit decides everything: 5.1.x is a bad address to suppress; 5.7.x is a policy block to fix on your side.
A reference for reading email bounce codes: the basic reply code, the enhanced status code, and the human-readable line. What the common 4xx and 5xx codes mean, why a 5.7.x bounce is usually you and not the address, and how to respond to each.
Read the guide
/ New — Authentication
A different layer from SPF, DKIM, and DMARC: those prove who sent the mail; these protect the content in transit.
STARTTLS encrypts email in transit, but a network attacker can strip it away and no one notices. MTA-STS, TLS-RPT, and DANE close that gap by making TLS mandatory. How each works, how they differ, and how to deploy them safely from testing to enforce.
Read the guide
/ New — Deliverability
The most common failure is DKIM not covering both headers — which silently hides the button.
Gmail, Yahoo, and Microsoft require one-click unsubscribe for bulk senders. It's two headers, a DKIM signature that covers them, and a POST endpoint with no friction. The exact syntax, the DKIM gotcha that silently hides the button, and the mistakes that break it.
Read the guide
/ New — Authentication
A body hash mismatch is a mail-flow problem, not a DNS or key problem — don't rotate keys to fix it.
The most-searched DKIM error means your message changed after it was signed — usually a footer, gateway, or mailing list. What the body hash checks, why it breaks, the canonicalization and sign-last fixes, and where forwarding and ARC fit in.
Read the guide
/ New — Deliverability
You can't look up trap addresses — defense is entirely about how you acquire and maintain a list.
Spam traps are addresses no real person uses, planted to catch senders with bad list practices — and one pristine hit can land you on Spamhaus. The three types, how they end up on your list, what a hit costs, and the playbook to avoid them and recover.
Read the guide
/ New — Authentication
A PermError invalidates the whole record — SPF fails for all your mail, not just the extra service.
The SPF 10-lookup limit fails authentication for every message you send the moment you cross it, silently — plus the second 2-void-lookup limit almost nobody knows. How the limit works, how to count your lookups, and the fixes ranked from subdomain delegation to last-resort flattening.
Read the guide
/ New — Authentication
Self-asserted for Yahoo, CMC for the Gmail logo, VMC for the blue checkmark and Apple Mail.
The DMARC-enforcement prerequisite, the SVG Tiny P/S logo, and the VMC-vs-CMC-vs-self-asserted decision that decides whether Gmail, Yahoo, and Apple Mail show your logo. What each provider requires, what it costs, and why logos fail to appear.
Read the guide
/ New — Deliverability
AI content isn't penalized for being AI — it's penalized for the pattern raw output falls into.
Gmail's Gemini added a semantic layer on top of spam filtering, and more than half of spam is now AI-generated. What actually happens to AI-written mail in 2026, why it isn't the AI itself that gets penalized, and how to send AI-assisted email that still lands.
Read the guide
/ 01 — Foundations
Doubling every 2–3 days, target complaint rate <0.1%, hard stop at 0.3%.
A 30-day warming schedule with the real thresholds, the metrics to watch, and the failure modes that derail teams. Written for someone who's moving to dedicated IPs and wants to do it once, correctly.
Read the guide
/ 02 — Foundations
Authentication is the floor; engagement decides the rest.
The full path through SPF, DKIM, and DMARC — why each one exists, how they interact, and the order to ratchet your policy up without locking yourself out of the inbox. Includes the alignment trap that catches most teams.
Read the guide
/ 03 — Compliance
Complaint rate >0.3% is a hard stop across all three providers.
The shared baseline major mailbox providers now enforce: complaint thresholds, one-click unsubscribe, authentication requirements. What's a warning, what's a delivery problem, and how to stay clear of the line as the rules continue to tighten.
Read the guide
/ 04 — Operations
The dashboard you trust is probably lying to you about opens.
Beyond the open-rate dashboard. The signals that predict a placement drop before it happens, the tools that surface them, and how to read Postmaster Tools and SNDS without being misled by Apple MPP-distorted opens.
Read the guide
/ A note on the writing
The email-deliverability internet is full of the same three articles rewritten a thousand times — "10 reasons your emails go to spam," "ultimate guide to email marketing," "everything you need to know about DMARC." They optimize for ranking, not for being useful, and they leave readers no better equipped than before they arrived.
We're not going to do that. The guides on this page are written to be read end-to-end by someone who actually has the problem, and they're long because the problems are. If a guide could be one paragraph honestly, it would be one paragraph. If it needs five thousand words and a couple of tables to be genuinely useful, that's what it is.
The guides exist because some teams genuinely want to do this themselves, and they should have honest writing to learn from. The service exists because other teams would rather not — and would rather have engineers who've done it before do it for them.
Book infrastructure reviewRelated capabilities
