DNS, TLS & Email Glossary
Concise engineer-friendly definitions of the terms used across the dnsverifier.com tools.
- SPF (Sender Policy Framework)
- SPF is a DNS TXT record at a domain's apex that lists which mail servers are permitted to send email using that domain. Receivers check the sender IP against the record; mismatch is a 'fail' or 'softfail'. Defined by RFC 7208.
- SPF has a strict ten-DNS-lookup limit per evaluation; exceeding it is a 'permerror' which most receivers treat as an authentication failure.
- DKIM (DomainKeys Identified Mail)
- DKIM signs outgoing email with a private key controlled by the sender. The matching public key is published as a TXT record at <selector>._domainkey.<domain>. Receivers verify the signature to prove the message wasn't modified in transit. Defined by RFC 6376.
- Use 2048-bit RSA or Ed25519 keys. Rotate selectors at least annually.
- DMARC (Domain-based Message Authentication, Reporting & Conformance)
- DMARC is a TXT record at _dmarc.<domain> that tells receivers what to do when a message fails SPF or DKIM 'alignment' — none (monitor), quarantine (spam folder), or reject (bounce). Defined by RFC 7489.
- Aggregate reports (rua=mailto:…) are typically sent daily; forensic reports (ruf=) are rare. Aim for p=reject after two weeks of clean DMARC reports.
- DNSSEC (Domain Name System Security Extensions)
- DNSSEC is a chain of cryptographic signatures over DNS records that lets a recursive resolver verify the answer wasn't forged or tampered with in transit. The chain runs from the root zone down through TLD (DS), zone apex (DNSKEY), and per-record (RRSIG).
- Defined by RFCs 4033-4035. Roughly 20-30% of TLDs and a smaller fraction of registered domains are signed.
- DNS Propagation
- DNS propagation is the period during which different recursive resolvers around the world return different answers for the same query, because each resolver caches the previous record value until the TTL expires.
- It is not a true network propagation — authoritative nameservers update immediately. The 'wait' is local cache expiry. Common ranges: 5 minutes to 48 hours.
- HSTS (HTTP Strict Transport Security)
- HSTS is an HTTP response header (Strict-Transport-Security) that tells the browser to use HTTPS for every future request to this host, even if the user types http://. Defined by RFC 6797.
- A+ TLS grades require max-age ≥ 180 days, includeSubDomains, and preload. Submission to the HSTS preload list at hstspreload.org hard-codes the header into Chrome, Firefox, Safari, and Edge.
- CAA (Certification Authority Authorization)
- CAA is a DNS record at the domain's apex that lists which Certificate Authorities are allowed to issue certificates for the domain. CAs must check CAA before issuance. Defined by RFC 8659.
- Example: 0 issue "letsencrypt.org" permits only Let's Encrypt to issue certs for this domain.
- Certificate Transparency (CT)
- Certificate Transparency is a public, append-only log of every TLS certificate issued by a Certificate Authority. Browsers require valid CT proofs (SCTs) in modern certs. Defined by RFC 6962.
- Side effect: every subdomain that has ever had a public HTTPS certificate is permanently visible via CT-log search engines like crt.sh.
- Subdomain Takeover
- A subdomain takeover happens when a subdomain has a CNAME record pointing to a third-party service (S3, Heroku, GitHub Pages, Azure, Netlify) where the underlying resource no longer exists. An attacker can claim the same resource at the provider and serve content under your domain.
- Detected by: CNAME present + target hostname returns NXDOMAIN, plus a known body-fingerprint string when fetched ('NoSuchBucket', 'There isn't a GitHub Pages site here', etc.).
- RDAP (Registration Data Access Protocol)
- RDAP is the IETF-standardized JSON-over-HTTPS replacement for the legacy port-43 WHOIS protocol. Every TLD registry has been required to offer RDAP since 2019. Defined by RFCs 7480-7483.
- RDAP returns structured records, supports authenticated access for restricted fields, and uses standardized JSON pointers and status codes.
- EPP Status Codes
- EPP (Extensible Provisioning Protocol) status codes are a set of seventeen flags a registrar or registry can set on a domain to control transferability, deletion, and resolvability. Examples: clientTransferProhibited, serverHold, pendingDelete.
- MTA-STS (SMTP MTA Strict Transport Security)
- MTA-STS is a policy mechanism that tells sending SMTP servers to require TLS when delivering mail to your MX hosts, preventing STARTTLS-stripping attacks. Defined by RFC 8461.
- Published as a TXT record at _mta-sts.<domain> pointing to a policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt.
- TLS-RPT (SMTP TLS Reporting)
- TLS-RPT is a TXT record at _smtp._tls.<domain> that requests daily JSON reports about TLS failures when other mail servers try to deliver to your MX. Defined by RFC 8460.
- BIMI (Brand Indicators for Message Identification)
- BIMI is a TXT record at default._bimi.<domain> that lets compliant inboxes display your brand's logo next to authenticated email. Requires DMARC at p=quarantine or p=reject. Logo must be SVG and (for Gmail) verified by a VMC.
- DNSBL (DNS Block List)
- A DNSBL is a public list of IP addresses known to send spam, queried via reversed-IP DNS lookups against the list's zone. Receivers check sender IPs against multiple DNSBLs.
- Common: zen.spamhaus.org, b.barracudacentral.org, bl.spamcop.net. The dnsverifier.com email checker queries 9 major DNSBLs.
- ALPN (Application-Layer Protocol Negotiation)
- ALPN is a TLS extension (RFC 7301) that lets client and server agree on the application protocol during the TLS handshake — e.g. 'h2' for HTTP/2, 'http/1.1' for HTTP/1.1, 'h3' for HTTP/3.
- Forward Secrecy (FS)
- Forward secrecy means that compromise of the server's long-term private key does not retroactively decrypt past sessions. Achieved by using ephemeral key-exchange (ECDHE, DHE) instead of RSA key exchange. Every TLS 1.3 cipher provides FS; in TLS 1.2 you must select ECDHE/DHE suites.