PCES common mistakes
PCES · Understand the traps and how to avoid them.
Treating SPF as the mechanism that authorizes the visible From: header, and answering that an SPF fail alone means the message is spoofed from that domain.
SPF authenticates the envelope sender (MAIL FROM / HELO identity), and receivers apply it to the bounce domain, not the header From. Candidates who learned 'SPF stops spoofing' from marketing material collapse the two identities and misread alignment questions.
What to do instead
Draw the three identities separately (HELO, MAIL FROM, header From) and state which record authenticates each. Remember SPF checks the envelope; DMARC alignment is what ties an authenticated identifier back to the From domain, and only DMARC alignment failure supports a 'spoofed From' conclusion.
Reading a DMARC aggregate report and concluding that every SPF or DKIM 'fail' result is a DMARC failure.
Aggregate reports list raw SPF and DKIM results per message plus a separate DMARC disposition. A message can show spf=fail but dmarc=pass if DKIM aligned, and candidates scan the first failing column they see.
What to do instead
Evaluate in order: did either mechanism pass and align with the From domain? Only then read the policy disposition. Practice reading a record where SPF fails on a forwarded message but DKIM survives, and state explicitly that DMARC passes on the aligned DKIM result.
Assuming a p=reject DMARC record protects every subdomain, including ones that never send mail.
The organizational domain policy applies to the From domain in the record, and subdomains are covered only through sp= or the organizational-domain fallback; candidates forget that non-sending subdomains are a prime spoofing target and that the fallback does apply but is often misread as not applying.
What to do instead
State the exact scope: record at the organizational domain with p=reject and sp=reject covers subdomains via the sp tag or fallback, but only if the record is published at the organizational domain. Then require an explicit reject record on non-sending subdomains or a wildcard DMARC, and verify with a DNS lookup rather than assumption.
Explaining DKIM as 'encrypting' the message or as validating the sender's identity, and confusing the selector lookup with the signing algorithm.
DKIM is a signature over headers and body using a private key; the public key is published at selector._domainkey. Candidates blur signing, encryption, and authorization because all three are 'security' features in the same stack.
What to do instead
Describe DKIM precisely: a domain signs selected headers plus a body hash with its private key; the verifier fetches the public key at selector._domainkey.domain and confirms integrity and domain accountability, not confidentiality or sender identity. Note that the d= tag is what must align for DMARC.
Answering a cloud email routing question by describing the on-premises connector path without identifying which hop performs filtering, which performs authentication evaluation, and where the message is journaled.
Cloud platforms chain inbound gateway, platform filtering, and mailbox delivery; candidates memorize feature names but not the sequence, so they misplace where DMARC is enforced or where a transport rule fires.
What to do instead
Build a one-line path diagram for each scenario (internet to gateway to platform to mailbox, and outbound in reverse) and label the enforcement point at each hop. For every question, first place the message on that path, then answer which component acts there.
Configuring a transport or mail-flow rule to block a sender domain and assuming it also covers messages that bypass the rule because of a connector or an allow-list entry higher in evaluation order.
Cloud mail-flow rules evaluate in priority order and can be pre-empted by connectors, directory-based edge settings, or tenant allow/block list entries. Candidates test one path and generalize.
What to do instead
State the precedence explicitly: connector and edge settings, then transport rules by priority, then tenant allow/block lists, and note that an allow entry can override a block. When answering, name the rule priority and the override that could pre-empt it, and verify with message trace.
Treating a user-reported phishing message as handled once it is deleted from the mailbox, without scoping whether other recipients received it or whether the sender infrastructure is still active.
The visible symptom is one mailbox; the incident is a campaign. Candidates respond to the report rather than the event and skip the search-and-purge and indicator pivot.
What to do instead
Run the standard sequence: preserve the original message, extract indicators (sender, return-path, URLs, attachment hashes), search all mailboxes for the same indicators, purge confirmed instances, block indicators at the gateway, and check for credential-entry or click telemetry before closing.
Judging a suspicious message by its display name or by whether the link 'looks like' the brand, instead of resolving the actual sending domain, authentication results, and final URL host.
Phishing kits copy branding and display names trivially; candidates apply visual heuristics because that is how users describe the message, and they skip header and URL analysis.
What to do instead
Analyze in a fixed order: full headers (Received chain, Return-Path, Authentication-Results, DKIM d=), then the actual URL host after redirects, then attachment type and hash. Base the verdict on the infrastructure, and record which indicator drove the classification.
Assuming TLS in transit or a cloud provider's default encryption satisfies a data-residency or regulatory requirement without checking message-level encryption, key custody, and journaling location.
Transport encryption protects the wire, not stored data, and providers vary in where content is stored and who holds keys. Candidates conflate 'encrypted in transit' with 'compliant at rest and in the right jurisdiction'.
What to do instead
Separate the controls: TLS for transit, message-level encryption (S/MIME or provider encryption) for content, and at-rest encryption with stated key custody. Then map each to the specific requirement (residency, retention, access logging) and name the control that satisfies it rather than the generic term 'encryption'.
Designing integration or access answers around a single global admin or a broad OAuth grant because it 'just works', ignoring least privilege, conditional access, and token scope.
Lab and tutorial setups use tenant-wide permissions; candidates transpose that convenience into exam answers and miss the identity-governance controls the exam tests.
What to do instead
For every integration, specify the narrowest scope or role that satisfies the function, require modern authentication with conditional access and MFA for interactive access, and state how the grant is reviewed and revoked. Name the specific role or scope rather than 'admin access'.