Email infrastructure glossary

SPF

Sender Policy Framework · RFC 7208

A DNS-published list of which IP addresses are allowed to send email from your domain. Receivers look up your domain's TXT record at the apex, find v=spf1 …, and check whether the connecting IP is in that list. If not, your mail looks suspicious — and gets penalized.

your-domain.com.  TXT  "v=spf1 include:_spf.relayly.io ~all"

The ~all at the end is a soft-fail (mark as suspicious but accept). Use -all only when you're confident every legitimate sender is whitelisted, otherwise you'll bounce real mail.

Why it matters.

Without SPF, anyone can send mail "from" your domain and recipients have no way to tell. Big providers (Gmail, Yahoo, Microsoft) increasingly require it for bulk senders.

DKIM

DomainKeys Identified Mail · RFC 6376

A cryptographic signature added to email headers, signed with a private key only you control. Recipients fetch your public key from DNS and verify the signature. If it matches, they know the message hasn't been tampered with and the signing domain is legitimate.

esp1._domainkey.your-domain.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg…"

The selector (esp1) lets you rotate keys without breaking historical mail. Each ESP usually has its own selector — Relayly uses esp1, SendGrid uses s1, etc.

Why it matters.

DKIM is the strongest of the three "you really sent this" signals. DMARC builds on top of it — without DKIM alignment, DMARC fails.

DMARC

Domain-based Message Authentication, Reporting & Conformance · RFC 7489

The policy layer on top of SPF and DKIM. It tells receivers what to do when authentication fails (p=none, p=quarantine, p=reject) and where to send aggregate reports about who's sending mail claiming to be you.

_dmarc.your-domain.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@your-domain.com; pct=100"

Start at p=none with a working rua address, monitor reports for a couple weeks, then escalate to p=quarantine and eventually p=reject. Going straight to reject on a domain you haven't profiled will drop legitimate mail.

Why it matters.

Gmail and Yahoo's bulk-sender requirements (effective 2024) require at least p=none with a valid rua. No DMARC means deliverability rate caps regardless of how clean your list is.

MTA-STS

SMTP MTA Strict Transport Security · RFC 8461

A standard that says "always use TLS to deliver mail to me, and here's where to fetch the policy that proves it." Senders fetch https://mta-sts.your-domain.com/.well-known/mta-sts.txt, verify the signature against your DNS-published policy ID, and refuse to deliver mail in plaintext.

_mta-sts.your-domain.com.  TXT  "v=STSv1; id=20260301T000000Z;"
mta-sts.your-domain.com.   A    <your TLS-serving IP>

Plus the policy file itself, served over HTTPS at /.well-known/mta-sts.txt on the mta-sts. subdomain.

Why it matters.

Without MTA-STS, an attacker on the network path can downgrade your mail to plaintext SMTP. Gmail and Microsoft give a small reputation bump for publishing it.

TLS-RPT

SMTP TLS Reporting · RFC 8460

A companion to MTA-STS: a DNS record telling receivers where to send aggregate reports about TLS handshake failures and policy violations.

_smtp._tls.your-domain.com.  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@your-domain.com"

Reports are JSON, sent daily, look like a list of { "policy-domain": "...", "summary": { "total-success-session-count": 12453, "total-failure-session-count": 0 } }.

Why it matters.

Gives you visibility into TLS-downgrade attempts and configuration drift. Without it you'd never know.

BIMI

Brand Indicators for Message Identification

A standard for displaying your brand logo next to your messages in supporting inboxes (Gmail, Apple Mail, Yahoo). Requires a Verified Mark Certificate (VMC) from a CA, plus a square SVG hosted at a known URL.

default._bimi.your-domain.com.  TXT  "v=BIMI1; l=https://your-domain.com/bimi.svg; a=https://your-domain.com/bimi-vmc.pem"

The VMC costs $1,500-$2,000/year from DigiCert or Entrust. Worth it for B2C brands; usually not for B2B SaaS.

Why it matters.

Logo-in-inbox is a real engagement boost — open rates rise 5-12% in tests we've seen. Also a strong "we're a real company" signal.

MX record

Mail Exchanger record

The DNS record that tells the rest of the internet which servers receive mail for your domain. Specifies one or more hostnames with priority numbers; lower priority is preferred.

your-domain.com.  MX  10  mx1.relayly.io.
your-domain.com.  MX  20  mx2.relayly.io.

Senders try the lowest-priority host first, fall back to the next on failure. Each MX hostname needs its own A/AAAA record.

Why it matters.

If you publish an MX record, the world expects mail delivery to work. If your MX points at infrastructure that 5xx's, every sender on earth thinks you're broken.

ARC

Authenticated Received Chain · RFC 8617

A way for forwarding services (mailing lists, calendar invites that get forwarded, etc.) to preserve the authentication state of an email even after they've modified it. Each forwarder adds an ARC-Seal header signed with their own DKIM-style key.

If a recipient sees a chain of ARC seals from trusted forwarders, they can give the message DMARC-pass treatment even if the standalone DKIM/SPF would fail.

Why it matters.

Without ARC, mailing-list-forwarded mail breaks DMARC and gets dumped to spam. With it, the chain is preserved.

FBL

Feedback Loop

A back-channel where mailbox providers tell senders "this recipient pressed Spam." You enroll once per provider; from then on, every spam-marking flows to your suppression list within minutes.

Major FBLs:

Yahoo CFL (Complaint Feedback Loop) — for yahoo.com, aol.com, sky.com
Microsoft JMRP (Junk Mail Reporting Program) — for outlook.com, hotmail.com, live.com
Google Postmaster Tools — aggregate-only, no per-message reports

Why it matters.

If you keep mailing recipients who marked you as spam, your reputation tanks. FBL ingest is the difference between a 0.05% complaint rate and a 1% one.

SNDS

Smart Network Data Services (Microsoft)

Microsoft's per-IP reputation portal. Shows you the spam-rate, RCPT-success-rate, and complaint-rate for each of your sending IPs as seen by Hotmail/Outlook over the last 30 days.

To enroll, request access at sendersupport.olc.protection.outlook.com/snds, prove control of your IP block (Microsoft sends a verification email to postmaster@), and your data starts populating within 24h.

Why it matters.

Microsoft's filters are aggressive on unauthenticated mail. SNDS gives you the per-IP signal you'd otherwise have to infer from bounce patterns.

JMRP

Junk Mail Reporting Program (Microsoft)

Microsoft's per-message FBL. When an outlook.com / hotmail.com user clicks "Junk", Microsoft sends you an ARF-formatted complaint message identifying the original message-id and recipient.

Enroll at sendersupport.olc.protection.outlook.com/snds/JMRP.aspx. You need an authenticated postmaster@ address on each domain.

Why it matters.

Without JMRP, you'd find out about a spam complaint when your delivery rate to Outlook tanks. With it, you suppress the recipient before sending again.

Google Postmaster Tools

Google's deliverability dashboard for senders. Shows IP/domain reputation (Bad/Low/Medium/High), authentication-pass rates (SPF, DKIM, DMARC), spam complaint rate, encryption (TLS) rate, and feedback loop volume — but only for domains sending >5,000 to Gmail per day.

Enroll at postmaster.google.com. Verify domain ownership via DNS TXT or HTML file.

Why it matters.

Google's filtering is the most consequential of any mailbox provider; this is the only way to see how Google sees you.

RFC 8058

One-Click List Unsubscribe

The standard for "click here, you're unsubscribed, no further confirmation needed." Combines two headers:

List-Unsubscribe: <https://relayly.io/u/abc123>, <mailto:unsubscribe+abc123@relayly.io>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Gmail and Yahoo's 2024 bulk-sender requirements mandate this for any sender doing >5,000 messages/day. Missing it means rate-capping at the recipient side, regardless of content.

Why it matters.

Hard requirement for B2C scale senders. Relayly enables it on every send by default.

List-Unsubscribe header

RFC 2369

The original (pre-2017) header that gives mail clients a known URL or mailto where the user can unsubscribe. Mail clients render it as a "Unsubscribe" link or button at the top of the message.

RFC 8058 extends this with the one-click POST requirement; both should be present for modern senders.

Why it matters.

Easier unsubscribe = lower spam-complaint rate. Cynically: making the user dig for the unsubscribe link gets you reported as spam instead.

DSN

Delivery Status Notification · RFC 3464

A structured machine-readable bounce message. When the recipient server can't deliver, the sending MTA receives a DSN with status codes that indicate the cause — temporary vs permanent, and the SMTP error class.

The Status: field follows the X.Y.Z format from RFC 3463. 5.x.x = permanent, 4.x.x = transient.

Why it matters.

Without parsing DSNs, you can't tell a hard bounce from a soft one — and you'll keep retrying messages that will never deliver, burning reputation.

Hard bounce

A permanent delivery failure — the recipient address doesn't exist, the domain doesn't exist, or the recipient mailbox is closed. SMTP response code 5.x.x.

Hard-bounced addresses must be removed from all future sends. Mailing them again damages your reputation and is, for B2C, generally illegal under GDPR/CAN-SPAM.

Why it matters.

One hard bounce per 1,000 sends is normal. More than 5 per 1,000 indicates a list-quality problem; mailbox providers will notice and rate-cap you.

Soft bounce

A temporary delivery failure — the mailbox is full, the recipient server is busy, the message is too large, or some short-term policy is rejecting. SMTP response code 4.x.x.

Convention: retry up to N times (3-5) over 24-72 hours, then convert to hard bounce. Don't suppress on the first soft bounce — the recipient might just be temporarily over quota.

Why it matters.

Treating soft bounces as hard bounces over-suppresses your list. Treating them as if they'll always recover never suppresses anyone.

Suppression list

The set of email addresses your sending platform will refuse to mail. Populated automatically from hard bounces, complaints (FBL), and unsubscribes. Scoped per account.

Sending platforms short-circuit at API time when an address hits the suppression list — the request returns 422 suppressed instead of the message getting queued.

Why it matters.

Auto-suppression is the difference between staying off blocklists and ending up on them. Manually managing this at scale is impossible.

IP warmup

Gradually ramping up send volume on a new dedicated IP so mailbox providers can build a reputation profile. New IPs with sudden 100k-volume blasts get filtered as suspicious.

Standard curve: day 1 = 50 sends, double daily for a week, then ramp by ~50% per day until you hit the IP's eventual cap. Modulate based on per-provider delivery success — if Gmail starts deferring, slow down for Gmail specifically.

Why it matters.

Skipping warmup is the single most common reason new IPs get blocklisted. The 14-day pain curve buys you years of clean reputation.

Dedicated IP

A sending IP allocated to a single account. Reputation is fully under your control — no co-tenants damaging it, no one else benefiting from your good behavior.

Worth it once you're sending consistent volume (typically >50k/month). Below that, your IP doesn't get enough send signals for mailbox providers to form a reputation, and a shared IP pool actually performs better.

Why it matters.

If you have B2B regulated customers, dedicated IPs are often a contractual requirement. Otherwise it's a function of volume and sender hygiene.

Shared IP pool

A set of sending IPs used by many accounts simultaneously. Reputation is collective; one bad actor can hurt everyone.

Quality ESPs vet the senders allowed onto their shared pool — checking content, list quality, and complaint rates. Cheap ESPs don't, which is why their shared-pool deliverability is poor.

Why it matters.

For low-volume senders, a well-curated shared pool delivers better than an under-warmed dedicated IP. The upper limit is the responsibility of the ESP.

Return-Path

Also called "Bounce address" or "Envelope From"

The address SMTP uses for MAIL FROM: — i.e., where bounces are delivered. Not the same as the visible From: header.

For DMARC alignment to work in aspf=relaxed mode, the Return-Path domain must share an organizational root with the visible From domain. This is why you'd publish a bounce.your-domain.com CNAME pointing at your ESP's bounce processor.

Why it matters.

Mismatch between Return-Path and From causes DMARC SPF-alignment failure, which means recipients don't trust your mail.

Envelope From

Same as Return-Path — the address SMTP uses for MAIL FROM: at the protocol level. The user never sees this; it's how mail servers route bounces.

Header From

The From: field in the message headers — what the recipient sees in their inbox UI. Different from the Envelope From / Return-Path used at the SMTP layer.

DMARC alignment compares this Header From domain against the SPF-validated Envelope From domain and the DKIM-signed d= domain.

ESP

Email Service Provider

A company or platform whose product is to send email on behalf of customers. Examples: SendGrid, Mailgun, Postmark, Resend, Mailchimp, Klaviyo, and yes, Relayly.

"Transactional ESP" usually means API-first, send-on-event focused. "Marketing ESP" usually means lists, segments, and campaigns. The distinction is increasingly artificial — most modern ESPs do both.

MTA

Mail Transfer Agent

The actual server software that speaks SMTP and moves mail between systems. Postfix, Exim, Sendmail, Haraka, and Microsoft Exchange are all MTAs.

An ESP that runs its own MTAs (vs wrapping AWS SES under a control plane) has direct control over the SMTP transaction, retry logic, and per-IP routing decisions.

MUA

Mail User Agent

The mail client. Apple Mail, Gmail web, Outlook, Thunderbird, mutt — anything a human reads mail in.

SMTP

Simple Mail Transfer Protocol · RFC 5321

The wire protocol that moves email between MTAs. Plain-text command/response (until upgraded to TLS), runs on port 25 (server-to-server) or 587 (client-to-server submission).

An SMTP transaction looks like:

EHLO sender.example
MAIL FROM:<sender@example.com>
RCPT TO:<recipient@example.org>
DATA
… message headers and body …
.

STARTTLS

SMTP TLS upgrade · RFC 3207

The mechanism for upgrading a plaintext SMTP connection to TLS mid-handshake. The server advertises STARTTLS in its EHLO response; the client issues STARTTLS and the connection is renegotiated over TLS.

Opportunistic — if the upgrade fails, plain SMTP is used. MTA-STS closes that loophole.

DANE

DNS-based Authentication of Named Entities · RFC 7672

A DNSSEC-based way to publish your TLS certificate fingerprint in DNS. Senders fetch your TLSA record, compare it to the cert your MTA presents, and refuse delivery on mismatch.

Stronger than MTA-STS in theory (no HTTPS dependency), weaker in practice (requires DNSSEC, which is uncommon). Most senders use both.

PTR record (rDNS)

Reverse DNS

The DNS record that maps an IP back to a hostname. Receivers do a reverse lookup on the connecting IP; if there's no PTR or it doesn't match the HELO domain, the mail looks suspicious.

Set rDNS via your IP provider's control panel. Each sending IP needs its own PTR pointing at a hostname you control.

Why it matters.

Missing or mismatched rDNS is a free spam-score boost. Most cloud providers either don't allow custom rDNS or charge extra for it — bare-metal providers (OVH, Hetzner) typically include it.

HELO / EHLO

The first command in an SMTP transaction. The sending MTA identifies itself with EHLO sender.example.com. Receivers compare this hostname against the connecting IP's PTR record.

HELO is the original SMTP greeting; EHLO is the modern (RFC 5321) variant that allows extensions. EHLO is the default; HELO is fallback.

Mailing list

An audience: a saved set of email addresses (with subscription status) that you send to as a unit. Distinct from a marketing automation flow (which targets dynamic predicates) and from a transactional send (one-off).

Quality dimensions: opt-in method (single vs double), consent timestamp, source attribution, and freshness (when did they last engage).

Double opt-in

A signup flow where the user enters their email on a form, then has to click a verification link in a confirmation email before they're considered subscribed. Single opt-in skips the verification step.

Double opt-in produces measurably cleaner lists (no typos, no malicious signups, no purchased addresses). Single opt-in produces faster list growth.

Why it matters.

GDPR doesn't require double opt-in by name, but it's the only practical way to demonstrate provable consent. Most B2C senders converge on it once their first complaint-rate-driven blocklist event happens.

HMAC webhook signature

Hash-based Message Authentication Code

A signature computed over a webhook payload using a shared secret. Recipients verify by computing the same HMAC and comparing — if they match, the payload hasn't been tampered with and was sent by someone who knows the secret.

X-Relayly-Signature: t=1714672000,v1=<hex hmac>
signed_payload = t + "." + raw_body
hmac = HMAC-SHA256(secret, signed_payload)

Always compare in constant time (use crypto.timingSafeEqual in Node, hmac.compare_digest in Python). Reject payloads with timestamps older than 5 minutes to defeat replay attacks.

Idempotency-Key

A unique-per-attempt token you supply on a request. The server records it; if the same token comes back later (e.g. you retried after a network blip), the server returns the cached response instead of executing the operation twice.

POST /v1/email/send
Idempotency-Key: order-12345-welcome
…

Most modern APIs accept this header (Stripe popularised the pattern). Without it, "did the network blip happen before or after the API processed my request?" is unanswerable.

Open rate

The percentage of delivered messages that were "opened" — measured by a 1×1 tracking pixel in the HTML body that fires when the recipient's mail client renders images.

Increasingly unreliable since Apple Mail Privacy Protection (2021) pre-fetches images for all recipients regardless of whether they actually opened — inflating open rates by 30-50% across most B2C lists.

Click rate

The percentage of delivered messages where the recipient clicked at least one tracked link. Measured by replacing destination URLs with a redirect URL on a tracker domain (e.g. t.relayly.io) that records the click before redirecting.

More reliable than open rate post-Apple-MPP — clicks require actual user intent, not just image pre-fetch.

Complaint rate

The percentage of delivered messages that the recipient marked as spam. Measured via FBL ingest from the major mailbox providers.

Industry guidance: keep below 0.1% (1 per 1,000). Above 0.3%, mailbox providers start rate-limiting you. Above 1%, you'll be blocklisted.

Why it matters.

This is the single most important deliverability metric. Open rate and click rate are vanity; complaint rate is consequence.

Deliverability

The probability that a sent message lands in the recipient's inbox (vs spam folder, vs bounced, vs blackholed). The composite outcome of authentication (SPF/DKIM/DMARC), reputation (IP, domain), content quality, and sender hygiene.

Distinct from delivery — a message is "delivered" once the recipient SMTP server returns 250, but it might still land in spam.

Inbox placement

The percentage of delivered messages that land in the primary inbox (vs Promotions tab, Spam folder, or other folders). Measured by seedlist services that maintain accounts across major providers and report where each test message landed.

Industry benchmark: above 95% is good, 90-95% is acceptable, below 90% needs investigation.

Jump to

Term you wanted that's not here?