Glossary

69 terms, each citing the standard it comes from.

Mail transport

SMTPRFC 5321: Simple Mail Transfer Protocol — the protocol servers use to hand messages to each other. It carries the message and the envelope around it, and authenticates nothing about the sender by itself.; Lessons using this
MUA (Mail User Agent)RFC 5598 §2.1: The mail client a person uses — Outlook, Thunderbird, a webmail interface. It composes messages and hands them to a submission server.
MSA (Mail Submission Agent)RFC 6409: The server a user’s client submits to, normally on port 587 and normally requiring the user to authenticate. Distinct from an MTA because submission and relay have different rules.
MTA (Mail Transfer Agent)RFC 5598 §2.3: A server that relays a message toward its destination, talking SMTP to the next MTA. Most authentication checks happen at the receiving MTA.; Lessons using this
MDA (Mail Delivery Agent)RFC 5598 §2.4: The component that places an accepted message into the recipient’s mailbox. Filtering and foldering typically happen here.
HELO / EHLORFC 5321 §4.1.1.1: The greeting a sending server opens an SMTP session with, naming itself. The name given is a claim and is not verified; EHLO is the extended form that also asks what the receiver supports.; Lessons using this
EnvelopeRFC 5321 §3.3: The addresses exchanged in the SMTP conversation itself — MAIL FROM and RCPT TO — as opposed to the From and To headers inside the message. The two need not match, and often legitimately do not.; Lessons using this
Header FromRFC 5322 §3.6.2: The From: header inside the message. This is the identity a mail client displays, and it is the identity DMARC is built to protect. SPF does not check it.; Lessons using this
Return-PathRFC 5321 §4.4: A header the receiving server writes at delivery time, recording the envelope sender it was given. It is where bounces go, and it is the best evidence of the envelope sender in a delivered message.; Lessons using this

Email authentication

Authentication-ResultsRFC 8601: A header the receiving system adds recording the authentication checks it performed and their outcomes. Trustworthy only within the system that wrote it — anyone can add the header upstream.; Lessons using this
SPFRFC 7208: Sender Policy Framework — a DNS record listing which hosts may send mail using a domain in the SMTP envelope sender. It authorises hosts, not messages, and says nothing about the From header a reader sees.; Lessons using this
MechanismRFC 7208 §5: A term in an SPF record that can match the sending IP — ip4, ip6, a, mx, include, exists, ptr, all. Mechanisms are evaluated left to right and the first match decides the result.; Lessons using this
ModifierRFC 7208 §6: An SPF term that changes evaluation rather than matching an IP — redirect and exp. A modifier may appear only once and is not position-sensitive the way a mechanism is.; Lessons using this
QualifierRFC 7208 §4.6.2: The prefix on an SPF mechanism setting what a match means: + pass (the default), - fail, ~ softfail, ? neutral.; Lessons using this
SoftfailRFC 7208 §8.4: The SPF result from a ~ qualifier: the host is not authorised, but the domain owner is not asking for rejection. Receivers treat it as weak negative evidence rather than a instruction.; Lessons using this
permerrorRFC 7208 §2.6.7: A permanent SPF evaluation error — a malformed record, more than one SPF record, or a record that exceeds the processing limits. It is a hard failure: the check cannot produce a pass no matter which host sent the message.; Lessons using this
Void lookupRFC 7208 §4.6.4: A DNS query during SPF evaluation that returns NXDOMAIN or an empty answer. More than two void lookups is a permerror — a separate limit from the ten-lookup one, in the same section, and very widely missed.; Lessons using this
DKIMRFC 6376: DomainKeys Identified Mail — a cryptographic signature over selected headers and the message body, verifiable against a public key published in DNS. It proves a domain took responsibility for the message and that the signed parts were not altered.; Lessons using this
SelectorRFC 6376 §3.1: A label that namespaces a DKIM key, so one domain can publish many. The public key lives at {selector}._domainkey.{domain}, and the signature names the selector it used.; Lessons using this
Body hash (bh=)RFC 6376 §3.7: A hash of the canonicalised message body carried in the signature. If the body changes in transit the body hash no longer matches and verification fails before the signature is even checked.; Lessons using this
CanonicalisationRFC 6376 §3.4: The normalisation applied to headers and body before hashing. "simple" tolerates almost no change; "relaxed" tolerates whitespace and header-case differences, which is why relaxed/relaxed survives more intermediaries.; Lessons using this
DMARCRFC 7489: Domain-based Message Authentication, Reporting and Conformance — ties SPF and DKIM to the From header a reader sees, tells receivers what to do when neither aligns, and asks them to report what they saw.; Lessons using this
AlignmentRFC 7489 §3.1: The requirement that the domain authenticated by SPF or DKIM match the domain in the From header. A message can pass SPF or DKIM and still fail DMARC because the passing domain was not the one the reader sees.; Lessons using this
Organisational domainRFC 7489 §3.2: The registrable domain beneath a public suffix — example.co.uk rather than mail.example.co.uk. Relaxed alignment compares organisational domains; strict alignment compares the full names.; Lessons using this
rua (aggregate reports)RFC 7489 §7.2: The DMARC tag naming where aggregate reports should be sent. Reports are periodic XML summaries of what receivers saw — counts, sources and results, never message content.; Lessons using this
ruf (failure reports)RFC 7489 §7.3: The DMARC tag naming where per-message failure reports should be sent. Because these can contain message content, most large receivers do not send them at all.; Lessons using this
DispositionRFC 7489 §7.2: What a receiver actually did with a message — none, quarantine or reject — as distinct from what the policy asked for. Aggregate reports carry both, and the difference is informative.; Lessons using this
ARCRFC 8617: Authenticated Received Chain — lets an intermediary record the authentication results it saw before modifying a message, so a later receiver can take that into account. Useful only if the later receiver trusts the intermediary.; Lessons using this

DNS

MX recordRFC 5321 §5.1: A DNS record naming a host that accepts mail for a domain, with a preference number. Lower preference values are tried first; equal values are load-shared.; Lessons using this
Public Suffix Listpublicsuffix.org: A community-maintained list of the suffixes under which the public may register names. DMARC uses it to work out where an organisational domain begins, which is why it matters outside browsers.; Lessons using this
TLDRFC 1034 §3.1: Top-level domain — the rightmost label of a name, such as .com or .uk. Each is operated by a registry under contract or delegation.; Lessons using this
RegistryICANN: The operator of a TLD. It holds the authoritative database of registrations in that TLD and runs its nameservers. You are not its customer; your registrar is.; Lessons using this
RegistrarICANN: The company you buy and manage a domain through. Your registrar account is the control point for the entire domain, which makes it the highest-impact credential you hold.; Lessons using this
RegistrantICANN: The party a domain is registered to. Legally the holder of the registration, and the identity a registrar will check before allowing a transfer or a recovery.; Lessons using this
ZoneRFC 1034 §4.2: The portion of the DNS namespace a particular set of servers is authoritative for. A zone and a domain are not the same thing: a domain can be split into several zones by delegation.; Lessons using this
DelegationRFC 1034 §4.2.2: A parent zone pointing at the nameservers for a child zone, using NS records. The parent’s NS set is what resolvers follow; the child publishes its own copy, and the two are supposed to agree.; Lessons using this
Glue recordRFC 1034 §4.2.1: Address records the parent zone supplies for nameservers that live inside the zone they serve, breaking the circular dependency. Required when the nameserver name is under the domain it answers for.
NS recordRFC 1035 §3.3.11: Names an authoritative nameserver for a zone. It appears in two places — the parent zone as a delegation, and the zone itself — and a mismatch between them is a common and long-lived misconfiguration.; Lessons using this
SOA recordRFC 1035 §3.3.13: Start of Authority — one per zone, carrying the primary nameserver name, the responsible contact, the serial number, and the timers that govern secondary refresh and negative caching.; Lessons using this
CNAME recordRFC 1034 §3.6.2: An alias pointing one name at another. A name with a CNAME may have no other records, which is why a CNAME cannot exist at a zone apex alongside SOA and NS.; Lessons using this
TXT recordRFC 1035 §3.3.14: A general-purpose text record. Because it has no fixed meaning, it became the carrier for SPF, DKIM, DMARC, domain verification and much else — each distinguished only by name and by a version prefix.; Lessons using this
TTLRFC 1035 §3.2.1: How long a resolver may cache a record, in seconds. It bounds how fast a change takes effect and, more importantly, how fast a mistake can be undone.; Lessons using this
Recursive resolverRFC 1034 §5: The server that does the work of finding an answer on a client’s behalf, walking from the root and caching what it learns. What you see from one resolver is not necessarily what everyone sees.; Lessons using this
Authoritative serverRFC 1034 §4: A server that holds a zone’s data and answers for it directly rather than from cache. Querying one bypasses caching, which is why it is the right place to check what you just published.; Lessons using this
SERVFAILRFC 1035 §4.1.1: A DNS response code meaning the server could not produce a valid answer. A validating resolver returns it when DNSSEC validation fails, which is why a signing mistake looks like a total outage rather than a warning.; Lessons using this
PunycodeRFC 3492: The ASCII encoding of an internationalised name, always beginning xn--. Seeing punycode rendered instead of the intended script is usually a client refusing to display something it considers confusable.
IDNRFC 5890: Internationalised Domain Name — a name containing non-ASCII characters, encoded as punycode in the protocol. Necessary for a global namespace, and the mechanism homograph attacks exploit.

DNSSEC

DNSSECRFC 4033–4035: A set of DNS extensions that sign zone data so a resolver can verify an answer came from the zone owner and was not modified. It provides authenticity and integrity — not confidentiality. DNSSEC does not encrypt anything.; Lessons using this
RRsetRFC 2181 §5: All records of the same name, class and type, treated as one unit. DNSSEC signs RRsets rather than individual records, which is why adding one record invalidates the signature over the whole set.; Lessons using this
DNSKEYRFC 4034 §2: A public key published in the zone. Conventionally split into a key-signing key, which signs the DNSKEY set and is what the parent commits to, and a zone-signing key, which signs everything else.; Lessons using this
RRSIGRFC 4034 §3: The signature over an RRset, carrying the signing key’s identifier and an explicit validity window. Signatures expire on a wall-clock date, which is why a zone that stops being re-signed fails rather than degrades.; Lessons using this
DS recordRFC 4034 §5: A digest of a child zone’s key-signing key, published in the parent zone. It is the single link between a zone’s signatures and the chain of trust, and updating it is the step that most often gets missed at a key rollover.; Lessons using this
NSEC / NSEC3RFC 5155: Records that prove a name does not exist, by signing the gaps between names that do. NSEC3 hashes the names so the zone cannot simply be enumerated; opt-out lets unsigned delegations be skipped, which speeds signing at the cost of proving less.; Lessons using this
Trust anchorRFC 4033 §2: A key a validator trusts without proof — in practice the root zone key-signing key, distributed with the resolver. Every DNSSEC validation chains back to it.; Lessons using this

Certificates

CAA recordRFC 8659: A DNS record naming which certificate authorities may issue for a domain. CAs are required to check it at issuance time; it constrains issuance, and does nothing about certificates already issued.; Lessons using this
Certificate authorityCA/Browser Forum Baseline Requirements: An organisation that issues TLS certificates after validating control of a name. Which CAs a browser trusts is a decision made by the browser vendor, not by you — CAA is how you narrow it for your own domain.; Lessons using this
Certificate TransparencyRFC 9162: Public append-only logs of issued certificates, which browsers require for a certificate to be trusted. This makes issuance for any name observable — including names that look like yours.; Lessons using this

Registrar

Transfer lockRFC 5731 §2.3: A registrar-level status (clientTransferProhibited) preventing a domain moving to another registrar until it is cleared. Free, near-universal, and frequently left off.; Lessons using this
Registry lockRFC 5731 §2.3: A stronger, registry-level hold requiring out-of-band human verification before any change. It deliberately makes legitimate changes slow, which is the point for a domain that must not move.; Lessons using this
RDAPRFC 9083: The structured, authenticated successor to WHOIS for registration data. Responses are JSON and access to contact detail is tiered, so what you can see depends on who you are.; Lessons using this

Attacks

SpoofingRFC 7960 §2: Sending a message that claims an identity the sender is not entitled to. In email this is trivial at the protocol level, because SMTP accepts whatever addresses it is given.; Lessons using this
Display-name spoofingM3AAWG best practice: Putting a trusted name in the human-readable part of the From header while the actual address belongs to the attacker. No email-authentication protocol addresses this, because the address really does belong to the sender.; Lessons using this
Cousin domainRFC 7960 §2: A domain registered by an attacker that resembles the target closely enough to deceive a reader, and which the attacker authenticates correctly. DMARC on the real domain has no bearing on it.; Lessons using this
Cache poisoningRFC 5452: Getting a resolver to cache an answer that did not come from the authoritative server. The attack DNSSEC exists to make detectable.
TyposquattingM3AAWG best practice: Registering domains that are plausible mistypings of a target — omitted, doubled, transposed or adjacent characters. It relies on the victim making the error rather than on being deceived by the name.; Lessons using this
CombosquattingM3AAWG best practice: Registering the brand name plus an extra word — brand-support, brand-login, brand-billing. The brand is spelled correctly, so typo-based defences miss it entirely and the space is effectively unbounded.; Lessons using this
BitsquattingDinaburg, Black Hat 2011: Registering domains one bit away from the target, to catch lookups corrupted by hardware memory errors. Real and documented, but a very small effect next to typo and combo squatting.; Lessons using this
Homograph attackUnicode TR#39: Using characters that look like others — Cyrillic а for Latin a — to build a name visually indistinguishable from the target. Browsers mitigate it by displaying punycode in some cases; mail clients, terminals and documents often do not.
Dangling recordNIST SP 800-81r3: A DNS record pointing at a resource that no longer exists or is no longer yours — typically a CNAME to a SaaS platform after the account lapsed. Whoever can claim that resource next controls a hostname under your domain.; Lessons using this