A finance team receives a convincing invoice email from a familiar supplier. The visible sender looks correct, the attachment appears to match an open purchase order and the message asks for an immediate bank-account change.
An email authentication dashboard says the message passed, yet an endpoint later makes a connection to an unfamiliar hostname. These observations are not inconsistent: domain authentication can succeed for a compromised legitimate mailbox, and an endpoint alert does not by itself identify whether the supplier payment request was fraudulent.
A reliable investigation follows the message, the user’s actions, the destination requested by the endpoint and the business approval workflow as separate evidence paths. SPF, DKIM, DMARC, DNS filtering, endpoint detection and security-event correlation each answer a different question. In CompTIA Security+ SY0-701 email and endpoint triage, choosing the right control starts by stating what it could have observed at the relevant moment.
Read email authentication in the order the receiver evaluates it
Sender Policy Framework (SPF) publishes authorized sending systems for a domain used in the envelope sender or return path. A recipient can check whether the connecting mail system is permitted by that domain’s SPF policy. This is not proof that the text displayed in the email client’s From field identifies the same organization, and indirect forwarding can change which system connects to the recipient.
DomainKeys Identified Mail (DKIM) authenticates a signing domain and checks integrity of selected signed headers and message content. A valid signature is meaningful only for the domain and message elements actually covered by it; it is not an independent declaration that the sender intended a legitimate invoice or that a compromised account has been detected. A marketing provider may sign for one identity while the visible From address uses another.
Domain-based Message Authentication, Reporting, and Conformance (DMARC) adds identifier alignment with the visible From domain and a domain owner’s published treatment and reporting preferences. SPF or DKIM can pass technically yet fail the relevant DMARC alignment test. The DMARC specification explains the relationships among authenticated identifiers, alignment and policy. Inspect actual message headers when investigating a suspected forgery: a dashboard total cannot identify which domain passed or why one delivered message was accepted.
For the supplier invoice, ask whether the message came from the supplier’s real account, a lookalike domain or an authorized third-party sender. Check the visible From address and domain, envelope sender, DKIM signing domain, authentication results and the organization’s approved supplier-contact record. Even strong alignment is compatible with a real supplier mailbox that an attacker has taken over. Protect the payment workflow independently of the authentication outcome.
Deploy mail policy without interrupting authorized senders
Before changing a domain’s DMARC policy to quarantine or reject, inventory its legitimate sending systems: normal mailboxes, help-desk notifications, finance software, billing platforms, newsletters and any outsourced service. An SPF entry that omits an authorized platform may cause legitimate delivery failures; broad authorization can also weaken the value of SPF. DKIM signing, aligned From identities and provider-specific configuration should be evaluated together.
A staged rollout can begin with monitoring and collection of appropriate aggregate evidence, then move toward enforcement when owners can explain actual sending sources and alignment. Review privacy and retention for reports. A policy of rejecting unauthorized mail is not successful merely because spoofed mail is blocked; measure whether invoices, incident notifications and customer replies from legitimate services still reach their intended recipients.
Do not change unrelated endpoint or network rules to repair an authentication problem. If a message fails DMARC because a third-party service signs with an unaligned domain, work with that sender to establish an appropriate aligned configuration. If the message passes alignment but contains a fraudulent instruction, mail authentication has performed its limited role and business verification remains essential.
Decide what DNS and web filtering can actually observe
DNS filtering can help block a client from resolving a known malicious or disallowed hostname when its queries pass through a controlled resolver or enforcement point. Web filtering may also use domain, category or URL information depending on inspection design. Neither mechanism can categorically protect activity that never traverses it. A process using an alternate resolver, cached answer, direct IP connection or a different application path may not generate the expected DNS-filter event.
Suppose the finance user’s laptop resolves an unfamiliar invoice-validation domain and receives a blocked DNS response. That is evidence a name-resolution control acted, not evidence that no browser opened a related site previously or that an authentication token was never exposed. Compare endpoint connection records, DNS event timing, the browser’s actual URL and the user report before closing the investigation.
When a security product reports only the domain name, do not claim that it inspected the content of an encrypted web session. HTTPS visibility, certificate trust, application protocol and filtering deployment affect which details can be examined. Record the boundary rather than inventing the missing URL path or file content.
Use EDR and XDR evidence for the endpoint behavior they cover
Endpoint detection and response (EDR) may provide process, file, network and response telemetry under the installed agent and configured policies. An extended detection and response (XDR) platform may correlate signals from endpoints, identity, email, cloud and network services when those integrations exist. These are capability descriptions, not guarantees that a single product has complete visibility into every device or account.
In the invoice case, compare whether the employee opened the attachment, which process ran, whether a suspicious child process appeared, what remote hosts were contacted and whether any credentials were entered. A browser making a legitimate request may generate a connection event without a malware finding. Conversely, a stolen cloud session can continue to create risk even if endpoint isolation successfully stops further local traffic.
File-integrity monitoring answers a different question again: did a monitored file or configuration change in a way that violates the expected baseline? A detected change should be tied to an asset, authorized deployment or investigation. It is not a general substitute for email authentication, endpoint process analysis or identity sign-in history.
Correlate the investigation without turning every alert into an incident
Use a common timeline and record source confidence. At 09:10 the email gateway accepted an aligned message; at 09:14 the user opened a link; at 09:15 the endpoint recorded a DNS query; at 09:18 identity logs recorded a new login. Those are illustrative observations, not claims about a live incident. They create hypotheses that need confirmation, especially where device clocks, proxies or shared accounts affect attribution.
| Question | Useful evidence | What it does not establish |
|---|---|---|
| Did a sending domain authenticate? | SPF, DKIM and DMARC results with identifiers and alignment | That an authorized mailbox was not compromised |
| Did DNS filtering act? | Resolver request, chosen policy, response and time | That the client had no other path or cached connection |
| Did code run on the endpoint? | Process ancestry, file and network telemetry | That the finance change was legitimate or malicious |
| Was a cloud session abused? | Identity sign-ins, tokens/sessions, target application logs | That an endpoint alert alone explains all account actions |
A SIEM investigation can join these signals when normalized timestamps and source identities are reliable. Establish which logging sources are configured and their blind spots before interpreting an empty search as proof nothing occurred. Containment should follow the evidence: hold the payment, verify the supplier through a previously recorded channel, investigate the affected account and preserve the events needed for authorized response.
Test the complete control chain with a safe scenario
Use a fictional invoice and approved test sender rather than sending deceptive messages to uninformed employees. First construct one properly aligned legitimate message and one intentionally unaligned test under an owned domain. Compare results, then check that legitimate authorized senders are not rejected. Next, model a phishing destination with a safe test domain and observe where a managed resolver or browser protection would record its decision. Do not test an unapproved real malicious destination.
For a separate endpoint exercise, examine sanitized or simulated process and connection logs rather than running harmful payloads. Add a hypothetical compromised cloud account and determine which identity events or session-revocation steps the investigation would need. A defensible report separates observed evidence from test inputs and unsupported assumptions.
Finally name the control owner for each failure: mail administrators for SPF/DKIM/DMARC and vendor sender inventory; network security for resolver and filtering path; endpoint operations for sensor coverage; identity operations for account and session investigation; and finance for payment validation. The incident-response workflow should coordinate those owners rather than claiming one green dashboard settles the whole event.
The useful outcome is a business process that remains safe if any single detector misses an event. Authentication limits domain spoofing, filtering reduces reachable malicious destinations, endpoint evidence helps explain execution and identity logs track cloud access. None of those replaces independent confirmation of a new bank account or careful, evidence-led response.