The email glossary

Thirty-five terms, defined the way we use them running live mail infrastructure: what each one is, why it matters, and the number attached when one exists. Every heading below is a stable anchor (#dmarc always lands on DMARC), so link to entries freely. Where a full article exists, the entry ends with a pointer.

Authentication

DMARC

Domain-based Message Authentication, Reporting and Conformance: a DNS TXT record that tells receiving servers what to do with mail that claims your domain but fails SPF and DKIM alignment. Three policies: p=none (just report), p=quarantine (spam folder), p=reject (refuse it). The reports are the underrated half; they show you everyone sending as your domain, legitimate or not. Treat DMARC as a progression, not a checkbox: publish p=none, read the reports for a few weeks, then tighten. We learned how easily alignment breaks: in June 2026, Gmail silently rejected 73% of the mail we mirrored through Cloudflare's forwarding, because forwarding breaks DMARC. No error appeared on our side. The mail just vanished. Go deeper: what is DMARC.

SPF

Sender Policy Framework: a DNS TXT record listing the servers allowed to send mail for your domain. Receivers check the connecting IP against that list. One record per domain, and it stops evaluating after 10 DNS lookups, which is the classic silent failure: stack enough include: mechanisms from your providers and the record breaks with no visible error. SPF also fails on forwarded mail, because the forwarder's IP is not on your list; that gap is what DKIM covers. A minimal record looks like v=spf1 include:_spf.example.com ~all. Go deeper: SPF records.

DKIM

DomainKeys Identified Mail: your sending server signs each message with a private key, and a TXT record at selector._domainkey.yourdomain publishes the public key so receivers can verify the signature. Unlike SPF, a DKIM signature usually survives forwarding, because it travels with the message instead of depending on the connecting IP. Use 2048-bit keys; 1024-bit keys are still common and still weak. A valid signature proves the message was authorized by the domain and not altered in transit, and it is one of the two signals DMARC alignment is built on. Go deeper: what is DKIM.

Email authentication

The umbrella for SPF, DKIM and DMARC working together, plus the supporting cast: a PTR record on the sending IP and TLS in transit. For years, failing authentication meant the spam folder. Now it means the mail does not arrive at all: Microsoft (May 2025) and Gmail (November 2025) return 550 hard rejections for unauthenticated mail. That is the authentication cliff, and it applies at any volume, not only to bulk senders. Set up all three before the first send; retrofitting a reputation is far slower than earning one. Go deeper: SPF, DKIM and DMARC together.

BIMI

Brand Indicators for Message Identification: a DNS record that lets participating mailbox providers display your logo next to authenticated mail. The requirements are the real story: DMARC at enforcement (p=quarantine or p=reject), and for Gmail a Verified Mark Certificate tied to a registered trademark, paid annually. BIMI changes how mail looks after it lands, not whether it lands, so it is a trust signal rather than a deliverability lever. Get to p=reject for its own sake and treat the logo as a side effect.

Reputation and delivery

Deliverability

Whether your mail reaches the inbox. Not the same as delivery: a message can be accepted by the receiving server and still land in spam. Deliverability is the product of authentication, domain reputation, list quality and content, and it is measured in the receiving provider's data, not in yours. The floor: SPF, DKIM and DMARC in place, spam complaints under 0.1%, bounces under 2%. Everything else in this glossary exists in service of this one word. Go deeper: the email deliverability guide.

Warm-up

Raising volume gradually on a new domain so mailbox providers see history before they see scale. The ramp our throttle computes, taken from Resend's documented schedule: about 150 sends on day one, multiplied by roughly 1.4 a day, reaching about 1,100 by day seven, then 10 to 20% more per day. What the send path enforces is the lower of that curve and the relay ceiling, which is 95 a day on our current plan. New-domain reputation matures over 4 to 8 weeks, and gaps hurt: consistency is itself a signal providers read. Go deeper: email warm-up.

IP reputation

The score mailbox providers keep on a sending IP address: its history of complaints, bounces, spam-trap hits and volume patterns. On a shared relay pool the IP arrives warm and the provider maintains it, which is exactly why shared pools are the right call at low volume. IP reputation only becomes your problem when you take a dedicated IP, and a dedicated IP below about 50,000 emails a month cannot be kept warm. Until then, the reputation you are actually building is your domain's.

Domain reputation

The score attached to your domain rather than to the IP it sends from. It follows you across providers, which makes it the asset worth protecting: switch sending platforms and your IP reputation resets, but your domain history comes along. It matures over 4 to 8 weeks of consistent sending. One catch in measuring it: Google retired Postmaster Tools' reputation dashboards around October 2025, so the spam-rate chart is now the working proxy. And subdomain behavior rolls up: a subdomain is isolation, not a wall.

Spam complaint rate

The share of delivered mail that recipients mark as spam. The two numbers to memorize, from Google's bulk sender rules (February 2024): stay under 0.1%, and never reach 0.3%. At or above 0.3%, Gmail withholds delivery mitigation until you are back under it for seven consecutive days. There is no appeals process; there is only the math. Our send path pauses itself at 0.3% with no human in the loop, because by the time a human notices, the damage is compounding. Go deeper: spam complaint rate.

Bounce rate

The share of sends the receiving server refuses. Keep it under 2%; above that, providers read your list as stale or purchased. The consequences scale with your provider's patience: AWS SES pauses entire accounts at 5% bounce or 0.1% complaints. Bounce rate is also the cheapest metric to fix, because it is entirely a list-quality problem: double opt-in on the way in, suppression on the way out. Go deeper: hard bounce vs soft bounce.

Hard bounce

A permanent delivery failure, usually a 550-class SMTP rejection: the address does not exist, the domain has no mail server, or the receiver has blocked you outright. The policy is simple and non-negotiable: suppress a hard-bounced address after one failure and never mail it again. Repeatedly hitting dead addresses is the signature of a purchased list, and mailbox providers score it exactly that way.

Soft bounce

A temporary delivery failure: the mailbox is full, the server is down, or the receiver is greylisting you (deferring first contact to test whether you retry like a real mail server). Soft bounces deserve patience, then a limit. Our policy: retry about three times over 14 days, then treat the address as a hard bounce and suppress it. A soft bounce that never resolves was a hard bounce with extra steps.

Feedback loop

A mailbox provider's channel for telling you which recipients marked your mail as spam so you can stop mailing them. Yahoo's Complaint Feedback Loop (which also covers AOL) and Microsoft's JMRP send per-complaint reports; enroll in both, they are free. Google offers no traditional feedback loop at all: instead you stamp a Feedback-ID header on every send and watch the aggregate spam rate in Postmaster Tools, which is what we do. Every complaint a loop reports should land on your suppression list the same day. Go deeper: Google Postmaster Tools.

Seed testing

Sending a campaign to a panel of addresses you control across Gmail, Outlook, Yahoo and the rest, to see where it lands before real recipients get it. The free version is mail-tester.com as a pre-send gate; the paid version is GlockApps or Validity Everest with true seed panels. The known limitation: seed addresses have no engagement history with you, so results skew pessimistic for a well-loved list and optimistic for a cold one. Useful signal, not gospel.

Engagement rate

How recipients interact with your mail, weighted the way mailbox providers weight it: replies count most, then clicks, then opens. Opens are the weakest signal and getting weaker, because Apple Mail Privacy Protection auto-fetches images and inflates opens across a large slice of any consumer list. We score on clicks and replies and never on opens. Two provider quirks worth knowing: Gmail rewards recent engagement, Outlook rewards a long consistent history. Go deeper: what open rates actually tell you.

Dedicated IP

An IP address only you send from, so its reputation is entirely yours. That sounds like control and is mostly a liability at small scale, because an IP needs steady volume to stay warm. The industry guidance is blunt: Postmark suggests around 300,000 emails a month before a dedicated IP makes sense, and AWS SES talks in terms of 100,000 a day. Below roughly 50,000 a month, we think a dedicated IP is a mistake. Stay on the shared pool and warm your domain instead.

Shared IP

An IP pool used by many senders at once, with its reputation maintained by the provider. The pool arrives warm, which is the only reason a new domain can send anything on day one. The tradeoff is neighbors: a bad sender in the pool dents it for everyone, so a provider that polices its pool is a deliverability feature you are quietly paying for. On shared IPs, the reputation you own and carry with you is your domain's.

Lists and consent

Suppression list

The do-not-send list: every hard bounce, spam complaint and unsubscribe, checked before every single send. One global list per sending entity, with no per-campaign exceptions. A suppression list is the memory that stops you from making the same mistake twice; without it, every send re-offends the same addresses and the damage compounds. We built auto-suppression before we needed it, because AWS SES pauses whole accounts at 5% bounce or 0.1% complaints, and by then it is too late to start.

List-Unsubscribe

The header pair that puts an unsubscribe action in the mail client's own interface: one click, no hunting through the footer. RFC 8058 one-click means sending both List-Unsubscribe: <https://...>, <mailto:...> and List-Unsubscribe-Post: List-Unsubscribe=One-Click. Gmail and Yahoo require it from bulk senders and allow two days to honor the request; we honor it immediately, because someone who wants out is one annoyance away from the spam button, and a complaint costs far more than an unsubscribe. Go deeper: the List-Unsubscribe header.

Double opt-in

Signup happens twice: the form, then a confirmation click in an email before the address joins your list. You trade list size for list quality, and the trade repays itself in every metric that matters: bounces fall because typos never confirm, complaints fall because nobody forgets subscribing twice, and most bots fail the second step. It also leaves you a provable consent record for every address you hold. Go deeper: double opt-in.

Sunset policy

The rule for when you stop mailing subscribers who stopped reading. Ours: no engagement in 60 to 90 days moves an address out of regular sends, with one win-back attempt before removal. It feels like shrinking your list. It is actually protecting it: mailbox providers grade you on the ratio of engaged recipients to mailed recipients, not on the raw count, and the disengaged drag the ratio down with every send.

List hygiene

The ongoing upkeep that keeps a list sendable: suppress hard bounces permanently, retry soft bounces about three times over 14 days, reject role accounts (info@, admin@, postmaster@, abuse@) at signup, confirm with double opt-in, and sunset 60-to-90-day inactives. The whole routine serves two targets: bounce rate under 2%, complaints under 0.1%. Hygiene is boring on purpose. A list you do nothing to gets worse every month on its own.

Infrastructure

Catch-all email

A routing rule that accepts mail sent to any address at your domain, whether or not that address was ever created. It is how our own inbound works: a catch-all routes every address on the domain to a Cloudflare Email Worker, the raw message is parsed once, and the result is stored as the source of truth. It is also why unlimited addresses can be literal: an address is a routing rule, not a paid seat. Two caveats: a catch-all collects spam aimed at guessed addresses, and verification tools flag catch-all domains as risky because every address on them looks deliverable. Go deeper: catch-all email.

MX record

The DNS record that names the servers receiving mail for your domain, with a priority number per entry: lowest wins, the rest are fallbacks. No MX record, no inbound mail, and a wrong one loses mail silently. That silence is why our inbound watchdog exists: every two hours a canary message round-trips our real inbound path, DNS included, and the owner gets an alert if it fails to arrive. Silence means healthy. Go deeper: MX records.

PTR record

Reverse DNS: the record that maps a sending IP back to a hostname, the mirror image of an A record. Receivers check that the IP you connect from resolves to a name that resolves back again (forward-confirmed reverse DNS), and Google's sender guidelines require it outright. On a relay or hosted platform the provider owns the PTR and you never touch it. If you self-host a mail server, your hosting provider has to set it, and many cheap-VPS and residential IPs simply cannot pass the check.

Email alias

An additional address that delivers into an existing mailbox: press@, billing@ and yourname@ can all land in one place without being separate accounts. The distinction that costs money: seat-priced providers charge per mailbox, and aliases are the escape valve. In a routing-based system every address is effectively an alias, created in one click and pointed anywhere. Use a distinct alias per function, because each one can be filtered, handed off, or killed independently. Go deeper: email aliases.

Shared inbox

One mailbox several people work out of: support@, hello@, sales@. The difference from a distribution list, which copies each message into everyone's personal inbox, is that a shared inbox holds one canonical copy of the thread, so two people cannot answer the same message without seeing each other's reply. At small-team scale the feature that matters is visible reply state, not assignment workflows. Go deeper: shared inboxes.

ESP

Email service provider. The term gets used two ways, which causes real confusion: mailbox providers that receive and host mail (Gmail, Outlook, Yahoo) and sending platforms that dispatch it for you (Mailchimp, SendGrid, Resend). In deliverability writing, ESP almost always means the sending platform, and "mailbox provider" names the receiving side. Your ESP choice matters most for its shared IP pool, because its worst customers are, temporarily, your neighbors.

SMTP

Simple Mail Transfer Protocol: the protocol mail servers use to hand messages to each other. Every send ends up as an SMTP conversation, whatever friendly API sits in front of it. The reply codes are the working vocabulary of deliverability: 250 means accepted, 4xx means try again later (the mechanism behind greylisting and soft bounces), and 550-class codes mean permanent refusal, which covers hard bounces and, since 2025, unauthenticated mail at Gmail and Microsoft. Go deeper: what is SMTP.

IMAP

Internet Message Access Protocol: how a mail client reads a mailbox that lives on the server. State syncs both ways, so a message read on your phone shows as read on your laptop, and folders exist server-side. The contrast is POP3, which downloads mail to one device and typically deletes the server copy. If you are choosing today, choose IMAP; POP3 survives mainly in legacy setups and single-device edge cases. Go deeper: IMAP vs POP3.

Sending

Transactional email

Mail that a specific action triggers for one recipient: receipts, password resets, magic links, shipping notices. Recipients expect it within seconds, which is why the cardinal rule is stream separation: keep transactional mail on its own domain or subdomain, away from bulk sends, so a newsletter's bad week cannot sink your password resets. Transactional mail is also exempt from most consent mechanics; nobody puts an unsubscribe link on a receipt. Smuggle marketing content into it and the exemption is forfeit.

Bulk sender

Gmail's formal category: senders of 5,000 or more messages a day to Gmail addresses, which triggers the February 2024 requirements in full (authentication, one-click unsubscribe, complaint thresholds). The 5,000 line is the most misread number in email. It marks where enforcement gets formal, not where the rules begin: unauthenticated mail is hard-rejected at any volume, and complaint math works the same at 50 sends a day. We follow the bulk sender rules at dozens of sends a day, on purpose. Go deeper: Gmail's bulk sender requirements.

Plain-text email

Mail with no HTML at all, or the plain-text half of a properly built message. The rule we enforce in our own template: every send is multipart/alternative with a real plain-text part, never HTML alone and never image-only. Filters distrust HTML-only mail, some clients and most smartwatches render only the text part, and it is what many screen readers get. Keep the text-to-image ratio at 60:40 or better. Go deeper: plain text vs HTML email.

Reply-To

The header naming where replies should go when that differs from the From address: a newsletter sent from news@yourdomain can steer replies to an inbox a human reads. Use it deliberately, because replies are the single strongest engagement signal a mailbox provider sees, and a Reply-To pointing at noreply@ throws that signal away. Keep it on your own domain; a cross-domain mismatch is a pattern phishing filters watch for. Our replies also carry In-Reply-To and References headers, so the conversation threads correctly in the recipient's client. Reply-To decides where it continues.