PCES key terms

A DNS TXT record listing the IP addresses and hosts authorized to send mail for a domain. Receivers compare the connecting server's IP against this list and record the result as pass, fail, softfail, or neutral.

A permanent SPF evaluation failure caused by a malformed record, such as too many DNS lookups or invalid syntax. Unlike a fail result, it means the policy could not be read at all.

The SPF specification caps DNS-querying mechanisms and modifiers at ten per evaluation. Exceeding it produces a permerror, so records using include, a, mx, ptr, exists, or redirect must be counted carefully.

A cryptographic signature added to message headers, allowing the receiving server to verify the message was signed by a party holding the private key and that signed content was not altered in transit.

The label in the d= and s= signature tags that tells the verifier which DNS record to fetch, published at selector._domainkey.domain. Multiple selectors let a domain rotate keys or separate sending services.

A hash of the canonicalized message body recorded in the DKIM bh= tag. If the recomputed hash differs, the body was modified after signing and the signature fails.

The normalization rules (relaxed or simple) applied to headers and body before DKIM hashing, so minor transport changes such as whitespace or line endings do not break signature verification.

Periodically replacing DKIM signing keys and publishing new selectors while old ones remain briefly for in-flight mail. Rotation limits the damage if a private key is compromised.

A DNS policy record that ties SPF and DKIM results to the visible From domain through alignment, tells receivers what to do on failure, and supplies a reporting address for aggregate and forensic feedback.

The requirement that the domain passing SPF or DKIM match the From header domain, either exactly (strict) or as an organizational domain (relaxed). Alignment is what makes DMARC pass meaningful.

The registrable base domain derived from a public suffix list, such as example.com from mail.example.com. DMARC relaxed alignment compares these base domains rather than full hostnames.

The p= tag (none, quarantine, or reject) instructing receivers how to handle mail failing both alignment checks, optionally with sp= for subdomains and pct= to apply the policy to a percentage of messages.

A periodic XML summary (RUA) sent to the domain owner listing sending sources, message counts, and SPF and DKIM pass rates. It is the primary tool for monitoring before tightening policy.

The staged progression from p=none monitoring through quarantine to reject, undertaken once aggregate reports show all legitimate senders aligned. Rushing this step causes legitimate mail loss.

An isolated organizational container in a cloud email platform with its own directory, configuration, and mail flow rules. Cross-tenant access must be explicitly granted and audited.

A domain configured in a cloud mail platform as authoritative, authoritative-with-relay, or internal relay. The type determines whether unknown recipients are rejected or forwarded elsewhere.

A configuration object defining how mail is routed between the cloud platform and another system, specifying direction, TLS requirements, and certificate or IP-based authentication.

A server-side transport rule that inspects message attributes and applies actions such as block, redirect, add header, or modify subject. Rules execute in priority order and can be scoped by sender, recipient, or content.

Opportunistic TLS applied to mail in transit between servers. It protects against passive interception but, without enforced certificate validation, does not prevent an active downgrade attack.

A published policy, fetched over HTTPS and cached, that requires TLS with valid certificates for inbound mail to a domain, closing the opportunistic-TLS downgrade gap. Paired with TLS reporting.

DNS-based Authentication of Named Entities, using TLSA records to pin a mail server's certificate in DNSSEC-signed DNS. It provides authenticated TLS without relying on a separate HTTPS policy fetch.

Filtering logic that flags messages whose display name, lookalike domain, or header pattern mimics a trusted internal or partner sender, even when no malicious attachment or link is present.

A registered domain visually or typographically similar to a target brand, using homoglyphs, transposed letters, or alternate TLDs. Detection relies on brand monitoring and similarity scoring.

Registering domains that differ from a legitimate name by a small typo, such as a missing or doubled character, to intercept mistyped traffic or host phishing pages.

A time-of-click URL rewriting service that re-evaluates links when a user clicks them, blocking destinations that became malicious after delivery and logging the click event.

Detonation of attachments in an isolated sandbox before delivery or at click time, detecting malicious behavior that signature-based scanning misses. Verdicts can be delayed or asynchronous.

Retroactive removal of messages already delivered to mailboxes once a later detection confirms they are malicious. It closes the gap between delivery and signature or sandbox verdict updates.

Holding suspicious or policy-violating messages in a controlled store instead of the inbox, with reviewer release or denial. Quarantine policies define notifications and what end users may self-release.

The workflow for reviewing blocked or quarantined legitimate mail, releasing it, and tuning the responsible rule or filter to prevent recurrence while preserving detection coverage.

Reading the full message header to trace delivery hops, authentication results, and originating IP. Key fields include Received, Authentication-Results, Return-Path, and Message-ID.

A header added by the receiving system recording SPF, DKIM, and DMARC outcomes for the message, including the evaluated domain and selector. It is the starting point for most investigations.

A platform query showing the delivery path and events for messages matching sender, recipient, subject, or time criteria, including filter verdicts and final disposition.

An attack in which a compromised or spoofed executive or vendor mailbox is used to redirect payments or extract data, typically with no malware and minimal technical indicators.

Reviewing hidden inbox rules, forwarding settings, and delegate permissions for signs of attacker persistence, such as rules that move finance mail to an archive folder.

An application authorization a user approves, giving a third-party app access to mail or files. Illicit consent grants let attackers read mail without a password and survive password resets.

Policy that grants or blocks access based on signals such as user, device compliance, location, and risk level. It is the main control for enforcing MFA and blocking legacy authentication.

Older mail protocols that cannot perform modern authentication or MFA, such as basic-auth IMAP, POP, and SMTP AUTH. Blocking them removes a common credential-stuffing entry point.

Encrypting message content so only intended recipients can read it, either through transport encryption, S/MIME end-to-end keys, or a portal-based wrapper that requires recipient authentication.

Policy that inspects outbound and internal mail for sensitive data patterns such as card numbers or identifiers, then blocks, encrypts, or alerts on matches.

Rules defining how long mail is kept, where it is stored, and when it is deleted, supporting legal holds and regulatory obligations while limiting breach exposure.

The process of searching, preserving, and exporting mailbox and message content for litigation or investigation, including holds that prevent deletion during the matter.