Here is the whole diagnostic on one screen. The rest of the article is each check in detail.

Check 1: authentication (the one that bounces now)

Since November 2025, Gmail rejects unauthenticated mail with a 550-5.7.26 error instead of filing it in spam (Google sender guidelines, enforcement documented across the industry in late 2025). Microsoft made the same move for Outlook, Hotmail and Live addresses in May 2025, with a 550 5.7.515 rejection. Partial authentication still lands you in the spam folder: SPF passing while DKIM fails, or both passing on a domain that does not match your From address, which is a DMARC alignment failure.

Test it today. Send a message to a Gmail address you own, open it, choose "Show original" from the three-dot menu, and read the summary table at the top. You want three PASS verdicts: SPF, DKIM, DMARC. Then confirm the DNS from a terminal:

dig TXT yourdomain.com +short
dig TXT _dmarc.yourdomain.com +short

The first should return a record starting v=spf1. The second should return one starting v=DMARC1. Silence on either line is your answer.

The fix: add the SPF include and DKIM records your sending provider lists in its dashboard, then publish a minimum DMARC record (v=DMARC1; p=none; plus a reporting address). Our SPF, DKIM and DMARC walkthrough shows the literal records.

One trap we hit ourselves: forwarding breaks alignment. In June 2026 we watched Gmail reject 73% of the mail we were mirroring through Cloudflare's forwarding, with no error visible on our side. The mail just vanished. We replaced the forward with an API insert and the failures stopped the same day. If your mail passes through any forwarder on the way to its destination, test the full path, not just your DNS.

Check 2: domain reputation (new domains are on probation)

Mailbox providers score your sending domain's history, and a new domain has none. Reputation matures over roughly 4 to 8 weeks, and during that window volume itself is a signal: a fresh domain pushing 5,000 emails on day 3 looks exactly like a spammer cycling through burner domains, because that is who else sends that pattern.

Test it: register your domain in Google Postmaster Tools (free, verified with one TXT record) and read the compliance and spam-rate dashboards. Fair warning: the charts need meaningful daily Gmail volume before they show anything. At dozens of emails a day, ours are mostly blank too. While you are logged in anywhere, run a blacklist check on the domain and your relay's IPs.

The fix is warm-up: start around 150 emails on day 1 and multiply by roughly 1.4 each day, reaching about 1,100 a day by day 7, then grow 10 to 20 percent daily. That curve comes from Resend's documented domain ramp, and it is the one our send path enforces in code. Send to your most engaged recipients first, and keep the cadence steady. Gaps cost progress.

Check 3: your spam complaint rate

Google's bulk-sender rules (in force since February 2024) draw two lines: keep user spam reports under 0.1% of delivered mail, and never reach 0.3%. At or above 0.3%, Gmail withholds delivery mitigation until you have been back under the line for 7 consecutive days. Seven days of spam-foldered mail is a long time for a newsletter.

The math is harsher than it looks at small scale. Three reports on a 1,000-email send is 0.3%. One report on 300 is worse. We work the numbers at every list size in our complaint-rate breakdown.

Test it: the spam-rate chart in Postmaster Tools, same login as check 2.

The fix has two parts. First, make unsubscribing one click, because a hidden unsubscribe converts bored readers into complainers. Stamp both RFC 8058 headers on every campaign:

List-Unsubscribe: <https://yourdomain.com/unsub/TOKEN>, <mailto:unsub@yourdomain.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Second, suppress anyone who complains, immediately and permanently.

Check 4: content triggers

Content filters matter less than reputation, but a few patterns still hurt on their own: image-only emails, link shorteners, a fake "Re:" or "Fwd:" on a first contact, ALL-CAPS subject lines, and HTML with no plain-text part.

Test it: mail-tester.com hands you a one-time address. Send it your actual campaign, not a lorem-ipsum stand-in, and read the score out of 10. We treat that score as a pre-send gate.

The fix: send multipart/alternative with a genuine plain-text part, keep the text-to-image ratio at 60:40 or better, link only to your own domain, keep the From name and address stable, and give every image alt text. None of this is exotic. It is just tedious enough that spammers skip it, which is why filters check for it.

Check 5: list quality

A bounce rate above 2% tells providers the list is scraped, bought, or stale, and stale lists carry spam traps: addresses that exist only to catch senders who never verified consent. Role accounts such as info@ and admin@ complain at far higher rates than personal addresses, and postmaster@ should never be on a list at all.

Test it: divide hard bounces by delivered on your last send. Over 2% means stop sending and clean the list before anything else.

The fix: suppress hard bounces permanently on a suppression list that is applied before every send, retry soft bounces about 3 times over 14 days, require double opt-in, and reject role accounts at signup. Our own playbook makes the last two non-negotiable, because retrofitting hygiene onto a dirty list is much harder than refusing the bad addresses up front.

Check 6: engagement collapse

Mailbox providers weight replies above clicks and clicks above opens. Gmail favors recent engagement, Outlook favors consistent history, and Apple Mail Privacy Protection auto-fetches images, so open rates read high even when nobody is looking (Litmus has tracked this effect since Apple shipped MPP in 2021). A list where most people have ignored you for months drags every future send down, and the damage compounds: low engagement causes spam placement, which causes lower engagement.

Test it: count subscribers with no click or reply in 90 days. If that is most of your list, you have found the problem, and no DNS record will fix it.

The fix: send the next campaign to the engaged segment only, run one winback attempt on the rest, then sunset anyone inactive for 60 to 90 days. A small list that gets read outdelivers a big one that gets ignored.

How to stop emails going to spam: run the checks in order

The order is the diagnosis. Authentication failures reject your mail outright. Reputation and complaint problems bury everything you send for weeks. Content triggers hurt one campaign at a time, and list or engagement rot erodes slowly enough that most senders never connect cause to effect. Start at check 1 tonight: it takes five minutes, it is the only one with a hard cliff, and since November 2025 it decides whether your mail arrives at all.

The protocol was written down by Jon Postel as RFC 821 in 1982; the current specification is RFC 5321, from 2008, and a server from either era could still complete a delivery today. SMTP is the sending half of a working email setup. The reading half is IMAP or POP3, and if you are building mail on your own domain end to end, our business email setup guide puts both halves in order. This article stays on the rail that moves the mail.

The conversation, line by line

An SMTP session is plain text over a TCP connection. You could type one by hand into a terminal, and debugging real delivery problems sometimes still means doing exactly that. Here is a minimal delivery, client lines marked C, server lines marked S:

S: 220 mx.example.com ESMTP ready
C: EHLO mail.sender.example
S: 250 mx.example.com greets mail.sender.example
C: MAIL FROM:<news@sender.example>
S: 250 2.1.0 OK
C: RCPT TO:<pat@example.com>
S: 250 2.1.5 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: From: The Weekly Letter <news@sender.example>
C: To: pat@example.com
C: Subject: Issue 12
C:
C: The body goes here.
C: .
S: 250 2.0.0 OK, queued
C: QUIT
S: 221 Bye

(HELO was the original 1982 greeting; EHLO is its extended replacement and what everything sends today. People still call the whole exchange "the HELO.")

The structural detail worth memorizing is the split between the envelope and the content. MAIL FROM and RCPT TO are the envelope: they are what the receiving server actually uses to route and return the message. The From, To, and Subject lines inside DATA are content, and to SMTP they are just text. Two everyday consequences follow. BCC works because an address can ride on the envelope without appearing anywhere in the headers. And the envelope sender (delivered mail records it as the Return-Path) can be a different address from the From your reader sees. That seam is where bounce handling lives, and it is exactly where email authentication gets bolted on. Hold that thought two sections.

Submission vs relay: 587 vs 25

SMTP does two different jobs on two different ports.

Submission is you handing outgoing mail to your own provider: a mail client with a username and password, or an app with an API key. It is authenticated, always, and it belongs on 587 (formalized for this job by RFC 6409) or 465 (implicit TLS, re-standardized by RFC 8314 in 2018). Use whichever your provider documents; both are fine.

Relay is servers delivering to each other on port 25, and no login exists there. Gmail's MX servers accept mail addressed to Gmail users from any machine on the internet; what varies is how the mail is judged, and the judging is done on the sending IP's and domain's reputation rather than on credentials. This is also why you cannot send mail straight from your laptop: most residential ISPs block outbound port 25 so that infected home machines cannot spray spam, and mailbox providers would distrust a residential IP anyway.

What an SMTP relay service is, and when you need one

An SMTP relay service (Amazon SES, SendGrid, Postmark, Mailgun, Resend) accepts your mail on the submission side, over authenticated SMTP or an HTTP API, and does the port-25 delivery from its own infrastructure: IP addresses with years of accumulated reputation, correct reverse DNS, TLS, bounce processing, and complaint feedback plumbing.

You need one whenever software is the sender. App notifications, receipts, newsletters, and anything else automated all qualify. A human in a mail client already has a relay in effect, because the provider's submission server is one.

The alternative, running your own mail server on port 25, is more workable than vendors admit and worth less than self-hosters hope. The software is a solved problem: Postfix installs in an afternoon. The IP reputation is not. Mailbox providers treat an unknown sending IP as guilty until proven consistent, proving that takes weeks of steady volume, and low volume can never finish the job. We made this exact call for our own workspace and send through a relay; our position is that below tens of thousands of emails a month, self-hosting the sending rail buys you deliverability risk and nothing else. Our send path also enforces a warm-up throttle on top of the relay: roughly 150 sends on day one, raised by about 1.4x daily toward about 1,100 by day seven, capped at whatever the relay allows, which for us is 95 a day. That is Resend's documented domain ramp, and we codified it into the send path so nobody can skip it on launch day. The rest of that policy lives in our email deliverability handbook.

SMTP verifies nothing: why SPF exists

Look back at the transcript. Nothing checked whether the client was allowed to say MAIL FROM:<news@sender.example>. Any connected machine can claim any envelope sender, and in 1982, among a few hundred cooperating research hosts, that was a reasonable design. On the open internet it is an open door, and spam and spoofing walked through it.

Authentication was retrofitted next to the protocol, in DNS, rather than inside it:

• SPF (RFC 7208, published April 2014) lets a domain publish the list of IP addresses allowed to use it in MAIL FROM. Note the envelope-content split from earlier: SPF checks the envelope sender, not the From header.
• DKIM signs the message with a key published in DNS, so altered or forged content fails verification.
• DMARC ties both checks to the From header the reader actually sees and tells receivers what to do on failure.

We explain how the three interlock in SPF, DKIM and DMARC, and the SPF record syntax gets its own walkthrough. What you should carry out of this article is the deadline: Gmail (November 2025) and Microsoft (May 2025) now hard-reject unauthenticated mail with a 550 instead of quietly spam-foldering it. Authentication stopped being extra credit.

One first-hand number on what breakage looks like. Forwarding re-sends a message from the forwarder's IP, which is not in the original domain's SPF record. In June 2026 we measured Gmail rejecting about 73% of the mail we were mirroring into a Gmail mailbox via Cloudflare's forwarding, and it happened silently: no bounce reached anyone, the mail just never arrived. We replaced forwarding with an API insert the same week. If forwarded mail is vanishing somewhere in your setup, broken authentication on the forwarding hop is the first suspect, and why emails go to spam has the fuller diagnostic list.

Reading SMTP errors: 550, 421, 535

Every server reply starts with a three-digit code, and the first digit does most of the work: 2xx means done, 3xx means continue, 4xx means temporary failure (retry later), 5xx means permanent failure (stop and fix something). Modern servers append an enhanced code, like 5.7.26, plus human-readable text, and the text is usually worth reading.

The bounce-handling rule that falls out of this table: a 5xx on a recipient is a hard bounce, and that address should never be tried again. Our own send path suppresses hard bounces permanently and retries soft (4xx) bounces about three times over 14 days before giving up; the distinction matters enough that hard bounce vs soft bounce gets its own article.

You will probably never type MAIL FROM by hand outside a debugging session, and that is fine. The layer is still worth knowing, because every delivery problem you will ever have is legible from here. When something bounces, read the three-digit code first: 4xx says wait, 5xx says fix. And before real volume leaves your domain, publish SPF, sign with DKIM, and set a DMARC policy, because since November 2025 the alternative is a mailbox full of 550s.

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489, published 2015) is one leg of the trio we cover across our deliverability handbook. If SPF and DKIM are new to you, start with how the three records work as one system; this article assumes both are set up and goes deep on the enforcement layer.

What the record looks like

DMARC lives at the _dmarc label of your domain:

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; sp=quarantine; adkim=r; aspf=r"

The tags that matter, in practice order:

A minimal starting record is just three tags: v=DMARC1; p=none; rua=mailto:you@yourdomain.com.

What DMARC actually checks

DMARC passes a message when at least one of two things is true: SPF passed and the Return-Path domain aligns with the From domain, or DKIM passed and the signature's d= domain aligns with the From domain. Alignment is the whole point. It welds the hidden authentication identities to the address your reader sees, which is the address phishers forge.

One aligned pass is enough. A message that fails SPF outright (every forwarded message does) still passes DMARC on an intact DKIM signature. That redundancy is deliberate, and it is why you set up both before you enforce anything.

The DMARC policy levels, honestly

p=none is monitoring mode. Failing mail is delivered as if DMARC did not exist, but receivers send you reports. This is where everyone starts, and where a great many domains quietly stay forever. A permanent p=none protects nobody; it just watches.

p=quarantine sends failing mail to spam. Real consequences, but recoverable: a misconfigured legitimate sender lands in spam folders instead of vanishing, and someone eventually tells you.

p=reject refuses failing mail at the door. This is the goal state and the only policy that actually stops your domain being spoofed, because quarantined phishing can still be fished out of a spam folder by a curious reader. The cost: your mistakes become invisible. Rejected mail does not bounce to anyone you control, it is simply gone. We saw this from the receiving side in June 2026, when Gmail enforced sender policies against mail we were forwarding and silently refused 73% of it. No error reached us. Silence is exactly what rejection looks like, which is why you do not publish p=reject on hope.

Quarantine vs reject, in one rule

Quarantine while humans can still catch your mistakes; reject once the reports prove there are no mistakes left to catch. If your reports have been clean for a month, quarantine is just reject with extra steps and a worse spoofing story.

The road to p=reject: a project plan with exit criteria

The failure mode with DMARC is not technical, it is organizational: someone flips p=reject in an afternoon and the CRM, the invoicing tool, and the CEO's newsletter all stop delivering. Run it as four phases and do not leave a phase until its exit criteria hold.

Phase 2 is where the actual work lives. The reports will surface senders you forgot existed: the support desk, the survey tool, the office printer that emails scans. Each one either gets authenticated, replaced, or consciously cut off. Budget four to ten weeks for the whole run at a small company, longer if procurement owns your DNS.

Reading a DMARC report (rua)

Aggregate reports are XML files, usually zipped, mailed to your rua address by each receiver roughly daily. Gmail, Yahoo, and Microsoft all send them. A report contains no message content: it is rows of source IPs with counts and results. The heart of one looks like this:

<record>
  <row>
    <source_ip>203.0.113.7</source_ip>
    <count>412</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim><domain>example.com</domain><selector>s1</selector><result>pass</result></dkim>
    <spf><domain>bounce.mailer.net</domain><result>pass</result></spf>
  </auth_results>
</record>

Read this one carefully, because it shows the distinction that confuses everyone. Under auth_results, SPF shows pass: the sending server was authorized for bounce.mailer.net, its Return-Path domain. Under policy_evaluated, SPF shows fail: that passing domain does not align with example.com, the From domain, so it counts for nothing. DKIM passed with an aligned domain, so the message passed DMARC. This is an ESP sending on your behalf with DKIM set up correctly and SPF alignment absent, which is normal and fine.

Read two or three reports raw so the structure sticks. Then stop. At any real volume you will receive dozens of files a day from different receivers, and the job is aggregation across weeks, not file reading. Use a parser: Postmark runs a free weekly digest service (still free as of mid-2026) that turns the XML into a readable email, and paid dashboards from the DMARC vendors add history and source labeling. There is no prize for hand-parsing XML.

What you are looking for in the aggregate: sources with volume that you cannot name, legitimate sources failing alignment, and, once you enforce, any disposition of quarantine or reject applied to mail that was actually yours.

What p=reject requires of you

Prerequisites, all of them, before the final flip:

• DKIM signing on every legitimate sending source, with 2048-bit keys where your providers support them.
• SPF covering every source, kept under the 10-lookup limit so it does not permerror into uselessness.
• A subdomain decision: sp= inherits your policy to subdomains, so either authenticate mail from subdomains too or set their policy explicitly.
• A monitored rua mailbox and a calendar habit of reading the digest, because vendors change IPs and colleagues add tools without telling you.
• Four or more clean weeks at quarantine.

Publish p=none with a rua address this week; it is one TXT record and it costs you nothing. Then work the phase table. A domain that reaches p=reject with clean reports has done more for its deliverability than any warm-up trick, and it has made itself worthless to every phisher who tries to borrow its name.

DKIM is the second leg of the authentication trio we map out in our deliverability handbook, and the counterpart to SPF, which authorizes sending servers by IP. SPF authenticates the connection; DKIM authenticates the message. The distinction sounds academic until a message leaves the original connection behind, at which point SPF has nothing to say and DKIM keeps working.

What the signature actually covers

A common misreading: DKIM does not sign "the email." It signs a hash of the body plus a hash over an explicit list of headers, and only what is listed is protected.

The signer computes a hash of the message body and stores it in the signature's bh= tag. It then builds a second hash over the headers named in the h= tag, in order, with the signature itself appended, and signs that with the private key to produce b=. RFC 6376 requires exactly one header in the list: From. Everything else is the signer's choice, and good signers include Subject, Date, To, and the MIME headers, because an unsigned header can be altered or added in transit without breaking the signature.

Two details worth knowing before you read your first header:

Canonicalization (c=) decides how forgiving verification is about whitespace and header formatting. relaxed/relaxed tolerates the folding and re-wrapping that real mail servers do to messages in flight; simple breaks if a single space changes. Sane platforms default to relaxed/relaxed, and this choice is a big part of why modern DKIM usually survives intermediate hops.

The l= tag limits the body hash to the first N bytes, letting anyone append content to a signed message without invalidating it. It exists for mailing-list compatibility and it is a hole. If your platform sets l=, ask why.

Selectors: what s1._domainkey means

The public key does not live at a fixed address. The signature's s= tag names a selector, and the receiver queries:

<selector>._domainkey.<domain>    TXT

So s=s1 with d=example.com sends the verifier to s1._domainkey.example.com. The names are arbitrary and every platform picks its own convention: Google Workspace uses google, SendGrid uses s1 and s2, Microsoft 365 uses selector1 and selector2. When a provider hands you two or three CNAME records at setup, those are selector records delegating the key lookup to infrastructure they control, which lets them rotate keys without asking you to touch DNS again.

Selectors are the mechanism behind two things you want. First, multiple simultaneous senders: your mail host signs with one selector, your newsletter ESP with another, each verifying against its own key, no coordination required. Second, rotation: publish a new key at a new selector, switch signing to it, and retire the old one later, with zero downtime.

The record itself looks like this (chunked, for reasons in the next section):

s1._domainkey.example.com.  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC...IDAQAB" )

The p= value is the base64 public key. An empty p= is the standard way to say a key is revoked.

Key length: 2048 in 2026

Use 2048-bit RSA keys. The floor is 1024: Google's sender guidelines require at least 1024 bits and recommend 2048, and NIST deprecated 1024-bit RSA for signatures back in 2013. RFC 8301 (2018) updated DKIM's algorithm rules to match, requiring verifiers to handle keys from 1024 to 2048 bits and retiring SHA-1 signing outright. In 2026 there is no good reason to generate a new 1024-bit key, and several deliverability platforms now flag them in audits.

One operational consequence of 2048: the base64 public key no longer fits in a single 255-character TXT string, so the record must be split into two quoted strings that resolvers concatenate. Most DNS providers handle the split automatically; a few older panels do not, and the failure is silent, so after publishing, always verify with:

dig +short TXT s1._domainkey.example.com

If the output is empty or visibly truncated, your panel mangled the split.

Rotation: the honest version

M3AAWG (the industry working group on messaging abuse) recommends rotating DKIM keys at least every six months. The honest observation from running mail: most small senders never rotate, and nothing visibly breaks, because a DKIM private key leak is a quiet, low-probability event. That is precisely the argument for making rotation somebody else's job. If your signing runs through a provider that manages keys behind delegated CNAMEs, rotation happens without you. If you hold your own keys, the parallel-selector method is the whole trick: generate a new key, publish it at s2, switch signing to s2, leave s1 published for at least a week so in-flight mail still verifies, then blank its p= value.

How to read a DKIM header

Open any message in Gmail, choose Show original, and find the DKIM-Signature header. A representative one:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=example.com; s=s1; t=1718200000;
        h=from:to:subject:date:mime-version:content-type;
        bh=4bRPuiVJrcsFY2Vd8MLtaCvMc3F7dQ38rapUqzHTGjY=;
        b=KxLZY0vN3q...

Read it in this order: d= is the domain claiming responsibility, s= is the selector (so the key is at s1._domainkey.example.com), a= is the algorithm (rsa-sha256 is the modern standard; treat rsa-sha1 as broken), c= is canonicalization, h= is the list of protected headers (check From is there; check Subject is too), bh= is the body hash, and b= is the signature itself. The t= tag is the signing timestamp. Gmail summarizes the verdict at the top of the same view: DKIM: PASS with domain example.com is what healthy looks like.

The d= domain is the one to squint at. A pass means that domain signed the message. It does not mean that domain matches the From address your reader sees.

Why a DKIM pass alone proves little

Any domain can sign any message. A spammer signing with d=spammer-infra.net gets a perfectly valid DKIM pass while displaying your domain in the From line. The pass is real; it just vouches for the wrong party. What closes the gap is alignment, enforced by DMARC: the signature counts only when its d= domain matches the visible From domain. DKIM is the strongest link in the chain, and it still needs the chain; the full picture of how the three records interlock is in our SPF, DKIM, and DMARC overview.

Survivability is what earns DKIM its keep. When Gmail was rejecting 73% of the mail we forwarded to an archive in June 2026, the mechanism was exactly this split: forwarding rewrites the sending IP, so SPF failed on every forwarded message, and only a message with an intact, aligned DKIM signature had any remaining way to pass DMARC. The signature rides inside the message; the connection details do not.

So: confirm every service that sends for you signs with your domain in d=, check the key length on your active selectors with a dig (a p= value around 220 characters is a 1024-bit key worth replacing; around 390 is 2048), and put a note in the calendar to rotate anything you self-manage. Then send yourself a test and read the header you just learned to read.

This article defines the term and draws the lines around it. The sending mechanics (separate domains, warm-up ramps, daily caps) live in our cold email infrastructure guide, and the statutes get a full treatment in is cold email legal.

The definition, drawn precisely

"Cold" describes the relationship. The recipient never subscribed, never bought anything, and would not recognize your name in the From line. The message is commercial: you want a reply, a call, a trial, an introduction. And it is individual. You picked this person after looking at what they do, and the email should prove it.

Sales teams call the practice outbound prospecting. Recruiters sourcing candidates, founders recruiting design partners, and freelancers pitching editors run the same play under different names.

Three neighbors it gets confused with. A newsletter goes to people who asked for it. A transactional email, like a receipt or a password reset, goes to people who triggered it. Spam goes to whoever a scraper found. Cold email sits in the fourth quadrant alone: unasked for, but aimed.

Cold email vs spam: the three lines

Consent separates neither category, because both arrive uninvited. The separation happens on relevance, identification, and the out.

The legal line runs close to that table. CAN-SPAM requires truthful headers and subject lines, a physical postal address, and an opt-out honored within ten business days, and it prices violations per email. The practical line is stricter, because mailbox providers count complaints instead of reading statutes. Gmail's bulk-sender rules, published February 2024, set a spam-complaint target under 0.1% and a hard ceiling at 0.3%; cross the ceiling and Gmail withholds delivery help until you stay under it for seven consecutive days. Our own send path pauses automatically at those exact thresholds, because stopping a campaign is cheaper than a week of earning back trust.

Cold email vs cold calls vs ads

The three ways to reach a stranger have different cost structures, and the differences decide when each one makes sense.

The row that matters is failure cost. Ads waste money and calls waste time, but both losses stop when you stop. Cold email failure compounds: spam complaints degrade the domain that carries the rest of your mail. That asymmetry is why this cluster spends an entire article on setting up a separate outreach domain.

When it works, and when it cannot

Cold email works when three conditions hold at once. The target is a business, so the address is professional and the message concerns the recipient's job. The deal size pays for research, because ten minutes per prospect only makes sense when a closed deal is worth thousands. And the sender is a human who can hold the conversation a reply starts. Send fifty researched emails, not five thousand scraped ones.

It cannot work as consumer marketing. Law is one reason: Canada's CASL requires consent before commercial email, and Germany reads its ePrivacy rules the same way. Arithmetic is the other. A 0.3% complaint ceiling means three complaints per thousand delivered messages, and consumers who have never heard of you tap "report spam" without a second thought. Three annoyed strangers per thousand. No purchased consumer list survives that ceiling for long. Cold email to consumer inboxes at scale is spam, whatever the tool selling it to you calls it.

One myth worth retiring: Gmail defines a "bulk sender" as 5,000+ messages a day, and small senders read the number as an exemption. It is the threshold for extra requirements like one-click unsubscribe. The authentication and complaint rules apply at any volume, and we follow them at dozens of messages a day.

The anatomy of a legitimate cold email

Every line of a defensible cold email does one of three jobs: identify you, deliver the reason, or offer the out. The example below is ours, written for this article; both companies and the postal address are invented.

From: Maya Chen <maya@brightloop-hq.com>
Subject: Question about Ridgeline's onboarding queue

Hi Sam,

Your careers page lists four support hires this quarter, which
usually means the onboarding queue is growing faster than the team.

Brightloop automates the account-provisioning half of that queue.

Worth a 15-minute look, or is onboarding not your side of the org?

If you would rather not hear from me again, say so and I will stop.

Maya Chen, Brightloop
2201 Fourth Ave, Suite 900, Seattle, WA 98121

Identification is the From line, the signature, and the postal address; the address is a CAN-SPAM requirement, and a registered PO box satisfies it. Value is the middle: one observed fact about the recipient, one plain sentence about what you do, one small question. The out is the sentence near the end, and it must be honored the moment someone uses it. On newsletter sends our workspace stamps RFC 8058 one-click unsubscribe headers automatically; a one-to-one cold email carries its out as a sentence instead, but the discipline behind both is identical. Whoever says stop goes onto a suppression list that is checked before every future send and never expires.

Notice what the example omits. No "hope this finds you well." No attachment. No fourth paragraph. It runs four sentences because the reader decides in two.

Where to start

Work these in order:

1. Rules first. Confirm what your target countries require. The legal article linked above covers CAN-SPAM, GDPR, and CASL in operator terms.
2. Domain second. Buy a separate outreach domain and publish SPF, DKIM, and DMARC on day one. The domain article linked above walks the checklist in order.
3. Volume third. Set a daily cap before the first send. How many cold emails per day publishes the caps math from our own throttle policy.
4. Copy fourth. Start from working cold email templates and spend most of your effort on the subject line, which decides whether anything else gets read.
5. Persistence fifth. Most replies arrive after the follow-up, so plan the sequence before message one goes out.

Copy sits at step four on purpose. A perfect email from an unauthenticated domain never reaches the inbox it was written for.

The output is a single JSON file: 14 providers besides our own, 87 published plans, 73 named sources, and the cost of each product computed at 1, 5, and 10 seats and at 500, 1,000, 5,000, and 10,000 subscribers. Every price table you see on this site renders from it, stamped with the date it was checked. This post is what the exercise taught us.

What we actually did

For each provider we opened the live pricing page and transcribed every plan: name, monthly price, annual-billing effective price, unit, and the limits attached. Where the page was rendered in JavaScript we read the data the page itself loads, which is more reliable than the rendered text. Kit's price ladder came out of its pricing bundle, beehiiv's out of the widget behind its slider, MailerLite's out of the USD matrix in the page source, Brevo's out of the billing API its calculator queries, and Zoho's out of the JSON feed that renders its table.

Then we normalized. Prices are US list prices in USD, annual-billing effective where annual billing exists, and the plan we price is the cheapest one that can actually do the job rather than the cheapest one on the page. Introductory promotions are excluded, because month 13 is the price you live with. For each provider we also wrote down four things it genuinely does better than we do and four things that genuinely cost its customers money, from the provider's own documentation.

Two things we could not get, stated plainly. Enterprise pricing does not exist in public anywhere: Google Enterprise, beehiiv Enterprise, Brevo Enterprise, Ghost Custom, and SendGrid Premier are all quote-only. And Constant Contact's pricing page returns HTTP 403 to automated fetches, so its tiers are the one set in the file cross-checked against three independent sources rather than read from the source, all updated between June 16 and June 30, 2026.

Six things that surprised us

1. The two suites have converged on identical numbers

Google Workspace charges $7, $14, and $22 per user per month on annual billing for Business Starter, Standard, and Plus. Microsoft 365 Business charges $7, $14, and $22 for Basic, Standard, and Premium. Microsoft only arrived there on July 1, 2026, when Basic went from $6 to $7 (up 16%), Standard from $12.50 to $14 (up 12%), and Apps for business from $8.25 to $10 (up 21%). Premium was already $22.

Two companies competing this hard do not land on the same three numbers by coincidence. It reads as a price umbrella, and it means the suite decision is genuinely about the bundle rather than the bill. The tier-by-tier math is on our Google Workspace pricing page, and Google Workspace vs Microsoft 365 referees the choice.

2. Flexibility has a published price, and it is 20%

Google's Flexible plan is exactly 20% above the annual rate: $8.40, $16.80, and $26.40 against $7, $14, and $22. Microsoft's month-to-month rates are the same $8.40, $16.80, and $26.40. Microsoft then adds a second lever most buyers never see: since April 1, 2025, paying an annual-term subscription in monthly installments carries a 5% surcharge. So there are three prices for the same seat, not two.

The rest of the field is all over the map. Zoho's Mail Lite and Premium have no monthly option at all, only 12 months prepaid per seat. Kit's annual plan is exactly ten times the monthly price, so a year of monthly billing costs 20% more. beehiiv's annual is 12% off, MailerLite's and Brevo's are 10% off, and Klaviyo, Buttondown, SendGrid, and Mailchimp publish no annual rate at all. When a comparison article quotes prices without saying which billing basis it used, the numbers are worth nothing.

3. Two providers bill you for people you cannot email

Mailchimp counts subscribed, unsubscribed, and non-subscribed contacts toward your billable total and never archives anyone automatically. SendGrid's Marketing Campaigns bills stored contacts, unsubscribed ones included. Everyone else we checked excludes them: Kit bills unique active subscribers, beehiiv bills active subscribers only, Klaviyo drops suppressed profiles from the count, MailerLite excludes unsubscribed and bounced addresses, Constant Contact confirmed in its own community that unsubscribes are not billed, Buttondown bills active subscribers, and Ghost and Substack do not price on this axis at all.

The money is not theoretical. On Mailchimp Essentials the difference between the 2,500-contact tier and the 5,000-contact tier is $45 against $75 a month, so a few hundred dead contacts can cost $360 a year for nothing. Our Mailchimp pricing teardown walks that example. If you take one action from this post, go archive your unsubscribes.

4. Substack's cut outgrows every flat plan in the set

Substack has no plan ladder to transcribe, which made it the strangest row to build. A free publication costs $0 at any list size. The bill starts when the revenue does: 10% to Substack, plus Stripe's 2.9% and $0.30 per transaction, plus a 0.7% Stripe Billing fee.

On a $5-a-month subscription, the minimum Substack allows, that stack takes $0.98, an all-in rate of 19.6%. Two hundred and fifty paying readers gross $1,250 a month and hand back about $245 of it. At $5,000 a month of paid revenue, the platform cut alone is $500 a month, more than the priciest published beehiiv plan ($459 at 100,000 subscribers) or Ghost plan ($399 a month at 100,000 members on annual billing), both of which take 0% of subscription revenue. The 10% has not moved since 2017. Full arithmetic on our Substack pricing page.

5. Deliverability is an upsell nearly everywhere

This is the finding that hit closest to home. Across the set, the things that actually keep mail out of spam are sold as line items. Brevo charges $251 a year for a dedicated IP and $12 a month to remove its logo from your emails on the Starter plan. SendGrid gates email validation to its Pro tier and charges $30 a month per additional IP. Constant Contact sells inbox preview as a $10-a-month add-on. Buttondown puts dedicated IPs on the $79 Professional plan, and beehiiv reserves them for quote-only Enterprise.

There is a whole product category selling the ramp itself, which we priced separately in the best email warm-up tools. Our position is that a warm-up schedule is not a product, it is a throttle: ours computes roughly 150 sends on day one, multiplying by about 1.4 a day to around 1,100 by day seven, enforces whichever is lower of that curve and the relay ceiling (95 a day on our current plan), and pauses the send path entirely at a 0.3% complaint rate or 2% bounce rate. If you want the mechanics rather than the pricing, we wrote up how email warm-up actually works.

6. The free tier you remember probably shrank or died

Three of the best-known free plans in email changed inside seven months. SendGrid's forever-free 100 emails a day was retired on July 26, 2025, and new accounts now get a 60-day trial and then a bill. MailerLite's free plan went from 1,000 subscribers to 500 in September 2025 and then to 250 subscribers and 2,500 emails a month. Mailchimp cut its free plan from 500 contacts and 1,000 sends to 250 contacts and 500 sends, effective February 17, 2026.

Generous free tiers do still exist, with a catch attached to each. Kit is free to 10,000 subscribers but withholds automations, sequences, and integrations. beehiiv is free to 2,500 active subscribers, and then the next stop is $89 a month on monthly billing, which is roughly a $0 to $1,000-a-year step for one subscriber. Brevo's free plan stores 100,000 contacts but caps sending at 300 a day, so a single blast to 1,000 people cannot go out. Zoho hosts five users free but blocks IMAP and POP, so no desktop mail client can connect.

The whole field: an email pricing comparison in one table

Annual-billing effective prices where offered. Checked August 7, 2026.

Tell us when a number drifts

Every one of these numbers has a shelf life, and the past year suggests that shelf life is short. Four providers raised prices in twelve months. Three cut free tiers. Two renamed their entire plan lineup, which is why third-party pricing articles written before June 2026 quote MailerLite plans that no longer exist and Kit prices from before the October 2025 increase.

So the tables on this site carry the date they were checked, our sources are listed on each pricing page, and one of the products in the dataset is ours and is labeled every time it appears. There are no affiliate links anywhere here, which is the only reason we can put Zoho at $1 a seat next to our $50 and let you draw the obvious conclusion for a five-person team.

If a price on this site is stale, wrong, or missing a fee we did not spot, tell us. Our editorial page has the correction policy and the address to send it to, and corrections get made in the dataset, which means every table on every page updates at once. That is the whole reason we built it as data instead of prose.

This article assumes people can already subscribe to you. If you are still wiring that up, start with our guide to running a newsletter on your own domain and come back for this part.

The three jobs of a welcome email

A welcome email that works does three things. Everything else is decoration.

First, deliver the promise. If the signup form offered a guide, the guide is the first line, not paragraph four. If it offered a weekly digest, hand over the best of the archive right now so the subscriber gets value before the first scheduled issue. An empty "thanks for subscribing" wastes the one send with guaranteed attention.

Second, set expectations. What arrives, how often, from which address. A subscriber who knows the Tuesday issue is coming does not mark it as spam on Tuesday. Asking them to add your address to their contacts is worth one line here; a contact add is a small positive signal and it costs nothing to ask.

Third, ask for a reply. One question, specific and easy. This is the deliverability play, and it is the part most welcome emails skip. Mailbox providers rank engagement in a clear order: replies above clicks, clicks above opens. A reply tells Gmail this sender is a correspondent, not a broadcaster, and that judgment matters most in the first weeks, while a new domain's reputation is still forming (reputation on a fresh domain matures over 4 to 8 weeks). "Let me know your thoughts" gets no replies. "What made you subscribe today?" gets some, and you only need some.

Send it instantly, from an address that answers

Timing is simple: the welcome fires the moment the subscription completes, not in tonight's batch. Fifteen minutes later the person has moved on and your carefully written email is just another unread row.

The From address matters more than most people think. Never send a welcome from noreply@. It contradicts the email's own reply prompt, and a subscriber who replies anyway gets a bounce as their first interaction with you. Use a real address: hello@, yourname@, editor@. On LetterDuck an address is a routing rule, not a paid seat, so a dedicated hello@yourdomain costs nothing, and replies thread into a shared inbox where you answer as that address.

Double opt-in makes it a two-part welcome

If you confirm subscriptions (we think you should, and we wrote out the double opt-in math separately), the welcome becomes two emails with two different jobs. Part one is the confirmation: one sentence, one button, no marketing. Part two is the welcome proper, and it fires the instant the confirmation click lands. Do not merge them. An unconfirmed address might be a typo or a bot, so welcome content is wasted on it, and anything you add to the confirmation dilutes its single job, which is the click.

Five welcome emails, written by us

The usual "welcome email examples" post is screenshots of other companies' mail. These five are originals we wrote for the newsletter shapes we see most, in the plain register we argue for in how to write a newsletter. Steal any of them.

1. The personal essay newsletter

Subject: You're in. Here's the deal.

You subscribed to [Name], so here is exactly what that means.

One essay, most Fridays, usually about [topic]. No roundups,
no sponsor breaks between paragraphs. When I have nothing
worth your time, I skip the week.

Start with the piece people share most:
[link to your best essay]

One question before you go: what made you subscribe today?
Hit reply and tell me. I read everything.

[Your name]

The cadence carries an honest escape clause. "I skip the week" builds more trust than an "every Friday" you will not keep. One link, one question, done.

2. The curated links digest

Subject: Welcome. Your first five links are inside.

Every Tuesday: five links on [niche], each with two sentences
on why it matters. Fifteen minutes of reading, tops.

So you don't have to wait a week, five from the archive:

- [Link]: one line on why it mattered
- [Link]: one line
- [Link]: one line
- [Link]: one line
- [Link]: one line

Reply with the best thing you read this month and it might
make next Tuesday's issue, credited to you.

[Name]

A curation newsletter can deliver its product inside the welcome itself, so it should. The reply prompt doubles as sourcing.

3. The indie product changelog

Subject: Subscribed: [Product] updates, monthly-ish

You'll get an email when we ship something worth telling you
about. In practice that is about once a month. No feature
votes, no "we've been quiet lately" filler.

Last month we shipped [feature]: [one line on what it does].
Full changelog: [link]

What is the one thing [Product] doesn't do that you wish it
did? Reply and it goes straight into the planning doc.

[Founder name], [Product]

"Monthly-ish" is an honest cadence for a changelog, and the reply prompt is roadmap research you would otherwise pay for.

4. The local newsletter

Subject: Welcome to [Name]. First question: where do you live?

Twice a week, everything worth knowing in [town]: council
decisions, openings and closings, and the stories the
regional paper skips.

Reply with your neighborhood and I'll keep a closer eye on
it. Not a gimmick: half our best stories start as reader
replies.

While you wait for Thursday's issue, the three most-read
stories this year: [links]

The reply prompt sits in the subject line itself. A local newsletter runs on reader tips, so the deliverability signal and the editorial engine are the same mechanism.

5. The paid newsletter with a free tier

Subject: You're on the free list. Here is exactly what that means.

Free: the Monday issue, every week, full length.
Paid ([price]/month): Thursday deep dives plus the archive.

No guilt trips. The Monday issue has to earn the upgrade on
its own.

Read the deep dive most subscribers upgrade for, free
for new readers: [link]

Reply if the link is broken or you have a question about
[topic]. A human answers, usually me, usually same day.

Drawing the free/paid line in the welcome prevents the churn that surprise paywalls cause later. The free sample does the selling so the copy does not have to.

Before you turn it on

Run the finished email against this list:

• It fires instantly on confirmation (or on signup, if you run single opt-in).
• It comes from a real address a human reads.
• The signup form's promise is delivered in the first two lines.
• The cadence is stated in plain words, with honest hedges.
• There is exactly one question, and it is easy to answer.
• The subject line does its own work; if it reads like a receipt, borrow from our notes on newsletter subject lines.

Then send yourself a test, read it on a phone, and answer honestly: would you reply to this? If not, cut it in half and sharpen the question.

SPF (Sender Policy Framework, RFC 7208, published 2014) answers a single question for the receiving server: is the IP address delivering this message allowed to send for the domain in its envelope sender? It says nothing about message integrity (that is DKIM's job) and enforces nothing by itself (that is DMARC's). Where it fits in the larger system is covered in our deliverability handbook; this page is the syntax and the failure catalog.

Anatomy of a record

example.com.  TXT  "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all"

Left to right: the version tag (always v=spf1, always first), then mechanisms evaluated in order, then a catch-all. The first mechanism that matches decides the result and evaluation stops. Order matters: put your highest-volume sources first, and all always last.

The mechanisms, one by one

ip4: and ip6: are the cheapest and most precise: ip4:203.0.113.7 for one server, ip4:203.0.113.0/24 for a range. Use them when you control the sending IPs. They cost no lookups, which becomes the whole game later.

include: is how you authorize a provider. include:_spf.google.com pulls in Google's record and passes if their evaluation passes. Despite the name, nothing is textually included; it is a nested evaluation, and every nested include inside the provider's record counts against your lookup budget too.

a and mx look convenient and usually are not. mx in particular encodes an assumption that the servers receiving your mail also send it, which stopped being true for most domains once an ESP entered the picture. Your MX records point at whoever receives your mail; your outbound often lives elsewhere. Prefer explicit ip4 or include.

exists: triggers a lookup of a constructed name and passes if it resolves; it enables per-IP macros and almost nobody needs it. ptr is formally discouraged by RFC 7208 itself: slow, unreliable, and some receivers skip it entirely. If you find ptr in your record, remove it today.

Qualifiers: the character before the mechanism

In practice you will only ever type a qualifier on all, which brings us to the argument.

~all or -all: our position

Publish ~all, and pair it with an enforced DMARC policy.

The case: -all asks receivers to refuse mail at SMTP time on SPF evidence alone, and SPF evidence is structurally unreliable, because forwarding rewrites the sending IP. Every message forwarded from your domain (a university alumni address, an old work account someone redirects) fails SPF at its final destination by design. In June 2026 we watched this class of failure from the receiving side, when Gmail rejected 73% of the mail we were forwarding to an archive; the full incident is in our SPF/DKIM/DMARC overview. With ~all, a forwarded message survives SPF to be judged on its DKIM signature. With -all, some receivers never get that far.

Meanwhile -all buys you almost nothing that DMARC does not do better. Spoofing protection is DMARC's job, done with alignment and your published policy, after both SPF and DKIM have been considered. A domain at p=reject with ~all is far better defended than a domain at -all with no DMARC.

The tradeoff, named: ~all alone, without DMARC, deters nobody, since softfail carries no mandatory consequence. If you genuinely will not publish a DMARC record, -all is the lesser evil. Our position assumes you will do the whole system, because half the system is not worth much.

The 10-lookup limit and flattening

RFC 7208 section 4.6.4 caps evaluation at 10 DNS-querying mechanisms per check. include, a, mx, exists, ptr, and the redirect modifier each count, including every nested lookup inside every include chain. Cross the line and the receiver returns permerror, a permanent evaluation error. Under DMARC, permerror means SPF contributes nothing, so if DKIM also fails you are now failing DMARC because your record was too long. (A separate cap: more than 2 lookups returning no answer, so-called void lookups, is also a permerror.)

This ceiling arrives faster than it reads. A plausible small-business record:

"v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net include:_spf.salesforce.com ~all"

Four includes, but each expands: Google's chain alone resolves through multiple nested includes. Ten is not a distant limit; it is two or three SaaS signups away for most companies. Check where you stand with an SPF-specific checker (MxToolbox and dmarcian both count lookups for free) rather than eyeballing the record, because the nested expansions are invisible in your own DNS.

When you are over, in order of preference:

1. Prune. Every include should map to a tool that still sends for you. Records accrete; vendors churn. Remove before you optimize.
2. Move bulk sending to a subdomain. Your newsletter ESP can authenticate on mail.example.com with its own SPF record and its own untouched lookup budget. This also separates reputations, which we recommend anyway.
3. Flatten last. Flattening replaces includes with the literal ip4:/ip6: ranges they resolve to, which costs zero lookups. The trap: providers change IPs without telling you, and a manually flattened record rots silently until mail starts softfailing. Flatten only with automated re-resolution (several DNS providers and DMARC vendors sell exactly this), never by hand-pasting today's IPs.

The modifiers

redirect= replaces the record wholesale: v=spf1 redirect=_spf.example.net means "evaluate that domain's record as if it were mine." Useful for many domains sharing one policy; it costs a lookup and there is no fallback if the target has no record. exp= attaches an explanation string to failures. Receivers largely ignore it; skip it.

Common breakages, from most to least frequent

1. Two SPF records. Merging tools, migrations, and helpful colleagues each add their own TXT. Two records starting with v=spf1 is an automatic permerror, no matter how correct each one is. Merge into one line. This is the first thing to check when SPF mysteriously fails.
2. Over the lookup limit. Covered above; it is a permerror and it is invisible until a checker counts for you.
3. The 255-character split. A single TXT string maxes at 255 characters. Longer records must be split into multiple quoted strings in one record ("v=spf1 ..." "... ~all"), which resolvers concatenate. Some DNS panels do this for you; some fail loudly; some truncate and fail silently. If your record is long, dig it after saving.
4. +all, or a trailing typo. v=spf1 +all authorizes the entire internet to send as you. It shows up in real audits more than you would hope, usually as a debugging step that shipped.
5. The record on the wrong name. SPF is checked on the Return-Path domain. If your ESP sends with the Return-Path bounce.example.com, the record on example.com is not consulted for those sends; the subdomain needs its own. (Most ESPs handle this in the DNS they hand you at setup; it is the part people delete because it "looked redundant.")
6. A dead include. An include pointing at a domain with no SPF record is a permerror. Vendors get acquired, rename, and retire domains; your record inherits the wreckage.

Verify it like a receiver would

dig +short TXT example.com

Confirm exactly one string starts with v=spf1, then run it through a lookup-counting checker, then send a test message to a Gmail account and read Show original: the SPF line names the domain checked and the verdict, which is the ground truth no syntax audit can give you.

Then remember what you built: a list of allowed senders for the envelope domain, nothing more. It breaks on forwarding, it says nothing about the From your reader sees, and receivers treat it as one signal among several. Count your lookups today, keep the record to one line, and spend the time you save on DKIM and DMARC, where the enforcement actually lives.

The problem all three exist to solve

The From header in an email is plain text. SMTP, the protocol mail servers speak to each other, checks it against nothing. Anyone can put billing@yourdomain.com in the From line of a message sent from anywhere on earth, and for the first few decades of email that message would simply arrive. Every phishing campaign that impersonates a bank works this way.

SPF, DKIM, and DMARC are three DNS records that give receiving servers a way to check the claim. Each answers one question, and none of them is sufficient alone, which is why our email deliverability handbook treats the trio as the floor of every send, not an optional hardening step.

SPF: who may claim the domain

SPF is a published list of sending servers. When mail arrives, the receiver looks up a TXT record on the sender's domain and checks whether the connecting IP address is on the list.

The subtlety: SPF does not check the From address you see in your mail client. It checks the envelope sender, also called the Return-Path, a hidden address used for bounce handling. Those two addresses are frequently different, and that gap matters enormously once we get to alignment.

A typical record is one line:

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

Translation: Google's servers may send for this domain, treat everyone else with suspicion. The full syntax (mechanisms, qualifiers, the 10-lookup limit that silently breaks records) gets its own reference in our SPF record guide.

DKIM: who signed the message

SPF authenticates the connection. DKIM authenticates the message itself. Your sending server computes a hash over the message body and selected headers, signs it with a private key, and stamps the result into a DKIM-Signature header. The receiver fetches the matching public key from your DNS, at an address like s1._domainkey.example.com, and verifies the signature.

Because the signature rides inside the message, DKIM keeps working when mail passes through intermediate servers. That single property makes it the sturdiest of the three, and the details (selectors, key length, what the signature actually covers) are in our DKIM explainer.

DMARC: who enforces

Without DMARC, SPF and DKIM are advisory. A receiver sees a failure and makes a private judgment call. DMARC is the domain owner publishing the judgment in advance:

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

The p= tag is the policy: none (deliver anyway, just report), quarantine (spam folder), or reject (refuse outright). The rua= tag is where receivers send aggregate XML reports about every message claiming your domain, which is how you find senders you forgot about before you tighten the policy. The none-to-reject progression deserves a project plan of its own, and we wrote one in What is DMARC.

Alignment: the part most guides fumble

Here is the loophole that DMARC exists to close, and that most three-paragraph summaries never mention.

SPF checks the Return-Path domain. DKIM checks the d= domain named inside the signature. Neither is required to have anything to do with the From address your reader sees. So a phisher can send from their own domain, with flawless SPF and a valid DKIM signature for phisher-mail.net, while displaying yourbank.com in the From line. Both checks pass. The reader sees your bank.

DMARC adds the missing rule: at least one passing check must align with the From domain. SPF aligns when the Return-Path domain matches the From domain. DKIM aligns when the d= domain matches. In the default relaxed mode a subdomain counts (mail.example.com aligns with example.com); in strict mode the match must be exact.

One aligned pass is enough. That "one is enough" rule is not a technicality. It is the entire reason forwarded mail can survive, as we found out the hard way.

A worked example

Take example.com, hosted on Google Workspace, sending its newsletter through an ESP. Three TXT records make the whole system:

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

google._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEF...IDAQAB"

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

Now trace one message from hello@example.com to a Gmail user. Gmail's server accepts the connection and runs the checks in order. SPF: the connecting IP belongs to Google's pool, which _spf.google.com includes, so SPF passes, and the Return-Path domain is example.com, so it aligns. DKIM: the message carries a signature with d=example.com and selector google; Gmail fetches google._domainkey.example.com, verifies the hash, pass, aligned. DMARC: at least one aligned pass exists, so the message passes DMARC, and the p=none policy would not have punished a failure anyway. The message is delivered, and once a day Gmail mails a summary of everything it saw to dmarc-reports@example.com.

Two passes is the healthy state. You need both because each one fails in situations the other survives.

Forwarding breaks SPF: we have the numbers

In June 2026 we were mirroring every inbound message on our domain to a Gmail archive using Cloudflare's message.forward(). No errors on our side, all green. Then we noticed mail was missing from the archive, quietly, with no bounce we could see. When we pulled the numbers, Gmail had been rejecting roughly 73% of everything we forwarded.

The mechanism is textbook. A forwarder re-sends someone else's message from its own IP address. That IP is not in the original sender's SPF record, so SPF fails on every single forwarded message, by design, with no workaround. The message can still pass DMARC through the other door: an intact, aligned DKIM signature travels with the message and verifies anywhere. But any message that arrived unsigned, or whose signature broke in transit, had nothing left. Under the sender's DMARC policy, Gmail refused it.

We stopped forwarding and switched the mirror to a Gmail API insert, which sidesteps SMTP entirely. The general lessons survive the specifics: SPF alone is fragile in the real world, DKIM is the only authentication that survives forwarding, and a DMARC policy is enforced silently, so the sender never sees the damage. If your setup relies on SPF passing everywhere, some of your mail is already failing somewhere.

Set them up in this order

The order matters less for DNS than for risk: you want signing and listing in place before any policy exists to punish their absence.

1. DKIM first. Turn on signing at your mail host and ESP, publish the selector records they give you, and send a test to a Gmail address. Open it and use Show original to confirm DKIM: PASS.
2. SPF second. One TXT record listing every service that sends for you. Keep it under 10 DNS lookups.
3. DMARC at p=none with a rua address. This punishes nothing and starts the reports flowing.
4. Read reports for two to four weeks. Find the printer, the CRM, the billing tool you forgot authenticates nothing.
5. Tighten to p=quarantine, then p=reject, only when the reports show every legitimate source passing with alignment.

For where BIMI fits, and what to prioritize at each sending volume, the series overview is our email authentication guide. But the sequence above is the work. Three TXT records, one system, and the receivers stop guessing.

What the rate is, exactly

Gmail's spam rate is user spam reports divided by mail delivered to the inbox, computed daily, per the definitions in Google Postmaster Tools. Only Gmail recipients count toward Gmail's number; Yahoo computes its own equivalent with the same 0.3% ceiling. Google's sender guidelines (February 2024, tightened through 2025) publish two lines: stay under 0.1%, and avoid ever reaching 0.3%. The full rule set lives in our breakdown of the Gmail bulk sender requirements, and the thresholds anchor the send policy in our email deliverability handbook.

The penalty structure is what makes 0.3% special. At or above it, Gmail withholds delivery mitigation until your rate has stayed under 0.3% for 7 consecutive days. In practice that is a week minimum of spam-foldered campaigns, and a week is generous only if you stop making it worse immediately.

The math at real list sizes

The percentages sound forgiving. The absolute numbers are not.

Read the top rows first. Below about 1,000 Gmail deliveries a day, one annoyed recipient breaches both lines at once. The rate is computed daily, so a single spiky day on tiny volume is survivable if it stays rare, but the published rule contains no small-sender exemption. Treat every campaign as if the line is live, because it is.

A worked example at newsletter scale: a 5,000-subscriber list with roughly 60% Gmail addresses delivers about 3,000 messages to Gmail per campaign. Your 0.1% budget is 3 reports. Nine reports on one send, which is nine people out of five thousand having a bad morning, puts you at 0.3% and starts the 7-day clock. Scale changes the arithmetic but never the exposure: at 100,000 delivered you have room for 99 reports, and a single mailing to a stale segment can produce all of them in an afternoon.

Make unsubscribing cheaper than complaining

The Report Spam button is one click and always visible. If leaving your list costs more than that click (a login, a survey, a "why are you going?" page), some readers will pick the button, and every one of them is a complaint you chose. The countermeasure is RFC 8058 one-click unsubscribe, stamped as two headers on every campaign:

List-Unsubscribe: <https://yourdomain.com/unsub/TOKEN>, <mailto:unsub@yourdomain.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The rules allow two days to honor the request. We honor it immediately, because a person who has asked to leave and then receives one more email is exactly the person who files a report. Our one-click unsubscribe guide covers the headers end to end.

Feedback-ID: the loop Google never built

Yahoo and Microsoft run traditional feedback loops: register for Yahoo's CFL or Microsoft's JMRP and they email you an ARF copy of each complaint, so you can suppress the complainer within minutes. Google offers no ARF loop at all, at any volume, and never has.

Its substitute is aggregate. You stamp a Feedback-ID header on every send, and Postmaster Tools breaks spam rates out per identifier so you can tell which campaign or list segment is generating complaints. The header is up to four colon-separated fields with the sender identifier last:

Feedback-ID: campaign-2026-08:newsletter:acme:ld

We stamp it on every campaign send, because when a complaint happens at Gmail this aggregate view is the only visibility that exists. The consequence worth internalizing: you never learn who complained at Gmail. Suppressing individual complainers there is impossible, which pushes all the real work upstream into unsubscribe friction and list hygiene.

Where to read your rate in 2026

Google retired the Postmaster Tools v1 interface on September 30, 2025, and the domain and IP reputation dashboards went with it. The spam-rate chart survived into v2, joined by a Compliance Status view that grades you against the sender requirements. So the current monitoring stack, all free:

• Google Postmaster Tools v2 for the Gmail spam rate and compliance checks.
• Yahoo CFL for per-complaint ARF reports (registration covers AOL as well).
• Microsoft SNDS and JMRP for the Outlook side.

One honest limit: the Postmaster charts need meaningful daily Gmail volume before they render anything. At dozens of emails a day, which is our own situation as a small live workspace, the graph is often blank. That is not a reason to skip registration. It is a reason not to make the dashboard your only safeguard, which brings us to the part we automated.

Auto-pause as policy, not judgment

Our send path halts itself at a complaint rate of 0.3% or a bounce rate above 2%. No human decides to stop; a human is required to resume. We built it that way because dashboards lag and humans rationalize. "Finish this campaign, then investigate" is how a bad hour becomes a bad month, and by the time someone reads a chart, the next thousand sends are already out the door.

There is precedent for the idea at the infrastructure layer: AWS SES reviews and can pause entire accounts around 0.1% complaints or 5% bounces, per its published documentation. Relays enforce this on you eventually, so enforcing it on yourself first is cheap insurance. Behind our brake sits a global suppression list of bounces, complaints and unsubscribes, checked before every single send, so an address that failed once can never be mailed again by accident.

Your complaint budget, in one division

Divide your typical Gmail delivery count by 1,000. That is your report budget at the 0.1% target: for most small newsletters, between one and three reports per campaign. Spend it on nothing. Ship the one-click headers this week, register the three dashboards, and put an automatic stop at 0.3% before you ever need one.

A shared inbox fixes that. It is one address (support@, sales@, hello@) that several people can read and answer without passing a password around. Every option in this article gets you there. The differences are price, clunkiness, and whether replies go out as the address or as the individual. This article assumes mail on your own domain already works; if it does not, start with our business email setup guide and come back.

Why support@ in one person's inbox fails

There are three standard workarounds, and each breaks in its own way.

Password sharing is the first. Two people logging into one mailbox defeats two-factor authentication, makes offboarding a fire drill (change the password, tell everyone, update every saved session), and leaves no record of who said what to a customer.

Forwarding is the second, and it fails quietly. We learned this in production: in June 2026, Gmail silently rejected 73% of the mail our own system auto-forwarded, because forwarding breaks DMARC alignment. Nothing errored on our side. The mail simply vanished. A support@ rule that forwards to someone's personal Gmail fails the same way, for some unpredictable fraction of messages, with no bounce to warn you.

The third workaround is doing nothing: support@ is one employee. That works until they take a vacation, and then your support queue takes one too.

Shared inbox for Gmail, option 1: Groups Collaborative Inbox

Google's real answer for teams is not in Gmail at all. It is Google Groups with the Collaborative Inbox feature switched on, included free with every Workspace plan. The group address does not consume a paid seat.

The setup, concretely:

1. In the Admin console (or at groups.google.com on a Workspace account), create a group named support@yourdomain.com.
2. In the group's settings, turn on "Collaborative Inbox" under additional Google Groups features.
3. Set "Who can post" to "Anyone on the web," or customer mail will be rejected.
4. Add your teammates as members with permission to moderate metadata, so they can assign conversations and mark them complete.

You get assignment, "mark as complete," and a shared history for $0. Now the clunk. The whole thing lives at groups.google.com in a forum-style interface, not in anyone's Gmail. Search is weaker than Gmail's. There are no shared drafts and no warning when two people answer the same message. Worst of all, replies default to the member's own address; answering as support@ requires each person to configure "Send mail as" in their own Gmail settings, one by one. Teams tolerate this at low volume. Nobody loves it.

Shared inbox for Gmail, option 2: delegation

Delegation grants other accounts access to one mailbox, reply rights included. Personal Gmail allows up to 10 delegates; Workspace accounts have allowed up to 1,000 since Google raised the limit in January 2021, with about 40 able to work concurrently under typical use (Google's published figures).

The catch sits in the From line: delegated replies are visibly marked as sent by the delegate on behalf of the owner. There is no assignment, no status, no queue. Delegation was built for an assistant managing an executive's mailbox, and for that it is the right tool. As a team support channel it is a hack.

Outlook and Microsoft 365 shared mailboxes

Microsoft's version is cleaner. A shared mailbox in Exchange Online needs no license of its own up to 50 GB of storage; past that it needs an Exchange Online Plan 2 license for the 100 GB tier (Microsoft's Exchange Online service description, checked August 2026). The real requirement hides one step back: every person who opens the shared mailbox must hold their own Exchange Online license, so this is only free inside an organization already paying for Microsoft 365.

Send As and Send on Behalf both work and are set by an admin, so replies can go out cleanly as support@. What you do not get is workflow: read and unread state is all the coordination there is, with no way to see who owns which conversation. For a Microsoft shop with modest volume, this is the best free option. The ownership problem stays yours to solve in chat.

Dedicated shared inbox software: Front and Hiver

When email becomes a support operation, the dedicated tools earn their keep: per-message assignment, collision detection (a banner when a colleague is already typing), SLA timers, CSAT surveys, and analytics.

They charge per seat, and that is the whole story of the bill. Neither one is in the 14-provider pricing dataset behind this site, so we will not quote their tiers from memory: open both pricing pages, and read the per-seat rate and the seat minimum before you budget.

Then do the multiplication, because it decides this. A five-person team on a $25 seat is $1,500 a year; the same team on a $65 seat is $3,900. Those are defensible numbers for a ten-plus-person support desk with contractual response times. Below that, you are paying help-desk prices for what is really a rota, and every hire adds a line to the invoice.

The LetterDuck model: every address is already shared

We built LetterDuck around a different unit. An address is a routing rule, not a seat. A catch-all routes every address on the domain into one threaded inbox, so support@, billing@, and any alias you invent next week are shared from the moment they exist. There is no provisioning step because there is nothing to provision.

Anyone in the workspace sees every thread. Replies go out as whichever address the conversation belongs to, with In-Reply-To and References headers set so the exchange threads correctly on the customer's side. The price is $50 per domain, flat, and hiring your fourth person changes nothing.

The honest limitation: LetterDuck has no per-message assignment, no collision detection, no SLA reporting. If you run a support desk that needs those, buy Front or Hiver and do not look back. LetterDuck is for teams of roughly one to ten who want every address on the domain answered from one place without per-seat pricing. It is the system we run our own mail on, and the inbound path behind it has been in production since June 2026 with a watchdog probe round-tripping it every two hours.

The decision table

Where to start

Count two things: the people who need to answer mail, and the addresses they answer for. One person, any number of addresses: aliases. Many people, one executive mailbox: delegation. Many people, many addresses, under ten humans: pick flat pricing over seats, because the per-seat bill grows exactly when your margins are thinnest. And if the count crosses ten, or a contract mentions response times, pay for a real help desk without guilt. The expensive mistake is not choosing the wrong tier; it is leaving support@ pointed at one person's inbox for another quarter.

The domain does the work

An address is two parts, and the right-hand side does the heavy lifting. maya@atelier-north.com says there is a company; mayadesigns1988@gmail.com says there is a hobby. Prospects check the domain, not the spelling of your first name. So before debating formats, get on a domain you control, with SPF and DKIM authenticating it; our business email setup guide walks the whole path from DNS to inbox. The stakes rose recently: Gmail (November 2025) and Microsoft (May 2025) now hard-reject unauthenticated mail with a 550 error rather than filing it under spam.

Once the domain is yours, addresses stop being scarce. On our own stack an address is a routing rule, not a mailbox you pay for, so the only real question left is what the pattern should be.

Person address formats: our positions

Format guides usually list options and refuse to choose. Here is what we would actually do, with the tradeoff named.

The phone test is the honest referee here: read the address aloud, once, to someone who cannot see your screen. If they need it repeated or spelled, the format failed. first@ and first.last@ pass. Almost nothing else does.

Whatever you choose, apply it to everyone, founders included. A team where the CEO is james@ but new hires are j.smith@ broadcasts a two-tier culture in the email directory.

The role addresses every business needs

People guess role addresses when they do not know a name, so owning the standard set is free surface area. Five cover most businesses.

Two rules make these work. First, every role address needs a named owner, because an address everyone watches is an address nobody answers. Second, role addresses should be readable by more than one person from day one; the mechanics of that (Google Groups, delegation, shared mailboxes, or a workspace where every address is shared by default) are the subject of our shared inbox guide.

On a setup with unlimited addresses these five cost nothing to create, and you can add narrower ones (careers@, security@, partners@) the day you need them. Aliases make the same point at the personal level.

Addresses that hurt trust

info@ is the one we would retire. It is the default that nobody owns, and the address a dictionary spray tries first, which is why our own list-hygiene rules bar role accounts (info@, admin@, postmaster@, abuse@) from a newsletter list. They signal a distribution list, not a person. When your public contact is info@, you are telling people their message goes onto a pile. hello@ receives the identical mail and implies a human will read it. Same function, better promise.

Do not send from noreply@. This one costs you twice. The first cost is stated plainly in the name: you are emailing customers while announcing you will not listen. The second cost is mechanical. Mailbox providers rank engagement signals in a clear order (replies above clicks, clicks above opens), and a From address that cannot receive replies sets your strongest reputation signal to zero by design. Every address you send from should be one a human reads. If the volume worries you, that is a filtering problem inside your inbox, not a reason to slam the door on the sender's side.

The rest of the trust-killers, briefly: admin@ and office@ as outward identities (internal plumbing, not a face), cutesy addresses (topdog@, duckboss@) outside brands where whimsy is the product, and any abbreviation your own staff have to look up.

Business email address examples by company type

Patterns worth noticing: client-facing professions stay formal (a law firm on first.last@ reads as intended), hospitality stays warm (first@ suits a business built on a person's name), and a media site's tips@ and corrections@ are trust signals in themselves.

Edge rules: dots, hyphens, unicode

Dots. Google famously ignores dots on @gmail.com addresses; m.aya and maya reach the same account there, and Google documents this. On your own domain that guarantee does not exist: maya.chen@ and mayachen@ are distinct addresses on most mail servers. Pick one form, publish it consistently, and if you expect people to guess wrong, run a catch-all so misremembered variants still arrive.

Case. RFC 5321 technically permits case-sensitive local parts, but no serious provider treats Maya@ and maya@ differently. Publish lowercase anyway; it removes the question.

Length. The local part maxes out at 64 characters (RFC 5321). If a business address is anywhere near that limit, something has gone wrong upstream of the RFC.

Hyphens. Legal, and best avoided in local parts: "maya hyphen chen at" survives dictation worse than the dot does. Hyphens in the domain itself are fine when the unhyphenated name is taken.

Unicode. RFC 6531 (2012) allows UTF-8 addresses, so josé@ and 田中@ are technically valid. Support remains uneven across providers, web forms, and CRMs, and one broken form is one lost lead. Our position: keep business addresses ASCII, whatever the brand name looks like.

Plus addressing. maya+invoices@ style tags are useful for filtering your own mail, and plenty of web forms reject the + sign. Treat them as a private tool, never as a published address.

Do this today

Pick the pattern: first@ if headcount is under 20 and you accept the collision risk, first.last@ if you would rather never migrate. Create the five role addresses and write a name next to each one. Retire info@ in favor of hello@, and delete noreply@ from every template it still haunts. The whole exercise takes an afternoon, and it is the cheapest credibility upgrade a small company can buy.

You have three options

The versus framing hides an option, and the hidden option is the right one.

This piece is about what the message is made of. If you are still building the list and the domain it comes from, that is the newsletter-on-your-own-domain guide; come back when something is ready to send.

Why HTML-only mail is a spam signal

SpamAssassin, the open-source filter that a lot of commercial filtering descends from, ships a rule literally named MIME_HTML_ONLY: the message has an HTML part and no plain-text alternative. The rule exists because it separates populations. Real mailing software emits both parts by default, so a missing text part correlates with hand-rolled spam scripts and rushed tooling. The score is small on its own, but spam filtering is cumulative, and this particular point is free to not concede.

The text part has to be real to help. A text/plain part that says "Please view this email in an HTML-capable client" hands back everything the fix bought, because filters read that part too. Generate it from the same content as the HTML: same words, same links, no markup. Our composer does exactly this on every campaign, alongside the rest of the content hygiene our playbook enforces: a text-to-image ratio of at least 60:40, never image-only mail, no link shorteners, links kept on the sending domain. None of these alone decides your fate; they stack, in both directions, with everything else covered in why emails go to spam.

The fake plain text pattern

Here is the part the versus articles skip: the famous "plain text" newsletters mostly are not plain text. They are HTML dressed as plain text, and email developers have a name for the pattern: fake plain text. The anatomy is consistent. A single column capped around 600 pixels. A system font stack. No images, or one small logo. Underneath: fully tracked links rewritten through a click domain, and a styled footer holding the unsubscribe link.

Senders build this because it keeps the two things HTML is genuinely for, click measurement and typographic control, while borrowing the intimacy of a personal note. You can verify the pattern yourself in about ten seconds: open the next minimal newsletter you receive in Gmail, choose Show original from the three-dot menu, and search the source for text/html. It is almost always there.

We think fake plain text is the right call for most newsletters, and it is what a minimal LetterDuck template is: quiet HTML with a true plain part sitting beside it in the same message. The label is the only dishonest thing about the pattern.

Where actually-plain still wins

Cold outreach. A 90-word text/plain message is structurally identical to mail one human writes to another, which is the entire game when nobody asked to hear from you. A designed HTML template arriving from an unknown domain announces "campaign" before the first word is read. If outreach is your problem, start with what cold email actually is, and keep it off your newsletter domain entirely.

Short transactional mail. A password reset is one sentence and a link. It has to survive every client, every screen reader, and every corporate filter, and there is nothing in it to design. Plain, or a near-plain multipart, is the right weight.

Replies. When we answer a reader from the workspace, the reply goes out as ordinary mail with In-Reply-To and References headers so it threads correctly in their client. No template, no tracking. A conversation is not a campaign.

The multipart mechanics, literally

This is the entire structure, trimmed to its skeleton:

From: The Print Room <hello@yourdomain.com>
To: reader@example.com
Subject: Issue 12: the letterpress that would not die
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1"

--b1
Content-Type: text/plain; charset=utf-8

Issue 12: the letterpress that would not die.
Read the illustrated version: https://yourdomain.com/12

--b1
Content-Type: text/html; charset=utf-8

<html><body>
  <h1>Issue 12</h1>
  <p>The letterpress that would not die.</p>
</body></html>

--b1--

Three details carry all the weight. The boundary string separates the parts and closes the message with a trailing double hyphen. Each part is a complete, standalone rendering of the same message. And the order is a rule, not a habit: RFC 2046 (1996) says the parts appear in increasing order of preference and the client renders the best one it supports, which in practice means the last one it can display. Plain first, HTML last. Reverse them and text-capable clients that follow the spec show your readers the plain part.

We live on both sides of this structure. Outbound, the composer emits it. Inbound, every message that reaches a LetterDuck workspace is parsed from the raw RFC822 stream by postal-mime, both parts stored, so malformed multipart is not an abstraction to us; it is a Tuesday.

One practical ceiling while you are in the HTML part: Gmail clips messages above roughly 102KB, a threshold Litmus has documented for years, and a clipped message hides everything below the fold, your unsubscribe link included. Keep the HTML lean and the design restrained; restraint is also what makes the plain part easy to generate.

What to do

For a newsletter: multipart/alternative, always. Generate the text part from the same content and actually read it once before the first send; a stray markdown artifact or a wall of raw URLs tells you the generator needs work.

For cold outreach and one-sentence transactional mail: plain or near-plain.

HTML-only: never. There is no case for it, and one named rule against it.

Before your next send, look at the raw message your tool actually emits. If there is no text/plain part inside it, fix the tool or change tools.

Subject lines are one piece of the craft; the full path from zero is in our guide to starting a newsletter on your own domain, and the writing that comes after the open is covered in how to write a newsletter.

Opens are inflated, so optimize for the click

MPP downloads images, including tracking pixels, when mail arrives on an Apple device, whether or not the recipient ever reads it. At launch, Litmus projected Apple Mail open rates would drift toward 75% as adoption peaked. Five years on, an "open" from an Apple reader tells you the mail arrived. That is all.

This changes what a subject line is for. Pre-2021, the industry graded subject lines on opens, which at least measured curiosity. Now the only numbers that survive contact with MPP are clicks and replies, so a subject line succeeds when the reader who opens goes on to do something. A line that tricks a person into opening and gives them nothing does not just waste the nine seconds Litmus measured; it teaches them to skip you next week. More on which metrics still mean anything in our piece on open rates.

The 40-character budget

Mobile clients cut subject lines short, and the cut points are tighter than most people write to. Email Tool Tester's client-by-client measurements (checked August 2026) put the visible portrait-mode budget at:

The math that falls out of this is simple. Write to 40 characters or fewer, put the word that carries the meaning inside the first 30, and let the preheader carry everything that did not fit, since inboxes render subject and preheader as one continuous line. "New: one-click rollback for failed deploys" runs 42 characters and loses its last word in the Gmail app; "One-click rollback is live" keeps the payload inside every budget and leaves "for failed deploys, no redeploy needed" to the preheader.

People ask us for catchy newsletter subject lines. Catchy is the wrong target at 40 characters. Clear beats catchy in every inbox we have ever read, including our own.

Newsletter headline examples by type

The sets below are ours, written for this article for three imaginary senders: a coffee roaster, a local city brief, and a developer tools changelog. We have not A/B tested them at scale, and we would distrust anyone who claims performance numbers for a list of unsent subject lines. Character counts are in parentheses. (Inside the email, the same patterns work as section headlines; the constraint that changes is the 40-character budget, which only applies in the inbox.)

Curiosity lines open a loop the issue must close:

• The blend we pulled after 12 days (33)
• What the inspector found upstairs (33)
• We deleted 4,000 lines of config (32)
• The feature nobody asked for (28)
• Our worst issue, by the numbers (31)

Curiosity works when the payoff is real and arrives early in the issue. Its failure mode is fatal, though: tease without a cashout twice and readers stop believing you, which is a worse outcome than never being opened.

Specific lines state the payload outright:

• Ethiopia Guji is back Thursday, 250g bags (41)
• Saturday: the harbor market moves indoors (41)
• One-click rollback is live (26)
• Free shipping ends Sunday night (31)

Specific is the default we recommend. It self-selects the right readers, and the click it earns is a qualified one. The tradeoff: a specific line gets skipped by everyone the payload does not apply to, and you have to be at peace with that.

Number-led lines promise a countable read:

• 3 breweries, 1 permit fight, 12 new jobs (40)
• Our January numbers: 41% fewer tickets (38)
• 5 links on caching, 2 worth your weekend (40)

Numbers signal that the issue respects the reader's time. They fail when every issue leads with a number, because the pattern reads as a template by week four. Rotate.

The spam-words reality check

The lists of "spam trigger words" that circulate every year are mostly folklore. Our stance, and the stance of the providers' own documentation: mailbox filters decide folders on sender reputation, authentication, and complaint rates, and vocabulary is a minor signal at the margin. Google's bulk-sender requirements (February 2024) demand SPF, DKIM, DMARC, one-click unsubscribe, and a spam-complaint rate under 0.3%. They contain no list of banned words. Even Mailjet, which publishes a spam-words guide, concedes in it that a sender with a clean reputation can say "free" without incident. Note the example set above: "Free shipping ends Sunday night" is a fine subject line on an authenticated domain with a warm history.

We have first-hand evidence that the folder decision lives below the content layer. In June 2026, Gmail silently rejected 73% of the mail we were forwarding between our own systems. The cause was DMARC alignment broken by forwarding. Not one word of any subject line was involved. If your mail is landing in spam, audit your authentication and your list before you audit your adjectives; the full diagnostic order is in why emails go to spam.

A/B testing under 2,000 subscribers is noise

Subject-line split tests need more sample than most newsletters have. The arithmetic: to detect a 5-point lift on a 40% baseline (40% vs 45%) at the standard 95% confidence and 80% power, you need roughly 1,500 recipients per arm, more than 3,000 subscribers split down the middle. Run that same test with 1,000 per arm and the smallest difference you can reliably detect is about 6 points, a swing real subject lines rarely produce. You can rerun this in any two-proportion sample-size calculator; Evan Miller's free one is the standard. And that math is on opens, the metric MPP already corrupted. Click-based tests need even more sample, because clicks are rarer.

So under about 2,000 subscribers, a per-issue split test is a random-number generator with a dashboard. Test across issues instead: pick one variable (say, specific vs curiosity), hold your send day and voice constant, run each style for a month, and compare clicks and replies over the whole period. Slower, honest, and it measures the thing that matters.

What we track instead

Two numbers: clicks and replies. Mailbox providers weight engagement in roughly that order themselves, replies above clicks above opens, so the metrics that tell you the truth are also the ones that build your sending reputation. Keep the From name and address identical on every send while you evaluate anything, because a changed sender identity resets the reader's pattern recognition and contaminates whatever you were measuring.

Write the subject and preheader together, spend the first 30 characters on the operative word, and grade the result on clicks. Opens flatter you. Clicks pay you.

This page is the idea catalog: 26 concepts, grouped by who you are, each with the format that fits it and a real published example where one exists. The mechanics of launching live in our guide to starting a newsletter on your own domain, and the issue-level craft is in how to write a newsletter.

The differentiation test

Before picking from the list, answer two questions in writing. First: if this newsletter vanished, what would readers use instead? If the answer is "another newsletter, interchangeably," the idea is not done. Second: which of four things are you? An expert (you know something), a curator (you read everything), an operator (you run something), or a community builder (you gather people). Most failed newsletters die of borrowed identity, an operator writing curator issues because digests look easy. The strong newsletter topics all come from the writer's actual position, which is why the list below is grouped by position and not by industry.

Expert ideas: you know something most people don't

1. The one-concept teacher

Teach a single idea per issue with one worked real-world example. The format is a short essay, 500 to 800 words, same day every week. The reference: Why We Buy, Katelyn Bourgoin's Tuesday buyer-psychology letter, which reached roughly 63,000 subscribers and seven figures of 2024 revenue on exactly this format (per Growth In Reverse's teardown).

2. The daily column

Voice-driven commentary on your field's news, published daily. Matt Levine's Money Stuff at Bloomberg is the canonical example: thousands of words, one voice, arrives every weekday. Highest-effort idea on this page, and the format least survivable part-time. Start weekly.

3. The free-weekly, paid-daily brief

One substantial free article a week to grow the list, short paid updates the other days. Ben Thompson's Stratechery built the model that most paid analysis newsletters now copy. Works only when your daily takes are genuinely better than the trade press.

4. The niche translator

Explain a jargon-heavy industry in plain language, for insiders who want clarity and outsiders who want a way in. Alex Johnson's Fintech Takes does this for financial technology twice a week, with analogies doing the heavy lifting.

5. The how-I-work guide

Tactical walkthroughs of your own craft: templates, checklists, decision frameworks. Lenny Rachitsky's newsletter grew on exactly this for product and growth people. Format: one question or problem per issue, answered with artifacts the reader can copy.

6. The annotated reading

You read the dense primary sources (papers, filings, RFCs, court documents) and send the three paragraphs that matter with your annotations. Nobody unsubscribes from the person who reads the boring things for them.

7. The office-hours letter

Answer one subscriber question per issue, in depth, with the question quoted. Self-feeding by design: every issue invites the next question, and replies are the strongest engagement signal a mailbox provider can see.

8. The prediction ledger

Make dated calls about your field and keep a public scoreboard, including the misses. The scoreboard is the differentiator; commentary is everywhere, accountability is scarce.

Curator ideas: you read everything anyway

9. Five good links

A handful of exceptional reads with a sentence or two of your judgment on each. The Browser, founded by Robert Cottrell, has sold subscriptions on five links a day for years. The taste is the product; the day you pad it with a sixth mediocre link, readers can tell.

10. The taste catalog

Slower, broader curation with a personal essay up top: tools, design, culture, one issue a week. Kai Brach's Dense Discovery is the reference, and its longevity shows the format retains readers who skip individual issues without churning.

11. Six short recommendations

Fixed count, tiny reviews, zero filler. Recomendo (Kevin Kelly, Mark Frauenfelder, Claudia Dawson) sends six one-paragraph recommendations every Sunday. The rigid format is the appeal: readers know the cost of opening it, about a minute.

12. The day's news through one voice

Pick what mattered today and say why in your own register. Dave Pell's NextDraft has done "the day's most fascinating news" this way for over a decade. Differentiates on personality, so it fails if you write it neutral.

13. The forum digest

Curate the best of a community you do not own. Hacker Newsletter, Kale Davis's weekly hand-picked digest of Hacker News, has run since 2010 on this model. Every large forum, subreddit, and Discord with no digest is an open slot.

14. The industry brief

Everything that happened in one niche this week, compressed to a five-minute read. Morning Brew proved the format for business news; the play now is the same brief for a market too small for a media company, which is precisely where a solo writer wins.

15. The archive resurfacer

Ignore the news entirely and surface old, timeless material: essays, letters, papers, forgotten books. Maria Popova's The Marginalian has spent two decades proving readers will subscribe to the past. Zero news-cycle pressure, which makes it the most sustainable curator format here.

Operator ideas: you run the thing

16. The build-in-public diary

What you shipped, what broke, what it taught you, weekly. Arvid Kahl's The Bootstrapped Founder goes out every Friday on this model. The candor is the moat: a competitor can copy your product, not your honest account of running it.

17. The metrics memo

Your real numbers on a schedule: revenue, churn, conversion, and one lesson per number. Publishing the figure you are slightly embarrassed by is what separates this from marketing.

18. The teardown letter

Dissect one artifact per issue: a landing page, a pricing page, a checkout flow, with annotations. Harry Dry's Marketing Examples grew a huge list on visual teardowns. Effort is front-loaded in the analysis, and the archive compounds into a reference readers cite back to you.

19. The customer mailbag

Answer real customer questions publicly, names removed. You already wrote these answers in your support inbox once; the newsletter is the second use. The best low-effort operator format, and it doubles as pre-sales.

20. The process letter

How the thing got made this week: the roast profile, the print run, the recipe test, the deploy that went sideways. Process is the one story a commodity business owns outright.

21. The changelog with a narrator

Release notes rewritten as a story: what changed, why, what it cost, what almost shipped instead. Most changelogs are lists nobody reads; a narrated one becomes the reason users stay current. We write our own product notes this way, which is partly why this list exists.

Community ideas: you gather people

22. The local brief

Your town, three mornings a week, written like a friend who knows everything happening. Naptown Scoop, from the top of this page, is the template: Sneddon reports a 65% open rate in that same profile, and while Apple's Mail Privacy Protection inflates that number for every sender, even discounted it signals a list that would riot if the mail stopped.

23. The scene report

Cover a subculture the mainstream press only parachutes into. Ryan Broderick's Garbage Day, started in 2019, turned internet-culture reporting into a three-day-a-week letter with over 100,000 subscribers (per Broderick's 2025 interview with Longlead). Substitute any scene you genuinely live in: modular synths, zine printing, competitive gardening.

24. The advice column

Readers send dilemmas; you answer one per issue with actual care. Heather Havrilesky's Ask Polly carried the newspaper advice column into email and proved the format's pull is intact. Requires a voice, not credentials.

25. The member spotlight

Interview one member of your community per issue, five questions, same five every time. The subjects share their issues, which grows the list; the archive becomes a directory of the scene. Near-zero writing burden, real scheduling burden.

26. The jobs-and-events board

Openings, gigs, meetups, and deadlines for one niche, reliably compiled. The least glamorous idea here and among the most defensible: utility newsletters get read on a schedule, and advertisers understand them instantly.

Four repeatable formats and their effort budgets

Most of the 26 concepts above run on one of four chassis. Budget honestly before committing; these are our planning budgets, not measurements, and your first three issues will run over.

The digest looks cheapest and rarely is, because the curation only works if you were reading widely anyway; the diary is genuinely cheap if the week supplies the material. Whichever chassis you pick, the subject line and preheader carry the issue into the open, so budget ten minutes for them every single time.

Pick one concept, run the differentiation test on it in writing, and choose the chassis you can sustain in the hours you really have. The right idea is the one still shipping in week six.

Copying a famous newsletter's look gets you nothing, because the look is the least transferable part. The mechanism transfers. If you are deciding what to build, read these as machines, then pick the one whose moving parts you can actually operate on schedule. (If you have not sent issue one yet, our guide to starting a newsletter on your own domain covers the plumbing side.)

The habit slot: Morning Brew and The Hustle

Morning Brew topped 4 million subscribers in March 2022, per CNBC, after selling a majority stake to Insider in 2020 at a reported valuation around $75 million. The Hustle went to HubSpot in February 2021 for a reported $27 million and its signup page claimed 2 million plus readers when we checked in August 2026. Two exits, one mechanism.

The mechanism is the habit slot. Both arrive every weekday morning, both promise roughly five minutes, and both compress business news into a conversational register that reads faster than a news site. The product is not any single story. The product is the slot itself: the reader's coffee has a fixed companion, and an advertiser can buy a seat next to that habit.

Notice what this requires. Daily production, a writing team, referral programs, and a list in the hundreds of thousands before ad revenue covers salaries. The habit-slot model is a media company, not a side project. Steal the compression and the fixed schedule; do not steal the business model unless you are hiring.

The voice: Money Stuff

Matt Levine's Money Stuff goes out from Bloomberg every weekday, free, and it is the strongest argument in email that voice is a moat. The subject is securities law and market structure, which should be unreadable. Levine makes it funny in a specific, footnoted, digressive way that no other writer can fake, and readers open it for the sentences, not the news.

The money mechanism is unusual: readers pay nothing. Bloomberg pays, because Money Stuff is talent gravity for the whole Bloomberg brand. Very few writers can run this play directly, but the lesson underneath it scales down: if your voice is distinctive enough, format barely matters. Money Stuff is one enormous column of prose with almost no design at all, and nobody has ever complained.

The taste filter: NextDraft and Dense Discovery

Dave Pell has called himself Managing Editor, Internet, and NextDraft is that job made literal: each weekday he reads the news so you skim ten items with punchy section titles, each a few sentences plus a link. Still landing as of August 2026. The mechanism is a taste filter with a persona attached. You are not subscribing to news. You are subscribing to Pell's eye.

Dense Discovery is the same mechanism at a weekly cadence and a slower temperature. Kai Brach has shipped more than 400 issues since 2018: design, technology, urbanism, and books, curated with a stated point of view. The funding model matches the pace. Memberships (Friends of DD) plus small, clearly marked sponsorships, with the issue count and the funding model both read off densediscovery.com in August 2026. No growth team, no ad network, one person with taste and a deadline.

Curation is the most accessible mechanism on this list. It needs no original reporting and no rare expertise, just consistent judgment. It is also the easiest to do forgettably, which is why the persona matters: a link list without a point of view is a bookmarks folder.

The beat: Garbage Day

Ryan Broderick's Garbage Day owns a beat that mainstream outlets touch only clumsily: internet culture as its own subject, covered three times a week (Monday, Wednesday, Friday). It won a Webby, passed 100,000 subscribers with 5 to 10 percent paying, per Broderick's 2025 interview with Longlead, and has grown into an eight-person company with a podcast attached.

The mechanism is territory. Pick ground nobody else patrols seriously, then patrol it so often that anyone who cares about the subject has to read you. The freemium split follows naturally: the free issues establish the beat, the paid issues deepen it. If you have genuine expertise in a niche your industry's trade press covers badly, this is your model.

The archive: Lenny's Newsletter and Stratechery

Lenny Rachitsky's newsletter passed one million subscribers by his own 2026 count, and the Growth In Reverse teardown puts paying subscribers above 18,000. The paid product is not really this week's issue. It is the archive: years of product-management deep dives, salary surveys, and templates that a subscriber can search the day a problem hits. The price reads like a business expense because it is one; most subscribers can put it on a company card.

Ben Thompson's Stratechery built this category. One free weekly article in public, paid Updates behind the subscription, running on that split since 2014 and since expanded into a bundle of newsletters and podcasts. Thompson also proved the strategic point that matters most here: he owns the relationship. His subscribers are email addresses on his list, on his domain, under his terms.

The archive mechanism demands real expertise compounding over years. Slowest to start, strongest once running, because every issue you publish makes the product more valuable.

The lifetime: The Marginalian

Maria Popova has written The Marginalian alone since 2006, free, ad-free, funded by reader patronage. Essays on books, science, and meaning, collected into a Sunday digest. Twenty years of it.

There is no format trick to extract here, and that is the point of including it. The mechanism is accumulated trust at a scale no growth tactic reaches. Patronage works for Popova because two decades of showing up made readers feel like participants in something. If you plan to fund a newsletter by donation, understand the timescale you just signed up for.

The anatomy lesson: what the design is actually doing

Strip the nine above to their skeletons and you find three visual grammars, not nine. We built our templates as those three directions, so here is the anatomy with our own drawings as the diagram. The Postcard is the template our composer ships today; Letter and Broadsheet are the other two directions, and you can flip between all three in the live demo on our home page.

Postcard is the image-led grammar. An illustration block up top (ours has a stamp in the corner, because we are that kind of shop), a serif headline under it, a short body, and exactly one button. This is the digest and curator skeleton: it assumes the real content lives at the other end of a link, so the email's job is to make one click feel inevitable. The discipline is the single button. Add three and you have a homepage, and homepages get archived unread.

Letter is the type-only grammar. A centered small-caps letterhead over a hairline rule, an italic serif title, a salutation ("Dear reader,"), body text set in a serif with generous 1.7 line height, and a signature in place of a button. No images at all. This is the columnist and essayist skeleton, Money Stuff's and The Marginalian's shape: the words are the product, so the design's whole job is to stay out of their way and signal that a human wrote them.

Broadsheet is the edition grammar. A letterspaced uppercase masthead, then a dateline row (volume, issue number, edition name) pinned between a thin rule above and a thick rule below, then a bold headline and dense body. The newspaper feel survives on the masthead-and-dateline furniture alone. Our own browser preview of it does set two justified columns, but that is a wide-screen flourish: in a real email client everything flows as one column, because multi-column email layouts die horribly in Outlook. This is the skeleton for roundups that want institutional weight, the shape Morning Brew gestures at with its own masthead.

Two rules sit under all three directions. First, single-column discipline: every layout is one column at 600 pixels, because that is the only geometry every email client renders faithfully (the full reasoning is in our newsletter design rules). Second, the footer is a trust surface, not legal debris. Our shipped template's footer says why you are receiving this, offers unsubscribe in one click, and carries the sender's mailing address, and every campaign leaves with RFC 8058 one-click unsubscribe headers attached. Readers who trust the bottom of your email open the next one.

The pattern library: which anatomy fits which writer

Read the table backwards, too. If you want sponsorship money but publish monthly essays, the mechanism and the model are fighting each other, and the model loses.

Pick one row. Write issue one in that shape this week, and put it on a domain you own, because every newsletter above that controls its own destiny sends from its own address, not a platform's.

nostalgiapost.com.  300  IN  MX  12 route1.mx.cloudflare.net.

That single line routes mail for the domain to Cloudflare's inbound servers. Everything else about email DNS (SPF, DKIM, DMARC) is about trust and authentication; the MX record is the only one about where mail physically goes. This article covers how that resolution really works, the backup-MX myth, and the complete DNS record set for a working email domain, all shown with live records. It is part of our email deliverability handbook.

Anatomy of the record

The format is name, TTL, class, type, then two values that matter: a preference number and a target hostname.

nostalgiapost.com.  300  IN  MX  2  route3.mx.cloudflare.net.
nostalgiapost.com.  300  IN  MX  12 route1.mx.cloudflare.net.
nostalgiapost.com.  300  IN  MX  77 route2.mx.cloudflare.net.

Two rules about the target trip people up. It must be a hostname, never an IP address; the sending server resolves that hostname to an address in a separate lookup. And it must not point at a CNAME. Both restrictions come from the DNS and SMTP standards, and while some servers tolerate violations, "some servers tolerate it" is a terrible foundation for the record that receives your invoices.

The preference number is relative, not absolute. Priorities of 2, 12, and 77 behave identically to 10, 20, and 30; only the ordering counts. Cloudflare assigns those odd-looking values automatically, which is a good reminder that nobody wins points for pretty numbers here.

How resolution actually works

When a mail server has a message for your domain, the sequence is rigid. It queries DNS for your MX records, sorts them by preference ascending, and attempts SMTP delivery to the lowest number first. If that host refuses connections, it tries the next number up. Records sharing the same preference are used in random rotation, which is how large receivers spread load.

Then comes the part most explanations skip: what happens when every host is unreachable. The sender does not bounce the message. It queues it and retries on a backoff schedule, typically for days; RFC 5321's guidance is that senders should keep trying for at least 4 to 5 days before giving up. Your mail server can be down for a full weekend and, with no backup MX at all, you lose nothing. The mail arrives Monday.

Two edge cases complete the picture. A domain with no MX records is still emailable: the standard falls back to the domain's A record, the so-called implicit MX, which is why mail sometimes reaches domains whose owners never configured email. And a domain that wants no mail at all can say so explicitly with a null MX (RFC 7505): a single record with preference 0 and a target of just ., which lets senders fail immediately instead of retrying for days against a domain that will never answer.

The backup MX myth

The traditional advice says to run a secondary MX at a higher preference so mail "has somewhere to go" when your primary is down. For almost everyone, this is solving a problem retry queues already solved while creating two real ones.

The first: spammers noticed decades ago that backup MX hosts usually had weaker filtering and looser recipient checks than the primary, and started delivering straight to the highest preference number. The second: a backup that accepts mail without knowing your valid recipients must accept everything, then bounce the junk later, generating backscatter that damages your reputation on mail you never wanted.

Our position: never run your own backup MX. If you use a managed inbound service you get multiple MX hosts anyway, all with identical filtering, as the three Cloudflare records above show. That is the correct version of redundancy: three equal doors into the same system, not a poorly guarded side entrance.

What our records do all day

Those three records feed a catch-all: every address on the domain, whether it existed five minutes ago or not, routes to the same inbound pipeline, where a Worker parses the message and writes it to a database as the source of truth. An "address" in our system is a routing rule, not a mailbox you pay for, which is what makes unlimited addresses literal rather than a pricing gimmick. The pattern is worth a look even if you build it differently: catch-all email changes how you hand out addresses.

We also monitor the whole path rather than trusting it: every two hours a canary message travels through DNS, those MX records, and the parser, and we get an alert if it fails to arrive. MX records fail rarely, but "rarely" is exactly the failure you want a machine watching for.

The complete DNS set for email

MX gets mail to you. Three more records get your mail trusted by everyone else, and one optional record serves your ESP's tracking. This is the full set, with the live values from our zone (DKIM key truncated):

One nuance from our own zone: your ESP may ask you to add an MX record on a sending subdomain, ours being send.nostalgiapost.com pointing at feedback-smtp.us-east-1.amazonses.com. That is not for your inbound mail; it routes bounce reports back to the relay so your bounce processing works. Add it where they tell you and leave your root MX alone.

How SPF, DKIM, and DMARC interlock is its own subject, covered in SPF, DKIM, and DMARC explained. The short version: MX without them means you can receive but your outbound lands in spam, and since November 2025 Gmail hard-rejects unauthenticated bulk mail outright.

MX is inbound only

The most common MX misconception is that it has anything to do with sending. It does not. Outbound mail goes wherever your sending server or relay connects; your own MX records are never consulted. This split is what makes the modern architecture work: our inbound rides Cloudflare's MX hosts while our outbound goes through a sending relay, and neither system knows the other exists.

It also means changing MX records cannot break your outbound sending, and switching ESPs cannot break your inbound. When you debug a mail problem, first decide which direction is broken; it tells you which records are even relevant.

Check yours with dig

Sixty seconds, four commands, and you know the state of a domain's email DNS:

dig MX yourdomain.com +short
dig TXT yourdomain.com +short
dig TXT selector._domainkey.yourdomain.com +short
dig TXT _dmarc.yourdomain.com +short

The first should return at least one priority-and-hostname pair. The second should include exactly one line starting v=spf1. The third needs your provider's selector name (ours is resend; check your ESP's DNS setup page). The fourth should start v=DMARC1.

Run those four against your own domain now. If the MX answer is empty, your domain is receiving mail by accident through the implicit-MX fallback or not at all; either way, fix that first, because every other email record only matters once mail knows where to go.

List-Unsubscribe: <https://nostalgiapost.com/api/unsubscribe?token=9f2c...>, <mailto:unsubscribe@nostalgiapost.com?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

That pair is what "one-click unsubscribe" means technically, it is what RFC 8058 specifies, and it is what Gmail and Yahoo require from bulk senders sending commercial mail. Google's requirement took effect February 1, 2024, with June 1, 2024 as the deadline for senders who already carried some unsubscribe link; Yahoo said only that enforcement would begin in June 2024. It is also one of the cheapest deliverability wins available, because the alternative exit from your list is the spam button, and the spam button is the one that hurts. The wider context lives in our email deliverability handbook; this article is just these two headers, done properly.

What RFC 8058 actually requires

RFC 8058 (published January 2017) exists because of a quiet failure mode in the older mailto-only approach: mail software sometimes prefetches URLs found in headers, and a GET request that unsubscribes someone means people get silently removed from lists they wanted. The fix is to require deliberate semantics. Three rules do the work:

1. The List-Unsubscribe header must contain at least one HTTPS URI. A mailto alone does not qualify for one-click.
2. The List-Unsubscribe-Post header must contain exactly List-Unsubscribe=One-Click. This is the signal that the URL accepts the one-click flow.
3. When the user clicks unsubscribe in their mail client, the client sends an HTTP POST to your URL with the body List-Unsubscribe=One-Click. Your server must complete the unsubscribe on that POST, without any further interaction: no confirmation page that requires a click, no login wall, no survey first.

There is a fourth requirement that trips up home-rolled implementations: the message's DKIM signature must cover both headers. If your relay signs the message before your code adds the headers, they are outside the signature and the one-click flow is not compliant. Any competent ESP handles this ordering for you, but if you built your own pipeline, check it.

The URL itself should carry a per-recipient token, as ours does. The POST arrives with no cookie and no authenticated user, so the token is the only thing telling you who is unsubscribing. Make it unguessable, and make it work forever; a token that expires after 30 days breaks unsubscribes from old emails, which is exactly when frustrated people go looking for the spam button.

Why both URL and mailto

The HTTPS URI satisfies RFC 8058 and powers the one-click button in Gmail and Yahoo. The mailto is a fallback for clients that predate the standard or implement only the older RFC 2369 behavior: they generate an email to your unsubscribe address instead. If you include the mailto, something on your side has to actually read that mailbox and process the requests, which is why our mailto points at a real routed address and not a decoy.

Belt and suspenders, and each strap costs one header. Gmail's own bulk-sender documentation asks for one-click support; the mailto costs nothing extra and catches the stragglers. The full requirement list, including the authentication rules that come with it, is in our walkthrough of Gmail's bulk sender requirements.

The 2-day rule, and why we ignore the allowance

Google's sender guidelines require unsubscribe requests to be honored within 2 days. That is the compliance ceiling, not a design target. We process the unsubscribe the moment the POST arrives: the recipient goes onto the entity's suppression list in the same request, and that list is checked before every future send.

The reasoning is not virtue. It is that delayed unsubscribes generate complaints. A person who unsubscribed on Tuesday and receives your Thursday campaign does not think "the 48-hour window has not elapsed." They think it did not work, and they report you as spam, and now the exit you gave them for free has been converted into the expensive kind. Batch-processing unsubscribes nightly was defensible engineering in 2010. In a world where the suppression check is one indexed query, holding a fresh unsubscribe in a queue for two days buys you nothing and risks the complaint you built all of this to avoid.

The math on hiding your unsubscribe

Some senders still shrink the unsubscribe link, bury it under a login, or leave the headers off so Gmail shows no unsubscribe affordance. The theory is retention. The arithmetic says otherwise.

Gmail's complaint threshold structure gives you a target spam rate under 0.1% and a critical limit of 0.3%. At 0.1%, your budget is one complaint per 1,000 delivered emails. One. A subscriber who wants out and finds no obvious exit does not stay and read your newsletter; they click "report spam," which is always one click and never hidden. So the real trade on every tired subscriber is: an unsubscribe, which costs you a recipient who had stopped converting anyway, or a complaint, which spends your entire allowance for a thousand deliveries. Cross 0.3% and Gmail withholds delivery mitigation until you have held under the line for 7 consecutive days, degrading placement for everyone on your list, including the people who love your mail.

An unsubscribe is free. A complaint is a thousandth of your budget. Price your UX decisions accordingly, and while you are at it, stop sending to people who have gone quiet: a double opt-in at the front door and a sunset policy at the back keep the tired cohort small in the first place.

Testing yours in five minutes

Send a real campaign message to a Gmail address you control, then open it and click the three-dot menu, then "Show original." Search the raw text for List-Unsubscribe. You are checking three things: both headers are present, the List-Unsubscribe value contains an HTTPS URL (not only a mailto), and the DKIM verdict at the top of the page says PASS.

Then check the rendered message for Gmail's own unsubscribe affordance next to the sender name, and click it. Confirm the address actually lands in your suppression store, and confirm a second send skips it. When we wired this up, the end-to-end test (click, POST handled, suppression row written, next send suppressed) was the test that mattered; the headers merely being present proves formatting, not behavior.

Two headers, a POST handler, and an immediate suppression write. Ship that, and the only people leaving your list will be the ones who were already gone.

The law is one of two rulebooks. The other, enforced faster and without appeals, is mailbox-provider policy, which is why our cold email infrastructure guide treats compliance and deliverability as a single system. If you want the definitional groundwork first, what is a cold email draws those lines.

CAN-SPAM: an opt-out law

The CAN-SPAM Act of 2003 governs commercial email in the US, and the most misunderstood thing about it is what it does not require: consent. You may email a stranger. The FTC's compliance guide reduces the law to seven obligations:

1. No false or misleading header information. From, reply-to, and routing data must identify the person or business that sent the message.
2. No deceptive subject lines. The subject must reflect the content.
3. Identify the message as an advertisement. The law leaves room in how, but disguising a pitch as personal correspondence or a fake "Re:" fails the test.
4. Include a valid physical postal address. A street address, a PO box registered with the USPS, or a private mailbox registered with a commercial mail receiving agency all qualify.
5. Tell recipients how to opt out, in language a person can spot and use.
6. Honor opt-outs within 10 business days, with no fee, no login, and no request for anything beyond an email address.
7. Monitor what others send on your behalf. Hiring an agency or a sending tool does not transfer the liability.

Each non-compliant email is a separate violation, currently priced at up to $53,088 in civil penalties. That figure comes from the FTC's inflation adjustment published in the Federal Register on January 17, 2025. The FTC restates the maximum for inflation most Januaries, so check the current adjustment before you quote it back to anyone. The agency does not chase theoretical maximums against small senders, and the per-email arithmetic is still the point: a 1,000-message campaign with a missing postal address is 1,000 violations on paper.

GDPR: legitimate interest, with homework

For prospects in the EU, GDPR governs the processing of personal data, and a work email address tied to an identifiable person qualifies. Consent is one lawful basis. The one B2B outreach actually runs on is legitimate interest, Article 6(1)(f), and Recital 47 says the quiet part aloud: processing for direct marketing purposes "may be regarded as carried out for a legitimate interest."

That sentence is not a free pass. Relying on legitimate interest obligates you to run and document a balancing test (a legitimate interest assessment): a genuine interest, a real need to use email specifically, and a balance that does not override the recipient's rights. Emailing someone in their professional capacity about their professional responsibilities strengthens that balance; scraping personal Gmail addresses collapses it. You must also disclose where you got the address, make objection easy, and delete on request. The penalty ceiling under Article 83 is EUR 20 million or 4% of global annual revenue, whichever is higher.

GDPR is also not the whole picture. The ePrivacy Directive (2002) governs the sending itself, and every member state implemented it as national law, so the practical answer changes at each border. Germany's unfair-competition law (UWG) requires prior consent for commercial email even in B2B; a cold pitch to a CEO in Munich needs the same consent as a consumer campaign. The UK's PECR exempts corporate subscribers, so email to a company address is permitted with identification and a working opt-out. France's CNIL accepts legitimate interest for B2B with a strict opt-out. The soft opt-in that appears across these regimes covers only existing customers, which by definition never describes a cold prospect. Check the target country before the list is built, and drop the strict-consent countries unless you have counsel.

CASL: the strict one

Canada's anti-spam law, in force since July 2014, is a consent regime. Commercial email requires consent before sending, and the burden of proving it sits with the sender.

Express consent means an affirmative act, like a checkbox the person ticked themselves; it never expires unless withdrawn. Implied consent is the narrow door cold email must fit through: a recent existing business relationship within time windows the act fixes, or an email address the person conspicuously published in a business capacity, with no note refusing solicitations, and a message relevant to that person's role. "I found it on LinkedIn" does not, by itself, meet the test.

Every message still needs sender identification and an unsubscribe honored within 10 business days. Penalties reach CAD $1 million per violation for individuals and CAD $10 million for organizations, and directors and officers can be personally liable. Our stance: unless a Canadian prospect plainly published their address in a role relevant to your pitch, or you have genuine prior dealings, leave Canadian addresses out of the sequence.

Mailbox providers enforce stricter rules than the law

A campaign can satisfy every statute above and still land entirely in spam. Gmail's bulk-sender rules (February 2024) demand aligned SPF, DKIM, and DMARC, a spam-complaint rate under 0.3% with a target under 0.1%, and RFC 8058 one-click unsubscribe on bulk mail. Since November 2025, Gmail hard-rejects unauthenticated mail with a 550 error; Microsoft has done the same since May 2025. Nothing in CAN-SPAM requires authentication. The inbox does.

The statutes allow 10 business days for an opt-out; honor it in seconds anyway. In our workspace an unsubscribe lands on a suppression list that is checked before every future send and never expires, and the send path pauses itself at 0.3% complaints or 2% bounces. Provider penalties arrive in days, legal ones in years, and only one of those timelines waits for your lawyer.

The compliance checklist

Every regime above compresses into one working list:

• Send from a domain that identifies your company. A lookalike outreach domain is fine when it discloses who owns it.
• Real From name, real company, working reply address. No forged headers, no fake "Re:".
• A subject line the body can back up.
• A physical postal address in every message.
• A one-sentence opt-out in every message, honored immediately and permanently.
• A record of where every address came from and why you may email it. GDPR makes you disclose the source; CASL makes you prove the consent.
• A country check before sending: US, opt-out rules apply. UK, corporate addresses are fair game. Germany, consent first. Canada, consent first.
• Volume discipline and complaint monitoring, per how many cold emails per day. The strictest regulator you answer to is Gmail.

Read the rules for your target countries before the list exists, and when a deal is worth real money, spend the hour with counsel. It costs less than one email at $53,088.

The more useful part is why, because IMAP vs POP3 is really a fight between two decades. Each protocol is a snapshot of what a personal computer was at the moment it was designed, and every practical difference between them falls out of that.

Both protocols handle the reading half of email; neither one sends anything. If you are standing up mail on your own domain from scratch, our business email setup guide walks the whole stack, DNS records included. This article is the layer where mail reaches your devices.

Built for different computers

The Post Office Protocol came first: RFC 918, published October 1984 and marked experimental. The computer it imagines is a workstation that is not always connected to the network. Mail piles up on a server; the workstation connects, downloads everything, deletes the server copies, and disconnects. Server storage was scarce, and your own machine was assumed to be the real home of your mail. The server is a post office box, and the protocol is the trip into town to empty it.

POP3, the version everything still uses, was pinned down in RFC 1939 in May 1996. It is a genuinely tiny protocol: USER, PASS, STAT, LIST, RETR, DELE, and QUIT cover a normal session. Nothing in it describes folders, read state, or search, because your local mail program was expected to handle all of that after the download.

IMAP began in 1985 at Stanford, designed by Mark Crispin, and it flips the core assumption: the mailbox lives on the server permanently, and a mail client is a window onto it. Read and unread state, folders, flags, and search all exist server-side, so any number of windows can point at the same mailbox and agree about what they see. The protocol is still maintained four decades on; the current base specification is IMAP4rev2 (RFC 9051), published August 2021.

POP3 moves the mailbox to your device. IMAP moves your view to the mailbox. Everything in the next table is downstream of that sentence.

Sync vs download, in one table

The POP3 vs IMAP choice compresses into seven rows.

The classic POP3 failure is a phone and a laptop on the same account. Each device downloads independently, so whichever checks first takes the mail, and the other may never see it. Clients patch this with a "leave a copy on the server" setting, which fixes the disappearing messages and nothing else: read state still lives per device, sent mail exists only on the machine that wrote it, and deleting a message on one device leaves it sitting on the other. That patched setup is half of IMAP with none of the coordination, which is why providers stopped recommending it years ago.

SMTP vs IMAP is a category error

"SMTP vs IMAP" is a heavily searched comparison, and it compares the delivery truck to the front door. IMAP and POP3 are retrieval protocols: they exist so your client can read a mailbox. SMTP is the transfer protocol: your client submits outgoing mail over SMTP on port 587, and servers hand mail to each other over SMTP on port 25. Every working email setup uses SMTP for sending plus exactly one of IMAP or POP3 for reading. There is no choice between them; the real choice was the one above.

The two reasons POP3 still exists

Case one is single-device control. With download-and-delete POP3, the server holds your mail only between checks; after that, the sole copy lives on hardware you own. People who treat a mail host as an untrusted relay rather than a storage service want exactly this, and it is a legitimate want: there is no provider-side archive to scan, subpoena, or breach. The cost is symmetrical, and you should hear it as a warning: with no server copy, one dead laptop drive ends your entire mail archive. POP3 without a backup routine is a countdown.

Case two is mailbox quotas. Budget shared hosting still hands out mailboxes measured in hundreds of megabytes. On IMAP, a quota that small eventually fills, and once it fills, new inbound mail starts bouncing. POP3 drains the mailbox on every check, so a tiny quota never fills no matter how much mail flows through it. Inelegant but effective, and still the standard advice on hosts with hard mailbox limits.

There are stragglers beyond those two: old scanners and appliances that only speak POP3, and scripts that eat a mailbox and delete as they go. If you have not recognized yourself by now, the answer is IMAP.

Ports and TLS: the reference table

Since RFC 8314 (published January 2018) the recommendation is implicit TLS everywhere: the connection is encrypted from the first byte instead of starting in plaintext and upgrading with STARTTLS. In practice that means 993 for IMAP, 995 for POP3, and 587 or 465 for sending. A config screen asking for port 143 or 110 with encryption set to "none" is a setup guide from another era. Close the tab.

Team email: whether you want a protocol at all

Both protocols assume one person, one mailbox, one password. That assumption is collapsing from two directions.

Providers closed the password door first. Microsoft permanently disabled basic authentication for IMAP and POP in Exchange Online in the first week of January 2023. Google turned off password-only access to IMAP, POP, and SMTP on September 30, 2024; third-party clients now have to authenticate with OAuth. Both changes were about credential theft, and the practical effect is that type-your-password-into-any-client IMAP no longer exists at the two largest business mail hosts.

Teams break the model from the other side. Point five people's clients at one shared IMAP mailbox and you get colliding read flags, no record of who took which message, and eventually two different answers sent to the same customer. The protocol has no concept of a team. A shared inbox is shared state with history and assignment, and shared state wants an application, not a retrieval protocol from 1984.

We build on the web side of that line, so weigh the stance accordingly: LetterDuck has no IMAP access today. Inbound mail for a domain arrives on a catch-all route, gets parsed once, and lands in a database that everyone on the team reads through the same threaded inbox; replies can go out as any address on the domain. An address in that model is a routing rule rather than a mailbox with its own credentials, which is why we do not count or bill them. The tradeoff points the other way too: if two decades of your workflow live in Thunderbird, a web workspace is a genuine migration, and you should choose a host that speaks your protocol instead.

So: IMAP on 993 for a person. POP3 on 995 only if you can name your reason, and back up the archive the day you switch it on. And if the address belongs to a team rather than a person, the honest answer to IMAP vs POP3 is neither; compare workspaces instead.