Suspicious email: what SPF, DKIM and DMARC actually establish
Interpret suspicious-email authentication: trusted results, assessed domains, alignment and relays, without mistaking a technical pass for a safe message.
Integration scope: Seculogik uses a source-agnostic architecture to ingest security alerts and events through its own data map. Wazuh and OpenSearch are the first integrations. Other named sources describe planned connector targets; their availability must be confirmed for each evaluation.
A phishing alert shows successful authentication checks. Should it be closed? Not on that observation alone. An analyst needs to know which check passed, which identity it assessed and who produced the result.
We propose an investigation method independent of the email platform: separate technical observations, message assessment and the operational decision. The deliverable is not another green indicator. It is a conclusion whose limits another analyst can verify.
1. Establish which result you can trust
Start by obtaining the original copy available within your authorised scope, including complete headers. Record the collection method, recipient and receipt time. An interface screenshot or copied text is insufficient for examining the message’s route.
The Authentication-Results header conveys authentication outcomes. Its provenance must be established: a familiar service name can be forged, and the first or last occurrence is not automatically trustworthy. Source: RFC 8601, sections 5 and 7
Ask the email team to corroborate that provenance with gateway records. Otherwise, record the uncertainty.
Keep the original in the designated investigation workspace. Do not submit the complete message to a public analyser or external assistant without authorisation: headers, attachments and content may expose information unrelated to the check you need.
2. Name the identity each mechanism assessed
The three mechanisms answer different questions:
- SPF checks the sending server’s authorisation for the assessed SMTP identity, MAIL FROM or HELO. It does not validate the person displayed in the message. Source: RFC 7208, section 2
- DKIM checks a domain-associated signature over the covered portions of a message. The signing domain can differ from the author’s domain; this is not a blanket integrity statement about every part of the message. Source: RFC 6376
- DMARC connects the From domain to an aligned authenticated identity. When a DMARC policy applies, either a successful SPF check on MAIL FROM or a valid DKIM signature is sufficient when the required alignment is satisfied. Source: RFC 9989, section 4.4
Record the exact domains in the case rather than summarising them as “verified sender”. Keep each result with its mechanism. If the tool does not expose the assessed identities or alignment, obtain the missing evidence before drawing a conclusion.
3. Return to what the message actually requests
Successful authentication can accompany malicious mail, including messages from a compromised source. It is insufficient to declare the content safe. Source: RFC 8601, section 7.2
Entirely fictional example: a request to change bank details arrives with positive authentication. The investigation must still establish whether the request matches an expected transaction and whether its supposed author confirms it. The technical result authorises neither payment nor automatic alert closure.
To verify a suspicious request, NIST recommends using known or independently obtained contact information, not details supplied in the message. Source: NIST, Phishing
We recommend keeping observations about the domain, display name, reply address and requested action separate. Links and attachments should follow the organisation’s approved analysis process; investigating them does not require opening them in the analyst’s normal working session.
4. Examine relays before interpreting failure
Forwarding can disrupt SPF; an intermediary’s changes can affect DKIM. These indirect-mail-flow issues are documented: a failure alone does not demonstrate malicious intent. Source: RFC 7960, sections 2.2 and 2.3
Our recommendation is to reconstruct the known route with the responsible teams. Identify any intermediary service and establish where the result changes. Do not turn a hypothesis about legitimate forwarding into a broad exception for a domain or gateway.
ARC carries authentication assessments between intermediaries. A valid chain establishes neither the participants’ trustworthiness nor message safety. Preserve the recipient’s DMARC result separately from any local decision based on ARC. Source: RFC 8617, section 9
Also separate the evaluation result from actual handling: inbox delivery, quarantine or rejection. Record the applied rule and its justification when those details are available. Successful delivery is not the investigation’s verdict.
5. Test conclusions using training messages
Prepare these six teaching scenarios with the email team, only in an authorised environment. The expected conclusions apply the distinctions above:
- SPF passes but is unaligned, with no valid aligned DKIM: do not infer a DMARC pass.
- SPF fails, but DKIM validates and aligns: DMARC can still pass.
- DMARC passes, but the request is unexpected: continue assessing content and context.
- A passing result has unknown provenance: seek reliable evidence; do not conclude.
- A relayed message has DMARC fail and valid ARC: retain both observations and examine the local decision.
- Evaluation encounters a temporary error: keep that state distinct; do not convert it into success or definitive failure.
For each exercise, specify the evidence to retrieve and the expected tier-1 decision beforehand. Have another analyst review the case. The aim is to test the assessment method, not to measure detection performance from a handful of messages.
6. Write a conclusion the next shift can use
Our decision record contains six items:
- Examined object: reference copy, recipient, date and collection method.
- Provenance: evaluating service and evidence supporting trust in its results.
- Results: mechanisms, identities, alignment, errors and relevant relays.
- Assessment: supporting and conflicting facts, business context and remaining unknowns.
- Decision: authorised action, scope, owner and justification.
- Verification: expected observable outcome and next check if uncertainty remains.
If an AI assistant prepares this record, we recommend requiring a precise reference for each observation and retaining unknowns. Fluent wording must not turn missing evidence into a successful check.
The completion criterion is straightforward: a colleague can retrieve the observations, understand what they establish and explain what remains to decide. Authentication then becomes properly scoped evidence, rather than a shortcut to closure.