CHFI Application, Email and Cloud Forensics Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  The receiving server rejected the email

  Why it's wrong here

  DKIM signature verification failure does not automatically imply that the receiving server rejected the email. SMTP rejection based on DKIM only occurs if a domain's DMARC policy is set to 'p=reject' and the message fails DKIM and SPF alignment; otherwise, the server may accept and quarantine it. The presence of a DKIM failure in headers indicates the message was still delivered, making this option factually incorrect.

• ✗

  The email is legitimate and was forwarded through a relay

  Why it's wrong here

  While legitimate forwarding through a relay or mailing list can break DKIM signatures due to header or body modification, the mere fact that a relay was involved does not establish the email as legitimate. A DKIM failure actually indicates that the signature cannot be cryptographically validated against the sender domain's public key, which is a hallmark of potential tampering, not authenticity. Therefore, this option misreads the evidence and incorrectly concludes legitimacy from a signature mismatch.

• ✗

  The email was sent from a compromised mail server

  Why it's wrong here

  A compromised mail server scenario would involve an attacker gaining access to the private signing key, allowing them to produce valid DKIM signatures that pass verification. In this case, DKIM is failing, meaning the signature is invalid or the domain does not match, which points to spoofing or alteration rather than a server compromise. The indicator is about signature misalignment, not about the internal state of the sending infrastructure, making this an unsupported inference.

• ✓

  The email may be spoofed or its content altered

  Why this is correct

  A DKIM failure means the message's signature does not verify against the public key published in the claimed sending domain's DNS records. This can occur when an attacker spoofs the domain and sends unsigned or incorrectly signed mail, or when the message body or selected headers were changed after the original signature was applied. Either way, the email is unreliable and may have been tampered with, directly supporting the conclusion that it is potentially spoofed or altered.

Go deeper

Related to this question