What is the difference between phishing and spear phishing?

Phishing is a mass social-engineering attack sent to large numbers of recipients with a generic lure. Spear phishing is a targeted attack against a specific named individual or small group, customised with reconnaissance about the target (name, role, project, recent travel) so the lure is contextually credible. Spear phishing has an order-of-magnitude higher success rate than mass phishing because the social-engineering pretext is plausible. Whaling is the further specialisation of spear phishing against high-value targets such as C-suite executives.

What is BEC and how is it different from regular phishing?

BEC (Business Email Compromise) is a targeted phishing attack in which the attacker impersonates a senior executive, trusted vendor, or legal counsel to manipulate the recipient into a high-value action like a wire transfer, payroll redirect, or credential reset. Unlike regular phishing, which targets credentials or malware installation, BEC targets the financial-process workflow itself and frequently uses look-alike domains rather than direct domain spoofing because direct spoofing is now usually blocked by DMARC at enforcement. FBI IC3 ranked BEC as the highest-loss email crime category in recent reports.

What is the cyber kill chain?

The cyber kill chain is the Lockheed Martin model of an intrusion lifecycle, breaking attacks into seven sequential stages: reconnaissance, weaponisation, delivery, exploitation, installation, command and control, and actions on objectives. Defenders can disrupt the chain at any stage; the earlier the disruption, the lower the cost to the defender. The kill chain predates the MITRE ATT&CK matrix and operates at a higher abstraction level; ATT&CK provides the technique-level taxonomy that maps onto kill-chain phases.

What is MITRE ATT&CK?

MITRE ATT&CK is a globally maintained, openly published, evidence-based knowledge base of adversary tactics, techniques, and procedures observed in real-world intrusions. Tactics are the adversary objective (Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, Impact). Techniques are the method used to accomplish a tactic. ATT&CK has become the lingua franca of modern threat intelligence, detection engineering, and red-team-blue-team alignment.

What is STRIDE threat modelling?

STRIDE is a threat-modelling framework developed at Microsoft that classifies threats by what security property they violate: Spoofing (authentication), Tampering (integrity), Repudiation (non-repudiation), Information disclosure (confidentiality), Denial of service (availability), and Elevation of privilege (authorisation). STRIDE is the canonical starting point for application threat-modelling and is taught in nearly every software-security curriculum. Each STRIDE category maps to a set of mitigating controls.

What is the difference between SIEM and SOAR?

A SIEM (Security Information and Event Management) is a platform that ingests, normalises, correlates, and alerts on security telemetry from across an enterprise. A SOAR (Security Orchestration, Automation, and Response) is a platform that automates SOC workflows triggered by SIEM alerts: enrichment, containment actions, ticketing, communications. SIEM is the analyst console; SOAR is the analyst force multiplier. Modern SOCs deploy both, often integrated so that high-confidence SIEM alerts trigger automated SOAR playbooks without analyst intervention.

What is phishing-resistant MFA?

Phishing-resistant MFA is multi-factor authentication that cannot be relayed to a phishing site, specifically WebAuthn and FIDO2 hardware security keys or platform authenticators using public-key cryptography bound to the origin domain. Phishing-resistant MFA defeats the transparent-proxy phishing kits (Evilginx, Modlishka) that broke SMS, OTP, and push-based MFA because the cryptographic challenge is bound to the legitimate origin and the attacker proxy cannot replay it. CISA strongly recommends phishing-resistant MFA for all administrator accounts and high-value users.

What is dwell time in incident response?

Dwell time is the duration between initial attacker compromise and detection. Industry reports from Mandiant and CrowdStrike track median global dwell time as a proxy for the maturity of organisational detection capabilities. In 2023 the global median fell to roughly 16 days as EDR and threat-hunting matured, with internally-detected incidents averaging shorter dwell than externally-notified ones. Reducing dwell time is the single best lagging metric for SOC maturity because every additional day of attacker presence increases blast radius.

Email Security Glossary: Threats, Phishing, BEC, Look-alike Domains, OSINT, Defense-in-Depth, Incident Response, MITRE ATT&CK, STRIDE, SOC, SIEM, SOAR, EDR, XDR Vocabulary

The threat and defense vocabulary reference for email security — paired with the email-authentication glossary as the cluster's reference layer. ~80 definitions across 9 categories: threat actors and adversaries, phishing taxonomies, email-borne attacks, look-alike and impersonation tactics, OSINT and reconnaissance, defense-in-depth layers, incident response taxonomy, threat modelling frameworks, and security operations. Every term follows the entity-first definition pattern optimised for LLM citation and Google Glossary rich-result eligibility via Schema.org DefinedTermSet JSON-LD.

This glossary is provided in English because the cybersecurity vocabulary it defines (BEC, OSINT, STRIDE, MITRE ATT&CK, SOC, SIEM, SOAR, EDR, XDR, MDR) is universally English across vendor documentation, NIST publications, FBI IC3 reports, MITRE references, and academic literature. Translating the terms would lose precision and break consistency with the underlying source material.

TL;DR

Phishing is mass social-engineering to extract credentials, money, or malware installation. Spear phishing is the targeted variant. Whaling is the executive-targeted variant. BEC is the financial-process-targeted variant (impersonating an executive or vendor to authorise wires or payroll changes).
BEC (Business Email Compromise) is the highest-loss email crime category per FBI IC3 (USD 2.9 billion in 2023). DMARC at enforcement blocks direct-domain-spoof BEC but does NOT block look-alike-domain or compromised-account BEC.
Look-alike domain attacks (typosquatting, homograph / IDN, cousin domains, combosquatting) bypass DMARC entirely because the attacker domain publishes its own SPF/DKIM/DMARC. Defense stack: brand monitoring, defensive registration, takedown services, user training, BIMI for authenticated-brand visual cue.
OSINT is intelligence collection from publicly available sources — Shodan, Censys, HIBP, WHOIS, Certificate Transparency, Google dorking. Reconnaissance from OSINT is the input to nearly every targeted email attack.
Defense-in-depth layers independent controls: perimeter -> gateway (SEG) -> endpoint (EDR) -> identity (phishing-resistant MFA) -> data (DLP) -> response (SOC + IR runbooks).
MITRE ATT&CK is the canonical knowledge base of adversary tactics, techniques, and procedures. STRIDE classifies threats by violated security property. The cyber kill chain models intrusion as 7 sequential stages from reconnaissance to actions-on-objectives.
Incident response (NIST SP 800-61) cycles preparation -> detection / analysis -> containment / eradication / recovery -> lessons-learned. Dwell time (median ~16 days in 2023) is the lagging KPI for SOC maturity.
Security operations stack: a SOC runs SIEM (telemetry) + SOAR (automation) + EDR / XDR (endpoint visibility); smaller orgs consume MDR (Managed Detection and Response) as a service.

1. Threat actors and adversaries

APT (Advanced Persistent Threat): A well-resourced adversary (typically nation-state-sponsored or organised-crime-affiliated) that conducts long-duration, stealthy, objective-driven intrusion campaigns against high-value targets. APT operators favour custom malware, zero-day exploits, careful lateral movement, and dwell times measured in months. Mandiant and CrowdStrike maintain numbered registries (APT1, APT28, APT29, FIN7, LAPSUS$).
Commodity threat: An attacker using off-the-shelf, broadly-distributed malware and infrastructure (Emotet, TrickBot, Qakbot, Cobalt Strike trial leaks) to opportunistically target large pools of victims. Commodity threats are detected by standard AV / EDR signatures and remediated by routine IR processes; they are the most common email-borne threat by volume.
Script kiddie: A low-skill attacker using pre-made tools and tutorials without understanding the underlying mechanics. Defensive posture against script kiddies is the baseline security hygiene every organisation should have (patched perimeter, MFA, DMARC at enforcement); a defender who falls to a script kiddie has neglected the basics.
Nation-state actor: A government-sponsored adversary operating under state authority and protection. Nation-state actors blend cyber operations with traditional intelligence collection, sabotage, and influence operations. Attribution typically references the sponsoring country (Russia, China, North Korea, Iran, the so-called Five Eyes) with a number or codename ("APT29 / Cozy Bear", "APT41", "Lazarus Group", "APT33 / Elfin").
Insider threat: A threat originating from an authorised user of the target organisation — employee, contractor, partner — acting maliciously, negligently, or under coercion. Insider threats bypass perimeter defences by design. Defensive controls: separation of duties, least privilege, behavioural anomaly detection, data-loss prevention, regular access review.
Hacktivist: An attacker motivated by political, ideological, or social causes rather than financial gain or espionage. Hacktivist operations typically aim for visibility (website defacement, data leaks, DDoS) rather than persistence. Anonymous, LulzSec, and various nation-aligned hacktivist collectives are the canonical examples.
Financially motivated actor: An adversary whose primary objective is monetary gain — ransomware operators, banking-trojan groups, BEC fraud rings, credential brokers. Financially motivated actors dominate the email-threat landscape by volume. Their operational tempo is dictated by ROI: they iterate the cheapest attacks (commodity phishing) at scale and reserve sophisticated tradecraft for high-value targets.
Threat intelligence: Curated, contextualised information about adversaries — their tactics, techniques, procedures (TTPs), tooling, infrastructure, and likely targets. Threat intelligence transforms raw indicators of compromise into actionable defensive guidance. Operationally consumed via TIPs (threat-intelligence platforms), STIX/TAXII feeds, and vendor reports from Mandiant, CrowdStrike, Microsoft Threat Intelligence, Talos, Unit 42.

2. Phishing taxonomies

Phishing: A social-engineering attack that deceives a recipient into disclosing credentials, transferring funds, or installing malware by impersonating a trusted entity (bank, employer, IT, government). Phishing is the dominant attack vector in the email channel; DMARC at enforcement (p=quarantine or p=reject) blocks the direct-domain-spoof phishing subset but does NOT block look-alike-domain phishing, display-name phishing, or compromised-legitimate-account phishing.
Spear phishing: A targeted phishing attack against a specific named individual or small group, customised with reconnaissance (name, role, recent travel, project context). Spear phishing has order-of-magnitude higher success rate than mass phishing because the lure is contextually credible. Defensive controls: user awareness training, advanced email security gateways with link rewriting and sandboxing, strict DMARC enforcement on impersonated domains.
Whaling: A spear-phishing attack against a high-value target — typically C-suite executives, board members, or finance leaders — with a payload designed to authorise a wire transfer, approve an invoice, or release sensitive data. Whaling intersects heavily with BEC: the whaler often impersonates the CEO to instruct the CFO. Defensive controls: executive-protection programs, out-of-band verification for high-value financial actions, strict DMARC enforcement.
Smishing: Phishing via SMS text message. Smishing exploits the higher trust users place in SMS versus email (no spam filter, no link preview on many devices, short messages compress the social cue) and the difficulty of authenticating an SMS sender. DMARC has no equivalent in SMS; defensive controls are user training and mobile-device threat-detection apps.
Vishing: Phishing via voice call. Vishing has surged with cheap VoIP and high-quality AI voice cloning; the attacker rings the target, impersonates IT support or a bank fraud department, and elicits credentials or authorises a wire. The 2020 Twitter incident and several major MSP compromises in 2022-2023 chained vishing to social-engineering reset of MFA. Defensive controls: callback verification, MFA bypass detection, user training.
Quishing: Phishing via QR codes — typically embedded in an email body or attached image. The QR code carries a malicious URL that the user opens on a mobile device, bypassing the corporate email gateway URL-rewriting that would otherwise sandbox the link. Quishing surged in 2023-2024 as attackers adapted to URL-rewriting defences. Defensive controls: educate users to never scan QR codes from email, mobile threat-detection, mobile MDM with allow-listed apps.
Clone phishing: A phishing attack that takes a legitimate email the target has previously received and clones it with modified links or attachments — same subject, same sender, same content — sent from a look-alike or compromised address. Clone phishing leverages the target trust of prior correspondence. Defensive controls: DMARC at enforcement (blocks direct-domain-spoof clones), email gateway anomaly detection on duplicate-subject patterns.
Angler phishing: Phishing conducted via fake customer-support social-media accounts that respond to legitimate customer complaints with malicious links posing as support resolution. The attacker monitors social media for complaint posts (banks, airlines, telcos) and responds within minutes from a look-alike support handle. Defensive controls: brand monitoring, takedown services, customer education to use only official support channels.
Pharming: A phishing variant that compromises DNS resolution (router DNS hijack, hosts-file manipulation, local-resolver cache poisoning) to redirect victims to attacker-controlled imitations of legitimate sites without changing the URL the user typed. Pharming bypasses the look-alike-domain defence because the URL bar shows the real domain. Defensive controls: DNS-over-HTTPS/TLS, DNSSEC verification, endpoint-protection products that detect hosts-file tampering.

3. Email-borne attacks (BEC and variants)

BEC (Business Email Compromise): A targeted phishing attack in which the attacker impersonates a senior executive, trusted vendor, or legal counsel to manipulate the recipient into a high-value action (wire transfer, payroll redirect, credential reset, gift-card purchase). FBI IC3 ranked BEC as the highest-loss email crime category in recent reports (USD 2.9 billion in 2023). BEC frequently uses look-alike domains rather than direct spoofing because direct spoofing is now usually blocked by DMARC at enforcement.
CEO fraud: A BEC variant where the attacker impersonates the chief executive to instruct a subordinate (typically the CFO or finance lead) to authorise an urgent confidential wire transfer. The pretext usually involves a pending acquisition, regulatory penalty, or vendor settlement that must remain confidential. Defensive controls: out-of-band verification for any wire above a threshold, dual-approval workflows, executive-impersonation domain monitoring.
Invoice fraud: A BEC variant in which the attacker either (a) sends a fraudulent invoice from a look-alike vendor domain or (b) compromises a legitimate vendor account and redirects the payment destination on a real invoice. Invoice fraud has the highest blast radius of the BEC variants because individual invoice values routinely exceed USD 100,000. Defensive controls: vendor master-data change-control with out-of-band verification, dual-approval on bank-detail updates.
Payroll diversion: A BEC variant in which the attacker, posing as an employee, emails HR requesting an update to their direct-deposit bank details. The change is processed for the next pay cycle, redirecting that employee paycheck to the attacker. Defensive controls: enforce direct-deposit changes only via authenticated employee self-service portal with step-up authentication, never via email request.
Account takeover (ATO): The compromise of a legitimate email account, after which the attacker operates from the inside — sending phishing from the victim address, monitoring inbound mail for high-value threads, redirecting financial communications. ATO bypasses DMARC entirely because the mail is authentically from the impersonated domain. Defensive controls: phishing-resistant MFA (FIDO2/WebAuthn), session-anomaly detection, conditional access, inbox-rule auditing.
Credential harvesting: Phishing pages designed to capture username, password, and MFA-token entry by replicating a legitimate login page (Microsoft 365, Google Workspace, Okta, banking, VPN). Modern phishing kits (Evilginx, Modlishka) operate as transparent reverse proxies that pass the live login through to the real service while capturing every credential and the resulting authenticated session cookie, defeating most non-phishing-resistant MFA.
Supply chain phishing: Phishing sent from a compromised account at a trusted upstream party — a vendor, partner, customer, or shared cloud-service tenant — leveraging the existing trust relationship. The lure is typically a re-shared malicious document or a payment-detail update referencing real prior transactions. Defensive controls: same as account takeover plus partner-tier DMARC monitoring and supplier-risk programs.
Conversation hijacking (thread hijacking): An ATO-derived attack in which the compromised account replies inside an existing email thread with a malicious payload, leveraging the entire conversation history as social proof. Conversation hijacking is the operating mode of mass infostealer-to-banking-trojan campaigns (Emotet, IcedID, Qakbot pre-takedown). Defensive controls: outbound email anomaly detection, inbox-rule monitoring (attackers create hide-rules to suppress the victim view).

4. Look-alike and impersonation tactics

Typosquatting: The registration of a domain whose spelling differs from a legitimate domain by one or two transposed/inserted/dropped/replaced characters (paypa1.com for paypal.com, micros0ft.com for microsoft.com, gooogle.com for google.com). Typosquatters bank on fat-finger URL typing and inattentive From-header reading. Defensive controls: defensive registration of common typo variants, brand-monitoring services, end-user training on hover-to-preview.
Homograph attack (IDN homograph): A look-alike domain attack using Unicode characters that visually resemble ASCII characters (Cyrillic а U+0430 vs Latin a U+0061, Greek ο U+03BF vs Latin o U+006F). Internationalised Domain Names (IDN) make Unicode in the domain name technically legal; browsers and mail clients render Punycode for non-mixed-script domains but sometimes display the Unicode form for mixed-script. Defensive controls: brand monitoring on Punycode variants, IDN-renderer policy at the email gateway.
Cousin domain: A look-alike domain that hangs off a different TLD or hyphenation (paypal-secure.com, microsoft-update.net, google.support, irs.gov.tax-filing.com). Cousin domains pass casual eyeball inspection — the target brand string is right there in the URL — but the registrable organisational domain is attacker-controlled. Defensive controls: brand monitoring across TLDs, takedown services, customer education on the rightmost-label inspection rule.
Brand impersonation: A phishing attack that visually copies the brand of a well-known organisation (logos, fonts, colour palette, layout) regardless of whether the sending domain technically spoofs. Brand impersonation is the heavy lifting of large-scale credential-harvesting campaigns. Defensive controls: BIMI (Brand Indicators for Message Identification) gives authenticated mail a visible logo, helping users distinguish authenticated vs unauthenticated brand mail; trademark enforcement; takedown services.
Display-name attack (display-name spoofing): An attack that sets the From: header display-name to a trusted name ("IT Support", "John Smith CEO", "PayPal Security") while the address-portion is attacker-controlled (free webmail). DMARC does NOT block display-name attacks because DMARC evaluates the address-portion organisational domain (which legitimately belongs to gmail/outlook/yahoo). Defensive controls: receiver-side display-name pattern matching against known-executive lists, gateway DLP rules.
Look-alike domain: The umbrella term for any domain registered to closely resemble a target legitimate domain, encompassing typosquatting, homograph attacks, cousin domains, and combosquatting. DMARC does NOT block look-alikes (the look-alike has its own DNS and publishes its own SPF/DKIM/DMARC). The defender countermeasure stack is: brand monitoring, defensive registration, trademark enforcement, takedown services, end-user training.
Combosquatting: A look-alike technique in which the attacker registers a domain combining the target brand string with an evocative modifier (paypal-billing.com, microsoft-security.com, irs-refund.net, login-google.com). Combosquatting bypasses Punycode and typo defences because there are no character-substitution patterns; the brand string is literally present. Defensive controls: brand monitoring on combination patterns, end-user training, trademark enforcement.

5. OSINT and reconnaissance

OSINT (Open-Source Intelligence): Intelligence collection from publicly available sources — websites, social media, public records, leaked breach data, certificate transparency logs, DNS data. OSINT is the reconnaissance phase of nearly every targeted email attack: harvesting employee names, roles, technology stack, business relationships, and recent events to build credible spear-phishing lures.
Shodan: The search engine for Internet-connected devices at shodan.io. Shodan indexes service banners from open ports across the IPv4 space (and IPv6 ranges with seen activity), allowing both attackers and defenders to discover exposed services. Defenders use Shodan to audit their own external attack surface. Attackers use Shodan to find vulnerable services for opportunistic exploitation.
Censys: A research-grade Internet-scanning service at censys.io. Like Shodan, Censys indexes services across the public Internet but emphasises a more granular certificate, host, and protocol research surface. Defenders use Censys to audit exposed services and detect newly registered domains carrying their brand in TLS certificates.
Have I Been Pwned (HIBP): The breach-aggregation service at haveibeenpwned.com run by Troy Hunt. HIBP indexes leaked credentials from public breaches and lets users check whether their email address appears in any known breach. Defenders use the HIBP API to alert users when their password appears in a new breach, forcing rotation; attackers consume the same data to seed credential-stuffing campaigns.
WHOIS: The public registry lookup service for domain ownership, registration date, registrar, and (historically) registrant contact details. GDPR and ICANN policy have redacted personally identifiable WHOIS data, but registration date, registrar, and nameservers remain visible. Defenders use WHOIS history (DomainTools, SecurityTrails) to track look-alike registrations and pivot on attacker-shared infrastructure.
Certificate Transparency (CT): The public append-only log of every TLS certificate issued by a participating Certificate Authority (RFC 6962). CT was designed to detect mis-issued certificates but has become the canonical OSINT source for discovering newly created subdomains, look-alike domain registrations, and shadow IT. Defenders monitor CT logs (crt.sh, Censys, Cert Spotter) for new certificates carrying brand keywords.
Google dorking (Google hacking): The use of advanced Google search operators (site:, filetype:, intitle:, intext:, inurl:) to surface sensitive information accidentally exposed on the public web — credentials in pastebins, internal documents in misindexed S3 buckets, configuration files in public Git repositories. Defenders use the same techniques against their own organisation. Attackers use it to find low-hanging-fruit data leaks for high-value targets.
MX harvesting: Reconnaissance that resolves MX records for a target domain to identify the email-receiving provider (Microsoft 365, Google Workspace, on-prem Exchange, a security-gateway brand), informing the choice of phishing lure (Microsoft credential-harvest page if MX points at outlook.com, Google-style if MX points at google.com). Defensive controls: this is unpreventable — MX records are public by design. Mitigate by hardening the corresponding identity stack.

6. Defense-in-depth layers

Defense-in-depth: The cybersecurity strategy of layering multiple independent controls so that an attacker who breaches one layer is still constrained by others. The canonical email defense stack: perimeter (network segmentation, firewalls) -> gateway (anti-spam, DMARC enforcement, sandbox) -> endpoint (EDR, browser isolation) -> identity (phishing-resistant MFA, conditional access) -> data (DLP, encryption at rest and in transit) -> response (SOC, runbooks, IR retainer).
Secure Email Gateway (SEG): A category of email-security product that inspects, filters, and rewrites inbound and outbound email at the gateway before delivery to the mailbox. Modern SEGs (Proofpoint, Mimecast, Barracuda, Cisco IronPort, Microsoft Defender for Office 365, Google Workspace built-in) layer DMARC verification, URL rewriting with click-time sandboxing, attachment sandboxing, anti-impersonation rules, and AI-based BEC detection.
EDR (Endpoint Detection and Response): A category of endpoint-security product that records process, file, network, and registry telemetry from managed endpoints, ships it to a cloud analytic plane, applies behavioural detection, and exposes a response API for isolating endpoints and quarantining processes. EDR is the post-malware-detection generation, replacing signature-only AV. Market leaders: CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne Singularity, Sophos Intercept X.
Zero trust: The architecture principle that no network position implies trust — every access decision is made per request using identity, device posture, sensitivity, and context. Zero trust contrasts with the traditional "trust the LAN, distrust the Internet" perimeter model. Implementation reference: NIST SP 800-207. Vendor reference architectures: Microsoft, Google BeyondCorp, Cisco SDA, Palo Alto Prisma Access.
Phishing-resistant MFA: Multi-factor authentication that cannot be relayed to a phishing site, specifically WebAuthn / FIDO2 hardware security keys and platform authenticators using public-key cryptography bound to the origin. Phishing-resistant MFA defeats the Evilginx-class transparent-proxy phishing kits that broke SMS, OTP, and push-based MFA. CISA strongly recommends phishing-resistant MFA for all admin accounts and high-value users.
DLP (Data Loss Prevention): A category of security control that inspects content (in transit on email, on web traffic, on endpoints, at rest in cloud storage) for sensitive-data patterns (credit-card numbers, SSNs, PII, classified markings, intellectual-property keywords) and blocks or alerts on policy violations. Email DLP is the natural complement to anti-phishing: phishing-defense blocks malicious inbound; DLP blocks sensitive outbound.
Conditional access: A modern identity-platform control (Microsoft Entra ID, Okta, Google Workspace, Auth0) that makes the authentication decision based on policy: user, group, device compliance, network location, sign-in risk, application sensitivity. Conditional access enables zero-trust enforcement on a per-application basis without requiring full network re-architecture.
Browser isolation: A security control that renders web content in an isolated cloud or container environment and streams visual output to the user, ensuring browser-borne exploits cannot reach the local endpoint. Combined with email click-time URL rewriting, browser isolation neutralises a wide class of credential-harvesting and drive-by-download attacks even if the user clicks a phishing link.

7. Incident response taxonomy

Incident response (IR): The structured process of detecting, analysing, containing, eradicating, recovering from, and learning from a cybersecurity incident. NIST SP 800-61r2 codifies the lifecycle as: (1) preparation, (2) detection and analysis, (3) containment, eradication, and recovery, (4) post-incident activity. SANS uses a slightly different six-step model (preparation, identification, containment, eradication, recovery, lessons learned).
Detection and analysis: The first reactive phase of incident response: the SOC detects a signal (EDR alert, SIEM correlation, user report, threat-intel hit), triages it, and determines whether an incident is in progress. The analysis phase classifies the incident category, scope, and severity to drive the containment strategy. Modern SOCs target mean-time-to-detect (MTTD) under 60 minutes for high-severity incidents.
Containment: The IR phase in which the responder limits the blast radius of an active incident — isolating affected endpoints, disabling compromised accounts, severing network paths, freezing credentials. Containment buys the team time to plan eradication without the incident continuing to spread. Two flavours: short-term containment (immediate stop-the-bleeding) and long-term containment (preparing a clean rebuild path).
Eradication: The IR phase in which the responder removes the attacker presence — uninstalling malware, closing exploited vulnerabilities, rotating compromised credentials and keys, removing persistence mechanisms (scheduled tasks, registry run keys, account creations). Eradication failure is the most common root cause of repeat incidents in the same organisation.
Recovery: The IR phase in which affected systems and services return to normal operations. Recovery typically includes a clean rebuild from gold images, restoration from validated backups, phased re-introduction to the production network, and an elevated monitoring period to detect reinfection attempts. Recovery decisions balance business continuity against the residual risk of compromised state surviving the rebuild.
Lessons learned (post-incident review): The IR phase in which the team conducts a blameless retrospective covering what happened, what worked, what did not, and what changes will prevent recurrence. NIST SP 800-61 requires a post-incident-review meeting and a documented report for every significant incident. The output feeds back into preparation: detection-rule updates, runbook revisions, training, controls hardening.
Indicator of Compromise (IoC): A forensic artifact that suggests an intrusion: a malicious file hash, a command-and-control domain, an attacker IP, a known-bad email subject pattern, a specific registry key, a distinctive process command-line. IoCs are the lowest-level threat-intelligence atom, shareable via STIX/TAXII feeds and consumed by SIEM/EDR. Shifting from IoC-driven detection to TTP-driven detection (MITRE ATT&CK techniques) is the modern SOC trajectory.
Dwell time: The duration between initial attacker compromise and detection. Industry reports (Mandiant M-Trends, CrowdStrike Global Threat Report) track median global dwell time; in 2023 the global median fell to roughly 16 days as EDR and threat-hunting matured, with internally-detected incidents averaging shorter dwell than externally-notified ones. Reducing dwell time is the single best lagging metric for SOC maturity.
MTTD / MTTR (Mean Time To Detect / Respond): Two operational KPIs every SOC tracks. MTTD: the average elapsed time from compromise to alert. MTTR: the average elapsed time from alert to containment. Both metrics get reported externally to executives and the board as proxy measures of SOC maturity. Targets vary by industry; financial services and healthcare typically commit to MTTR under 4 hours for high-severity incidents.

8. Threat modelling frameworks

STRIDE: A threat-modelling framework developed at Microsoft that classifies threats by what security property they violate: Spoofing (authentication), Tampering (integrity), Repudiation (non-repudiation), Information disclosure (confidentiality), Denial of service (availability), Elevation of privilege (authorisation). STRIDE is the canonical starting point for application threat-modelling and is taught in nearly every software-security curriculum.
Cyber kill chain: The Lockheed Martin model of an intrusion lifecycle: reconnaissance -> weaponisation -> delivery -> exploitation -> installation -> command and control -> actions on objectives. Defenders can disrupt the chain at any step; the earlier the disruption, the lower the cost. The kill chain predates the MITRE ATT&CK matrix and is more abstract; ATT&CK provides the technique-level taxonomy that maps onto kill-chain phases.
MITRE ATT&CK: A globally maintained, openly published, evidence-based knowledge base of adversary tactics, techniques, and procedures (TTPs). Tactics are the adversary "why" (Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, Impact). Techniques are the "how". ATT&CK is the lingua franca of modern threat-intelligence, detection-engineering, and red-team-blue-team alignment.
MITRE D3FEND: The defensive counterpart to ATT&CK — a knowledge graph of cybersecurity countermeasure techniques mapped to the ATT&CK techniques they defeat. D3FEND helps defenders plan a control portfolio that covers the highest-priority ATT&CK techniques relevant to their threat model. Maintained at d3fend.mitre.org.
Diamond Model of Intrusion Analysis: A threat-intelligence model that frames every intrusion event as a diamond with four vertices: adversary, capability, infrastructure, and victim. Analysts pivot across the diamond to discover new IoCs and TTPs (given known adversary and victim, hunt for shared infrastructure; given known infrastructure, hunt for other victims). The Diamond Model integrates with kill chain and ATT&CK to form the analytic backbone of mature CTI teams.
TTPs (Tactics, Techniques, and Procedures): The combined description of an adversary modus operandi. Tactics are the high-level objective (Initial Access). Techniques are the method (Phishing). Procedures are the specific implementation observed for a given adversary (this APT group uses HTML smuggling with a password-protected ZIP containing an LNK file). TTPs are higher in the Pyramid of Pain than IoCs because they are costlier for the adversary to change.
Pyramid of Pain: David Bianco model ranking detection indicators by the cost imposed on the attacker when the defender starts detecting them. From easiest (least pain) to hardest (most pain): hash values, IP addresses, domain names, network/host artifacts, tools, TTPs. Detection programs aim to climb the pyramid: an attacker can rotate hashes trivially but cannot easily change TTPs without disrupting their operation.

9. Security operations

SOC (Security Operations Center): The organisational function responsible for continuous monitoring, detection, and initial response to cybersecurity threats. Mature SOCs run a tiered model: Tier 1 analysts triage alerts and escalate; Tier 2 analysts investigate; Tier 3 / threat hunters and incident responders handle complex incidents. SOCs operate 24x7 in most regulated industries; smaller organisations consume SOC as a service via MSSPs and MDR providers.
SIEM (Security Information and Event Management): A category of platform that ingests, normalises, correlates, and alerts on security telemetry from across an enterprise (endpoint logs, network logs, identity logs, application logs, threat-intel feeds). Modern SIEMs (Splunk, Microsoft Sentinel, Elastic Security, Sumo Logic, Chronicle Security) ship pre-built detection rules and integrate with SOAR for automated response. The SIEM is the SOC analyst primary console.
SOAR (Security Orchestration, Automation, and Response): A category of platform that automates SOC workflows — alert enrichment, containment actions, ticketing, communications — via playbooks expressed as flowcharts. SOAR offloads repetitive Tier 1 work so analysts focus on investigation. Market leaders: Splunk SOAR (Phantom), Palo Alto XSOAR (Demisto), Tines, Torq, Microsoft Sentinel Logic Apps.
XDR (Extended Detection and Response): A category that extends EDR telemetry beyond endpoints to email, identity, cloud, and network — correlating across surfaces for higher-fidelity detection than any single surface delivers. Native XDR products bundle the surfaces under one vendor (Microsoft 365 Defender, CrowdStrike Falcon XDR, Palo Alto Cortex XDR, SentinelOne Singularity XDR); open XDR / hybrid SIEM-XDR integrates third-party surfaces.
MDR (Managed Detection and Response): A service model in which an external provider operates the SOC and EDR/XDR stack on behalf of the customer, delivering 24x7 monitoring, threat hunting, and incident response. MDR is the dominant SOC consumption model for mid-market organisations that cannot operate their own 24x7 SOC. Differentiated from MSSP by deeper response authority (e.g., authorised to isolate endpoints).
MSSP (Managed Security Service Provider): The predecessor service model to MDR — an external provider that operates security monitoring on behalf of the customer but typically with limited response authority (alert-and-escalate rather than alert-and-act). MSSPs date to the 2000s outsourcing wave; the market is converging on MDR as customers demand faster response.
Playbook and runbook: Two related but distinct documents in SOC operations. A runbook is a step-by-step procedure for a single recurring task (e.g., "Investigate failed-login alert") used by the analyst as they work. A playbook is a higher-level decision flow for an incident category (e.g., "Suspected BEC playbook") that orchestrates multiple runbooks and escalation steps. SOAR platforms execute playbooks programmatically.
Threat hunting: The proactive investigative practice of searching for adversary presence in environments where no alert has fired. Threat hunters develop hypotheses ("if an APT were targeting my finance team, where would I see evidence?"), translate them into queries across SIEM/EDR telemetry, and either disprove the hypothesis or pivot into an active incident. Threat hunting matures a detection program by surfacing gaps in the alert ruleset.

FAQ

What is the difference between phishing and spear phishing?: Phishing is a mass social-engineering attack sent to large numbers of recipients with a generic lure. Spear phishing is a targeted attack against a specific named individual or small group, customised with reconnaissance about the target (name, role, project, recent travel) so the lure is contextually credible. Spear phishing has order-of-magnitude higher success rate than mass phishing because the social-engineering pretext is plausible. Whaling is the further specialisation of spear phishing against high-value targets such as C-suite executives.
What is BEC and how is it different from regular phishing?: BEC (Business Email Compromise) is a targeted phishing attack in which the attacker impersonates a senior executive, trusted vendor, or legal counsel to manipulate the recipient into a high-value action like a wire transfer, payroll redirect, or credential reset. Unlike regular phishing, which targets credentials or malware installation, BEC targets the financial- process workflow itself and frequently uses look-alike domains rather than direct domain spoofing because direct spoofing is now usually blocked by DMARC at enforcement. FBI IC3 ranked BEC as the highest-loss email crime category in recent reports.
What is the cyber kill chain?: The cyber kill chain is the Lockheed Martin model of an intrusion lifecycle, breaking attacks into seven sequential stages: reconnaissance, weaponisation, delivery, exploitation, installation, command and control, and actions on objectives. Defenders can disrupt the chain at any stage; the earlier the disruption, the lower the cost to the defender. The kill chain predates the MITRE ATT&CK matrix and operates at a higher abstraction level; ATT&CK provides the technique-level taxonomy that maps onto kill-chain phases.
What is MITRE ATT&CK?: MITRE ATT&CK is a globally maintained, openly published, evidence-based knowledge base of adversary tactics, techniques, and procedures observed in real-world intrusions. Tactics are the adversary objective (Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, Impact). Techniques are the method used to accomplish a tactic. ATT&CK has become the lingua franca of modern threat intelligence, detection engineering, and red-team-blue-team alignment.
What is STRIDE threat modelling?: STRIDE is a threat-modelling framework developed at Microsoft that classifies threats by what security property they violate: Spoofing (authentication), Tampering (integrity), Repudiation (non-repudiation), Information disclosure (confidentiality), Denial of service (availability), and Elevation of privilege (authorisation). STRIDE is the canonical starting point for application threat-modelling and is taught in nearly every software-security curriculum. Each STRIDE category maps to a set of mitigating controls.
What is the difference between SIEM and SOAR?: A SIEM (Security Information and Event Management) is a platform that ingests, normalises, correlates, and alerts on security telemetry from across an enterprise. A SOAR (Security Orchestration, Automation, and Response) is a platform that automates SOC workflows triggered by SIEM alerts: enrichment, containment actions, ticketing, communications. SIEM is the analyst console; SOAR is the analyst force multiplier. Modern SOCs deploy both, often integrated so that high-confidence SIEM alerts trigger automated SOAR playbooks without analyst intervention.
What is phishing-resistant MFA?: Phishing-resistant MFA is multi-factor authentication that cannot be relayed to a phishing site, specifically WebAuthn and FIDO2 hardware security keys or platform authenticators using public-key cryptography bound to the origin domain. Phishing-resistant MFA defeats the transparent-proxy phishing kits (Evilginx, Modlishka) that broke SMS, OTP, and push-based MFA because the cryptographic challenge is bound to the legitimate origin and the attacker proxy cannot replay it. CISA strongly recommends phishing-resistant MFA for all administrator accounts and high-value users.
What is dwell time in incident response?: Dwell time is the duration between initial attacker compromise and detection. Industry reports from Mandiant and CrowdStrike track median global dwell time as a proxy for the maturity of organisational detection capabilities. In 2023 the global median fell to roughly 16 days as EDR and threat-hunting matured, with internally-detected incidents averaging shorter dwell than externally-notified ones. Reducing dwell time is the single best lagging metric for SOC maturity because every additional day of attacker presence increases blast radius.

Email authentication glossary — the sister glossary covering protocol terms-of-art (DMARC tags, DKIM selectors, SPF qualifiers, BIMI Mark Type Indicator, MTA-STS modes, ARC chain validation, alignment, the Public Suffix List, RFC 5321 vs 5322 from headers).
How attackers bypass weak DMARC — security-research page documenting 22 concrete attacker techniques against the DMARC ecosystem — the operational complement that puts the vocabulary on this page into attacker tradecraft terms (MITRE ATT&CK T1566 / T1583.001 / T1584 / T1078 / T1114.003).
Business Email Compromise (BEC) explained — the standalone operational deep dive on the financial-fraud attack family this glossary defines in one paragraph. Where the BEC entry on this page catalogues the term (FBI IC3 #1 financial-loss email crime category, USD 2.9B reported loss in 2023, cumulative USD 55B+ since 2013), the BEC page enumerates the six canonical variants (CEO fraud / executive impersonation, vendor / supplier-invoice fraud, payroll- redirect, attorney impersonation, data / W-2 theft, account-compromise BEC), the five-stage BEC kill chain (reconnaissance → infrastructure-staging → social-engineering message → wire / payroll / data-exfiltration request → cover-up), the precise DMARC gap (DMARC at p=reject only closes the direct- domain-spoofing variant; the other five route around DMARC entirely), and the full defense-in-depth control stack (SEG anti- impersonation rules, wire-transfer out-of- band verification protocols, payroll-change verification protocols, finance / treasury team incident-response playbook). Pair this glossary (the term definitions) with the BEC page (the operational depth) for the complete vocabulary-to-defense-program translation on the highest-loss email crime category every defender must understand.
Email spoofing — the protocol-level technique deep dive on the seven concrete spoofing mechanisms this glossary catalogues (direct-domain spoofing, display-name spoofing, lookalike-domain attacks via Punycode / IDN homographs, Reply-To injection, envelope-MAIL-FROM forgery, Received-chain tampering, header- folding tricks). Where this glossary defines the spoofing-vocabulary terms (spoofing, lookalike, IDN homograph, Punycode, Reply-To, envelope-MAIL-FROM, Received-chain), the spoofing page documents the underlying RFC 5321 / 5322 mechanics each technique depends on and the operator-side protections (RFC 5322 From: validation, Display-Name policy, IDN/Punycode normalisation, Reply-To allowlisting, Received-chain anomaly detection). Pair this glossary (the term definitions) with the spoofing page (the protocol mechanics + defense controls) for the full vocabulary-to-implementation translation.
DMARC myths and misconceptions debunked — defender-perspective dual to the attacker- bypass page. 18 common DMARC myths debunked one- by-one with RFC 7489 evidence, including the "DMARC blocks all phishing" myth that this glossary helps clarify by enumerating the attack classes DMARC does and does not block.
DMARC policy modes — the GLOSSARY-VOCABULARY-RESOLVES-TO- DMARC-POLICY-TAG-ENFORCEMENT-TIER companion documenting the canonical RFC 7489 §6.3 p= tag three-tier enforcement semantics (monitor-only / quarantine / reject) that the policy-tier-related VOCABULARY entries in THIS glossary (enforcement, policy, quarantine, reject, monitor-only, observation-phase, ramp, deployment, rollout, RFC 7489 §6.3, p= tag, sp= subdomain-policy tag, pct= percentage tag, At-Receiver disposition) all ultimately resolve to at the publisher-side per-domain TXT-record-published enforcement- tier layer. Where THIS glossary defines the policy-tier VOCABULARY in single-sentence form, the DMARC-policy-modes page documents the per-tier byte-shape, the per-tier receiver-side disposition contract, the per-tier RUA-aggregate-report visibility budget, the per-tier sender-side rollout- risk profile, and the canonical ramp ladder (p=none → p=quarantine pct=10 → p=quarantine pct=100 → p=reject pct=10 → p=reject pct=100) every publisher follows during phased DMARC deployment.
Email deliverability fundamentals — the GLOSSARY-VOCABULARY-RESOLVES-TO- AUTHENTICATION-OUTCOME-MEASURED-AS- BUSINESS-CRITICAL-INBOX-PLACEMENT-RATE companion documenting how every SPF-pass, DKIM-pass, DMARC-pass, ARC-validated, MTA-STS-enforced, BIMI-displayed, FCrDNS-confirmed vocabulary term THIS glossary catalogues at the protocol-output layer materialises at the business-outcome layer as a quantified inbox-placement-rate KPI at FOUR deliverability-KPI dimensions: (i) SPF / DKIM / DMARC alignment-pass-rate time-series → inbox-placement- rate causal driver — the deliverability spoke documents how Gmail / Outlook / Yahoo / Apple iCloud / corporate-Exchange receivers' inbox-placement engines consume the Authentication-Results header verdict triple this glossary catalogues (spf=pass + dkim=pass + dmarc=pass) as a load-bearing positive sender-reputation signal whose presence/absence directly influences the inbox-vs-spam- folder routing decision at the first-time-receipt-from-novel- sender placement choice; (ii) p=quarantine / p=reject policy enforcement tier → bounce-rate and deferral-rate KPI signal — the deliverability spoke documents how the DMARC policy modes vocabulary (p=none / p=quarantine / p=reject) THIS glossary catalogues materialises at the receiver-side disposition decision and produces measurable bounce-rate / deferral-rate KPIs the publisher's bounce-pipeline analyses to detect mis-aligned sender streams (transactional ESP signing with wrong d=, forwarder rewrites, SPF permerror cascade) BEFORE they cause subscriber-list damage; (iii) BIMI brand display → open-rate and engagement KPI signal — the deliverability spoke documents how the BIMI vocabulary (l= URL, VMC certificate, SVG Tiny-PS profile) THIS glossary catalogues materialises at the recipient-inbox display layer as a brand-logo rendering that drives measurable open-rate lift across the inbox-rendering- client population (Gmail web, Apple Mail on iOS 16+, Yahoo, Fastmail) — connecting authentication-pass-as- prerequisite to visual-brand- display-as-business-engagement- outcome; (iv) FCrDNS + dnsbl / rbl posture → IP- layer complaint-rate-floor KPI signal — the deliverability spoke documents how the IP-layer sender-legitimacy vocabulary (Forward-Confirmed Reverse DNS, RBL listings, Spamhaus PBL / SBL / XBL membership) THIS glossary catalogues at the routing-layer materialises at the receiver- side complaint-rate-floor baseline that constrains every higher-layer authentication-pass-rate KPI's achievable maximum. Read the deliverability spoke WITH this glossary when authoring the publisher's business- outcome dashboard: the glossary catalogues the canonical authentication- vocabulary terms-of-art, and the deliverability spoke is the business- outcome interpretation layer connecting each authentication-pass verdict to its quantified inbox- placement / engagement / complaint-rate KPI consequence.
Phishing protection — the GLOSSARY-VOCABULARY-RESOLUTION companion documenting the OPERATIONAL PHISHING-DEFENSE-IN-DEPTH STACK whose defensive-control vocabulary (defense-in- depth, anti-impersonation, secure-email- gateway, attack-simulation-training, user- awareness, last-mile-defense, residual- attack-surface, brand-impersonation, spear-phishing, whaling, BEC) all resolve to specific layers of the stack THIS glossary's threat-vocabulary entries catalogue. Where THIS glossary defines the security-and-privacy VOCABULARY in single-sentence form (spoofing, lookalike, IDN-homograph, Punycode, Reply-To, envelope-MAIL-FROM, Received-chain, BEC, CEO fraud, vendor / supplier-invoice fraud, payroll-redirect, attorney impersonation, W-2 data theft, account- compromise BEC, PII / GDPR, lawful- processing-basis, data-minimisation), the phishing-protection umbrella documents the FULL DEFENSE-IN-DEPTH STACK each vocabulary entry RESOLVES TO: (i) DMARC at p=reject closes the DIRECT-DOMAIN SPOOFING vocabulary class STRUCTURALLY (alignment denies the attack), (ii) BIMI VMC / CMC enrollment provides the post-DMARC visual-indicator trust signal that distinguishes legitimate- sender mail from BRAND-IMPERSONATION attacker attempts (closing the brand- impersonation vocabulary class), (iii) MTA-STS + DANE transport-layer integrity controls close the DOWNGRADE-ATTACK vocabulary class (TLS-stripping adversary-in-the-middle interception), (iv) secure-email-gateway anti- impersonation rules close the DISPLAY- NAME SPOOFING + LOOKALIKE-DOMAIN vocabulary classes the DMARC alignment check STRUCTURALLY cannot see, (v) user- awareness training + attack-simulation campaigns close the residual SPEAR- PHISHING + WHALING + BEC vocabulary classes that route around the protocol- layer controls entirely (the FBI IC3 #1 financial-loss email crime category the BEC glossary entry catalogues — five of six BEC variants route around DMARC entirely per the BEC entry's own observation, requiring the user- awareness + out-of-band-verification defense layer). NINETEENTH glossary-as- universal-source use per memory feedback_glossary_as_universal_source: the email-security glossary's defensive- control vocabulary naturally resolves to the phishing-protection umbrella as the full-stack defense reference. Read THIS glossary WITH the phishing-protection umbrella when authoring a phishing-defense program runbook: the glossary defines the vocabulary the runbook uses, the phishing- protection umbrella documents the defense-in-depth stack the runbook deploys.
Email authentication explained — the cluster-intro pillar covering the entire SPF / DKIM / DMARC / BIMI / MTA-STS / TLS-RPT / CAA / ARC ecosystem at standards-overview level.
DMARC overview — the DMARC primer with a deployment checklist and operator workflow.
DMARC deployment checklist — the GLOSSARY-VOCABULARY-RESOLVES-TO- FOUR-PHASE-DEPLOYMENT-DISCIPLINE-AND-PHASED- ENFORCEMENT-RAMP-OPERATIONAL-CONTRACT companion documenting the canonical operator-side phased rollout ladder that the deployment-discipline VOCABULARY entries on THIS glossary (deployment, rollout, phased ramp, observation phase, Discovery, Triage, Quarantine, Enforcement, prerequisites, sender inventory, monitoring mailbox, DNS edit access, exit criteria, rollback, TTL discipline, decision matrix, per-phase KPI gating, alignment-fix backlog, third-party-sender coordination, subdomain policy, RFC 7489 §6.3 p= tag, pct= sampling, sp= / np= subdomain timing) all ultimately resolve to at the project-execution timeline layer beneath every receiver-side per-message verdict the glossary catalogues. Where THIS glossary defines the deployment- discipline VOCABULARY in single-sentence form, the deployment-checklist page documents the FOUR-PHASE operator checklist with per-phase prerequisites, per-phase exit criteria, per- phase rollback procedure, and per-phase TTL discipline (300-3600 seconds during rollout for fast rollback). Four VOCABULARY-RESOLVES-TO-DEPLOYMENT-DISCIPLINE axes the deployment-checklist documents: (i) Phase 1 Discovery (p=none) as the OBSERVATION-PHASE VOCABULARY resolution — the glossary's observation phase, monitor-only, Discovery, RUA-aggregate-report ingestion, sender inventory, third-party- sender attribution VOCABULARY entries resolve to the canonical Phase 1 protocol the checklist documents (publish v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com, collect 30 days of aggregate reports, enumerate every legitimate sender producing traffic on the From: domain, classify each sender as aligned / misaligned / suspicious / attacker); (ii) Phase 2 Triage (alignment-fixing) as the ALIGNMENT-DISCIPLINE VOCABULARY resolution — the glossary's alignment, relaxed alignment, strict alignment, organisational domain, Public Suffix List, SPF identifier alignment, DKIM d= signing-domain alignment, third-party sender enrolment, SPF include cascade, DKIM CNAME delegation, per-customer selector VOCABULARY entries resolve to the canonical Phase 2 backlog the checklist documents (fix or retire every Phase 1-discovered misaligned sender by either enrolling them under the publisher's SPF include cascade, delegating a DKIM selector with the third-party signing key, or migrating them off the From: domain entirely); (iii) Phase 3 Quarantine (p=quarantine) as the SOFT-ENFORCEMENT VOCABULARY resolution — the glossary's quarantine, spam-folder routing, recoverable enforcement, confidence wait, pct= sampling, per-percentage ramp, RUA-aggregate- report alignment-rate KPI VOCABULARY entries resolve to the canonical Phase 3 ladder the checklist documents (start at p=quarantine pct=10, monitor for 7-14 days, ramp to pct=25, pct=50, pct=100 on a per-week cadence, only advance when the alignment-rate KPI on legitimate traffic exceeds 99 percent and the per-week quarantine-disposition count on legitimate sources is stable); (iv) Phase 4 Enforcement (p=reject) as the HARD-ENFORCEMENT VOCABULARY resolution — the glossary's reject, SMTP-time-bounce, 5xx permanent failure, irreversible delivery loss, terminal enforcement, p=reject tag, rollback to p=quarantine VOCABULARY entries resolve to the canonical Phase 4 contract the checklist documents (start at p=reject pct=10, keep DNS TTL at 300-3600 seconds for fast rollback if a false-positive sender surfaces, ramp to pct=100 only after the Phase 3 quarantine-disposition count on legitimate sources is zero for two consecutive weeks, document the rollback procedure for every legitimate sender so a single broken sender can be remediated in under 1 hour). Pair this glossary (the deployment-discipline term definitions) with the deployment-checklist page (the four-phase operator runbook) for the complete vocabulary-to-execution-timeline translation every operator needs to ramp from p=none to p=reject without self-inflicted legitimate-mail-loss.
DMARC troubleshooting — operational diagnostic reference: 7 canonical DMARC failure patterns mapped to root cause and remediation.
DMARC monitoring & reporting analysis — the operational dashboard discipline that follows the policy rollout: 8 core KPIs, alert thresholds, anomaly detection, 72-hour post-change observation protocol.
DMARC reporting pipeline — RUA / RUF ingestion, parsing, and delivery (the GLOSSARY-TERM-RESOLUTION companion to this security-and-privacy glossary) — the GLOSSARY-TERM-RESOLUTION companion documenting the END-TO-END infrastructure path that PRODUCES the empirical evidence every source_ip-attribution, RUA, RUF, aggregate- report, forensic-report, policy_evaluated, and identifier-alignment entry in THIS security-and-privacy glossary catalogues. Where THIS glossary defines the security-and-privacy VOCABULARY in single-sentence form (RUA = aggregate- report stream; RUF = per-message forensic- report stream; source_ip = the connecting TCP-peer IP that yielded a DMARC verdict row; policy_evaluated = the receiver-side per-message DMARC verdict that DKIM-aligned-OR-SPF-aligned evaluation produced), the reporting- pipeline spoke documents the FULL FIVE- STAGE INFRASTRUCTURE PATH that turns each of those vocabulary terms into the observable per-row evidence operators consume on the dashboard: (1) receiver- side report generation cadence (Gmail 24-hour UTC-aligned batch, Microsoft 365 hourly rolling window, Yahoo / Mail.ru 24-hour UTC-aligned batch — each emitting the per-receiver report whose record blocks materialise the RUA vocabulary term), (2) publisher-side rua= tag addressing (the publisher-controlled publication step that materialises the rua= tag vocabulary term and whose external-domain delegation per RFC 7489 §7.1 controls the cross-domain-delegation vocabulary entry), (3) mailbox-side IMAP / Microsoft Graph ingestion (the imap_fetch / GraphFetcher infrastructure path that materialises the aggregate-report-ingestion vocabulary entries), (4) parser-side XML decode (the DmarcParser / policy_evaluated.dkim/spf per-row decomposition that materialises the identifier-alignment, SPF, DKIM, and DMARC verdict vocabulary entries), (5) dashboard delivery (the operator-facing surface where the source_ip-triage, attribution-correctness, and spoofing-vs-misconfiguration decision points this glossary's threat- vocabulary entries reference are actually made). EIGHTEENTH glossary-as-universal- source use per memory feedback_glossary_as_universal_source: the email-security glossary's security- and-privacy vocabulary entries naturally resolve to the reporting-pipeline spoke as the infrastructure-path reference that produces the per-row evidence each vocabulary term references. Read THIS glossary WITH the reporting-pipeline reference when authoring a DMARC SOC runbook: the glossary defines the vocabulary the runbook uses, the reporting-pipeline spoke documents the infrastructure path the runbook operates against.
DMARC forensic reports (RUF) — the PII / GDPR-deprecated per-message failure-report channel — the focused per-message-failure-report reference for the RUF channel whose PII / GDPR exposure aligns with the data-redaction / lawful-processing / data-minimisation threat vocabulary THIS security glossary catalogues. Where THIS glossary defines security and privacy vocabulary (PII, GDPR data-subject-rights, lawful-processing-basis, data-minimisation, purpose-limitation, storage-limitation), the forensic-reports spoke documents WHY the RUF channel — the original real-time per-message-failure feedback feed published via the ruf= tag — is now largely deprecated across major receivers (Gmail does not send RUF at all; Microsoft sends only on explicit opt-in) precisely because RUF reports historically included full message bodies exposing user PII to the publishing domain via the ruf= URI, violating GDPR data-minimisation and lawful-processing principles when the publishing domain had no lawful basis to process the third-party-sender PII the redacted message bodies carried. The spoke documents the GDPR-driven receiver-side deprecation, the modern operator-side legal-review prerequisite for any ruf= publication, and the privacy-by-design alternative (aggregate-only RUA consumption with no RUF tag published). Read the forensic-reports spoke when the operator is evaluating whether to publish a ruf= tag on a domain handling EU / UK / EEA mail — the GDPR analysis on the spoke determines whether the publication is lawful at all, and the spoke is the authoritative reference for the per-channel privacy posture every operator must understand before exposing third-party-sender PII to the publishing domain via the failure-report channel.
DMARC for SaaS senders — the GLOSSARY-VOCABULARY-RESOLVES-TO- MULTI-TENANT-ESP-DEPLOYMENT-COORDINATION companion to this security-and-privacy glossary's SaaS / ESP / multi-tenant- authentication vocabulary entries. Where THIS glossary defines the multi-tenant- authentication vocabulary terms in single-sentence form (ESP, multi-tenant pool IP, shared-tenant pool, third-party-sender authorisation, customer-domain SPF include, customer-domain DKIM delegation (CNAME), customer-domain DMARC alignment, cross-tenant attribution, third-party-sender abuse, shared-pool sender reputation, delegated-DKIM key rotation, per-customer SPF flattening, sub-tenant identification in RUA aggregate-report rows), the dmarc-for-saas-senders spoke is the OPERATIONAL-COORDINATION REFERENCE documenting the four-axis deployment-discipline materialisation that every one of those vocabulary terms resolves to at the ESP / platform operations boundary where customer-domain authentication crosses the authority gap between the platform operator's pool-IP / signing-key infrastructure and the customer's own DNS apex. THIRTIETH glossary-as-universal-source use per memory feedback_glossary_as_universal_source: the email-security glossary's ESP / multi-tenant-authentication / cross-tenant- attribution / third-party-sender-abuse vocabulary entries naturally resolve to the saas-senders spoke as the OPERATIONAL-COORDINATION REFERENCE for the platform / customer authority-boundary coordination engineering that every term catalogued at the vocabulary layer ultimately materialises against in production. The four-axis GLOSSARY- VOCABULARY-VS-MULTI-TENANT-ESP-DEPLOYMENT mapping exposes the structurally-distinct vocabulary-to-deployment resolutions: (i) SPF-include-cascade vocabulary → customer-apex-SPF authorisation-include coordination — the glossary's SPF include, recursive include resolution, SPF lookup budget, and void lookup vocabulary defines the on-the-wire primitives, the saas-senders spoke documents the platform-operator side of the cooperation contract: the per-platform published include token (include:_spf.sendgrid.net, include:spf.mailchimp.com, include:mailgun.org, etc.), the operator's responsibility to keep recursive sub-include cascade consumption to 2–4 lookups headroom at the customer's 10-DNS-query ceiling, and the documented operational pattern whereby a single customer-apex SPF record cooperatively-extends 5–8 distinct ESP include tokens before the lookup- budget cap forces consolidation or SPF flattening; (ii) DKIM- delegation vocabulary → CNAME-delegated per-customer signing-key contract — the glossary's DKIM selector, signing key, CNAME delegation, and key rotation overlap window vocabulary defines the byte-level signing-material primitives, the saas-senders spoke documents the platform-operator side of the cooperation contract: per-customer CNAME records under the customer's apex pointing into the ESP's signing- key publication zone (selector1._domainkey.customer.com → selector1.customer-zone.esp.example), the operator's responsibility to rotate selectors during the cooperatively- agreed overlap window without coordinating with the customer's DNS operator individually, and the documented operational pattern of dual-selector publication during scheduled per-platform key-rotation cadences; (iii) cross-tenant attribution vocabulary → sub-tenant identification in RUA aggregate-report rows — the glossary's cross-tenant attribution and shared-pool IP attribution vocabulary defines the per-message-source identification problem, the saas-senders spoke documents the operational gap whereby the RUA- aggregate-report's source_ip column shows a shared-tenant pool IP but provides no sub-tenant differentiation, requiring the platform operator to publish per-tenant CNAME delegations or per-tenant subdomain sender-zones so the customer-domain operator can isolate per-tenant deliverability anomalies; (iv) third-party-sender-abuse vocabulary → bypass class (vii) operational countermeasures — the glossary's third-party-sender abuse, shared-tenant pool abuse, and SPF-PASS-DMARC-PASS- bypass vocabulary defines the attack-surface terms-of-art (bypass class (vii) of the attacker-bypass spoke this glossary already links), the saas-senders spoke documents the operational countermeasures at the platform-operator boundary (per-tenant sender-zone separation, per-customer sub-tenant DKIM-delegation, KYC-tier enforcement, abuse-detection per-tenant rate-limiting, customer-domain RUA- forwarding agreements for sub-tenant deliverability transparency). Read the saas-senders spoke when this glossary's multi-tenant-authentication vocabulary needs to resolve to the actual operational- coordination engineering the platform operator deploys against the customer- domain authentication-authority boundary — the spoke is the canonical operational- coordination reference downstream of every multi-tenant / ESP / SaaS / cross- tenant-attribution vocabulary term this glossary catalogues at the security-and- privacy-terminology layer.
SPF explained — pillar page for the Sender Policy Framework.
SPF DNS record syntax — the GLOSSARY-VOCABULARY-MAPS-TO-SPF- DNS-RECORD-FIELDS companion documenting the wire-format reference for the SPF- related DNS-record vocabulary THIS glossary catalogues. Where THIS glossary defines the SPF-record-related security- and-deployment vocabulary terms in single-sentence form (SPF record, v=spf1 version tag, SPF mechanism, include directive, SPF lookup limit (10-DNS-query cap), SPF qualifier, SoftFail, HardFail, Neutral, Pass, SPF permerror, SPF temperror, SPF flattening, single-TXT-record- per-domain constraint, 255-byte string limit, multi-string concatenation), the SPF-DNS-syntax spoke is the AUTHORITATIVE byte-grammar reference for the on-the-wire SPF TXT-record structure whose RFC 7208 §3 / §4 / §5 grammar encodes EVERY vocabulary term THIS glossary catalogues. TWENTY-FIFTH glossary-as-universal-source use per memory feedback_glossary_as_universal_source: the email-security glossary's SPF / deployment-vocabulary entries naturally resolve to the SPF-DNS-syntax spoke as the on-the-wire BYTE-SYNTAX REFERENCE for each vocabulary term. The four-axis GLOSSARY-VOCABULARY-VS-SPF-BYTE-SYNTAX mapping exposes the structurally- distinct vocabulary-to-byte-syntax resolutions: (i) mechanism- vocabulary → §5 byte-syntax mechanism- token grammar — the glossary's include directive / SPF mechanism / a: / mx: / ip4: / ip6: / exists: terms resolve to RFC 7208 §5 mechanism- token byte-grammar the SPF-DNS-syntax spoke documents; (ii) qualifier-vocabulary → §4 byte-syntax qualifier prefix grammar — the glossary's HardFail / SoftFail / Neutral / Pass qualifier terms resolve to the four-byte qualifier-prefix grammar (- / ~ / ? / +) the SPF-DNS-syntax spoke documents at the byte-syntax level; (iii) record-structure- vocabulary → §3 record-grammar constraints — the glossary's single-TXT-record-per-domain constraint / v=spf1 version tag / 255-byte string limit / multi-string concatenation terms resolve to RFC 7208 §3 record- grammar byte-level constraints the SPF-DNS-syntax spoke documents (the §3.1 single-record-per-domain rule, the §3.3 multi-string concatenation algorithm); (iv) failure-mode- vocabulary → §2.6 result-code byte- layer manifestation — the glossary's SPF permerror / SPF temperror / flattening terms resolve to RFC 7208 §2.6 result- code semantics + the byte-syntax patterns (multi-record publication producing permerror, byte-string truncation producing permerror, deep-include cascade producing permerror at the lookup- limit boundary) the SPF-DNS-syntax spoke catalogues as the on-the-wire byte- layer publishing-anti-pattern reference. Read THIS glossary WITH the SPF-DNS- syntax spoke when the security analyst has internalised the SPF-deployment vocabulary and is now PUBLISHING the TXT record whose byte-syntax encodes the operator's SPF policy — the publication-side byte-grammar companion to the deployment-vocabulary entries this glossary catalogues.
SPF qualifiers explained (+ / — the GLOSSARY-VOCABULARY-RESOLVES-TO- FOUR-QUALIFIER-PREFIX-ENFORCEMENT-OUTCOMES companion to this security-and-privacy glossary's SPF-mechanism + enforcement- outcome vocabulary entries. Where THIS glossary defines the SPF-mechanism and enforcement-outcome vocabulary terms in single-sentence form (SPF qualifier, SPF mechanism, pass, fail, softfail, neutral, policy enforcement, RFC 7208 §4.6.2, all-mechanism tail qualifier, hard-fail (-all), soft-fail (~all), neutral (?all), policy-not-set (+all)), the qualifiers-explained spoke is the AUTHORING-DECISION REFERENCE documenting the four single-character qualifier-prefix operators (+ pass, - fail, ~ softfail, ? neutral) that convert every mechanism listed in an SPF record into one of the four authoritative RFC 7208 §2.6 evaluation outcomes a receiving MTA materialises against the envelope-sender IP — the on-the-wire SEMANTIC DIFFERENTIATOR between the operator who thinks they have published a deliverability- protecting SPF record and the operator who has actually published one. TWENTY-NINTH glossary-as-universal-source use per memory feedback_glossary_as_universal_source: the email-security glossary's SPF- mechanism and enforcement-outcome vocabulary entries naturally resolve to the qualifiers-explained spoke as the AUTHORING-DECISION REFERENCE for the per-record-tail qualifier that distinguishes a defensive SPF posture from an advisory one. The four-axis GLOSSARY-VOCABULARY-VS- QUALIFIER-PREFIX-ENFORCEMENT mapping exposes the structurally-distinct vocabulary-to-enforcement resolutions: (i) pass-outcome vocabulary → + qualifier prefix (default-omitted) — the glossary's pass and authorised sender vocabulary defines the affirmative-enforcement outcome the receiver MUST emit when an SPF mechanism matches; the qualifiers spoke documents that the + prefix is the DEFAULT and almost always OMITTED in published records (include: is semantically +include:), which is exactly WHY the +all anti-pattern (universal-pass at the tail) is so catastrophically widespread — operators who type +all believing it is a "permissive default" do not realise they have published a record that explicitly authorises EVERY IP on the internet; (ii) hard-fail outcome vocabulary → - qualifier prefix (-all) — the glossary's hard-fail, SPF fail, and terminal-rejection enforcement vocabulary defines the strict-enforcement outcome the receiver SHOULD treat as a protocol-layer rejection signal; the qualifiers spoke documents that - is the only qualifier-prefix that makes the SPF record DEFENSIVE rather than merely ADVISORY — the per-receiver enforcement consequence (Gmail Postmaster Tools surfaces -all rejection actions, Microsoft EOP treats -all as a quarantine input, Yahoo/AOL applies stricter rate-limits to -all-violating IPs); (iii) soft- fail outcome vocabulary → ~ qualifier prefix (~all) — the glossary's soft-fail and monitoring-mode enforcement vocabulary defines the advisory-only enforcement outcome receivers SHOULD accept but flag in the Authentication-Results header; the qualifiers spoke documents the Workspace-default soft-fail posture (v=spf1 include:_spf.google.com ~all) — the most-deployed soft-fail record on the internet by tenant count, deliberately published as ~all because the multi-tenant provider cannot commit to terminal rejection on behalf of every tenant's third-party-sender authorisation coverage; (iv) neutral outcome vocabulary → ? qualifier prefix (?all) — the glossary's neutral and policy-not-set vocabulary defines the explicitly-non-committal enforcement outcome (semantically identical to publishing no SPF record at all per RFC 7208 §2.6.2); the qualifiers spoke documents the narrow operational-niche use case (temporary record during a multi-step SPF authoring migration where the operator wants the SPF record present in DNS for monitoring purposes but has not yet committed to an enforcement posture). Read the qualifiers-explained spoke when this glossary's enforcement- outcome vocabulary needs to resolve to the on-the-wire single-character prefix the operator actually types into the SPF record's DNS TXT value — the spoke is the canonical authoring-decision reference between a defensive deliverability posture and a misconfigured-by-omission record that authorises arbitrary spoofing.
SPF 10-DNS-lookup limit (RFC 7208 §4.6.4) — the GLOSSARY-VOCABULARY-RESOLVES-TO- OPERATIONAL-DEPLOYMENT-CONSTRAINT-AND- PERMERROR-FAILURE-MODE companion to this security-and-privacy glossary's SPF- deployment-and-failure-mode vocabulary entries. Where THIS glossary defines the SPF-deployment-and-failure-mode vocabulary terms in single-sentence form (SPF lookup limit, 10-DNS-query cap, recursive include resolution, void lookup, 2-void-lookup secondary cap, SPF permerror, SPF temperror, include cascade, SPF flattening, subdomain delegation, sender consolidation), the SPF-lookup-limit spoke is the AUTHORITATIVE OPERATIONAL DEEP-DIVE reference documenting the RFC 7208 §4.6.4 10-DNS-query-budget protocol constraint that the vocabulary terms THIS glossary catalogues resolve to. TWENTY-SEVENTH glossary-as-universal- source use per memory feedback_glossary_as_universal_source: the email-security glossary's SPF / deployment-budget-constraint vocabulary entries naturally resolve to the SPF-lookup-limit spoke as the OPERATIONAL DEEP-DIVE reference for each vocabulary term. The four-axis GLOSSARY-VOCABULARY-VS-SPF-LOOKUP- LIMIT-OPERATIONAL-DEEP-DIVE mapping exposes the structurally-distinct vocabulary-to-deployment-constraint resolutions: (i) lookup- counting-vocabulary → §4.6.4 per- mechanism counting-grammar resolution — the glossary's SPF lookup limit / 10-DNS-query cap / include directive / a: mechanism / mx: mechanism / exists: mechanism / ptr: mechanism (deprecated) / redirect modifier vocabulary entries resolve to the SPF-lookup-limit spoke's PER-MECHANISM LOOKUP-COUNTING section documenting how each mechanism counts against the 10-query budget (include / a / mx each consume ONE lookup AT THE TOP LEVEL plus recursive lookups for included content; ip4 / ip6 / all consume ZERO lookups; ptr counts as ONE plus the cost of the reverse-DNS check pattern); (ii) recursive- include-expansion-vocabulary → cascade- resolution-model resolution — the glossary's recursive include resolution + include cascade + nested include expansion vocabulary entries resolve to the SPF-lookup-limit spoke's RECURSIVE-RESOLUTION section documenting how the receiver's evaluator performs depth-first traversal of the include chain, accumulating lookup-count across every nested layer until either resolution completes or the 10-query cap is breached (typical Workspace+Microsoft-365+SendGrid stack consumes 6–8 lookups, leaving 2–4 lookups of headroom for additional sender platforms); (iii) void-lookup-secondary-cap- vocabulary → §4.6.4 void-lookup-2- strike-rule resolution — the glossary's void lookup + 2-void-lookup secondary cap vocabulary entries resolve to the SPF-lookup-limit spoke's VOID-LOOKUP section documenting the RFC 7208 §4.6.4 secondary cap that fails the SPF check with permerror when the receiver's evaluator encounters more than 2 lookups returning empty (NXDOMAIN / NoData / NODATA) results — a separate failure mode from the 10-lookup primary cap that catches operators with stale include references; (iv) permerror- symptom-and-remediation-vocabulary → diagnostic-and-remediation-path resolution — the glossary's SPF permerror + DMARC-fail cascade + SPF flattening + subdomain delegation + sender consolidation vocabulary entries resolve to the SPF-lookup-limit spoke's SYMPTOMS- AND-REMEDIATION section documenting the four canonical symptoms (SPF permerror in Authentication-Results, DMARC-fail cascade because permerror is NOT SPF pass, receiver-specific NDR variations, RUA aggregate-report evidence rows) and the four remediation paths in operator- recommended order of preference (lookup-audit → subdomain delegation → sender consolidation → monitored SPF flattening with daily regeneration pipeline). Read THIS glossary WITH the SPF-lookup-limit spoke when authoring an SPF- deployment runbook: the glossary defines the vocabulary the runbook uses, the SPF-lookup-limit spoke documents the operational deployment- budget-constraint and remediation- path-decision-framework the runbook operates against.
SPF mechanisms explained (per-directive RFC 7208 §5 reference) — the PER-MECHANISM-RFC-7208-§5- EVALUATION-CONTRACT companion to the SPF-mechanism vocabulary this glossary catalogues. Where this glossary defines the SPF-mechanism vocabulary the publisher / operator / receiver-side analyst uses (mechanism / qualifier / modifier / directive / cascade / recursion / lookup-budget / void-lookup / macro / redirect), the SPF-mechanisms- explained spoke is the PER-DIRECTIVE- EVALUATION-CONTRACT companion documenting the RFC 7208 §5 receiver-side per- mechanism-type evaluation algorithm every vocabulary term ultimately resolves to at the per-message evaluation layer. The GLOSSARY- VOCABULARY-RESOLVES-TO-PER-MECHANISM- EVALUATION-CONTRACT cross-reference establishes FOUR structurally-distinct dimensions where the spoke's per- directive reference is the canonical evaluation-semantics resolution target for the vocabulary THIS glossary catalogues: (i) include: mechanism vocabulary resolves to RFC 7208 §5.2 recursive-cascade-evaluation contract — the spoke documents the include: mechanism's recursive evaluation semantics where the receiver resolves include:<target-domain> as a sub-evaluation of the target domain's SPF tree, with each recursion level consuming 1 lookup against the §4.6.4 budget — every "include cascade" / "include chain" / "platform include token" / "delegated SPF evaluation" vocabulary entry on this glossary ultimately resolves to the per-directive recursive-evaluation contract the spoke documents; (ii) ip4: + ip6: mechanism vocabulary resolves to RFC 7208 §5.6 literal- CIDR-match contract — the spoke documents the ip4:/ip6: mechanism semantics where the receiver matches the message's envelope-source IP against the published CIDR range, consuming 0 DNS lookups against the §4.6.4 budget — every "literal IP block" / "CIDR-range whitelist" / "static egress IP authorization" / "budget-conserving authorization" vocabulary entry on this glossary ultimately resolves to the per- directive literal-CIDR-match contract the spoke documents; (iii) a: + mx: mechanism vocabulary resolves to RFC 7208 §5.3 / §5.4 A- record / MX-record-resolved-IP-set contract — the spoke documents the a: and mx: mechanism semantics where the receiver resolves the mechanism target's A record (a:) or MX-record-host-list (mx:) and matches the resolved IP set against the envelope-source IP, consuming 1 lookup per resolved record — every "A-record authorization" / "MX-host authorization" / "DNS-resolved IP set" / "bidirectional MTA topology" vocabulary entry on this glossary ultimately resolves to the per- directive A-record / MX-record- resolved-IP-set contract the spoke documents; (iv) ptr / exists: / all / redirect= modifier-and- special-mechanism vocabulary resolves to RFC 7208 §5.5 / §5.7 / §5.1 / §6.1 special-evaluation-semantics contracts — the spoke documents the special-evaluation semantics of the deprecated ptr: mechanism (reverse- DNS-PTR-record-resolution authorization with strong RFC 7208 §5.5 discouragement because of cost and DNS-poisoning exposure), the macro-expanded exists:<macro> mechanism (per-message macro expansion producing DNS query for sender-specific existence-check evaluation), the all fall-through mechanism (default-action when no preceding mechanism matched), and the redirect=<domain> modifier (whole-record delegation to target domain's SPF tree) — every "PTR-based authorization" / "macro expansion" / "fall-through all" / "whole-record redirect" / "deprecated-mechanism" vocabulary entry on this glossary ultimately resolves to the per-directive special- evaluation-semantics contract the spoke documents. Read the SPF- mechanisms-explained spoke alongside this security-and-privacy glossary when authoring an SPF-evaluation- semantics reference document — the spoke is the canonical per-directive RFC 7208 §5 evaluation-contract reference whose four per-mechanism- type dimensions are the receiver-side evaluation semantics that every SPF- mechanism-related vocabulary term THIS glossary catalogues ultimately resolves to.
SPF for Google Workspace — the GOOGLE-WORKSPACE-PROVIDER- DEPLOYMENT-RECORD companion to the SPF- deployment vocabulary this glossary catalogues. Where this glossary defines the SPF deployment-and-operational vocabulary terms in single-sentence form (SPF record, SPF mechanism, include directive, SPF lookup limit, SPF flattening, SPF permerror, third-party sender, nested include expansion, cloud mailbox provider, SPF qualifier tail, hard-fail vs soft-fail, policy delegation), the SPF-for- Google-Workspace spoke documents the WORKSPACE-PROVIDER-DEPLOYMENT-MATERIALIZATION of those vocabulary terms in concrete form: (i) the canonical apex SPF record every Workspace tenant publishes — v=spf1 include:_spf.google.com ~all — concretely materialising the SPF record + include directive + soft-fail tail qualifier vocabulary in the standard Workspace form (note the soft-fail ~all tail contrasts with M365's -all hard-fail — both being valid operator choices governed by the SPF-qualifier glossary entries, with Workspace's soft-fail historically preferred for forwarding-friendly receivers); (ii) the recursive include expansion Gmail unfolds at receiver-side resolution — _spf.google.com → _netblocks.google.com + _netblocks2.google.com + _netblocks3.google.com — consuming ~4 DNS lookups and concretely materialising the nested include expansion + SPF lookup limit vocabulary; (iii) the operator-side third-party sender coordination pattern — Workspace's ~4-lookup baseline leaves ~6 lookups of headroom before the 10-lookup ceiling, allowing the addition of multiple third- party senders (SendGrid, Mailchimp, HubSpot, Salesforce SFMC) before the flattening-or-delegation decision becomes unavoidable — concretely materialising the SPF flattening + third-party sender + SPF permerror vocabulary as the per-tenant headroom decision Workspace operators face when extending the apex record, and (iv) the per-tenant sending-method matrix that adds optional include cascades — operators using SMTP-relay, Workspace's outbound gateway, or per-domain delegated egress paths must extend the canonical single-include record with secondary include tokens or ip4: literals — concretely materialising the policy delegation + authority boundary vocabulary as the Workspace-tenant-topology-specific authority-coordination decision. Pair this glossary (the single-sentence vocabulary entries) with the SPF-for- Google-Workspace spoke (the canonical Workspace provider-deployment record + the recursive chain expansion + the third-party-sender coordination decision + the per-tenant sending-method extension surface) for the vocabulary-to-deployment- reality translation operators need when adopting Workspace or auditing an existing Workspace tenant's SPF posture.
SPF for Microsoft 365 — the MICROSOFT-365-PROVIDER-DEPLOYMENT- RECORD companion to the SPF-deployment vocabulary this glossary catalogues. Where this glossary defines the SPF deployment- and-operational vocabulary terms in single-sentence form (SPF record, SPF mechanism, include directive, SPF lookup limit, SPF flattening, SPF permerror, third-party sender, nested include expansion, cloud mailbox provider, SPF qualifier tail, hard-fail vs soft-fail, policy delegation), the SPF-for- Microsoft-365 spoke documents the M365-PROVIDER-DEPLOYMENT-MATERIALIZATION of those vocabulary terms in concrete form: (i) the canonical apex SPF record every M365 tenant publishes — v=spf1 include:spf.protection.outlook.com -all — concretely materialising the SPF record + include directive + hard-fail tail qualifier vocabulary in the standard M365 form (note the hard-fail -all tail contrasts with Workspace's standard ~all soft-fail — both being valid operator choices governed by the SPF-qualifier glossary entries); (ii) the recursive include expansion EOP unfolds at receiver-side resolution — spf.protection.outlook.com → spf-a.outlook.com + spf-b.outlook.com — consuming ~3–5 DNS lookups, concretely materialising the nested include expansion + SPF lookup limit vocabulary; (iii) the operator-side third- party sender coordination pattern — M365's ~3–5 lookups leaves ~5–7 lookups of headroom (substantially more than Workspace's ~6–8-lookup baseline), allowing the addition of multiple third-party senders (Salesforce SFMC, SendGrid, Mailchimp, HubSpot, Marketo) before hitting the 10-lookup ceiling — concretely materialising the SPF flattening + third-party sender + SPF permerror vocabulary as the per-tenant headroom decision M365 operators face when extending the apex record, and (iv) the hybrid Exchange topology dual-egress coordination surface — operators with a hybrid topology (on-prem Edge Transport + Exchange Online) must extend the canonical single-include record to authorise the on-prem path's egress IPs via ip4: literals or a secondary operator-controlled include token, concretely materialising the policy delegation + authority boundary vocabulary as the hybrid-topology-specific authority- coordination decision. Pair this glossary (the single-sentence vocabulary entries) with the SPF-for-Microsoft-365 spoke (the canonical M365 provider-deployment record + the recursive chain expansion + the third-party-sender coordination decision + the hybrid-topology dual-egress coordination surface) for the vocabulary- to-deployment-reality translation operators need when adopting M365 or auditing an existing M365 tenant's SPF posture.
Why SPF alone is insufficient — the GLOSSARY-TERM-RESOLUTION companion documenting WHY the security-and-privacy vocabulary catalogued on this page exists at all. Where THIS glossary defines individual security-and-privacy terms-of-art each in single-sentence form (the display-name spoofing entry, the Reply-To substitution entry, the lookalike domain entry, the cousin domain entry, the Punycode/IDN homograph entry, the From: header spoofing entry, the display-name disposition entry, the email-thread hijacking entry, the business-email-compromise entry), the why-SPF-alone-is-insufficient spoke documents the FIVE SPF-only-deployment gaps that produced the need for the security-vocabulary on this page: (i) the From:-header spoofing gap (SPF authenticates envelope MAIL FROM, not the visible From: header — the GROUND of every From:-header-spoofing, display-name- spoofing, lookalike-domain, cousin-domain and Punycode-homograph term in this glossary), (ii) the forwarding gap (SPF breaks on the second SMTP hop — the GROUND of every mailing-list-spoofing and forwarding-loop term), (iii) the mailing- list gap (mailing-list expansion rewrites both envelope AND From: — the GROUND of the list-server abuse and discussion-list spoofing terms), (iv) the third-party- sender gap (CRM/marketing platforms send From: customer-domain.com via vendor infrastructure — the GROUND of the third-party-vendor compromise and partner- tenant compromise terms), (v) the DKIM- replay-from-cooperating-spammer gap (the GROUND of the cooperating-spammer and cooperating-vendor terms). Read the why-SPF-alone-is-insufficient spoke when a glossary entry leaves an "and WHY is this attack class possible at all" question unanswered — the spoke is the authoritative reference for the FIVE SPF-only-deployment gaps that motivate every From:-header-targeting attack class this glossary catalogues, sixteenth glossary-as-universal-source application per the cluster's universal-source pattern.
Reverse DNS / PTR / FCrDNS — the GLOSSARY-VOCABULARY-RESOLVES-TO- IP-LAYER-SENDER-LEGITIMACY-DNS-RECORD companion to this security-and-privacy glossary. Where THIS glossary catalogues every From:-header spoofing, display-name spoofing, lookalike domain, cousin domain, IDN/Punycode homograph, Reply-To substitution, account-compromise BEC, and third-party-vendor compromise attack-class vocabulary term at the From:-header / envelope- domain / DKIM-signing-domain layer, the reverse-DNS / PTR / FCrDNS spoke documents the IP-ROUTING-LAYER sender- legitimacy DNS-record signal that UNDERLIES the entire authentication stack: (i) PTR records — the <reverse-octets>.in-addr.arpa (IPv4) / <reverse-nibbles>. ip6.arpa (IPv6) DNS-zone authority delegations operators publish to declare a HUMAN-READABLE hostname for the sending IP, (ii) FCrDNS (Forward-Confirmed Reverse DNS) — the two-step round-trip verification receivers perform (PTR lookup of sending IP returns mailout-1.example.com → forward A/AAAA lookup of mailout-1.example.com must resolve BACK to the original sending IP) that distinguishes legitimate hosted-MTA IPs from rogue / botnet / consumer-ISP- residential-NAT IPs at the IP layer BEFORE the receiver examines SMTP envelope or message headers, (iii) FCrDNS-pass as a sender- legitimacy precondition at Gmail / Outlook / Yahoo / iCloud — the receiver-side check that gates the Sender-Score / Domain-Reputation / Postmaster-Tools observability surface (the spoofing / lookalike-domain phishing / account-compromise BEC attack-classes this glossary catalogues almost always launch from FCrDNS-FAILING residential-NAT / dynamic-DSL / consumer-VPN IPs because legitimate mailbox-provider egress IPs uniformly publish FCrDNS-passing PTR records), (iv) the PTR record's intersection with the deprecated SPF ptr mechanism (RFC 7208 §5.5 explicitly deprecates the SPF ptr mechanism but the underlying PTR record itself remains a load-bearing receiver-side legitimacy signal — the deprecation applied to the SPF EVALUATION of PTR records, not to the records themselves; an operator who publishes broken PTR records still loses deliverability at every major receiver). Read the reverse-DNS / PTR / FCrDNS spoke when a glossary entry's attack- class catalogue surfaces an IP-layer precondition for the attack (the attacker's botnet IP CANNOT pass FCrDNS and therefore cannot reach inbox at any major receiver without burning a legitimate FCrDNS-passing relay first — an IP-layer reason WHY From:-header spoofing attacks need the third-party- sender-abuse and compromised-legitimate- sender bypass classes documented in the attacker bypass spoke). The PTR / FCrDNS spoke is the IP-LAYER SENDER-LEGITIMACY-DNS-RECORD reference beneath every From:-header / envelope- domain / DKIM-signing-domain attack- class this glossary catalogues at the message-content layer.
MX records explained — the GLOSSARY-VOCABULARY-RESOLVES-TO- DNS-LAYER-MESSAGE-ROUTING-AND-RUA-MAILBOX- INGESTION-FOUNDATION-RR companion to this security-and-privacy glossary. Where THIS glossary catalogues every RUA mailbox, aggregate-report ingestion, monitoring mailbox, SMTP routing, MX preference ordering, dangling MX, MX takeover, FCrDNS-paired forward record, third-party RUA-provider MX, per-tenant inbound MX, backup MX, null MX, MX-vs-A-record fallback term in single-sentence form, the mx-records spoke documents the on-the-wire RFC 1035 §3.3.9 TYPE 15 MX-RR byte-syntax (16-bit PREFERENCE field + variable-length EXCHANGE domain-name field), the receiver-side MX- preference-ordering algorithm (lowest PREFERENCE first, equal-preference round- robin, fallback to higher PREFERENCE on connection failure), and the per-MX-RR availability discipline operators MUST sustain to keep both inbound legitimate-mail AND inbound DMARC aggregate-report streams flowing. Four MX-RR-VOCABULARY-RESOLUTION axes the mx-records spoke documents: (i) MX RR as the AGGREGATE-REPORT-INGESTION-PREREQUISITE VOCABULARY resolution — the glossary's RUA mailbox, aggregate-report ingestion, monitoring mailbox, third- party RUA provider, per-customer RUA delegation VOCABULARY entries resolve to the canonical apex MX RR the operator publishes on the rua=mailto:dmarc-rua@example.com domain — without this MX RR pointing to a host that accepts SMTP at port 25 AND delivers to the dmarc-rua@ mailbox, the receiver-emitted aggregate- report stream never reaches the operator and the entire DMARC deployment ramp lacks the per-source-IP empirical evidence stream it structurally depends on; (ii) MX RR as the DANGLING-MX-AS-ATTACK-VECTOR VOCABULARY resolution — the glossary's MX takeover, dangling MX, registrar misconfiguration, authoritative-DNS takeover, orphaned MX target, MX-pointing-to-deleted-host VOCABULARY entries resolve to the canonical attack class the mx-records spoke documents (an attacker registers the unowned domain to which a stale MX RR points, accepts SMTP on port 25 at the takeover host, and reads or rewrites every inbound message destined for the publisher's domain) — the operator-side defense is the per-MX-RR validation discipline the mx-records spoke documents (verify every MX-EXCHANGE host's A/AAAA record is owned by the publisher, retire orphaned MX RRs within the per- DNS-TTL window, monitor for unauthorised MX changes); (iii) MX RR as the FCrDNS-PAIRED-FORWARD-RECORD-AT-SENDING- BOUNDARY VOCABULARY resolution — the glossary's FCrDNS, Forward-Confirmed Reverse DNS, PTR-RR-and-A-RR-pair, sender-IP-legitimacy verification VOCABULARY entries resolve to the OUTBOUND-MTA forward-name lookup the receiver-side FCrDNS check evaluates against the PTR-RR-pointed forward name — the mx-records spoke documents the outbound-MTA-host-naming discipline (publish forward A/AAAA RR matching the PTR-RR target, align outbound HELO/EHLO announcement to the same forward name) operators MUST sustain alongside the MX publication discipline to pass receiver- side FCrDNS verification at the inbound boundary; (iv) MX RR as the PER-TENANT-INBOUND-MAILBOX-PROVIDER- DELEGATION VOCABULARY resolution — the glossary's per-tenant inbound MX, cloud-mailbox-provider MX delegation, Microsoft 365 Exchange-Online MX, Google Workspace MX, shared-hosting cPanel MX, SaaS-RUA-provider delegated MX, per-customer- domain MX-CNAME-substitution VOCABULARY entries resolve to the provider-specific MX-RR shapes the mx-records spoke catalogues (example-com.mail.protection.outlook.com for M365, ASPMX.L.GOOGLE.COM et al. for Workspace, per-cPanel-tenant MX shape for shared-hosting, provider- delegated MX-CNAME for third-party RUA provider) every multi-tenant deployment publishes to enrol the inbound mail-and- feedback-loop stream onto the provider's receiver infrastructure. Pair this glossary (the DNS-layer-routing vocabulary terms) with the mx-records spoke (the apex MX-RR byte-syntax + per- provider deployment + per-MX-RR availability discipline reference) for the complete vocabulary-to-DNS-layer- message-routing-and-aggregate-report- ingestion translation every defender and every DMARC-deployment operator needs to keep the inbound-mail-AND- feedback-loop-ingestion streams flowing through the per-DNS-TTL message-routing layer beneath the From:-header application-layer attack-class vocabulary this glossary catalogues.
DNS propagation explained — the GLOSSARY-VOCABULARY-RESOLVES-TO- RECURSIVE-RESOLVER-CACHE-AGEING-MODEL companion documenting the receiver-side DNS propagation timing every email- security record this glossary catalogues is subject to. Where this glossary catalogues SPF record, DKIM selector, DMARC policy record, BIMI record, MTA-STS policy DNS record, TLS-RPT record, DANE TLSA, CAA, MX record, reverse DNS PTR, TTL, and authoritative nameserver each as single-sentence vocabulary terms, the dns-propagation spoke is the AUTHORITATIVE receiver-side observability-timing reference documenting the RFC 1035 §4.1.3 per-resource-record TTL field semantics, the RFC 2181 ranking-of-data- by-source rules every recursive resolver consults when reconciling conflicting cached responses, the RFC 2308 negative- caching SOA-min-TTL window every recursive resolver applies to NXDOMAIN / NODATA responses (the most-frequently-overlooked propagation surface every operator publishing a NEW email-security record encounters), and the RFC 8767 serve-stale extension that allows recursive resolvers to continue serving stale data for hours under upstream-failure conditions — producing the empirical "DNS propagation takes 24-72 hours" floor every email- security record this glossary catalogues must respect. THIRTY-SECOND glossary-as-universal-source use per memory feedback_glossary_as_universal_source: the email-security glossary's per-record DNS vocabulary entries naturally resolve to the dns-propagation spoke as the RECURSIVE-RESOLVER-CACHE- AGEING-MODEL reference whose per-RFC propagation discipline every glossary vocabulary term collectively depends on at the DNS-publication-to-observation boundary. Four operationally-distinct propagation-axis-vs-glossary-vocabulary resolutions the spoke catalogues that this glossary's vocabulary entries individually catalogue but never collectively interconnect: (i) positive-cache TTL ageing — the glossary's TTL vocabulary defines the per-RR cache-lifetime field, the dns-propagation spoke documents how recursive resolvers reconcile per-RR TTL across the SPF / DKIM / DMARC / BIMI / MTA-STS / TLS-RPT / DANE / CAA / MX record-set the glossary catalogues; (ii) negative-cache NXDOMAIN / NODATA windows — the glossary defines publishing a DNS record but the propagation spoke documents the RFC 2308 SOA-min-TTL negative-cache window that makes the first hours after publication a STRUCTURAL silent-failure period; (iii) RFC 8767 serve-stale re-emergence — the glossary's per-record vocabulary does not surface the serve-stale risk surface; the propagation spoke documents the resolver-side serve-stale mechanic that makes post-TTL stale responses possible; (iv) per-receiver Authentication- Results temperror attribution — the glossary's temperror vocabulary term catalogues the per-message verdict- keyword, the propagation spoke documents the DNS-fetch-failure root-cause class that produces the verdict.
DKIM explained — pillar page for DomainKeys Identified Mail.
DKIM cryptography basics — the GLOSSARY-VOCABULARY-RESOLVES-TO- DKIM-CRYPTOGRAPHIC-PRIMITIVES companion documenting the RFC 6376 / RFC 8463 asymmetric- signature byte-anatomy whose RSA-2048, Ed25519, and SHA-256 cryptographic primitives every signature-cryptography vocabulary term THIS security-and-privacy glossary catalogues ultimately resolves to at the mathematical signing-algorithm layer the signer computes and the receiver verifies. Where THIS glossary defines the cryptographic-primitive VOCABULARY in single-sentence form (asymmetric cryptography, signing key, public key, private key, RSA-2048, Ed25519 elliptic-curve signature, SHA-256 cryptographic hash, body hash, headers hash, signature verification, key publication via DNS, post-quantum cryptography, cryptographic-algorithm migration), the DKIM-cryptography-basics spoke is the BYTE-ANATOMY REFERENCE documenting the MATHEMATICAL CONSTRUCTION the signer applies and the verifier reverses per RFC 6376 §3.5 + RFC 8463. THIRTY-FIRST glossary-as- universal-source use per memory feedback_glossary_as_universal_source: the email-security glossary's cryptographic- primitive vocabulary entries naturally resolve to the DKIM-cryptography-basics spoke as the MATHEMATICAL-CONSTRUCTION REFERENCE for each abstract vocabulary term. The four-axis GLOSSARY-VOCABULARY-VS-DKIM- CRYPTOGRAPHIC-BYTE-ANATOMY mapping exposes the structurally-distinct vocabulary-to- cryptographic-primitive resolutions: (i) RSA-asymmetric-cryptography vocabulary → RSA-2048 modulus + public-exponent byte-anatomy — the glossary's RSA, signing key, public-key publication, private-key custody, and SubjectPublicKeyInfo vocabulary defines the abstract asymmetric-cryptography terms-of-art, the cryptography-basics spoke documents the actual RSA-2048 2048-bit modulus + 65537 public-exponent byte construction the DER/PEM-encoded SubjectPublicKeyInfo blob (the p=-tag-payload the receiver fetches from DNS) emits at the wire-format layer including the RFC 6376 strong-key- size guidance (≥2048-bit modulus mandatory for production, 1024-bit deprecated as cryptographically obsolete since 2017 NIST SP 800-131A); (ii) Ed25519- elliptic-curve-cryptography vocabulary → RFC 8463 Edwards-curve EdDSA signature-algorithm byte-anatomy — the glossary's Ed25519, elliptic-curve cryptography, and post-quantum-cryptography migration path vocabulary defines the abstract elliptic-curve-signature terms-of-art, the cryptography-basics spoke documents the actual RFC 8463 Ed25519 32-byte public- key byte structure + EdDSA signing- algorithm + Curve25519 elliptic-curve parameter set the modern receiver verifies when k=ed25519 is published in the TXT record (8.5× faster signing, 2.3× faster verification, 32-byte-vs-2048-byte- modulus key-size advantage relevant for DNS TXT-record byte-budget headroom at the published-zone-size constraint); (iii) SHA-256-hash-construction vocabulary → FIPS 180-4 §6.2 hash- algorithm byte-construction — the glossary's cryptographic hash, SHA-256, SHA-1 deprecated, body hash, and headers hash vocabulary defines the abstract hash-function terms-of-art, the cryptography-basics spoke documents the actual FIPS 180-4 §6.2 SHA-256 256-bit- output hash construction the DKIM signer applies to (a) the canonicalised body to produce the bh=-tag body-hash the verifier independently recomputes and compares, and (b) the canonicalised header- set + body-hash to produce the b=-tag signature-input the verifier reverses through the public-key cryptographic operation, plus the SHA-1 deprecation rationale (RFC 8301 OBSOLETED h=sha1 in 2018 after the 2017 SHAttered collision attack) the modern signer respects; (iv) asymmetric- vs-symmetric cryptographic-primitive- choice vocabulary → structural non-shared-secret + DNS-publication-as- canonical-channel justification — the glossary's asymmetric cryptography, shared-secret cryptography (HMAC), key publication, and signature verification vocabulary defines the abstract symmetric-vs-asymmetric design- choice terms-of-art, the cryptography- basics spoke documents the STRUCTURAL REASON DKIM is asymmetric-signature-based rather than HMAC-symmetric-secret-based (DKIM signers and receivers don't share secrets — receivers are unknown third-parties; DNS is the canonical public-key publication channel the signer controls; the verifier's verification step is publishable and auditable without secret custody) and the canonical implications downstream (key-rotation cadence is publishable, signing-domain is cryptographically bound to the signature via the d= tag, and the signature is independently verifiable by any receiver without prior coordination with the signer). Read THIS glossary WITH the cryptography-basics spoke when the operator's vocabulary-layer understanding of DKIM signing primitives needs to resolve to the MATHEMATICAL BYTE-ANATOMY of the signature-algorithm and hash-construction the signer computes and the verifier reverses — the spoke is the canonical reference for the RSA-2048- vs-Ed25519 algorithm-choice, the SHA-256- vs-SHA-1 hash-deprecation timeline, and the asymmetric-vs-symmetric structural design-choice justification every cryptographic-primitive vocabulary term this glossary catalogues at the security- and-privacy-terminology layer ultimately resolves to.
DKIM DNS record syntax — the GLOSSARY-VOCABULARY-MAPS-TO-DKIM- DNS-RECORD-FIELDS companion documenting the wire-format reference for the DKIM- related DNS-record vocabulary THIS glossary catalogues. Where THIS glossary defines the DKIM-record-related security- and-privacy VOCABULARY in single-sentence form (selector, public-key publication, hash-algorithm constraint, service-type flag, testing-mode flag, key-type designation, key revocation, granularity constraint, notes field), the DKIM DNS- record-syntax spoke is the BYTE-SYNTAX REFERENCE documenting how each of those vocabulary terms RESOLVES to a specific tag field in the published selector._domainkey.<domain> TXT record the receiver fetches during DKIM verification. The GLOSSARY- VOCABULARY-MAPS-TO-DKIM-DNS-RECORD- FIELDS cross-reference covers FIVE specific vocabulary-to-tag-field mappings: (i) "selector" vocabulary → the FIRST label of the selector._domainkey.<domain> DNS name — the SAME vocabulary term THIS glossary catalogues that the byte-syntax spoke documents as the SELECTOR component of the published record name; (ii) "public-key publication" vocabulary → p= tag value in the TXT record — the SAME vocabulary term THIS glossary defines as the BASE64-encoded SubjectPublicKeyInfo blob that the byte-syntax spoke documents at the wire-format layer including the 255-octet TXT-chunking constraint; (iii) "key-type designation" vocabulary → k= tag value (k=rsa default per RFC 6376 OR k=ed25519 per RFC 8463) — the SAME vocabulary term THIS glossary defines that the byte-syntax spoke documents as the algorithm-identifier tag the receiver enforces during verification; (iv) "hash- algorithm constraint" vocabulary → h= tag value (in the DNS record, NOT the signature header) — the SAME vocabulary term THIS glossary defines that the byte-syntax spoke documents as the published hash- algorithm constraint set (h=sha256 default, h=sha1 deprecated); (v) "service-type flag" vocabulary → s= tag value (s=email scopes the key to email; s=* permits all service types) — the SAME vocabulary term THIS glossary defines that the byte-syntax spoke documents as the service-scope tag the receiver enforces during verification, alongside the t=y testing-mode and t=s strict-d=-match flag-tag combinations. TWENTY-THIRD glossary-as-universal-source use per memory feedback_glossary_as_universal_source: the email-security glossary's DKIM- record-related DNS-tag vocabulary naturally resolves to the DKIM DNS- record-syntax spoke as the byte-format wire-level reference. Read THIS glossary WITH the DKIM DNS-record- syntax spoke when the operator has internalised the DKIM-record vocabulary and is now AUTHORING or VERIFYING the published TXT record byte-by-byte.
DKIM best practices — the GLOSSARY-VOCABULARY-RESOLVES-TO-DKIM- BEST-PRACTICES-RULESET companion documenting the 15-rule operator-discipline synthesis whose ruleset every DKIM-related vocabulary term THIS glossary catalogues resolves to. Where THIS glossary defines the DKIM-related security-and-privacy VOCABULARY in single- sentence form (DKIM replay attack, DKIM key strength, selector rotation, signing key compromise, third-party DKIM signing, canonicalisation downgrade, l= length-tag abuse, cryptographic agility, DKIM2 / ed25519 algorithm), the DKIM best-practices spoke is the SYNTHESIS LAYER documenting the 15-rule actionable operator-discipline reference each vocabulary term RESOLVES to in operator practice. The GLOSSARY-VOCABULARY-RESOLVES- TO-DKIM-BEST-PRACTICES-RULESET cross- reference covers FIVE specific vocabulary-to-best-practices-rule mappings: (i) "DKIM replay attack" vocabulary → "rotate selectors quarterly + constrain l= tag usage" best-practices rules — the SAME threat THIS glossary catalogues that the best-practices ruleset closes via the rotation + length- constraint discipline; (ii) "DKIM key strength" vocabulary → "use 2048-bit RSA keys at minimum, prefer ed25519 where receiver-side support permits" best-practices rule — the SAME cryptographic-strength vocabulary THIS glossary defines that the best-practices ruleset enforces as the minimum key length; (iii) "selector rotation" vocabulary → "rotate selectors quarterly with 30-day publish-overlap + retire-overlap windows" best-practices rule — the SAME rotation vocabulary THIS glossary defines that the best- practices ruleset codifies as the cadence + overlap windows the rotation procedure must respect; (iv) "third- party DKIM signing" vocabulary → "use CNAME delegation under _domainkey.<domain> so partner-MTA-managed keys live in your zone for revocation control" best-practices rule — the SAME delegation vocabulary THIS glossary catalogues that the best-practices ruleset codifies as the canonical CNAME-delegation deployment pattern; (v) "canonicalisation downgrade" vocabulary → "use relaxed/relaxed canonicalisation default to maximise forward-survivability" best- practices rule — the SAME canonicalisation vocabulary THIS glossary defines that the best-practices ruleset codifies as the relaxed/relaxed default choice the operator should make. TWENTY- SECOND glossary-as-universal-source use per memory feedback_glossary_as_universal_source: the email-security glossary's DKIM-related threat-and-defence vocabulary naturally resolves to the DKIM best-practices synthesis layer as the 15-rule actionable operator-discipline ruleset. Read THIS glossary WITH the DKIM best-practices spoke when the operator has internalised the DKIM-related vocabulary and is now AUTHORING the DKIM-deployment operator-discipline ruleset the vocabulary resolves to.
DKIM alignment with DMARC — the GLOSSARY-VOCABULARY-RESOLVES-TO- DKIM-DMARC-ALIGNMENT-CONTRACT companion documenting the RFC 7489 §3.1 DKIM-side alignment-evaluation contract — the per-message d= signing-domain vs Header-From-domain match-evaluation step that the alignment-related VOCABULARY entries in THIS glossary (alignment, DKIM-alignment, identifier alignment, strict alignment, relaxed alignment, Organizational Domain, Public Suffix List, PSL, eTLD+1, d= tag, i= tag, adkim= tag, From: header, Header-From, Authentication-Results, dkim=pass-but- unaligned, dkim=aligned-pass) all ultimately resolve to at the per-message verifier-side alignment-evaluation layer. Where THIS glossary defines the alignment-mode VOCABULARY in single- sentence form, the DKIM-alignment-with- DMARC spoke documents the per-mode evaluation contract: strict-alignment (adkim=s) requires byte-identical d=<domain> vs Header-From-domain; relaxed-alignment (adkim=r, the default) requires Organizational-Domain match per the PSL-anchored eTLD+1 algorithm (sub.example.com d= aligns with example.com Header-From under relaxed but not strict); per-mode dkim= verdict emission in Authentication-Results; per- mode DMARC RUA-aggregate-report dkim_aligned column attribution; per-mode publisher-side operator-decision matrix (when to publish adkim=s vs adkim=r given the org's subdomain-vs-apex signing topology + ESP-cohabitation pattern + cousin-domain look-alike defense posture). Without the DKIM-alignment-with- DMARC spoke a reader fluent in THIS glossary's alignment vocabulary has no canonical reference for the per-mode byte-shape evaluation contract their org's DMARC RUA-aggregate-report's dkim_aligned column materialises against — this link closes that vocabulary-to- contract resolution gap at the DKIM-side identifier-alignment-evaluation layer.
DKIM failure verdicts explained — the TERMINOLOGY-DECODE companion to this security-and-privacy glossary's verdict-vocabulary entries. Where THIS glossary catalogues the security-and- privacy term-of-art definitions, the DKIM-failure-verdicts spoke is the per-verdict-keyword catalogue documenting what each of the seven RFC 6376 §3.9 + RFC 8601 §2.7.1 verdict KEYWORDS this glossary may reference (dkim=none, dkim=neutral, dkim=pass, dkim=fail, dkim=policy, dkim=temperror, dkim=permerror) MEANS at the protocol layer plus the diagnostic action each verdict class calls for. Critical vocabulary cross-reference when this glossary's security-incident-response vocabulary (DKIM-related incident-class terms, body-hash-mismatch, selector-NXDOMAIN, weak-key-rejection, key-rotation-overlap, wallclock-skew, signature-syntax-permerror) needs to map onto the canonical RFC 8601 verdict keyword the auth_results/dkim/result Authentication-Results field surfaces. Read the verdict-decode spoke when an incident playbook on this page references a DKIM-related security term-of-art that an aggregate-report XML row in the operator's incident-response workflow manifests as one of the seven verdict keywords — the spoke documents the full keyword-to-remediation translation every defender needs when triaging a DKIM-related security or privacy incident routed via the Authentication-Results / aggregate- report XML data path.
DKIM troubleshooting (symptom-driven debugging) — the GLOSSARY-VOCABULARY-RESOLVES- TO-DKIM-SYMPTOM-DRIVEN-DEBUGGING- PLAYBOOK companion to this security- and-privacy glossary's DKIM-related vocabulary entries. Where THIS page catalogues the DKIM-related vocabulary terms-of-art the operator encounters when triaging DKIM-related security incidents (selector naming, body-hash construction, signed-headers list, l= tag body-length-truncation semantics, t=y testing-flag burn-in semantics, x= expiration tag for RFC 9103 replay-mitigation, c=simple-vs- c=relaxed canonicalization semantics, RSA-vs-Ed25519 algorithm identifiers, key-length-floor guidance, key-rotation-cadence operational primitives), the DKIM-troubleshooting spoke documents the OPERATOR-FACING SYMPTOM-DRIVEN DEBUGGING PLAYBOOK whose per-symptom decision-tree branches resolve each encountered DKIM-failure-class to the underlying cryptographic- verification-failure cause via explicit lookup of the vocabulary terms this glossary catalogues. FOUR structurally-distinct DKIM-TROUBLESHOOTING-VOCABULARY- RESOLUTION dimensions emerge from cross-mapping the glossary against the playbook: (1) Body-hash-mismatch-symptom-vocabulary- resolution at the per-message c=simple-vs-c=relaxed canonicalization + signed-headers-list + l=-tag- truncation joint-vocabulary boundary — the troubleshooting-spoke documents the canonical body-hash- mismatch triage flow where the operator differentiates between canonicalization-mismatch (publisher signed c=simple but forwarder normalised whitespace), signed- headers-list violation (publisher signed h=From:To:Subject:Date but forwarder added a Reply-To-header that shifted positional order), and l=-tag-truncation exploitation (publisher signed l=1024 but forwarder appended unsigned trailing bytes the attacker substituted). THIS glossary's vocabulary entries for canonicalization, signed-headers list, and l= tag are the lookup- reference the troubleshooting playbook consults at each decision point. (2) Selector-related- symptom-vocabulary-resolution at the per-message selector + d= + DKIM-record-state joint-vocabulary boundary — the troubleshooting- spoke documents the selector-related triage flow where the operator differentiates between selector- revocation (publisher published empty p= to retire a compromised key), selector-rotation-mid-flight (message-in-transit during the publisher's dual-selector overlap window), and selector-impersonation (attacker-controlled cousin-domain publishing a near-lookalike-named selector). THIS glossary's vocabulary entries for selector, d= signing- domain, p= key-publication tag, and selector-revocation discipline are the lookup-reference the troubleshooting playbook consults. (3) Replay-symptom-vocabulary- resolution at the per-message Date-header + x= expiration-tag + per-source_ip cohort joint- vocabulary boundary — the troubleshooting-spoke documents the replay-symptom triage flow where the operator differentiates between LEGITIMATE-message-sent- legitimately-late (publisher's own delayed-egress) vs DKIM-REPLAY- attacker-rebroadcasted-with-stale- Date-header (per RFC 9103 the x= expiration tag bounds the cryptographic-validity window). THIS glossary's vocabulary entries for replay, body-hash, x= expiration tag, and per-source_ip cohort attribution are the lookup- reference the troubleshooting playbook consults at each decision point. (4) Key-rotation- related-symptom-vocabulary- resolution at the per-domain annual-rotation-cadence + dual- selector-overlap-window + post- rotation-validation joint- vocabulary boundary — the troubleshooting-spoke documents the key-rotation-event triage flow where the operator differentiates between INTENTIONAL- rotation-overlap (publisher's annual-cadence rotation event where both old and new selectors are temporarily published) vs ROTATION-INDUCED breakage (old selector retired too early before all in-flight messages delivered) vs POST-COMPROMISE- EMERGENCY-rotation (publisher responding to confirmed key- leak by aggressive rotation + post-rotation aggregate-report validation). THIS glossary's vocabulary entries for key- rotation cadence, dual-selector overlap window, and post- rotation validation discipline are the lookup-reference the troubleshooting playbook consults at each decision point. 33rd glossary-as-universal-source use (per memory [[feedback-glossary-as-universal-source]] — confirmed natural source for every per-term / per-token / decision-view target). Read the troubleshooting-spoke alongside THIS glossary when the operator encounters a DKIM-related symptom whose root-cause requires vocabulary lookup: this glossary tells you WHAT THE TERM MEANS, the troubleshooting-spoke tells you HOW THE TERM-MEANING RESOLVES the symptom-signature AND WHY each vocabulary term is a load-bearing lookup-reference at a per-decision-point branch of the playbook.
DKIM-Signature header explained — the GLOSSARY-VOCABULARY-RESOLVES-TO- DKIM-SIGNATURE-HEADER-BYTE-ANATOMY- CANONICAL-REFERENCE companion to this security-and-privacy glossary's DKIM- related vocabulary entries. Where THIS glossary defines the DKIM-related security-and-deployment vocabulary terms in single-sentence form (DKIM signature, signed- header set, body hash, signed-domain identifier (d=), selector (s=), signing algorithm (a=), rsa-sha256, ed25519-sha256, canonicalization (c=), Agent / User Identifier (i= / AUID), query method (q=), body-length limit (l=) replay attack, signature timestamp (t=), signature expiration (x=), diagnostic copied headers (z=), signature version (v=), two-hash design, signed-header set reconstruction), the signatures- explained spoke is the AUTHORITATIVE byte-grammar reference for the on-the- wire DKIM-Signature HEADER structure whose RFC 6376 §3.5 tag-by-tag grammar encodes EVERY vocabulary term THIS glossary catalogues. TWENTY-SIXTH glossary-as-universal-source use per memory feedback_glossary_as_universal_source: the email-security glossary's DKIM / signature-cryptography vocabulary entries naturally resolve to the DKIM-Signature-explained spoke as the on-the-wire BYTE-SYNTAX REFERENCE for each vocabulary term. The four-axis GLOSSARY-VOCABULARY-VS-DKIM-SIGNATURE- HEADER-BYTE-SYNTAX mapping exposes the structurally-distinct vocabulary-to- byte-grammar resolutions: (i) tag-vocabulary → §3.5 tag- grammar token-list resolution — the glossary's DKIM signature / signing-domain (d=) / selector (s=) / body hash (bh=) / signature (b=) / signed-header list (h=) / AUID (i=) / query method (q=) term-of-art entries resolve to RFC 6376 §3.5 tag- grammar the signatures-explained spoke documents byte-by-byte (the spoke is the structural one-stop catalogue of every tag, its required-vs-optional status, default value if omitted, wire-format encoding, and operator- side discipline); (ii) algorithm-vocabulary → a= tag value- grammar resolution — the glossary's rsa-sha256 / ed25519-sha256 / rsa-sha1 (deprecated per RFC 8301 §3.2) algorithm-name terms resolve to the byte-exact a= tag value strings the signatures- explained spoke documents (with operator-side discipline preferring rsa-sha256 as the RFC 8301 modern default and ed25519-sha256 per RFC 8463 as the post-quantum-curious alternative); (iii) two-hash- design vocabulary → bh= + b= tag independence resolution — the glossary's body hash (bh=) + signed-header set signature (b=) + signed-header set reconstruction algorithm + self-referential signature header handling (b= temporarily empty) terms resolve to the signatures-explained spoke's TWO-HASH- DESIGN section documenting the independent body-hash check (bh= recomputation over canonicalised body) followed by the signed-header- set signature verification (b= verification over canonicalised signed-header set including the DKIM-Signature header itself with b= temporarily empty) — the cryptographic decomposition every verifier implementation follows and every forensic-report incident-response playbook depends on for accurate per-failure root-cause attribution; (iv) replay-attack vocabulary → l= body-length-limit tag-omission resolution — the glossary's l= body-length limit replay attack + l= tag (avoid) + signature-truncation replay vector terms resolve to the signatures-explained spoke's l= TAG section documenting the RFC 6376 §3.5 cautionary text that warns operators against publishing the l= tag because it allows attackers to APPEND content to a legitimately-signed message without invalidating the b= signature (since the signature only covers the first l= bytes) — a structural cryptographic vulnerability the spoke documents alongside the operator-side discipline of omitting l= entirely so the b= signature covers the full body and the replay attack is structurally impossible. Read THIS glossary WITH the signatures-explained spoke when authoring a DKIM-incident-response runbook: the glossary defines the vocabulary the runbook uses, the signatures-explained spoke documents the byte-anatomy reference the runbook decodes the cited DKIM-Signature header against during per-message-failure triage.
DKIM replay attacks — the GLOSSARY-VOCABULARY-RESOLVES-TO- SIGNATURE-REUSE-AFTER-AUTHENTICATION companion to this security-and-privacy glossary's DKIM-related vocabulary entries. Where THIS glossary catalogues the DKIM-related security-incident-response vocabulary terms in single-sentence form (DKIM signature, body-length limit (l=) replay attack, signature expiration (x=), signature timestamp (t=), selector compromise, nonce / replay attack, two-hash design, signed-header set, signing algorithm rotation, per-message velocity baseline), the replay-attacks spoke is the AUTHORITATIVE attack-class catalogue documenting the operational mechanics of the signature-reuse abuse pattern that EVERY one of those vocabulary terms ultimately defends against. TWENTY-SEVENTH glossary-as-universal-source use per memory feedback_glossary_as_universal_source: the email-security glossary's DKIM / signature-cryptography / attack-class / per-message-velocity-monitoring vocabulary entries naturally resolve to the DKIM-replay-attacks spoke as the ATTACK-MECHANICS REFERENCE for the residual-signature-reuse abuse class that survives every successful per-message DKIM verification. The four-axis GLOSSARY-VOCABULARY-VS-REPLAY-ATTACK- MECHANICS mapping exposes the structurally-distinct vocabulary-to- attack-mechanics resolutions: (i) signature-reuse vocabulary → post-verification residual-attack-surface mechanic — the glossary's DKIM signature + signed-header set + signed-domain identifier (d=) vocabulary defines the on-the-wire cryptographic artefact, but the replay-attack mechanic shows how the SAME signed artefact captured from a legitimate first delivery can be re-replayed against thousands of receivers (each emitting dkim=pass independently) because the protocol-layer signature contract does NOT bind the signature to the recipient channel, the receiving MTA, the wallclock window beyond x=, or the per-message delivery instance; (ii) body-length-limit (l=) vocabulary → trailing-content-injection replay-amplification mechanic — the glossary's body-length limit (l=) replay attack entry catalogues the term-of-art, the replay-attacks spoke documents the operational mechanic whereby an attacker appends arbitrary unsigned trailing content (new recipient list, new phishing payload, new attachment) AFTER the l=-bounded signed prefix and still earns a dkim=pass verdict because the body-hash bh= covers only the signed prefix per RFC 6376 §5.2 — the single most cited reason DKIM best practices (per the dkim_best_practices spoke this glossary already links) forbid l= use in production signing; (iii) signature-expiration (x=) + signature-timestamp (t=) vocabulary → replay-window-hardening mechanic — the glossary's signature timestamp (t=) + signature expiration (x=) vocabulary defines the cryptographic-validity-window contract, the replay-attacks spoke documents how narrowing x=-t= from the de-facto unbounded-window emission to a deliberately-narrow (≤7 days) operational window strictly bounds the post-capture replay-attempt window and shifts the attacker's economic calculus toward faster-but-narrower-yield campaigns; and (iv) per-message-velocity-baseline vocabulary → receiver-side replay-detection signal — the glossary's per-message velocity baseline + per-selector recipient-velocity baseline vocabulary entries catalogue the receiver-side observability terms-of-art, the replay-attacks spoke documents the actual per-selector recipient-velocity threshold model that large mailbox providers (Gmail / Yahoo / Microsoft / Apple) increasingly publish as a residual-attack-surface DETECTION signal for signature reuse that no per-message DKIM verification can independently surface. The replay-attacks spoke is therefore the OPERATIONAL-MECHANICS REFERENCE directly downstream of every signature- reuse and signature-validity-window vocabulary entry on this page — a defender fluent in THIS glossary's signature-and-replay vocabulary has no canonical reference for the actual attack-mechanics catalogue and receiver-side residual-attack-surface detection model their org's anti-impersonation engineering work materialises against — this link closes that vocabulary-to-attack- mechanics resolution gap at the post-DKIM-verification residual- attack-surface defence layer.
DKIM for Google Workspace — the per-provider Workspace-side DKIM deployment procedure mapping the security vocabulary this glossary catalogues onto the Workspace operator's actual control surface. Where this glossary catalogues threat-and-defense terms (key-compromise as a threat, super-admin-account takeover as the supply-chain attack vector, DKIM signing material as protected key material under the operator's secret-management posture, replay-window as a measurable risk surface, dwell-time as the operator response budget), the Workspace DKIM spoke documents the Workspace-specific control surface operators actually click in the Admin console (Apps → Google Workspace → Gmail → Authenticate email): the 2048-bit DKIM keypair generated and held by Workspace (NOT by the operator — Google retains custody of the private key on the tenant's behalf, which is a security-tradeoff operators must understand vs self-hosted BYOK key-management), the google._domainkey.<domain> TXT-record publication at the registrar, the half-yearly Google-driven key-rotation cadence Workspace performs automatically when the operator clicks Rotate, the Workspace-super-admin permission gate (any super-admin account compromise gives the attacker full DKIM-signer control: they can rotate the signing key, sign messages from From: ceo@<domain> with valid dkim=pass verdicts that align under DMARC, then rotate again to erase forensic traces — which is why super-admin accounts are the single most valuable Workspace privileged identity from an adversary's perspective), and the gappssmtp.com signing-identity gotcha (Workspace's default DKIM signing identity before custom-DKIM activation is <domain>.gappssmtp.com — the message PASSES DKIM verification but does NOT align with the From-header organisation domain, so DMARC FAILS despite the green DKIM verdict; the adversary value of this default-signing- identity gap is that legitimate-looking Workspace mail can fail DMARC post-enforcement and trigger operator rollback of p=reject, which widens the attacker's spoofing window). This is the FIRST email-security-glossary → Workspace-DKIM bridge — operators reading this glossary for the super-admin-account / key-compromise / replay-window vocabulary need the Workspace-DKIM procedural deep dive to understand the Workspace-specific control surface where those threat classes manifest in production.
DKIM for Microsoft 365 — the per-provider Exchange-Online-side DKIM deployment procedure mapping the security vocabulary this glossary catalogues onto the M365 operator's actual control surface. Where this glossary catalogues threat-and-defense terms (key-compromise as a threat, Global-Admin / Security-Admin account takeover as the supply-chain attack vector, DKIM signing material as protected key material under the operator's secret-management posture, Microsoft-managed BYOK-tradeoff in Exchange Online's CNAME-delegated model, replay-window as a measurable risk surface, dwell-time as the operator response budget), the M365 DKIM spoke documents the Microsoft-365-specific control surface operators actually click in the Defender portal (security.microsoft.com → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM): the CNAME-delegated signing model where the operator publishes only selector1._domainkey and selector2._domainkey CNAMEs but Microsoft retains custody of both private keys on the tenant's behalf (a security-tradeoff operators must understand vs self-hosted BYOK key-management — the operator has ZERO visibility into the actual signing keys, ZERO ability to revoke compromised keys outside the Microsoft-driven rotation cadence, and MUST trust Microsoft's HSM-backed key storage), the Microsoft-driven dual-selector rotation cadence (~6 months) Exchange Online performs automatically by alternating selector1 ↔ selector2, the Global-Admin / Security-Admin permission gate (any privileged-role account compromise gives the attacker full DKIM-signer control via the Defender portal: they can rotate the signing key by toggling DKIM off then back on which forces immediate regeneration, sign messages from From: ceo@<domain> with valid dkim=pass verdicts that align under DMARC, then rotate again to erase forensic traces — which is why Global-Admin and Security-Admin accounts are the single most valuable Exchange Online privileged identities from an adversary's perspective, and why Conditional Access + Privileged Identity Management + FIDO2-only sign-in for those roles is the load-bearing defensive control), and the onmicrosoft.com signing-domain gotcha (Exchange Online's default DKIM signing identity before custom-DKIM activation is <tenant>.onmicrosoft.com — the message PASSES DKIM verification but does NOT align with the From-header organisation domain, so DMARC FAILS despite the green DKIM verdict; the adversary value of this default-signing- identity gap is that legitimate-looking M365 mail can fail DMARC post-enforcement and trigger operator rollback of p=reject, which widens the attacker's spoofing window). The CNAME-delegated Microsoft model and the TXT-published Workspace model (documented in the DKIM-for-Workspace entry immediately above) present DIFFERENT security tradeoffs: Microsoft retains both keys (operators trust Microsoft's HSMs but cannot rotate out-of-cadence), Workspace retains one key per active selector (operators can force rotation by clicking Rotate in the Admin console but Google still holds the private key) — read the two per-provider DKIM-deployment spokes side-by-side for the BYOK-tradeoff comparison both major mailbox providers share. This is the FIRST email-security-glossary → M365-DKIM bridge — operators reading this glossary for the Global-Admin / Security-Admin / key-compromise / replay-window vocabulary need the M365-DKIM procedural deep dive to understand the Exchange-Online-specific control surface where those threat classes manifest in production.
MTA-STS for Google Workspace — the per-provider Workspace-side transport-security deployment procedure mapping the network-layer threat vocabulary this glossary catalogues onto the Workspace operator's actual control surface for inbound SMTP. Where this glossary catalogues network-layer threat-and-defense terms (STARTTLS stripping as the opportunistic-TLS downgrade attack where an active-network adversary intercepts the unencrypted SMTP greeting and suppresses the 250-STARTTLS capability advertisement so the sender falls back to cleartext, opportunistic TLS as the cleartext-fallback default that makes the downgrade possible, port 25 / MTA-to-MTA encryption as the encryption tier inbound mail to the receiver actually achieves in practice, MITM as the active-network adversary model, and certificate pinning as the defensive primitive an enforced policy provides), the MTA-STS-for-Workspace spoke documents the Workspace-specific defensive control surface operators actually configure to close the STARTTLS-stripping window: the _mta-sts.<domain> TXT-record publication at the registrar with the v=STSv1; id=<policy-version> format and the version-bump rotation protocol, the HTTPS hosting requirement for mta-sts.<domain> with valid TLS certificate and renewal cadence (typical patterns: GCS bucket + Cloud CDN, Cloud Run + Cloud Load Balancing, Firebase Hosting, third-party static-site host) — the HTTPS-hosting requirement is the STRUCTURAL DEFENSIVE PRIMITIVE that prevents an attacker spoofing the policy itself, because the receiving MTA validates the mta-sts.<domain> certificate chain before honoring the policy directives, the /.well-known/mta-sts.txt policy-file grammar ( version: STSv1 / mode: testing|enforce|none / mx: *.aspmx.l.google.com / max_age: <seconds> — the max_age field determines how long the policy is CACHED by senders, with the recommended 604800-second (one week) TTL representing the defensive-control TRADE-OFF between rotation agility and attacker-window narrowing), the four canonical Workspace MX hosts (aspmx.l.google.com + alt1-4.aspmx.l.google.com) that the policy file's mx: directives must enumerate to align with the actual receiving MTA topology, the TLS-RPT wire-up at _smtp._tls.<domain> for failure-report visibility (the dwell-time primitive applied to the transport layer — TLS-RPT JSON-failure-reports give operators the observability needed to detect ongoing STARTTLS-stripping campaigns and shorten adversary dwell time), and the testing-mode burn-in workflow (mode: testing → monitor TLS-RPT for failures over 4 weeks → switch to mode: enforce only when zero unexplained delivery failures observed) which manages the DEPLOYMENT-RISK TRADE-OFF between transport-security enforcement and legitimate-mail availability. This is the FIRST email-security-glossary → Workspace-MTA-STS bridge — operators reading this glossary for the STARTTLS-stripping / opportunistic-TLS / MITM / certificate-pinning vocabulary need the Workspace-MTA-STS procedural deep dive to understand the Workspace- specific control surface where those threat classes manifest in production and the defensive controls that close the network-layer downgrade window.
MTA-STS for Microsoft 365 (Exchange Online sibling of the Workspace MTA-STS deep dive immediately above) — the per-provider operational deep dive on the Microsoft-365 MTA-STS deployment procedure mapping this glossary's TRANSPORT-SECURITY THREAT vocabulary (STARTTLS stripping, opportunistic TLS, MITM, certificate pinning, downgrade attack) to the Exchange-Online-specific defensive control surface. Where this glossary catalogues STARTTLS (the SMTP verb advertised in the receiver banner that an attacker controlling a hop between the sender and Exchange Online inbound can strip), opportunistic TLS (the failure-mode the unstripped sender silently downgrades to when STARTTLS is missing — the STRUCTURAL-FALLBACK-TO-CLEARTEXT property MTA-STS exists to close), man-in-the- middle (MITM) (the active attacker model on the SMTP path between sending MTA and Exchange Online inbound), and certificate pinning (the DEFENSIVE PRIMITIVE MTA-STS implements via the policy file's mx: directive matching the TLS certificate chain on the Exchange-Online MX <tenant>-com.mail.protection.outlook.com), the MTA-STS-for-Microsoft-365 spoke documents the M365-specific defensive control surface closing each threat: where the _mta-sts.<domain> TXT record pins the inbound SMTP session to enforced TLS at the policy-version- pointer layer (the v=STSv1; id=<policy-version> format and the version-bump rotation protocol), where the HTTPS-hosted mta-sts.<domain> web origin on Azure (Blob Storage + CDN, Static Web Apps, App Service, Front Door) is the STRUCTURAL DEFENSIVE PRIMITIVE preventing policy-spoofing via certificate-chain validation (where this glossary catalogues the certificate-chain validation vocabulary entry as the defensive property), where the /.well-known/mta-sts.txt policy file's mx: directive with the tenant-scoped <tenant>-com.mail.protection.outlook.com hostname (distinct from the four-host Workspace aspmx.l.google.com set catalogued in the entry above) is the actual SMTP-session pinning surface, where the max_age policy- cache-lifetime directive (typically 604800 seconds = 7 days) manages the DEFENSIVE-CONTROL TRADE-OFF between rotation agility and attacker-window narrowing, where the _smtp._tls.<domain> TLS-RPT TXT record completes the feedback-loop closing the STARTTLS-STRIPPING DWELL-TIME PRIMITIVE applied to the Exchange Online transport layer, and where the testing-mode burn-in workflow (publish testing-mode policy → monitor TLS-RPT for failures over 4 weeks → switch to enforce mode only when zero unexplained delivery failures observed) manages the DEPLOYMENT-RISK TRADE-OFF between transport-security enforcement and legitimate-mail availability. This is the FIRST email-security-glossary → M365-MTA-STS bridge — operators reading this glossary for the STARTTLS-stripping / opportunistic-TLS / MITM / certificate-pinning vocabulary need the M365-MTA-STS procedural deep dive to understand the Exchange-Online-specific control surface where those threat classes manifest in production and the defensive controls that close the network-layer downgrade window. Pairs side-by-side with the MTA-STS-for-Workspace entry immediately above for the two-major-mailbox-provider transport-security coverage — the Workspace and M365 sides have STRUCTURALLY DIFFERENT MX hostnames (multi-host aspmx.l.google.com + four alt[1-4].aspmx.l.google.com on the Workspace side vs single tenant- scoped <tenant>-com.mail.protection.outlook.com on the M365 side), STRUCTURALLY DIFFERENT HTTPS-hosting ecosystems (GCP-native vs Azure-native), but IDENTICAL defensive primitive (pin the SMTP session to TLS, enforce certificate-chain validation via web-PKI, dwell-time feedback via TLS-RPT) and IDENTICAL deployment-risk trade-off (testing-mode burn-in before enforce-mode flip).
MTA-STS policy file syntax — the byte-exact grammar reference for the /.well-known/mta-sts.txt policy file — the SYNTAX-REFERENCE companion to the two MTA-STS deployment guides immediately above. Where the deployment guides document the per-provider PROCEDURE for publishing the _mta-sts.<domain> DNS record + standing up HTTPS hosting for the mta-sts.<domain> web origin, the syntax-reference spoke documents the byte-exact grammar of the /.well-known/mta-sts.txt policy file itself: the four canonical directives (version: STSv1, mode: testing|enforce|none, mx: <host-pattern>, max_age: <seconds>), the per-directive value rules (the version is the literal STSv1; the mode is one of three enumerated literals; the mx directive accepts one host per line and supports the leading-*. wildcard for the first label only; the max_age is an integer seconds value bounded by RFC 8461 at 86400 minimum and 31557600 maximum), and the version-bump DNS-TXT rotation protocol (the v=STSv1; id=<policy-version> TXT record at _mta-sts.<domain> is the rotation pin — bumping the id= value forces receivers to re-fetch the policy file before the previously cached max_age: window has elapsed). The syntax-reference spoke is the operator-side authoritative per-directive grammar reference that translates this glossary's STARTTLS / STARTTLS-stripping / opportunistic-TLS / downgrade-attack vocabulary into the actual policy-file text the receiver fetches and the directive enumeration the operator authors — read it when authoring or reviewing an MTA-STS policy file for an STARTTLS-stripping-hardening deployment.
DKIM selectors explained (s= and d= tags) — the operator-side tag-by-tag deep dive on the DKIM-Signature header tags (s= selector, d= signing domain, v=, a=, c=, q=, t=, x=, i=, l=, h=, bh=, b=) that translate this glossary's security vocabulary into the actual DNS records and signing configuration operators deploy. Where this glossary catalogues threat-and-defense terms (selector rotation as a control, key-compromise as a threat, replay-window as a measurable risk surface, dwell-time as the operator response budget), the selectors page documents the byte-exact DNS publication sequence — dual-selector zero-downtime rotation (publish-new / wait-TTL / cutover-signer / wait-replay-window / retire-old / DNS-purge), the eight canonical naming patterns (date / sequence / hash / purpose / tenant / environment / version / opaque), and the per-provider selector catalogue — that implement defensive control posture in production. Pair this glossary (the threat-and-defense vocabulary) with the selectors page (the DNS-record and tag mechanics) for the vocabulary-to-control- configuration translation that closes the loop from incident-response playbook to actual TXT-record changes operators publish during rotation or key-compromise response.
DKIM canonicalization explained (simple vs relaxed) — the byte-level header-and-body normalisation algorithm that determines whether replay-attack body-tail mutations survive verification. Where this glossary catalogues DKIM replay as a threat class (capture-and-resend of legitimately-signed messages — the signature remains valid because the signed content was not modified), the canonicalization page documents the operator-side control posture at the byte layer: simple body canonicalization (RFC 6376 §3.4.3 hashes the body verbatim and rejects ANY trailing-byte modification — strongest against body-tail replay variants but most fragile against benign whitespace- mangling MTAs and mailing-list footer injection) versus relaxed body canonicalization (§3.4.4 collapses internal whitespace, strips trailing whitespace, ignores trailing empty lines — survives most forwarders but admits a small replay-mutation surface at the body tail). The page also documents the most replay-dangerous knob in the spec — the l= partial-body-length tag (§3.5) — which lets attackers APPEND arbitrary content after the signed prefix while the signature still verifies; avoid in production regardless of canonicalization choice. Pair this security glossary (the threat catalogue) with the canonicalization page (the byte-level defensive-control posture) when configuring DKIM signers for replay-attack risk-tolerance and forwarder-survivability tradeoffs.
BIMI explained — pillar page for Brand Indicators for Message Identification — the defensive countermeasure to brand impersonation that gives authenticated brand mail a visible logo cue.
BIMI Verified Mark Certificates (VMC / CMC) — the certificate-side reference for the BIMI VMC and CMC terms catalogued in this glossary. Where this glossary defines the term VMC (the Verified Mark Certificate issued by qualified CAs after corporate-identity / trademark verification) and CMC (the Common Mark Certificate variant Apple Mail honors for unregistered trademarks with prior-use evidence) in one line each, the BIMI certificates spoke documents the FULL operator-side issuance and integration workflow: the dual-CA-vendor landscape (DigiCert + Entrust as the only qualified issuers — neither vendor offers the certificate via the general-purpose web PKI TLS-cert storefront, which the glossary's Web-PKI definition surface incorrectly suggests to readers not yet familiar with BIMI), the trademark-jurisdiction matrix (USPTO / EUIPO / UKIPO / JPO and the WIPO-recognised national IP offices that feed the CA's verification process), the Mark Type Indicator (mark-type) / indicator-uri tag binding from the certificate Subject CN to the SVG asset URI, the per-certificate renewal cadence (typically 1-2 year validity with annual CA re-verification of trademark registration status), and the dual-mode VMC-or-CMC selection logic operators apply based on their trademark portfolio status. Pair this glossary (the term definitions) with the certificates page (the operational workflow) for the vocabulary-to-deployment translation operators need when scoping a BIMI rollout against the legal / trademark-portfolio constraints.
BIMI SVG Tiny Portable / Secure profile requirements — the format-side reference for the BIMI SVG and SVG Tiny P/S terms catalogued in this glossary. Where this glossary defines the terms SVG (Scalable Vector Graphics) and SVG Tiny 1.2 Portable / Secure (the BIMI-specific format constraint preventing scripts and external references) in one line each, the BIMI SVG-requirements spoke documents the FULL operator-side format validation rules: the per-element whitelist (no <script> / <foreignObject> / external-href <use>), the fixed-aspect viewBox constraint (1:1 square), the post-optimisation 32 KB file-size ceiling, the no-external-font rule (text-as-paths only — the glossary's Web-PKI definition does not cover this rendering-constraint surface), and the per-CA SVG-asset validation that gates VMC issuance on file-format compliance. Pair this glossary (the format-term definitions) with the SVG-requirements page (the validation-rule depth) for the vocabulary-to-asset-prep translation operators need when commissioning the SVG-Tiny-P/S logo file from a brand design team unfamiliar with the BIMI format constraints.
ARC explained — pillar page for Authenticated Received Chain — the protocol-level countermeasure to forwarding- induced DMARC breakage.
SPF forwarding issues — the FORWARDING-BREAKAGE-FAILURE-MODE companion to the forwarding-and-list vocabulary this glossary catalogues. Where this glossary defines the infrastructure-and-pattern terms forwarding, auto-forwarding, mailing list, discussion list, list expansion, SRS (Sender Rewriting Scheme), envelope sender, Return-Path, MAIL FROM, and 5321.MailFrom each in single- sentence form alongside the cross-cutting forwarding-as-deliverability-risk sub-vocabulary (vacation responder, shared mailbox auto-relay, .forward file, Sieve redirect), the SPF forwarding-issues spoke documents the OPERATIONAL FAILURE MODES the vocabulary maps to: (i) the classic forwarder problem — an intermediate MTA receives a message envelope-addressed to a local user, then re-injects the same RFC 5322 message body toward the user's actual mailbox under a new envelope sender (typically the forwarding-system's own bounce-handling address), instantly breaking the SPF-authorised-sender-IP pairing the original domain published in its TXT record (the new envelope sender's domain does not authorise the forwarder's outbound IPs, producing a 5321.MailFrom-domain SPF-fail result for every forwarded message), (ii) the mailing-list expansion problem — discussion lists receiving a member's post and re-fanning it out to the full member roster MUST rewrite the envelope sender to the list- owner's bounce address (RFC 5321 envelope- sender uniqueness requirement for bounce handling) and typically also rewrite the Subject line ([list-name] prefix) and append a list-footer to the body — collectively breaking SPF (envelope-rewriting), DKIM (body and Subject-header mutation invalidates the body-hash bh= and the signed-header signature b=), and producing alignment failures on both identifiers, (iii) the multi-hop forwarding chain problem — sequential forwarder-of-forwarder paths (university → personal → corporate) compound the envelope-rewriting count, and each hop's SRS-encoded return-path becomes longer and more fragile, with eventual SRS-decoder-incompatibility producing silent bounces, and (iv) the autoresponder / vacation- responder problem — automated replies generated from a forwarded message often inherit the forwarder's identity rather than the original sender's, propagating a misattributed sender into the bounce- loop with broken SPF and DKIM validation against the original sender's authentication record. The forwarding- issues spoke documents the THREE canonical mitigation patterns operators deploy: SRS rewriting (RFC 5321 envelope-rewriting at the forwarder to a forwarder-authorised return-path), ARC sealing (RFC 8617 chain-of-custody signatures that let downstream receivers trust the forwarder's prior authentication results when the original SPF / DKIM fails post-forwarding), and mailing-list operator discipline (configuring list software to preserve DKIM signing-friendly headers and to ARC-seal outbound list traffic). Pair this glossary (the vocabulary terms) with the SPF forwarding-issues page (the four failure-mode taxonomy + three mitigation patterns) for the vocabulary-to-operational-reality translation operators need when an unexplained spike of SPF-fail rows appears in the aggregate feed attributable to a forwarder source-IP the operator does not directly own.
DANE explained — the PROTOCOL-LEVEL DEFENSE companion for the transport-layer attack vocabulary this security glossary catalogues. Where this glossary defines the threat-and- defense vocabulary terms STARTTLS stripping, SMTP downgrade attack, man-in-the-middle, rogue certificate, CA compromise, DNS hijacking, DNS cache poisoning, passive eavesdropping, active interception each in single-sentence form alongside the broader threat-actor taxonomy (APT groups, nation-state SIGINT, commercial MITM appliances at carrier peering points, compromised on-path residential ISPs), the DANE-explained spoke documents the protocol-level defense: RFC 7672 binds each receiving MX hostname's TLS certificate (or its issuing CA) to a TLSA record published in DNSSEC-signed DNS — making STARTTLS-stripping detectable (TLSA-required + STARTTLS-absent = fail closed), making rogue-certificate substitution detectable (presented-cert hash ≠ TLSA-published hash = fail closed), and making CA-compromise irrelevant for DANE-EE deployments (the trust anchor is the domain's own DNSSEC chain, not any external CA infrastructure). The DANE protocol is the canonical transport-layer DEFEND-OPERATIONALIZATION of the threat-vocabulary entries on this glossary — read once the threat terms have surfaced in an incident context (TLS-RPT failure-type certificate-host-mismatch, certificate-not-trusted, starttls-not-supported, validation-failure) and the operator needs the deployable protocol-defense reference. The adjacent pillar MTA-STS is the PKIX-based alternative defense; DANE and MTA-STS serve OVERLAPPING but DISTINCT trust-model threat scenarios (DANE = DNSSEC trust anchor → defends against PKIX-CA compromise; MTA-STS = PKIX trust anchor → simpler deployment, no DNSSEC requirement, accepts CA-issued cert as authority). The DANE pillar documents the comparison in detail.
MTA-STS vs DANE — the GLOSSARY-VOCABULARY-RESOLUTION companion documenting the head-to-head decision reference for choosing between MTA-STS and DANE. Where THIS glossary defines the transport-security threat-and- defense vocabulary terms (STARTTLS stripping, SMTP downgrade attack, certificate pinning, certificate transparency, DNSSEC chain validation, TLSA record, MX hijacking, man-in-the-middle, rogue CA, cert-host-mismatch, cert-not-trusted, starttls-not-supported, validation-failure, trust anchor) — the mta_sts_vs_dane spoke is the HEAD-TO-HEAD DECISION REFERENCE documenting how those vocabulary terms map to the operator's CHOICE between the TWO deployable transport-security protocols. The glossary-to-decision-reference resolution covers FIVE specific vocabulary-to-decision mappings the cross-reference makes explicit: (i) "trust anchor" maps to the MTA-STS-vs-DANE DECISION CORE — MTA-STS trusts the public-PKI hierarchy (any browser-trusted CA), DANE trusts the domain's own DNSSEC chain (the domain owner is the cert authority); choosing between them IS choosing the trust anchor; (ii) "STARTTLS stripping" defense maps to BOTH protocols — both MTA-STS and DANE defend against active downgrade, so the choice is NOT about which threat is defended but about which trust-anchor model fits the operator's CA-authorization landscape; (iii) "rogue CA" vulnerability maps to MTA-STS-WEAKNESS, DANE-STRENGTH — a compromised public CA can issue rogue certs that MTA-STS treats as trustworthy; DANE's DNSSEC-anchored hash bypasses public-CA trust entirely, so DANE is the natural defense against rogue-CA threats; (iv) "DNSSEC chain validation" prerequisite maps to DANE-PREREQUISITE, MTA-STS-NEUTRAL — DANE is OPERATIONALLY UNAVAILABLE without DNSSEC-signed-zone support; MTA-STS works without DNSSEC; (v) "cert-host-mismatch" + "cert-not-trusted" failures map to DIFFERENT INCIDENT REPORTING CHANNELS — MTA-STS failures surface in TLS-RPT JSON as policy-source: mta-sts failures with sts-webpki-invalid; DANE failures surface as policy-source: tlsa failures with tlsa-invalid, so the operator's TLS-RPT-stream observability signal is protocol-specific. Read the MTA-STS-vs-DANE head-to-head when the operator has internalized the transport-security vocabulary on THIS glossary and is now CHOOSING the deployment path.
TLS-RPT explained — the GLOSSARY-VOCABULARY-RESOLVES-TO- TLS-RPT-PROTOCOL-OVERVIEW companion reference. Where THIS glossary catalogues the email-security vocabulary at the transport layer (StripTLS, MTA-MITM, downgrade attack, opportunistic-TLS, STARTTLS-stripping, certificate-host- mismatch, BGP-hijack, aggregate-report, per-receiver per-day cadence, RUA-mailbox, per-day-per-domain aggregation), the TLS-RPT-explained spoke is the PROTOCOL- OVERVIEW canonical reference defining the RFC 8460 charter every term on THIS glossary's transport-security vocabulary section structurally resolves to. FOUR structurally-distinct GLOSSARY-VOCABULARY- TO-TLS-RPT-PROTOCOL-OVERVIEW resolution dimensions: (i) glossary terms StripTLS / MTA-MITM / opportunistic-TLS / downgrade-attack resolve to RFC 8460 §1 protocol charter — the protocol-overview spoke documents §1's explicit articulation of why TLS-RPT exists (passive observers and the sender operator alike cannot distinguish a StripTLS attacker-bypass path from natural per-receiver opportunistic-TLS failure without per-domain aggregate-evidence- stream observability); the four glossary terms documented on THIS page (StripTLS, MTA-MITM, opportunistic-TLS, downgrade- attack) are the protocol-charter's load-bearing motivation vocabulary; (ii) glossary terms _smtp._tls.<domain> / RUA-mailbox / per-receiver per-day cadence resolve to RFC 8460 §2 operator deployment model — the protocol- overview spoke documents the §2 deployment-model the glossary's TXT- record-publication and RUA-mailbox- ingestion vocabulary presupposes; the glossary vocabulary terms catalogued on THIS page name the operator-side artifacts the protocol-overview's deployment-model defines (TXT publication location, per-day aggregation cadence, per-receiver per-domain coverage expectations at major Gmail/Yahoo/ Microsoft/Apple populations); (iii) glossary terms per-day-per-domain aggregate / no-per-message-PII / privacy-by-design resolve to RFC 8460 §5 privacy constraints — the protocol-overview spoke documents the §5 privacy-by-design protocol invariant defining the per-day-per-domain aggregate cardinality boundary that strictly excludes per-message envelope-sender, message-id, recipient; the glossary vocabulary terms on THIS page name the privacy-invariant the protocol guarantees by design (distinguishing TLS-RPT aggregates from RFC 7489 §7.3 DMARC forensic-report per-message-PII payloads); (iv) glossary terms cross-receiver consistency / compromised-reporter / second-order-attacker-bypass resolve to RFC 8460 §6 reporter-side trust model — the protocol-overview spoke documents the receiver-trust model under which receivers themselves are attacker-targetable (an attacker who compromises one major receiver's reporting pipeline can fabricate per-day TLS-pass-rate baseline rows to suppress detection of an ongoing transport-layer attack); the glossary vocabulary terms on THIS page name the operator-side defense pattern (per-day cross-receiver consistency analysis as the second-order attacker-bypass detection primitive). Read the TLS-RPT-protocol-overview spoke alongside this glossary when the transport-security vocabulary terms on THIS page need to resolve to their canonical protocol-layer charter — the protocol-overview is the CHARTER + DEPLOYMENT-MODEL + PRIVACY-INVARIANT + REPORTER-TRUST-MODEL canonical reference every transport-security vocabulary term on THIS glossary's transport-observability section structurally resolves to.
TLS-RPT JSON report format (RFC 8460 §4) — the GLOSSARY-VOCABULARY-MAPS-TO-TLS-RPT- JSON-REPORT-SCHEMA companion documenting the on-the-wire JSON schema (RFC 8460 §4) of every TLS-RPT aggregate report. Where THIS glossary defines the transport- security vocabulary terms (STARTTLS stripping, SMTP downgrade attack, certificate pinning, certificate transparency, DNSSEC chain validation, TLSA record, MX hijacking, man-in-the-middle, rogue CA, cert-host-mismatch, cert-not-trusted, starttls-not-supported, validation-failure, trust anchor) in single-sentence form, the TLS-RPT report-format spoke is the JSON SCHEMA REFERENCE documenting how each of those vocabulary terms RESOLVES to a specific JSON field or result-type enum value the operator reads off the wire when ingesting TLS-RPT reports. The GLOSSARY-VOCABULARY- MAPS-TO-TLS-RPT-JSON-REPORT-SCHEMA cross-reference covers FIVE specific vocabulary-to-JSON-schema mappings: (i) "cert-host-mismatch" vocabulary → certificate-host-mismatch result-type enum value in the failure-details[] array per RFC 8460 §4.3 — the SAME failure mode THIS glossary defines as the cert subject not matching the connecting hostname; (ii) "cert-not-trusted" vocabulary → certificate-not-trusted result-type enum value — the SAME failure mode THIS glossary catalogues as the receiving MTA's trust store not containing the issuing CA's root; (iii) "STARTTLS stripping" / "SMTP downgrade attack" vocabulary → starttls-not-supported / sts-webpki-invalid / sts-policy-fetch-error result-type enum values — the three RFC 8460 §4.3 result-types that encode the active-downgrade attack class THIS glossary defines; the SPECIFIC result-type depends on whether MTA-STS is deployed (sts-* enums) or not deployed (starttls-not-supported); (iv) "DNSSEC chain validation" / "TLSA record" / "DANE" vocabulary → tlsa-invalid / dnssec-invalid / dane-required result-type enum values — the three RFC 8460 §4.3 result-types that encode the DANE-specific failure class THIS glossary catalogues; (v) "policy-domain" vocabulary → policy-domain JSON field in the policies[].policy object — the SAME policy-domain identifier THIS glossary defines as the receiving domain whose MTA-STS or DANE policy is being evaluated; the JSON schema reference is what operators consult when reading the on-the-wire report and matching the observed transport failures back to the vocabulary THIS glossary catalogues. TWENTY-FIRST glossary-as-universal-source use per memory feedback_glossary_as_universal_source: the email-security glossary's transport- security vocabulary naturally resolves to the TLS-RPT JSON report schema as the on-the-wire reference. Read THIS glossary WITH the TLS-RPT report-format spoke when the operator has internalized the transport-security vocabulary and is now READING the JSON reports whose result-type enum encodes the SAME vocabulary at the on-the-wire layer.
TLS-RPT record syntax — the EMAIL-SECURITY-VOCABULARY- TRANSPORT-LAYER-RECORD-PUBLICATION- BYTE-SYNTAX-CANONICAL-REFERENCE companion reference. Where THIS glossary catalogues the EMAIL-SECURITY VOCABULARY across ~80 terms (phishing, spoofing, BEC, AitM, transport- encryption, MTA-STS, DANE, TLS-RPT, StripTLS, downgrade attacks, MITM, certificate-pinning, opportunistic- TLS), the TLS-RPT-record-syntax spoke is the PUBLICATION-SIDE BYTE-LEVEL CANONICAL REFERENCE for the _smtp._tls.<domain> TXT record an operator publishes to make their domain a TLS-RPT-reporting ENDPOINT — i.e. the DNS publication the vocabulary glossary's TLS-RPT/transport-encryption terms describe the OPERATIONAL CONTEXT of. The v=TLSRPTv1 version identifier, rua=mailto: report-delivery target, semicolon separator + whitespace discipline, and per-receiver TXT-record location (underscore-prefixed sub-zone NOT apex) are the per-byte semantics the glossary's TLS-RPT vocabulary entries reference at the protocol-publication layer. TWENTY-SECOND glossary-as- universal-source use per memory feedback_glossary_as_universal_source: the email-security glossary's transport-encryption vocabulary naturally resolves to the TLS-RPT RECORD-SYNTAX as the on-the-wire PUBLICATION reference (a sibling to the on-the-wire REPORT-FORMAT reference the entry above resolves to). Read THIS glossary WITH the TLS-RPT-record-syntax spoke when the operator has internalised the transport-encryption vocabulary and is now PUBLISHING the TXT record whose byte-syntax encodes the operator's TLS-RPT reporting endpoint — the publication-side companion to the report-format-reading vocabulary this glossary catalogues.
CAA records explained — the PKI-ISSUANCE-POLICY-DNS-PUBLICATION companion reference for this glossary's CA-misissuance / cert-chain-compromise / publisher-side-PKI-control vocabulary. Where THIS glossary catalogues per-term single-sentence vocabulary entries for "CA" / "Certificate Authority" / "X.509 certificate chain" / "WebPKI trust store" / "CA misissuance" / "DNS RR-type-257" / "iodef contact" / "publisher PKI control" each as an individual single-sentence definition, the CAA-records spoke is the authoritative per-concept procedural reference covering the FULL CAA byte- syntax and operational-deployment framework: the RR-type-257 DNS record format <domain>. CAA <flags> <property> "<value>", the three core properties (issue for regular TLS certificates / issuewild for wildcard certificates / iodef for incident-reporting contact endpoint), the critical-bit flag (flags=128 REQUIRING CA-side comprehension or refusal-to-issue), the empty-value ";" idiom FORBIDDING all CA issuance, the inheritance-up-the-DNS- tree algorithm for subdomain lookups (CA queries from the most-specific subdomain upward until it finds a CAA RRset, treating absence-of-CAA at any level as no-restriction), the deployment-sequence recommendations (publish CAA records BEFORE applying for the first certificate from a new CA / CAA changes are issuance-time- only and do NOT revoke already-issued certificates / CAA records SHOULD be DNSSEC-signed to prevent attacker- substitution of the publisher's policy assertion), and the operator- observability framework (CA-side iodef reporting surfaces attacker- attempts at adversarial certificate procurement BEFORE the attacker succeeds, providing publisher-side DETECTION signal independent of any WebPKI-validator-pipeline detection). TWENTY-THIRD glossary-as-universal-source use per memory feedback_glossary_as_universal_source: the email-security glossary's PKI / cert-chain / CA-misissuance vocabulary naturally resolves to the CAA-records spoke as the on-the-wire PUBLISHER-SIDE- PKI-ISSUANCE-POLICY-DNS-PUBLICATION reference. Read THIS glossary WITH the CAA-records spoke when the security analyst has internalised the CA-misissuance- attack-surface vocabulary and is now PUBLISHING the CAA TXT record whose byte-syntax encodes the publisher's per-CA authorisation policy — the publication-side companion to the attack-surface-reading vocabulary this glossary catalogues. Especially valuable when the analyst is investigating an OSINT lookalike-domain finding (the SECURITY-GLOSSARY's CORE OPERATIONAL WORKFLOW): the analyst can query the lookalike domain's CAA records to determine whether the attacker has PUBLISHED publisher-side-PKI-control policy or LEFT IT DEFAULT (no CAA RRset means the attacker can issue from any CA in the WebPKI trust store) — both signals are publisher-side-attacker- sophistication indicators.
DMARC for shared hosting — the GLOSSARY-VOCABULARY-RESOLVES-TO- SHARED-HOSTING-PANEL-TENANT-DEPLOYMENT- OPERATIONAL-CONTEXT companion reference documenting how the per-term vocabulary on THIS glossary (DMARC tag-anatomy, SPF mechanism-anatomy, DKIM selector + signing-identity vocabulary, alignment, public-suffix-list, organisational-domain, forwarder-rewrite-class, third-party- sender-class, BIMI VMC / CMC, MTA-STS modes, DNS-RR-publication, propagation- TTL, key-rotation-cadence) maps onto the Plesk / DirectAdmin / ISPConfig / WHM- reseller hosting-panel tenant's ACTUAL DEPLOYMENT SURFACE — where the panel operator publishes records via the panel UI (Plesk Hosting Settings → DNS Settings tab, DirectAdmin Admin Level → DNS Administration, ISPConfig DNS → SPF Wizard, WHM-reseller WHM → DNS Functions → Edit DNS Zone) rather than the tenant directly editing a zone file or controlling a signing-MTA configuration. TWENTY-FOURTH glossary-as-universal-source use per memory feedback_glossary_as_universal_source: the email-security glossary's deployment- agnostic protocol-and-defense vocabulary naturally resolves to the shared-hosting spoke as the on-the-wire SHARED-HOSTING- PANEL-TENANT-DEPLOYMENT-OPERATIONAL- CONTEXT for FOUR distinct vocabulary clusters: (i) DMARC-publication vocabulary (the v=DMARC1; p=<policy>; rua=<mailbox>; ruf=<mailbox>; sp=<subdomain-policy>; adkim=<mode>; aspf=<mode>; pct=<percentage>; fo=<forensic-options> tag- anatomy) maps onto the panel's DNS-zone-editor UI where the tenant publishes the _dmarc.<tenant- domain> TXT record without direct zone-file shell access; (ii) SPF-publication vocabulary (the eight mechanisms, four qualifiers, ten-lookup limit) maps onto the panel-provided SPF helper-record (include:spf.<hosting-provider>.com) whose include-chain depth + ESP-include compounding the shared-hosting spoke catalogues against the lookup-budget arithmetic this glossary's "DNS lookup limit" vocabulary defines; (iii) DKIM-publication vocabulary (selector, d= signing- identity, key rotation, canonicalisation) maps onto the panel-managed default._domainkey.<tenant- domain> selector key the panel generates on the tenant's behalf and publishes via the same DNS-zone-editor UI; (iv) third-party-sender vocabulary (ESP-relay, transactional- mail, marketing-mail, sender-domain alignment) maps onto the panel-bypass deployment topology where the tenant routes outbound mail through SendGrid / Mailgun / Amazon SES (bypassing the panel's MTA) and must publish per-ESP DKIM CNAMEs + per-ESP SPF includes via the same panel-DNS-editor UI. Read THIS glossary WITH the shared-hosting spoke when the panel-tenant operator has internalised the deployment-agnostic protocol-vocabulary and is now PUBLISHING the records whose byte-syntax encodes the tenant's actual DMARC + SPF + DKIM configuration on a shared-hosting panel whose UI semantics differ from cPanel (sibling spoke) and from M365 / Google Workspace enterprise tenant.
include vs ip4 vs a vs mx — the GLOSSARY-VOCABULARY-RESOLVES-TO- SPF-MECHANISM-CHOICE-DECISION-VIEW companion to this email-security glossary. Where THIS glossary defines the protocol-vocabulary every email- authentication operator must internalise (SPF / DKIM / DMARC / ARC / MTA-STS / DANE / TLS-RPT / BIMI / and the per- mechanism terms include / ip4 / ip6 / a / mx / ptr / exists / all / redirect= / exp=), the include-vs-ip4- vs-a-vs-mx spoke is the DECISION-VIEW- INSTANTIATION companion documenting how four of the most-frequently-used SPF- mechanism vocabulary entries (include:, ip4:, a:, mx:) instantiate as a focused per-publisher mechanism-choice decision surface. The four-axis GLOSSARY-VOCABULARY-VS-DECISION-MATRIX- INSTANTIATION comparison exposes the structurally-distinct glossary-to- decision-view couplings: (i) the glossary entry for include: defines the per- mechanism syntax and per-mechanism semantics (include another domain's SPF record as if it were inlined); the include-vs-ip4-vs-a-vs-mx spoke instantiates the include: decision-criteria (managed providers like Microsoft 365 and Google Workspace, where the provider publishes a versioned SPF record at _spf.<provider> that the customer cascades via include:) with worked examples and the seven most common include-cascade mistakes — operators reading the glossary's include: entry follow the include-vs-ip4-vs-a-vs-mx spoke for the when-to-use vs when-NOT-to-use operational guidance; (ii) the glossary entry for ip4: defines the per-mechanism syntax (literal IPv4 CIDR authorisation); the include-vs-ip4-vs-a-vs-mx spoke instantiates the ip4: decision-criteria (static IPs you own and control, on-prem Postfix relays with stable egress topology, never cloud-provider IP-pools that rotate) with worked examples and the canonical ip4:0.0.0.0/0 catastrophic- mistake warning — operators reading the glossary's ip4: entry follow the include-vs-ip4-vs-a-vs-mx spoke for the per-IP-topology decision framework; (iii) the glossary entry for a: defines the per-mechanism syntax (authorise the A-record-resolved IP of a hostname); the include-vs-ip4- vs-a-vs-mx spoke instantiates the a: decision-criteria (self- hosted servers identified by an A-record, never bare a on an apex shared with a hosting-panel webserver whose A-RR points at a webserver IP that does not send mail) — operators reading the glossary's a: entry follow the include-vs-ip4-vs-a-vs- mx spoke for the apex-vs-subdomain decision pattern; (iv) the glossary entry for mx: defines the per-mechanism syntax (authorise the A-record-resolved IPs of the domain's MX targets); the include- vs-ip4-vs-a-vs-mx spoke instantiates the mx: decision-criteria (the historical "outbound also serves as MX" pattern from the 1990s-era single-server topology; rarely appropriate in modern cloud-mail deployments where MX targets are Microsoft / Google receive-side infrastructure that does NOT send the customer's outbound mail) — operators reading the glossary's mx: entry follow the include-vs-ip4-vs-a-vs-mx spoke for the legacy-vs-cloud topology decision pattern. Read the include-vs-ip4-vs-a-vs- mx spoke alongside this glossary when the operator has internalised the deployment-agnostic SPF-mechanism vocabulary and is now PUBLISHING the per-mechanism choice whose syntax this glossary defines — the spoke documents the focused four-way decision view between the four IP-providing mechanism classes that resolve the "which mechanism should I use" question every per-publisher SPF-record author must answer.
SPF PermError vs TempError — the EMAIL-SECURITY-GLOSSARY- VOCABULARY-RESOLVES-TO-PER-MESSAGE-SPF- EVALUATION-FAILURE-CLASS-CATALOGUE companion to this email security glossary reference. Where THIS page documents the per-publisher per-domain email-security-vocabulary catalogue (per-term per-publisher per-domain canonical-definition lookup, per-term cross-vocabulary mapping, per-term RFC-anchored authoritative-definition reference), the SPF-PermError-vs- TempError spoke documents the per- publisher per-message RFC 7208 §4.6.4 SPF-evaluation-failure-class catalogue whose per-message verdict-class lexicon is the LOAD-BEARING per-publisher per- message SPF-error-class publication- discipline-vocabulary every per-publisher per-receiver per-day per-source-IP rua-aggregate-XML SPF-error-class evidence row resolves against at FOUR per-publisher per-message SPF-error- class-vocabulary coupling dimensions: (i) per-publisher per-message spf=permerror verdict- class as PER-PUBLISHER-FAULT permanent SPF-evaluation failure-class vocabulary primitive — per-publisher per- message spf=permerror verdict-class emergence attributes per-publisher per- domain SPF-publication-discipline-fault (per-publisher SPF-record-syntax-error, per-publisher 10-DNS-lookup-limit- overflow, per-publisher void-lookup- overflow, per-publisher multi-record- SPF-publication) as the load-bearing per-message SPF-evaluation-failure upstream root-cause class the per- publisher per-domain operations team consumes from per-publisher per-domain rua-aggregate-XML evidence stream — the SPF-PermError-vs-TempError spoke is the STRUCTURALLY-UPSTREAM per-publisher per- message PERMANENT-SPF-EVALUATION- FAILURE-CLASS publication-discipline- vocabulary reference whose per-publisher- fault attribution every per-publisher per-domain rua-aggregate-XML SPF- permerror evidence row this glossary catalogue's per-term per-publisher per- domain canonical-definition lookup resolves the per-message verdict-class attribution of; (ii) per- publisher per-message spf= temperror verdict-class as PER- RECEIVER-FAULT transient SPF-evaluation failure-class vocabulary primitive — per-publisher per-message spf= temperror verdict-class emergence attributes per-receiver-fault transient SPF-evaluation infrastructure failure (per-receiver DNS-resolution-timeout, per-receiver intermittent-DNS-failure, per-receiver SPF-record-fetch-network- error) as the load-bearing per-message SPF-evaluation-failure upstream root- cause class STRUCTURALLY-DISTINCT from per-publisher-fault SPF-permerror emergence — the SPF-PermError-vs- TempError spoke is the STRUCTURALLY- UPSTREAM per-publisher per-message TRANSIENT-SPF-EVALUATION-FAILURE- CLASS publication-discipline-vocabulary reference whose per-receiver-fault attribution every per-publisher per- domain rua-aggregate-XML SPF-temperror evidence row this glossary catalogue's per-term per-publisher per-domain canonical-definition lookup resolves the per-message verdict-class attribution of; (iii) per- publisher per-domain SPF-error-class- vocabulary publication-discipline as load-bearing per-publisher per-domain operator-vocabulary primitive every per-publisher per-domain operations- team SPF-error-class diagnostic decision-discipline consumes — per-publisher per-domain operations- team per-publisher per-domain SPF- error-class diagnostic decision- discipline (per-publisher SPF- permerror-class incident-response runbook, per-publisher SPF-temperror- class observability-stability decision- discipline, per-publisher per-source-IP per-day per-message-class SPF-error- class root-cause attribution workflow) structurally consumes the per-publisher per-message SPF-error- class publication-discipline-vocabulary the SPF-PermError-vs-TempError spoke documents as the LOAD-BEARING per- publisher per-domain operator- vocabulary primitive — the glossary catalogue's per-term per-publisher per- domain canonical-definition lookup connects per-publisher per-domain operator-vocabulary per-term per- publisher SPF-error-class lookup to the SPF-PermError-vs-TempError spoke's per-publisher per-message verdict- class catalogue authoritative reference; (iv) per-publisher per-domain SPF-error-class-vocabulary cross- vocabulary mapping to per-publisher per-domain DMARC-aligned-pass- evaluation-vocabulary as load-bearing per-publisher per-domain cross-protocol glossary-vocabulary mapping primitive — per-publisher per-message spf= permerror / spf=temperror verdict- class produces per-publisher per- message DMARC-aligned-pass-evaluation outcome class STRUCTURALLY-DISTINCT from per-message spf=pass / spf=fail / spf=softfail / spf=neutral verdict- class outcomes — the SPF-PermError- vs-TempError spoke documents the per- publisher per-message SPF-error-class publication-discipline-vocabulary whose per-message verdict-class STRUCTURALLY-DRIVES per-publisher per- message DMARC-aligned-pass-evaluation- vocabulary cross-protocol mapping the glossary catalogue's per-term per- publisher per-domain cross-vocabulary- mapping primitive structurally catalogues. Read the SPF-PermError-vs- TempError spoke alongside this email security glossary reference for the canonical per-publisher per-message RFC 7208 §4.6.4 SPF-evaluation- failure-class catalogue whose per- publisher-fault vs per-receiver-fault attribution per-publisher per-message verdict-class lexicon is the LOAD- BEARING per-publisher per-message SPF-error-class publication-discipline- vocabulary every per-publisher per- receiver per-day per-source-IP rua- aggregate-XML SPF-error-class evidence row this glossary catalogue's per- term per-publisher per-domain canonical-definition lookup resolves against.
DMARC for transactional email — the per-publisher per-domain TRANSACTIONAL-EMAIL-DEPLOYMENT- VOCABULARY companion to this email security glossary reference. Where THIS page documents the per-publisher per-domain email-security-vocabulary catalogue (per-term per-publisher per- domain canonical-definition lookup, per-term cross-vocabulary mapping, per-term RFC-anchored authoritative- definition reference), the DMARC-for- transactional-email spoke documents the per-publisher per-domain high- volume transactional-sender DMARC deployment vocabulary catalogue (per-ESP per-publisher per-domain SendGrid / Mailgun / Postmark / Amazon SES / SparkPost SUBDOMAIN-DELEGATION deployment-pattern vocabulary, per-ESP CNAME-DKIM-KEY-PROVISIONING vocabulary, per-publisher per-domain per-ESP SPF-INCLUDE-BUDGET-COORDINATION vocabulary, per-publisher per-domain DMARC pct=-RAMP-UP deployment vocabulary, per-publisher per-domain TRANSACTIONAL-vs-MARKETING SUBDOMAIN-SEPARATION vocabulary). The DMARC-for-transactional-email spoke is the per-publisher per-domain DEPLOYMENT-VOCABULARY catalogue documenting the operational deployment terms-of-art the glossary catalogue's per-term per-publisher per-domain canonical-definition lookup resolves to authoritative deployment patterns: the operator searching the glossary for "what is subdomain delegation", "what is per-ESP CNAME-DKIM provisioning", "what is SPF-include- budget breach", "what is DMARC pct= ramp-up", or "what is transactional- vs-marketing subdomain separation" finds the per-term canonical definition in the glossary catalogue and the operational deployment recipe in the DMARC-for-transactional- email spoke. Read THIS page when ESTABLISHING the per-publisher per- domain email-security-vocabulary baseline; read the DMARC-for- transactional-email spoke when AUTHORING the per-publisher per-domain per-ESP transactional-sender DMARC deployment whose per-publisher per- domain deployment-vocabulary catalogue the glossary catalogue's per-term canonical-definition lookup resolves the operational deployment terms-of- art of.
Email Header Analyzer — paste any email's headers and see SPF, DKIM, DMARC, and ARC results applied to a real message; the operational tool for investigating suspicious mail without leaving the platform.
Domain Security Checker — live DNS lookups for every email-authentication record on a domain; useful for OSINT on suspected look-alike domains.
DNS Record Generator — SPF / DKIM / DMARC / TLS-RPT / MTA-STS / CAA / BIMI record wizards for hardening your own domain.
DMARC Analyzer Dashboard — ingests aggregate (RUA) and forensic (RUF) reports via includes/DmarcParser.php and includes/ForensicReportParser.php, evaluates DNS records via includes/DnsChecker.php, and parses raw email headers via includes/EmailHeaderParser.php.
MITRE ATT&CK — the canonical knowledge base of adversary tactics, techniques, and procedures.
MITRE D3FEND — the defensive counterpart to ATT&CK.
CISA (Cybersecurity and Infrastructure Security Agency) — U.S. national cyber-defense authority publishing alerts, advisories, and Known Exploited Vulnerabilities (KEV) catalog.
FBI IC3 (Internet Crime Complaint Center) — the annual IC3 report quantifies BEC and other email-crime losses by category.
NIST SP 800-61r2 — Computer Security Incident Handling Guide — the canonical IR lifecycle reference.
NIST SP 800-207 — Zero Trust Architecture — the reference architecture for zero-trust deployment.
Have I Been Pwned — the breach-aggregation service referenced in the OSINT section.
DMARC aggregate (RUA) reports — the PER-PUBLISHER-PER-DOMAIN-DMARC- RUA-XML-SCHEMA-AS-CANONICAL-PER-GLOSSARY- TERM-AUTH-RESULTS-VOCABULARY-EVIDENCE-STREAM companion to this email-security-glossary terminology hub. Where THIS glossary documents the canonical per-term per-protocol Auth-Results-vocabulary (per-term dkim=pass / dkim=fail / dkim=neutral / dkim=temperror / dkim=permerror / dkim=policy + per-term spf=pass / spf=fail / spf=softfail / spf= neutral / spf=temperror / spf=permerror / spf= none + per-term dmarc=pass / dmarc=fail result-value vocabulary the per-publisher per-domain operations team consults during per-receiver per-message per-protocol verdict decode discipline), the DMARC-aggregate-RUA- reports spoke is the per-publisher per-domain operational-evidence stream operators consult at FOUR per-glossary-term decode-discipline dimensions: (i) per-glossary-term per-protocol verdict-value definition coordinated with per-publisher per-domain DMARC RUA aggregate-report per-receiver per- message auth_results element verdict-value observability — per-publisher operators decoding per-receiver per-message auth_results element verdict values (per- receiver per-message dkim/spf/dmarc result- value-and-selector-and-identity-and-comment sub-children) consult per-glossary-term per-protocol verdict-value definition for canonical per-term semantics — the per- publisher per-domain DMARC RUA aggregate- report stream IS the per-publisher per- domain operational-evidence observability primitive the per-glossary-term per-protocol verdict-value definition decode-discipline attributes per-message; (ii) per- glossary-term per-protocol identity-vs- identifier discipline (per-term Header-From vs envelope-MAIL-FROM vs DKIM-signing-domain vs HELO/EHLO-domain) coordinated with per- publisher per-domain DMARC RUA aggregate- report per-receiver per-message identifiers element observability — per- publisher operators decoding per-receiver per-message identifiers element per-row attribution (per-receiver per-message header_from / envelope_from / envelope_to / envelope_to_domain sub-children) consult per-glossary-term identity-vs-identifier per-protocol-discipline definition for canonical per-term per-protocol attribution semantics — the per-publisher per-domain DMARC RUA aggregate-report stream IS the per-publisher per-domain identifier- observability primitive the per-glossary- term per-protocol identity-discipline decodes per-message; (iii) per- glossary-term per-protocol policy-tag vocabulary (per-term p=none/p=quarantine/ p=reject + per-term sp= subdomain-policy + per-term pct= partial-enforcement + per- term adkim=/aspf= alignment-mode + per- term fo= forensic-emission) coordinated with per-publisher per-domain DMARC RUA aggregate-report per-receiver per-message policy_published element observability — per-publisher operators decoding per-receiver per-message policy_published element per-receiver- interpretation evidence (per-receiver per-message per-publisher per-domain p=/ sp=/pct=/adkim=/aspf=/fo= per-receiver- side resolved values) consult per- glossary-term per-protocol policy-tag vocabulary definition for canonical per- term per-protocol policy-tag semantics — the per-publisher per-domain DMARC RUA aggregate-report stream IS the per- publisher per-domain policy-tag- publication-observability primitive the per-glossary-term per-protocol policy- tag-vocabulary decodes per-message; (iv) per-glossary-term per-protocol disposition-vocabulary (per-term disposition=none/disposition=quarantine/ disposition=reject + per-term reason- type=trusted_forwarder/reason-type= mailing_list/reason-type=local_policy/ reason-type=other) coordinated with per- publisher per-domain DMARC RUA aggregate- report per-receiver per-message row disposition observability — per-publisher operators decoding per- receiver per-message per-row disposition evidence (per-receiver per-message per- publisher per-domain per-source-IP per- author-domain per-alignment-outcome per- receiver-side disposition decision + per-receiver-side reason-type override rationale) consult per-glossary-term per- protocol disposition-vocabulary definition for canonical per-term per-protocol per- receiver-side disposition semantics — the per-publisher per-domain DMARC RUA aggregate-report stream IS the per- publisher per-domain per-receiver-side- disposition observability primitive the per-glossary-term per-protocol per- disposition-vocabulary decodes per- message. Read the DMARC-aggregate-RUA- reports spoke alongside this email- security-glossary terminology hub when AUTHORING per-publisher per-domain per- glossary-term per-protocol verdict decode-discipline runbooks that integrate per-publisher per-domain DMARC RUA aggregate-report per-receiver per-message auth_results / identifiers / policy_ published / row disposition element evidence-stream attribution, when ESTABLISHING per-publisher per-domain per-glossary-term per-protocol per- receiver-side verdict-attribution discipline-floor that operationally codifies the per-term Auth-Results- vocabulary the per-publisher per-domain operations team consults during per- receiver per-message triage, or when AUDITING per-publisher per-domain per- receiver-side per-message verdict- attribution observability discipline- floor cross-referenced against per- glossary-term per-protocol vocabulary canonical-semantics reference.
DMARC for cPanel-hosted domains
DMARC alignment — the per-publisher per-domain application-layer composite-verdict alignment-evaluation longer-form reference per RFC 7489 §3.1.1 that the glossary’s per-term “alignment” and “organisational domain” entries presuppose. Where THIS glossary codifies the cross-protocol vocabulary (alignment, strict-vs-relaxed alignment mode, organisational domain, Public Suffix List, RFC 5321 envelope-MAIL-FROM vs RFC 5322 From, aligned-pass disjunction) as canonical-semantics one-liner definitions every glossary consumer reaches for at per-protocol vocabulary-disambiguation time, the DMARC alignment spoke documents the load-bearing longer-form per-publisher per-domain alignment-evaluation engine reference whose strict-vs-relaxed mode publication-decision the glossary’s per-term “adkim=”/“aspf=” DMARC TXT-RR tag entries reference as one- liner anchors, whose psl-derived organisational-domain extraction discipline the glossary’s “Public Suffix List” one-liner anchors, and whose per-message aligned-pass disjunction evaluation (any-DKIM-aligned-pass OR SPF- aligned-pass = DMARC composite alignment) the glossary’s “aligned-pass” and “DMARC composite verdict” entries reference at the per-publisher per- domain composite-verdict canonical-semantics boundary. Pair this glossary (the one-liner vocabulary entries) with the DMARC alignment spoke (the load-bearing evaluation-engine reference) for the complete per-publisher per-domain application-layer composite-verdict-and- alignment vocabulary-to-evaluation-engine translation every per-publisher per-domain DMARC operator must understand at the per- message per-receiver alignment-evaluation boundary.
DMARC policy rollout — the deployment-procedure companion to this glossary. Where this page catalogues the email-security vocabulary as terse dictionary entries (the p= policy-mode tag, the pct= sampling ramp, identifier alignment, the RUA aggregate stream, quarantine and reject dispositions), the policy-rollout spoke is the OPERATIONAL PROCEDURE those terms resolve to: it walks the operator through publishing p=none first, reading the per-source aligned-pass evidence in the RUA aggregate stream until every legitimate sender authenticates, advancing to p=quarantine with a monotonically-ramped pct=, and reaching p=reject only once the enforcement floor is stable. Read the policy- rollout spoke when a reader has learned what the p=none / p=quarantine / p=reject policy-mode vocabulary means on this glossary and needs the deployment procedure that safely sequences a domain through the enforcement ramp those terms describe.
DMARC for Office 365 hybrid (on-prem Exchange + Exchange Online) — the GLOSSARY-VOCABULARY-RESOLVES-TO-DUAL-EGRESS-HYBRID-DEPLOYMENT-CONTEXT companion — the deployment-context reference where the identifier-alignment, SPF include, DKIM selector and p= policy-mode vocabulary THIS glossary catalogues is applied to the hybrid Exchange topology. The spoke documents how a tenant routing mail through BOTH an on-prem Exchange Send Connector and the Exchange Online outbound queue publishes per-tenant SPF (include:spf.protection.outlook.com plus the on-prem egress IPs), dual DKIM selectors, and a DMARC record whose p=quarantine / p=reject ramp must hold across both egress paths — the operational context the glossary's authentication terms resolve to in a mixed on-prem/cloud deployment.
Microsoft SNDS + JMRP monitoring — the operational guide behind the SNDS, JMRP, ARF, and complaint-rate entries: what Microsoft's consumer network exposes per sending IP and how to monitor it via the Automated Data Access key with its silent 30-day expiry.

Apply the security glossary to your domain

Every term in this glossary translates to a concrete countermeasure in your domain configuration. Use the Domain Security Checker to verify your SPF / DKIM / DMARC / MTA-STS / TLS-RPT / CAA records, the Email Header Analyzer to investigate a suspicious message, and the dashboard to monitor real-world attacks against your domain via DMARC aggregate reports.