Learn email deliverability
Plain-English guides to the protocols and operational practices that decide whether your email lands in the inbox.
Authentication
SPF explained: how Sender Policy Framework actually works
SPF lets a receiver ask DNS which servers are allowed to send mail using a given domain. It is the oldest of the three modern authentication standards and the easiest to misconfigure.
DKIM explained: keys, selectors, alignment, and rotation
DKIM cryptographically signs the headers and body of each message, letting receivers prove the message was authorised by the signing domain and was not modified in transit.
DMARC explained: from p=none to p=reject without breaking mail
DMARC ties SPF and DKIM together with an alignment requirement and a published policy, then asks receivers to send back aggregate reports.
ARC: surviving forwarders without breaking DMARC
ARC adds a signed authentication-results chain so a forwarder can vouch for the original DMARC result even after modifying the message.
Reputation
BIMI and VMC: getting your logo into Gmail
BIMI displays your verified brand logo next to your messages in supporting mailbox providers. Eligibility requires DMARC at enforcement plus a trademark-verified logo (VMC).
Feedback Loops (FBL): how mailbox providers tell you about complaints
Most major providers send 'this is spam' clicks back to senders as ARF reports. Subscribing to FBLs lets you suppress complainers immediately.
IP warm-up: a practical schedule for dedicated sending IPs
Sending too much from a brand-new IP triggers rate limits and spam folder placement. Warm-up is about establishing a positive baseline before scaling.
Spam traps: pristine, recycled, and typo traps
Three kinds of spam trap: pristine (never used by a human), recycled (abandoned mailboxes turned trap), and typo (common misspellings of real domains). Each tells the listing service something different about you.
Engagement metrics that actually matter for inbox placement
Major mailbox providers use machine-learning models that weight engagement signals: reads, replies, conversations, archives, deletes without read, and spam clicks.
TLS
MTA-STS: enforcing TLS for inbound mail
Without MTA-STS, SMTP TLS is opportunistic and vulnerable to downgrade attacks. MTA-STS publishes a policy that turns TLS into a hard requirement.
TLS-RPT: collecting SMTP TLS failure reports
TLS Reporting (RFC 8460) is the feedback loop for MTA-STS and DANE. Without it, policy failures are silent.
DANE/TLSA: DNSSEC-anchored TLS for SMTP
DANE for SMTP publishes a TLSA record that pins your certificate (or CA) in DNS. It requires DNSSEC on the entire chain.
Operations
List-Unsubscribe (RFC 8058): making one-click unsubscribe work
Gmail and Yahoo require RFC 8058 one-click unsubscribe for any sender above ~5000 messages per day. Implementing it wrong has the same effect as not implementing it.
Google and Yahoo 2024 sender requirements: the practical checklist
Since February 2024, Gmail and Yahoo require bulk senders (5000+ per day) to authenticate properly, support one-click unsubscribe, and keep complaint rate below 0.3%.