During an email forensics investigation, an analyst examines headers and sees `Received: from mail.evil.com (192.168.1.100) by mail.victim.com` followed by `DKIM-Signature: v=1; a=rsa-sha256; d=evil.com; s=selector; bh=...; h=...; b=...`. The email claims to be from support@paypal.com. Which finding is the strongest indicator of spoofing?
A valid DKIM signature verified under the domain 'evil.com' while the From header claims 'paypal.com' is a definitive spoofing indicator. The 'd=' tag in the DKIM signature identifies which domain's private key signed the message, and Paypal's private key is cryptographically inaccessible to an attacker. Under DMARC alignment, the signing domain must match the From domain (or be an organizational parent), so this mismatch proves the message was not authorized by Paypal and is a direct sign of forgery, much stronger than SMTP or SPF observations.
Why this answer
The DKIM signature domain (d=evil.com) does not match the claimed sender domain (paypal.com). DKIM uses a digital signature verified against the public key published in the DNS of the signing domain. Since the signature is from evil.com, the email cannot be authenticated as originating from paypal.com, making this the strongest indicator of spoofing.
Exam trap
EC-Council CHFI often tests the distinction between authentication mechanisms (SPF, DKIM, DMARC) and the specific meaning of DKIM's 'd=' tag, trapping candidates who think any missing authentication header or a private IP alone is the strongest spoofing indicator.
How to eliminate wrong answers
Option A is wrong because SMTP is the standard protocol for email transmission and does not itself indicate spoofing; almost all emails are received via SMTP. Option B is wrong because the absence of an SPF record in the header does not directly prove spoofing—SPF may not be published or checked, and the header shown does not include an SPF result. Option C is wrong because the IP 192.168.1.100 is a private RFC 1918 address, which is non-routable on the public internet; its presence in a Received header often indicates internal relay or header manipulation, but it is not as definitive as the DKIM domain mismatch.