The email body read like routine insurance correspondence. The danger was in the single link at the bottom, and in how thoroughly it had been constructed to appear unexceptional.
A mid-sized organization in a commercial sector received an email framed as claims coordination. The sender was an address at a long-established adjusting firm, a domain registered in 2007 with a clean history. The firm appears to have had its environment compromised; the sending domain is a victim. The body discussed a letter of representation, a claims investigation, and referenced claim details by identifier. The signature block listed a name, title, phone, and a Phoenix-area office: standard corporate correspondence format.
The message contained one external CTA: a link to accelaclaims[.]com.
accelaclaims[.]com was registered on November 3, 2023. The registrant is listed as "Contact Privacy Inc. Customer 0169186878," a privacy-shielding service operated by Tucows subsidiary Hover. The registrar is Tucows. Name servers are Cloudflare. The domain is approximately 20 months old, has no publicly identifiable operator, and is fronted by Cloudflare's CDN edge.
The incident link scanner flagged the URL as malicious and recommended a block verdict. When the automated crawler attempted to retrieve the page content, it encountered a Cloudflare challenge interstitial (a 403 response rather than page content). That interstitial is the mechanism: credential harvesting pages hosted behind Cloudflare can pass automated reputation checks that only verify HTTP status and header presence, because the interstitial produces a technically reachable response without exposing the landing form itself.
This is MITRE ATT&CK T1598.003, phishing for information via a spearphishing link, combined with infrastructure choices designed to resist analysis. T1566.001 covers the email delivery vector. T1656 (impersonation) applies to the use of the established claims firm's identity in the From address and signature.
The body analyzed as low-risk by content classification tools: no credential-collection request, no urgent money-transfer instruction, no password prompt. The impersonation technique here is more subtle. Claims correspondence naturally involves parties exchanging information, reviewing documents, and following external links to portals. A recipient primed by the professional claims context is likely to click a "portal link" without questioning it.
The PDF attachment, described as a letter of representation, scanned clean. No embedded scripts, no AcroForm fields with active functions, no external URI annotations. The attachment was not the delivery mechanism; the link was.
See Your Risk: Calculate how many threats your SEG is missing
The relay chain included smtp.us1.defend.egress.com (IP 18.246.145.203), an Egress Defend outbound security gateway. At the Egress hop, the intermediate X-MS-Exchange-Authentication-Results recorded an SPF softfail: the gateway's IP was not in the sending domain's SPF record, and intermediate DMARC evaluation reflected that misalignment.
This is expected. Egress Defend, like other outbound gateway relays, changes the envelope-sender IP. Unless the sending domain's SPF record explicitly authorizes Egress's IP range, downstream evaluation of that specific hop will softfail. ARC sealing by the Egress infrastructure and downstream validation by Microsoft's protection stack resolved the chain: the final delivered Authentication-Results showed DKIM pass and SPF pass for the Microsoft-originated IPv6 hop.
The intermediate softfail did not reflect spoofing. But it does create a monitoring challenge: defenders who flag all SPF softfails for review will encounter this pattern frequently with Egress-relayed mail, potentially conditioning them to dismiss softfails from that relay range as routine noise.
URL rewriting and link-wrapping services legitimately exist to add click tracking and security inspection layers. The risk pattern here is the inverse: a domain purpose-built to function as a phishing landing, using Cloudflare to defeat automated content inspection and privacy WHOIS to defeat operator identification.
The incident record flagged the sender as high-risk despite authentication ultimately passing. IRONSCALES' Adaptive AI evaluated the combination of first-time external sender, a body with plausible professional framing, and a single external link resolving to a recently-registered, privacy-shielded, Cloudflare-gated domain. Authentication passing tells you the envelope was not forged. It tells you nothing about whether the destination of the one link in the message is safe to visit.
Three signals distinguished this message from legitimate claims correspondence: the domain age (under two years for a site handling sensitive insurance transactions), the privacy-shielded registrant (no legitimate insurance portal hides its operator), and the automated malicious verdict on the URL itself. Any one of those would warrant a hold; all three together made the classification clear.
| Type | Indicator | Context |
|---|---|---|
| Malicious domain | accelaclaims[.]com | Registered 2023-11-03; registrant: Contact Privacy Inc.; Cloudflare-fronted; flagged malicious; landing content not retrieved (Cloudflare interstitial) |
| Relay | smtp.us1.defend[.]egress[.]com (18.246.145.203) | Legitimate Egress Defend outbound gateway; causes SPF softfail at intermediate hop; expected behavior |
| Sender domain | Long-established insurance adjusting domain (name withheld; victim) | Registered 2007; DKIM pass; SPF pass; DMARC pass in final ARC-authenticated result; appears compromised |
| Attachment | LOR-2026050006.pdf | Scanned clean; no embedded scripts or active form fields; not the delivery mechanism |
| Attack | What happened |
|---|---|
| The Phishing Link Lived on a Domain That Didn't Exist Nine Hours Earlier | A compromised university student account sent a phishing email that passed SPF, DKIM, and DMARC. |
| The Health Spending Account Alert That Rode a Benefits Administrator's Own Infrastructure | An Anthem-branded spending account notification routed through a legitimate benefits administrator's redirect infrastructure. |
| How ARC Re-Signing and an IP Allow-List Turned Three Authentication Failures Into SCL -1 | A phishing email claiming to be a OneDrive share from an outlook.com address originated from a county government mail server. |
| SafeLinks Wrapped the Phishing URL With the Recipient's Name on It | Microsoft SafeLinks rewrote a phishing URL and embedded the recipient's email address into the redirect chain. |
| Seven Days Old, Port 8443: The Throwaway Domain That Safe Links Couldn't Stop | A compromised university email account impersonated a known contact. |