DKIM is supposed to provide cryptographic proof that an email was authorized by the domain it claims to come from. But that proof depends on the key being strong enough for the evaluating gateway to accept it. When a sending domain publishes a DKIM key that is too small, some gateways silently ignore the signature entirely. The message is not marked as failing DKIM. It is marked as having no usable DKIM at all.
An attacker exploited this gap to send a targeted BEC email impersonating a known executive at a manufacturing company. The email contained no links, no attachments, and no urgency language beyond a polite request for the company's accounts receivable aging report. SPF passed. DKIM was ignored. DMARC had no policy to enforce. The only thing that caught it was behavioral analysis.
The email arrived as plain text with a short, professional message:
"Good morning [recipient]. Please share the latest aging report for inspection at your earliest convenience, ensure all balances are current and reconciled. Also, do well to include any notable variances or overdue items requiring attention."
The signature read as the name of a known executive at the recipient's company. No title, no phone number, no corporate formatting. The brevity is the point. Short, informal requests from executives are common enough that they rarely trigger suspicion, especially when the display name matches someone the recipient knows.
The request itself is a data exfiltration play. An accounts receivable aging report contains open invoice amounts, customer names, payment terms, and overdue balances. That intelligence fuels follow-up attacks: invoice fraud with accurate amounts, payment-diversion requests referencing real transactions, or vendor impersonation using actual business relationships. According to the FBI IC3 2024 report, BEC losses exceeded $2.9 billion, and reconnaissance-stage emails like this one are often the first move in a multi-step campaign.
See Your Risk: Calculate how many threats your SEG is missing
The sending domain, filterfine[.]net, published a DKIM key under the default selector. The domain signed the outbound message. In theory, DKIM should have either passed or failed.
Instead, Microsoft's evaluation returned: dkim=ignore (ignored public key size).
This result means the published DKIM key was below the minimum size threshold that the evaluating gateway considers cryptographically meaningful. Microsoft and other major receivers have progressively raised their minimum accepted key sizes, and keys below 1024 bits are increasingly treated as equivalent to unsigned messages. The domain's DKIM configuration was present but functionally useless.
The SPF record for filterfine[.]net uses a permissive ?all mechanism (neutral), and the message routed through Bluehost shared hosting (omta37.uswest2.a.cloudfilter.net), which SPF designates as an authorized sender. SPF passed, but a neutral ?all mechanism means SPF cannot produce a hard fail for any IP, authorized or not.
No DMARC record existed for filterfine[.]net. Microsoft's evaluation returned dmarc=bestguesspass, an inferred result that has no enforcement teeth. Without a published DMARC policy, there is no reject or quarantine action to trigger regardless of SPF or DKIM results.
The net result: SPF passed (meaningless with ?all), DKIM was ignored (key too small), DMARC guessed a pass (no policy published). Microsoft's antispam engine still caught it, classifying the message as CAT:PHISH with SCL:5 and routing it to the Junk folder. But the Adaptive AI analysis is what identified the real threat: exact display-name impersonation of a VIP.
IRONSCALES BEC protection identified that the display name in the From header exactly matched a known internal VIP contact. The sender name was recognized from a legitimate internal email address at the target organization, but this message originated from may@filterfine[.]net, a Bluehost-hosted domain with no relationship to the impersonated individual.
The impersonation tag "Exact Display Name Impersonation" was applied, and the Themis analysis assigned VIP Impersonation, Vendor Email Compromise, and VIP Recipient labels at 72% confidence. The message was quarantined.
The sending infrastructure tells its own story. The X-AntiAbuse headers reveal the message was sent from box2408.bluehost.com using Roundcube Webmail (version 1.6.15) via HTTP POST from IP 109.110.169.16. The X-Email-Count header shows this account had sent 31 messages. That volume suggests the attacker was working through a list of targets, not sending a single opportunistic message.
| Technique | ID | Application |
|---|---|---|
| Phishing: Spearphishing Attachment | T1566.001 | Targeted email with social-engineering content (no attachment, but direct request) |
| Impersonation | T1656 | Exact display-name match of known internal VIP |
| Remote Email Collection | T1114.002 | Request for financial documents (aging report) for intelligence gathering |
| Type | Indicator | Context |
|---|---|---|
| Sending Domain | filterfine[.]net | Bluehost-hosted domain with weak DKIM key |
| Sending Email | may@filterfine[.]net | Envelope sender, Roundcube webmail origin |
| Sending IP | 109[.]110[.]169[.]16 | HTTP POST origin for webmail submission |
| Hosting | box2408[.]bluehost[.]com | Shared hosting server |
| DKIM Result | Ignore (key size too small) | Published key below minimum threshold |
| SPF Result | Pass (neutral ?all mechanism) | Permissive SPF provides no blocking signal |
| DMARC Result | bestguesspass (no policy) | No DMARC record published |
| SCL | 5 | Microsoft spam confidence level |
| EOP Category | PHISH | Microsoft Exchange Online Protection classification |
| Email Count | 31 | Messages sent from this account (X-Email-Count header) |
This attack had no links to scan, no attachments to detonate, and no domains to block after the fact. The entire payload was a sentence asking for a document. Detection depends entirely on identity and behavioral signals.
Audit DKIM key sizes across your vendor and partner ecosystem. If a domain that sends you mail publishes a DKIM key below 1024 bits, that domain's emails are effectively unsigned from your gateway's perspective. Treat DKIM ignore results as equivalent to DKIM absent, not DKIM neutral.
Flag bestguesspass as a risk indicator. A domain with no DMARC record cannot be enforced against. Messages from domains with bestguesspass results and first-time or low-frequency sender patterns should receive elevated scrutiny, particularly when they contain financial requests.
Build display-name impersonation detection into your VIP protection policy. The From address in this attack was obviously external. But the display name matched a known internal executive exactly. Any email where the display name matches a protected identity but the sending domain does not should trigger an alert or a warning banner, regardless of authentication results.