Identifying Malicious DKIM Spoofing Attempts Against Your Brand

Detecting malicious DKIM spoofing attacks requires a methodical approach to analyzing email authentication headers, inspecting public cryptographic keys, and monitoring your domain's sending infrastructure. When a bad actor attempts to impersonate your domain, they often fail to replicate valid cryptographic signatures, leaving behind distinct footprints in the message transport layer. By mastering these diagnostic techniques, you can identify unauthorized senders, protect your brand reputation, and safeguard your recipients from phishing.

To quickly verify the structural integrity of your cryptographic signatures and spot configuration gaps, you can use the DKim Checker to inspect your public records and test live selector deployments.

Understanding the Anatomy of DKIM Spoofing

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to outgoing messages, linking a domain name to an email. Mail receivers use this signature to verify that the email was genuinely sent by the domain owner and that the content was not altered in transit.

Spoofing occurs when an attacker crafts an email claiming to originate from your domain (such as billing@example.com) without possessing your private key. Because they lack your private key, they cannot generate a valid signature matching your public key published in the DNS. Instead, attackers typically rely on three common methods:

1. Unsigned Messages: Sending emails entirely without a DKIM signature, hoping the receiving server does not enforce strict authentication policies.
2. Invalid Signatures: Applying a malformed signature or using a rogue domain's selector, which causes verification checks to fail outright.
3. Display Name Deception: Forging the From header display name while using a completely different, attacker-controlled domain in the envelope sender and DKIM signature (technically a cousin to spoofing, often confused with direct DKIM bypass).

Step-by-Step Guide to Detect Malicious DKIM Spoofing

Investigating a suspected spoofing attempt involves pulling raw internet headers, validating DNS records, and tracing the routing path of the offending message.

Step 1: Extract and Inspect Raw Email Headers

Ask your recipient or check your quarantine mailbox to obtain the complete, unmodified internet headers of the suspicious email. Look specifically for the Authentication-Results header, which is injected by the receiving mail transfer agent (MTA).

A genuine email from example.com signed with selector s2023 will typically display a pass result:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s2023 header.b=AbCdEfGh;
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass (p=REJECT sp=QUARANTINE dis=NONE)

A spoofed email will show a failure or indicate that no signature was present:

Authentication-Results: mx.google.com;
       dkim=fail header.s=s2023 header.d=example.com;
       spf=fail smtp.mailfrom=attacker.net;
       dmarc=fail (p=REJECT)

Step 2: Query Public DNS for DKIM Records

Once you identify the selector used or attempted in the message headers, query your DNS to verify the published public key. You can use command-line utilities like dig or nslookup from your terminal.

Run the following dig command to check the TXT record for selector s2023:

dig TXT s2023._domainkey.example.com

Sample output of a valid public key:

;; ANSWER SECTION:
s2023._domainkey.example.com. 3600 IN TXT    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0..." 

If the query returns NXDOMAIN (Non-Existent Domain) for the selector used in an incoming message, you have caught an attacker using a nonexistent selector to trick poorly configured mail servers.

Step 3: Analyze the DKIM-Signature Header Tag Fields

Examine the DKIM-Signature header inside the raw email payload. Pay close attention to these key tags:

Step 4: Trace the Routing Path

Review the Received: headers from bottom to top (chronological order) to see where the email actually originated. Cross-reference the source IP address with your authorized outbound mail servers (such as Microsoft 365, Google Workspace, or your marketing automation platform).

If the Received: IP address falls outside your known network ranges—for instance, originating from an unknown residential IP or hosting provider in subnet 192.0.2.0/24—and the DKIM signature failed or was missing, you are witnessing an active spoofing campaign.

Advanced Verification Using PowerShell and OpenSSL

If you need to programmatically analyze raw email files (.eml), you can leverage PowerShell or OpenSSL utilities to inspect message integrity.

To inspect email headers quickly in PowerShell, load the file and select header properties:

$email = Get-Content -Raw "C:\path\to\suspicious_email.eml"
$email -split "`r`n`r`n" | Select-Object -First 1

To verify certificate and key parameters if you manage your own MTA keys directly, use openssl to check private key validity before publication:

openssl rsa -in private.key -check -noout

Common Mistakes When Investigating Spoofing

• Confusing SPF with DKIM Failures: SPF relies on the envelope sender domain and source IP address, whereas DKIM relies on cryptographic signatures embedded in the message headers. An attacker can spoof the From header while passing SPF if they abuse a legitimate third-party bulk mailing service. Always analyze DMARC alignment, which binds both mechanisms.
• Ignoring Subdomains: Attackers frequently target unprotected subdomains (e.g., mail.example.com or staging.example.com) that lack strict DMARC or DKIM policies. Ensure you audit all active subdomains.
• Failing to Rotate Compromised Keys: If you discover a legitimate-looking signature that actually originated from an old, leaked third-party API key, simply blocking IPs will not stop the abuse. You must immediately revoke the old selector in your DNS and generate a new key pair.

DKIM Spoofing Prevention Checklist

• Publish strong 2048-bit RSA DKIM records for all active selectors.
• Implement a strict key rotation schedule every 6 to 12 months.
• Configure DMARC with a policy of p=reject or p=quarantine to automatically handle failed DKIM and SPF checks.
• Monitor daily DMARC XML aggregate reports to spot unauthorized IP addresses attempting to sign mail with your domain.
• Restrict access to internal DNS management consoles using multi-factor authentication.