Skip to content
AdminKit

Email authentication

SPF, DKIM and DMARC are the three DNS-published records that tell receiving mail servers whether a message from your domain can be trusted — get one wrong and mail lands in spam or gets rejected outright.

Tools (4)

All tools →

Guides (16)

All guides →

Glossary (21)

Full glossary →
  • ARC (Authenticated Received Chain) — ARC (Authenticated Received Chain), defined in RFC 8617, lets each server in an email forwarding chain add a signed record of what the message's SPF, DKIM, and DMARC results looked like before that hop forwarded it onward. A forwarded message typically fails SPF, and sometimes DKIM, by the time it reaches its final destination, because forwarding changes the connecting server's IP and can alter the message in ways that break a DKIM signature; ARC gives the receiving mail system a verifiable record that the message passed authentication earlier in its path, so it can weigh the forwarder's own reputation instead of rejecting on the final-hop failure. Both the forwarder and the final recipient's mail system need to support ARC for it to help -- support exists today among major providers including Gmail and Microsoft 365, but is not universal.
  • Authentication-Results header — The Authentication-Results header (RFC 8601) is a header a receiving mail server adds to a message recording the verdicts of its own SPF, DKIM, and DMARC checks -- pass, fail, softfail, or none -- along with identifying details like which domain and selector were checked. Downstream systems, such as a user's mail client, an anti-spam filter, or a later hop in a multi-server mail setup, can read this header to see what was already verified instead of repeating the same DNS lookups and cryptographic checks. Because any sender could forge this header on a message sent directly to a mailbox, receivers are expected to add it only at a trust boundary and strip or overwrite any instance a message already carried, so recipients inside that boundary can rely on it.
  • Backscatter (email) — Backscatter is the unwanted bounce or auto-reply traffic a mail server generates when it accepts a message and only later discovers, after the original sender's connection has already closed, that the message can't actually be delivered -- so it sends the bounce notification to whatever address the message claimed as its sender. When that claimed sender address was forged, which is common with spam and phishing sent under a spoofed-from address, the bounce lands in an innocent third party's inbox who never sent the original message at all. A domain can receive a flood of backscatter if spammers happen to forge it as the sender on messages that later bounce elsewhere, and receiving servers increasingly treat unsolicited bounce traffic itself as a spam signal. Validating the recipient during the SMTP conversation, before accepting the message, is what avoids generating backscatter in the first place.
  • BIMI — BIMI (Brand Indicators for Message Identification) is a DNS TXT record that lets a domain display a verified brand logo next to its messages in supporting inboxes, such as Gmail and Yahoo Mail. BIMI has a hard prerequisite: the domain's DMARC policy must already be enforced at p=quarantine or p=reject, not p=none, because BIMI's trust model depends on DMARC already having proven that unauthenticated mail claiming to be from the domain gets blocked or flagged. Many implementations also require a Verified Mark Certificate (VMC) from a recognized authority, tying the logo to a legally registered trademark, which adds cost and process beyond the DNS record itself.
  • Catch-all address — A catch-all address (or catch-all mailbox) is a mail server configuration that delivers messages sent to any address at a domain -- including addresses that were never specifically created -- to one designated inbox instead of bouncing them as undeliverable. It's commonly used so a typo in a customer's email, like sales@ instead of sale@, still reaches someone, but it carries a real security and hygiene cost: a domain with a catch-all accepts mail to any made-up address, making it a convenient target for spammers harvesting addresses, and it prevents legitimate bounce messages (RFC 3464 delivery status notifications) from ever signaling that an address doesn't exist. This also interacts with backscatter, where a server using a catch-all forwards or auto-responds to spoofed senders instead of silently dropping mail to nonexistent addresses. AdminKit's guide to email bounces and backscatter explains how this failure mode shows up and how to avoid it.
  • DANE/TLSA — DANE (DNS-Based Authentication of Named Entities) uses a TLSA DNS record to publish exactly which TLS certificate, or which certificate authority, a server is supposed to present, so a connecting client can confirm the certificate it receives matches what the domain owner actually published instead of just trusting any certificate authority. It depends entirely on DNSSEC: without a signed, verifiable chain of trust for the TLSA record itself, an attacker who can forge DNS could also forge the pin, defeating the purpose. The most common real-world use is SMTP mail servers pinning their TLS certificate so other mail servers can detect a TLS downgrade or interception attempt during delivery, complementing MTA-STS, which achieves a similar goal through a web-hosted policy file instead of DNS. Browser support for DANE on the web has stayed limited, so its practical adoption today is concentrated in mail transport rather than general HTTPS.
  • DKIM — DKIM (DomainKeys Identified Mail) lets a sending domain cryptographically sign outgoing email with a private key, adding a DKIM-Signature header that covers key parts of the message. The receiving server looks up the corresponding public key from a DNS TXT record at a selector-specific hostname (selector._domainkey.example.com) and verifies the signature, confirming the message wasn't altered after signing and genuinely originated from a system holding that domain's private key. Unlike SPF, which authenticates the sending IP, DKIM authenticates the message content itself and survives forwarding through an intermediate server, which is why DMARC checks both mechanisms together. DKIM is defined in RFC 6376.
  • DKIM selector — A DKIM selector is a short label included in a message's DKIM-Signature header that tells a receiving server exactly which DNS TXT record holds the public key needed to verify it, at the hostname selector._domainkey.example.com. Selectors let one domain publish multiple DKIM keys at once -- a common setup when several outbound mail systems (a marketing platform, a helpdesk tool, an internal mail server) each sign with their own key and selector, such as mandrill._domainkey.example.com or google._domainkey.example.com. A verification failure often traces back to a selector mismatch rather than a bad signature: the sending system changed selectors, rotated a key, or the DNS record for that specific selector was never published or was deleted during cleanup.
  • DMARC — DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS TXT record that builds on SPF and DKIM by telling receiving mail servers what policy to apply when a message fails both checks -- p=none (monitor only), p=quarantine (send to spam), or p=reject (refuse outright) -- and where to send aggregate reports (rua) summarizing authentication results across all senders using the domain. DMARC also requires "alignment": the domain in SPF or DKIM must match the domain the recipient sees in the From header, closing a gap where a message could pass SPF or DKIM for an unrelated domain. DMARC is defined in RFC 7489.
  • Envelope sender vs header From — An email has two different "sender" addresses that are often confused. The envelope sender is the address given in the SMTP MAIL FROM command (RFC 5321), used only for routing and bounce delivery between mail servers; the header From address is the human-readable "From:" field (RFC 5322) a mail client actually displays to the recipient. Nothing requires the two to match, and legitimate setups -- mailing lists, some forwarding services -- routinely set them differently. SPF checks the envelope sender's domain against the connecting server's IP, not the header From a reader sees, which is why a message can pass SPF while still displaying a different, even forged, header From address. Spammers exploit the gap by forging an uninvolved third party's address as the envelope sender, so any bounce generated for an undeliverable message lands on that victim instead of the real sender -- the mechanism behind email backscatter.
  • Forward-confirmed reverse DNS — Forward-confirmed reverse DNS (FCrDNS) is a two-step check some receiving mail servers run on a connecting IP before accepting mail: look up the IP's PTR record to get a claimed hostname, then look up that hostname's own A or AAAA record and confirm it resolves back to the same IP. Checking only the PTR record has a gap, since whoever controls an IP block can publish any hostname there; confirming the forward record agrees closes that gap without needing a cryptographic signature, though it's still a hygiene signal rather than proof of identity. FCrDNS predates SPF, DKIM and DMARC, and survives because it's cheap and catches abuse infrastructure -- compromised devices, throwaway cloud instances -- that was never configured with matching forward and reverse records in the first place. AdminKit's reverse DNS and DNS lookup tools together let you run both halves of an FCrDNS check manually.
  • Greylisting — Greylisting is a spam-reduction technique where a receiving mail server temporarily rejects an unfamiliar sender/recipient/IP combination with a standard SMTP 4xx temporary-failure code, then accepts the message once the same sender retries after a short delay. The technique, described by Evan Harris in 2003, relies on RFC 5321's requirement that a compliant SMTP server must queue and retry temporary failures: well-behaved mail servers retry automatically, while much of the spam-sending infrastructure of the time fired messages once and moved on. Greylisting adds delivery latency, typically minutes, to first-time senders, its main downside for time-sensitive mail. It's largely a legacy technique now, since modern filtering leans more on SPF, DKIM, DMARC and sender reputation, but many mail servers still layer it on as one more low-cost check. AdminKit's MX lookup tool shows which mail server handles a domain's inbound mail so its configuration can be reviewed.
  • MTA-STS — MTA-STS (Mail Transfer Agent Strict Transport Security) lets a domain publish a policy, via a DNS TXT record plus an HTTPS-hosted policy file, declaring that mail destined for it must be delivered over TLS with a valid, matching certificate -- and specifying whether a connection that can't meet that bar should be deferred or rejected. Without MTA-STS, email between two mail servers that both support TLS is usually encrypted opportunistically, but an attacker in the network path can often force a downgrade to an unencrypted connection without either side noticing. MTA-STS closes that gap by making encryption a declared, enforceable requirement. It's defined in RFC 8461.
  • Null MX record — A null MX record is a specific MX record -- a single record pointing to the root domain (".") -- that a domain publishes to explicitly declare it doesn't accept email at all, standardized in RFC 7505. Before null MX existed, a domain that sent no mail had no standard way to say so: it would either publish no MX record, which falls back to trying the domain's own A/AAAA record for SMTP delivery under RFC 5321's implicit MX rule, or leave mail handling undefined, leaving senders unable to tell a missing server from a misconfiguration. Publishing a null MX tells sending servers to reject outgoing mail to that domain immediately, useful for domains used only for hosting or infrastructure, where no one should ever email that name. AdminKit's MX lookup tool reports a null MX explicitly, rather than showing it as a missing or broken record.
  • Open relay — An open relay is a mail server configured to accept and forward email from any sender to any recipient, without verifying that the sender is an authorized user of that server or domain. Mail servers are meant to relay only for their own authenticated users or a defined list of trusted sources; a misconfigured server that relays for anyone becomes a free, anonymous sending point that spammers actively scan for and abuse, often without the operator noticing until deliverability problems appear. Once abused, an open relay's IP typically ends up listed on DNS-based blocklists (DNSBLs), which then causes legitimate mail from that same server to be rejected or quarantined by other mail systems. Testing for the specific cause behind a blacklist listing, including whether a mail server is acting as an open relay, is the first step before requesting delisting from the list that flagged it.
  • SMTP (Simple Mail Transfer Protocol) — SMTP (RFC 5321) is the protocol mail servers use to relay email from a sender's outgoing server to a recipient's incoming server, and from a mail client to its own outgoing server before that. It's a store-and-forward protocol: a message can hop through several SMTP servers before reaching its final destination, each one accepting responsibility for onward delivery or returning a bounce if it can't deliver. SMTP on its own has no built-in encryption or sender authentication -- both were added later as extensions, STARTTLS (RFC 3207) for encrypting the connection, and SPF, DKIM and DMARC as separate DNS-based mechanisms for verifying who actually sent a message -- which is why a server running plain SMTP alone cannot guarantee either privacy in transit or that a message's claimed sender is genuine.
  • SPF — SPF (Sender Policy Framework) is a DNS TXT record that lists which mail servers are authorized to send email claiming to be from a domain. A receiving mail server checks the SPF record of the domain in the message's envelope sender address against the IP that actually delivered the message; a mismatch can be treated as a sign of spoofing. SPF records use mechanisms like include:, ip4:, and mx to name authorized senders, and end with a qualifier (-all hard-fails unauthorized senders, ~all soft-fails) that sets how strictly a mismatch is treated. RFC 7208 defines SPF and caps lookups at 10 to limit DNS load.
  • SPF void lookup — A void lookup is a specific category of SPF evaluation outcome, defined in RFC 7208 section 4.6.4, tracked separately from the record's overall 10-lookup budget: a DNS query during SPF evaluation that returns either a positive answer with an empty answer set, or a Name Error (NXDOMAIN). RFC 7208 recommends -- a SHOULD, not the hard MUST governing the 10-lookup cap -- limiting void lookups to 2 for the entire evaluation, so a record can't force a receiving server to keep querying names that plainly don't resolve. In practice the limit gets tripped by stale includes: a mechanism like include:oldvendor.com left in a record long after that vendor deleted its SPF record or let the domain lapse. Each one burns through the 2-void budget, and a third stale or missing name can turn the whole check into a PermError, the same outcome as exceeding the 10-lookup limit.
  • SRS (Sender Rewriting Scheme) — SRS (Sender Rewriting Scheme) fixes SPF failures caused by email forwarding by rewriting the envelope sender address at the forwarding server, replacing it with an address on the forwarder's own domain that still encodes the original sender for bounce routing. Because SPF checks the connecting server's IP against the domain in the, now rewritten, envelope sender, and that address belongs to the forwarder, it's the forwarder's own SPF record -- which correctly lists its own IP -- that gets checked, so the forwarded message passes instead of failing on the original domain's SPF record, which never authorized the forwarder. SRS is a widely implemented convention rather than a formal IETF standard; it only works if the forwarding server itself supports it, and it does nothing for DKIM, which a message-modifying forwarder can still break separately.
  • STARTTLS — STARTTLS is a command that upgrades an initially plain-text SMTP (or IMAP/POP3) connection to an encrypted TLS connection, if both the sending and receiving server support it. It's "opportunistic" encryption by default: if a connection attempt doesn't offer or accept STARTTLS, most mail servers will silently fall back to sending the message unencrypted rather than failing the delivery, which means an attacker able to intercept and manipulate the connection can sometimes strip the STARTTLS offer entirely (a downgrade attack) without either party noticing. MTA-STS exists specifically to close this gap by letting a domain declare that TLS is mandatory, not optional, for mail addressed to it.
  • TLS-RPT — TLS-RPT (SMTP TLS Reporting) is a DNS TXT record that tells other mail servers where to send reports summarizing TLS connection failures when they tried to deliver mail to the domain -- including failures related to an MTA-STS policy the domain has published. Without TLS-RPT, a domain enforcing MTA-STS has no visibility into legitimate senders whose mail is silently being deferred or rejected because they couldn't establish a compliant TLS connection, which makes rolling out strict TLS requirements risky without reporting to catch problems early. TLS-RPT is usually deployed alongside MTA-STS rather than on its own, and is defined in RFC 8460.

Comparisons (3)

All comparisons →

Solutions (1)

All solutions →

Related clusters

DNS

DNS turns domain names into the IP addresses, mail servers and records your tools actually look up — most "it broke" reports trace back to one wrong or missing DNS record.

Security basics

TLS certificates, HTTP security headers and open ports are the fundamentals every internet-facing service should get right, independent of which protocol or cloud it runs on.

See all six clusters →

Frequently asked questions

What belongs in the Email authentication cluster?

SPF, DKIM and DMARC are the three DNS-published records that tell receiving mail servers whether a message from your domain can be trusted — get one wrong and mail lands in spam or gets rejected outright. This hub lists every AdminKit tool, guide, glossary term, comparison and solution tagged with this cluster.

How does Email authentication relate to DNS and Security basics?

DNS — DNS turns domain names into the IP addresses, mail servers and records your tools actually look up — most "it broke" reports trace back to one wrong or missing DNS record. Security basics — TLS certificates, HTTP security headers and open ports are the fundamentals every internet-facing service should get right, independent of which protocol or cloud it runs on.