REFERENCE
Plain-English definitions followed by the technical detail needed to interpret assessments, DNS records and message-header analysis.
46 terms
A signed record of authentication results added as a message passes through intermediaries.
ARC uses ARC-Authentication-Results, ARC-Message-Signature and ARC-Seal fields to create a verifiable chain across forwarding systems.
It can preserve evidence when legitimate forwarding breaks SPF or modifies a DKIM-signed message.
A summary of email-authentication checks recorded by a receiving system.
The field can report SPF, DKIM, DMARC, ARC and related method results together with evaluated identities.
It explains why a receiver treated authentication as passing, failing or inconclusive.
The sequence of certificates that connects a server certificate to a trusted authority.
A relying party builds a path from the leaf certificate through one or more intermediate certification authorities to a trusted root. Every signature, validity period and policy constraint in the path must validate.
An incomplete or untrusted chain can cause encrypted mail delivery to fail when strict TLS is required.
A way to mark a certificate as unsafe before its normal expiry date.
Certification authorities publish revocation information through Certificate Revocation Lists or the Online Certificate Status Protocol. Validation may return good, revoked or unknown when current status cannot be obtained.
A revoked certificate may indicate key compromise, incorrect issuance or another reason it should no longer be trusted.
A published list of certificates that a certificate authority has cancelled.
A CRL is a signed structure containing revoked certificate serial numbers and update times. Clients download and validate it against the issuing certification authority.
It provides one method for detecting a certificate that should no longer be trusted.
The set of cryptographic methods selected to protect a TLS connection.
For TLS 1.2 a cipher suite defines key exchange, authentication, bulk encryption and message authentication. TLS 1.3 simplifies this and separates key exchange and signature negotiation from the named suite.
Modern cipher suites protect confidentiality and integrity; obsolete suites can expose connections to known attacks.
A provider's combined judgement using several identity and reputation signals.
Some platforms combine SPF, DKIM, DMARC, sender reputation and other evidence into a proprietary result.
It may explain treatment that is not apparent from one authentication method alone.
Fields recording the mailbox or address involved in final delivery.
Providers add fields such as Delivered-To, X-Original-To or Original-Recipient during alias expansion and local delivery. They are not universally standardised.
They can explain forwarding and aliases but may expose personal addresses.
A name that tells recipients which DKIM public key to retrieve.
The selector appears in the DKIM-Signature header's s= tag. The public key is queried at selector._domainkey.example.com. Domains can use several selectors to separate services or rotate keys.
The selector is required for a conclusive DKIM DNS lookup; it cannot always be discovered from the domain alone.
A check that the domain visible to the recipient agrees with the domain authenticated by SPF or DKIM.
SPF alignment compares the RFC5322.From domain with the authenticated RFC5321.MailFrom domain. DKIM alignment compares it with the d= signing domain. Relaxed mode permits organisational-domain alignment; strict mode requires an exact match.
Authentication without alignment does not satisfy DMARC and may not prevent visible From-address impersonation.
A DNS record used to publish text-based configuration and verification information.
TXT records carry character strings. Email standards use them for SPF, DKIM, DMARC, MTA-STS discovery and TLS reporting. Long logical values may be divided into several quoted strings in one DNS record.
Incorrect placement, duplication or formatting can make an email-security policy invalid.
A policy that tells receiving systems how to handle messages that do not properly authenticate as coming from the visible sender domain.
DMARC evaluates identifier alignment between the RFC5322.From domain and a passing SPF or DKIM result. The DNS policy can request none, quarantine or reject treatment and can specify aggregate and forensic reporting destinations.
An enforced DMARC policy reduces direct domain impersonation and provides visibility into authorised and unauthorised senders.
A digital signature added to outgoing email so recipients can verify who authorised it and that important content was not changed.
The sending system signs selected message headers and the body using a private key. The receiver obtains the corresponding public key from a selector-specific DNS TXT record under _domainkey and validates the signature.
DKIM supports message integrity and is one of the authentication methods DMARC can use for alignment.
The SMTP command a client uses to introduce itself and ask what features the server supports.
EHLO starts an Extended SMTP session. The multiline 250 response advertises extensions such as STARTTLS, SIZE, PIPELINING and authentication mechanisms.
STARTTLS should appear in the EHLO response before a sending server attempts to upgrade the connection.
From identifies the displayed author; Reply-To can direct responses somewhere else.
Both are RFC 5322 message fields and are independent of the SMTP envelope sender. DMARC aligns against the From domain, not Reply-To.
An unexpected Reply-To difference can deserve scrutiny, although many legitimate workflows use one.
A long header continued on one or more indented lines.
A folded field uses CRLF followed by whitespace. Parsers unfold that sequence before interpreting the field value.
Without unfolding, authentication and routing evidence can be split or misread.
Fabricating header fields to make a message appear to have a different origin or route.
An attacker can create visible From fields and untrusted Received lines before the first trusted gateway. Cryptographic authentication and the trusted boundary determine evidential weight.
A plausible-looking header is not necessarily authentic.
The date, time and offset recorded by a mail system.
Received timestamps normally contain a numeric UTC offset. Normalising those offsets allows hop-delay calculation, subject to server clock accuracy.
Comparing local clock text without its offset can produce an incorrect route or delay.
A check that a server certificate was issued for the mail-server name being contacted.
The client compares the reference MX hostname with DNS names in the certificate's Subject Alternative Name extension, applying wildcard matching rules where permitted.
A trusted and in-date certificate can still be unsuitable if it identifies a different server.
A certificate authority between the server certificate and a trusted root.
A root certification authority signs an intermediate CA certificate, and the intermediate signs leaf certificates or further intermediates. Servers normally provide the necessary intermediate certificates during TLS negotiation.
Missing intermediates can prevent a client from building a trusted certificate chain.
A DNS record that identifies the servers responsible for receiving email for a domain.
An MX record contains a preference value and mail-server hostname. Senders normally try the lowest preference value first and may use higher values for fallback delivery.
Incorrect or obsolete MX records can cause failed delivery or direct messages to an unauthorised service.
A server passing a message to the next mail system on its route.
A message transfer agent accepts SMTP delivery, may queue or inspect the message, and opens a new SMTP session to the next hop.
Every handoff can add delay and creates another Received entry.
A policy that tells supporting senders to require secure TLS when delivering mail to a domain.
A DNS TXT discovery record points to a versioned policy retrieved over HTTPS from mta-sts.example.com. The policy lists permitted MX patterns, a maximum age and a mode of none, testing or enforce.
Enforce mode prevents silent fallback to plaintext and helps detect or stop MX interception when certificate validation fails.
The routing and technical information attached to an email.
Internet-message headers are named fields governed primarily by RFC 5322 and extended by authentication, transport and filtering systems.
They provide evidence about routing and checks, but do not always prove final inbox placement.
An identifier intended to distinguish one email message from another.
The RFC 5322 Message-ID normally contains a locally generated identifier and a domain-like right-hand side.
It helps correlate logs and conversations, but should be treated as potentially sensitive and is not proof of authenticity.
A DNS declaration that a domain intentionally does not accept email.
RFC 7505 defines a single MX record with preference 0 and an exchange value of a dot. It prevents senders from falling back to the domain's address records.
It clearly distinguishes a non-mail domain from one whose receiving-mail configuration is missing.
A protocol for asking a certificate authority whether a particular certificate has been revoked.
A client sends the certificate serial number and issuer identifiers to an OCSP responder and validates its signed response. Availability, caching and privacy considerations affect how clients use it.
It can provide fresher, certificate-specific revocation information than downloading an entire CRL.
The standard network port used by mail servers to transfer email between domains.
SMTP message transfer agents listen on TCP port 25. Submission by end users normally uses port 587, while implicit TLS submission commonly uses port 465.
A genuine server-to-server STARTTLS assessment must connect to each MX host on port 25.
Public addresses are internet-routable; private addresses are intended for internal networks.
IPv4 private ranges include 10/8, 172.16/12 and 192.168/16. IPv6 has link-local and unique-local ranges. Internal Received hops may legitimately show them.
A private address cannot be reliably geolocated and usually represents an internal handoff.
A server-local reference used to track a message while it is waiting or being processed.
MTAs commonly record a queue ID in Received fields and server logs. Its format and uniqueness scope depend on the product.
It lets an administrator correlate a header hop with mail-server logs.
A stamp added by a mail system when it accepts the message from another system.
Each relay prepends a Received field containing from/by identities, protocol and usually a timestamp. Reading the fields from bottom to top reconstructs the route.
The chain exposes mail flow and allows approximate delay calculations, although untrusted senders can forge earlier entries.
The address used for delivery errors and SPF evaluation, which may differ from the visible From address.
It represents the RFC5321.MailFrom identity carried in the SMTP envelope and is commonly written into Return-Path at final delivery.
A different envelope and visible sender is normal for some services, but DMARC requires appropriate alignment.
A DNS lookup that maps an IP address back to a name.
Reverse DNS queries the in-addr.arpa or ip6.arpa namespace. Mail receivers often compare the result with forward DNS and SMTP identity.
Missing or inconsistent reverse DNS can affect reputation, but a matching PTR alone does not authenticate a sender.
A highly trusted authority at the top of a certificate chain.
A root CA certificate is self-signed and distributed through operating-system or application trust stores. Trust in a leaf certificate ultimately depends on a valid path to one of these configured roots.
A chain ending at an unknown root will normally be rejected even if every cryptographic signature is correct.
A DNS policy listing the systems authorised to send email using a domain.
A receiver evaluates the connecting IP against mechanisms in the domain's SPF TXT record for the RFC5321.MailFrom or HELO identity. Evaluation has a ten-DNS-lookup limit and returns results such as pass, fail, softfail or neutral.
SPF helps identify unauthorised sending infrastructure and can satisfy DMARC when the authenticated domain aligns.
The protocol mail systems use to send and relay email.
SMTP is a command-and-response protocol. A receiving server sends a 220 banner, the client issues EHLO, and the server returns supported extensions before the message-transfer conversation continues.
The STARTTLS capability is negotiated within SMTP before message content is transmitted.
A reporting standard that tells senders where to report failures when delivering email securely.
A _smtp._tls DNS TXT record publishes a rua destination. Supporting sending systems deliver aggregate JSON reports describing successful TLS sessions and failure categories.
It gives domain owners evidence of certificate, policy and downgrade-related delivery problems.
A Microsoft score indicating how likely a message is to be spam.
Exchange Online Protection records SCL values in Microsoft-specific headers; interpretation and resulting actions depend on tenant policies.
It can help explain junk placement but is not a universal standard or malware verdict.
A DMARC check that the SPF-authenticated sending domain corresponds with the domain visible in the From address.
DMARC compares the RFC5321.MailFrom domain used by SPF with the RFC5322.From domain. Alignment may be relaxed at the organisational-domain level or strict at the exact-domain level.
A message can pass SPF but still fail DMARC if the authenticated identity belongs to a different domain.
An SMTP feature that upgrades an initially unencrypted connection to TLS.
After EHLO advertises STARTTLS, the client sends the STARTTLS command. A 220 response is followed by a TLS handshake on the same TCP connection, after which SMTP restarts inside the encrypted channel.
It protects messages in transit, but without an enforcement policy an attacker may attempt to remove the offer and cause plaintext fallback.
The certificate field that lists the hostnames the certificate is allowed to represent.
The X.509 Subject Alternative Name extension contains typed identities such as dNSName entries. Modern clients use these names for hostname validation rather than relying on the legacy Common Name alone.
The MX hostname must match an applicable SAN for strict TLS validation to succeed.
The encryption version and algorithm suite used for a protected connection.
A Received or provider-specific field may name TLS 1.2/1.3 and the negotiated cipher suite, but many systems record only that encrypted SMTP was used.
Explicit values provide stronger transport evidence than merely seeing ESMTPS.
A digital identity document presented by a server during an encrypted connection.
An X.509 certificate binds public-key material to named identities and includes an issuer, serial number, validity period, extensions and a certification-authority signature. SSL is the historic name; modern connections use TLS.
For enforced mail TLS, the certificate must be in date, trusted and valid for the MX hostname.
Time spent between two recorded mail-handling stages.
The analyser compares adjacent Received timestamps after normalising their time-zone offsets. Clock errors and forged fields can distort the calculation.
A large delay may indicate queuing, retries, filtering or an unavailable downstream system.
The protocol that encrypts and authenticates a network connection.
TLS negotiates a protocol version, cipher suite, key agreement and server authentication using X.509 certificates. TLS 1.2 and TLS 1.3 are the modern versions relevant to mail transport.
TLS prevents passive reading or alteration of SMTP traffic while it crosses a network.
A non-standard or product-specific header field, usually beginning with X-.
Mail gateways and clients use X-fields for filtering, diagnostics and internal metadata; their semantics are defined by the creating product rather than one universal standard.
They can provide useful clues but should not be interpreted without knowing the originating platform.
