Phishing That Passes DMARC: Real Dell and Staples Order Emails Carry Callback Scams
Attackers put fake support numbers into real Dell and Staples order confirmations, and the retailers' own systems sent them with authentication intact.
AegisAI Threat IntelligenceAegisAI Threat Watch · Callback phishing
Phishing That Passes DMARC: Real Dell and Staples Order Emails Carry Callback Scams
Attackers put fake support numbers into real Dell and Staples order confirmations, and the retailers' own systems sent them with authentication intact.
Analysis based on research reported by Help Net Security, 22 Oct 2026.
Phishing can pass SPF, DKIM and DMARC when a legitimate platform sends it: attackers type a lure into a form field, and the platform's own mail system delivers it. Research published on 21 October 2026 documents this pattern across more than 25 legitimate platforms over the past year, including two campaigns of roughly 1,400 messages sent through genuine Staples and Dell order confirmations.
No account was compromised and no domain was spoofed. The retailers' own order systems generated each message; the attackers supplied only the text that ended up in the shipping and billing fields, which was a fake support phone number.
Sources: Help Net Security; GBHackers for the order details.
Key judgments
- The weak point is content, not identity. Every message in the order campaigns was a real retailer email; only a few user-controlled fields carried the attacker's text.
- Callback lures sidestep link analysis. The order emails asked the recipient to phone a number, so there was no malicious URL or attachment to score.
- The pattern is not limited to retail. The same reporting covers sign-up mail that echoes a lure typed into a name or company field, and bounce reports that carry a lure inside the returned message.
- Sender authentication cannot close this gap by design. SPF, DKIM and DMARC confirm who sent a message, not whether a platform should have rendered a phone number in a shipping address.
Why do phishing emails pass DMARC and still reach the inbox?
Because DMARC checks identity, not intent. It confirms that a message came from servers allowed to send for the domain in the From line and that SPF or DKIM align with it (RFC 9989). It says nothing about what the sending platform was told to put inside the message.
The usual explanations are a compromised mailbox, a lookalike domain or a domain left at p=none. This research adds a fourth that needs none of them: a legitimate platform, working as designed, renders attacker text into its own notification and sends it with its own authentication intact (Cyber Security News).
| Check | A pass proves | A pass does not prove |
|---|---|---|
| SPF | The sending server is authorized for the envelope domain | That the message content is safe |
| DKIM | The signing domain sent the message and it was not altered in transit | That every field in it was written by the domain owner |
| DMARC | SPF or DKIM aligns with the visible From domain | That the request inside the message is legitimate |
Real order confirmations carried a fake support number
The order lures arrived as genuine purchase confirmations. The attackers placed an order, put their text into the shipping and billing fields, and let the retailer's own system send the confirmation to the victim.
How the order lure works
- The attacker places or starts an order with the victim's email address as the customer contact.
- Instead of an address, the Ship To and Bill To fields get "Confirmed Order", a phone number and, in the Dell case, "Call Our Sales Team".
- The retailer's order system builds the confirmation, signs it and sends it from its own domain.
- The recipient sees a purchase they never made and calls the number to cancel it.
The Staples message came from orders.staples[.]com, Staples' own order domain, and showed an Apple iPad purchase with order number 9939818875. The Dell message came from Dell's order system at order.dell[.]com and described a $736.09 purchase of Microsoft Project Standard 2024 under Purchase ID 2009829958247 (GBHackers). Both passed authentication because the retailers' own infrastructure sent them.
The goal is a phone call, not a click. An unexpected order confirmation with a number to call is a known callback pattern that moves the victim to a live operator who pushes for payment or remote access (York University Information Security).
Sign-up mail and bounce reports carry the same kind of lure
The same trust failure appears wherever a platform copies user input into its own mail. The reporting describes two further routes beyond order confirmations.
Sign-up forms that echo a lure
List bombing normally floods a victim's inbox with sign-up confirmations to bury or distract. In a subset of cases, attackers instead type a lure into a name, company or title field on a registration or profile form that does not validate input. The platform then repeats that text in its own welcome email, with its reputation and authentication intact (CyberPress).
Bounce reports with a lure inside
A delivery status notification, or bounce, is generated when a message cannot be delivered and can return the original message or part of it (RFC 3464). One observed bounce carried a WeTransfer-themed file-sharing lure in that returned content. A bounce like this can reach a victim through backscatter, where the attacker forges the victim's address as the envelope sender, or through a failure triggered on purpose.
The sender is real. The lure is not. Authentication can only vouch for the first.
AegisAI Threat IntelligenceWhy do email gateways miss phishing sent through legitimate platforms?
Gateways that lean on sender reputation, authentication results and lookalike-domain checks see nothing wrong, because the outer message is real. The hostile part sits in personalization fields, transaction details or nested content inside a bounce, not in the sender or the template (GBHackers).
The order lures also carry no link and no attachment. A control built to score URLs and files has nothing to score; the only signal is that a support number sits where a street address belongs.
How AegisAI protects against it
Aegis does not classify infrastructure. It classifies intent. A lure with no attacker-owned infrastructure still has to ask the recipient to do something on the attacker's behalf, and that request is what gets classified, independent of how clean the destination URL is.
More on how that works: inbound email security. Related: the new world of AI spearphishing.
What the reporting does not tell us
Attribution. No threat actor has been named, and it is not known whether one operator ran all three routes.
Scale. The only volume published is the combined figure for the two order campaigns. There are no counts for sign-up or bounce abuse, and no callback or loss figures.
Platforms. More than 25 platforms were abused, but only Staples, Dell and WeTransfer are named publicly.
MITRE ATT&CK mapping
| ID | Name | Use in this campaign |
|---|---|---|
T1566.003 | Phishing: Spearphishing via Service | Lures are delivered by legitimate retail, registration and mail platforms rather than attacker mail servers. |
T1566.004 | Phishing: Spearphishing Voice | The order confirmations push the victim to call an attacker-controlled number. |
Mapping by AegisAI; the original research does not assign technique IDs.
Recommendations for defenders
- Inspect the rendered message, not only the sender. Include personalization fields, transaction details and nested MIME parts in analysis, so a trusted template does not excuse its contents.
- Parse bounce reports. Extract the returned message from delivery status notifications and run the same phishing, URL and attachment checks on it as on any inbound mail.
- Flag content that does not fit the workflow. A phone number, URL or urgent instruction in a shipping, billing or name field should raise a transactional email's risk, not pass on the sender's reputation.
- Validate user input on owned platforms. Organizations that send their own order or sign-up mail should reject phone numbers, links, markup and line breaks in fields that never need them, both when storing values and when rendering templates.
- Brief staff on callback lures. Unexpected order confirmations should be checked through the vendor's known site or account, never through a number printed in the email.
FAQ
Why do phishing emails pass DMARC and still reach the inbox?
DMARC confirms that a message came from servers allowed to send for its domain; it does not judge the content. When a real retailer or SaaS platform sends a notification that contains an attacker's text, every authentication check passes because the platform genuinely sent it.
Why do email gateways miss phishing sent through legitimate platforms?
The sender, domain and template are all genuine, so reputation and authentication checks see a trusted message. The lure sits in a field such as a shipping address, or inside a bounce report, and in the order campaigns there was no link or attachment to analyze.
How did the fake Dell and Staples order emails work?
Attackers put "Confirmed Order" and a support phone number into the shipping and billing fields of real Dell and Staples orders, so the retailers' own systems emailed a confirmation for a purchase the recipient never made. The two campaigns totaled roughly 1,400 messages and aimed to get the victim to call.
Can a bounce or delivery failure notice carry a phishing lure?
Yes. A bounce can include the original message, and one observed bounce carried a WeTransfer-themed file-sharing lure. It can reach you through backscatter from a forged envelope sender or through a delivery failure triggered on purpose.
References
- Help Net Security (22 Oct 2026). Attackers abuse legitimate platforms to deliver phishing emails that pass authentication checks. helpnetsecurity.com
- GBHackers (22 Oct 2026). Scammers Exploit Dell and Staples Order Emails to Bypass Traditional Phishing Detection. gbhackers.com
- Cyber Security News (22 Oct 2026). Hackers Are Using Real Dell and Staples Emails to Make Their Scams Look Legitimate. cybersecuritynews.com
- CyberPress (22 Oct 2026). Report on list bombing and bounce abuse across trusted platforms. cyberpress.org
- York University Information Security (16 Sep 2026). Unexpected Order Confirmation? It Could be a Phishing Scam. yorku.ca
- IETF (2003). RFC 3464: An Extensible Message Format for Delivery Status Notifications. rfc-editor.org
- IETF (May 2026). RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC). rfc-editor.org
- MITRE ATT&CK. T1566.003 Spearphishing via Service; T1566.004 Spearphishing Voice. attack.mitre.org
Related posts
More from the AegisAI blog.