Most of the campaigns we cover pass DMARC by routing around it entirely, borrowing a compromised mailbox, an OAuth token, or a reputable ESP’s sending pool. Email security vendor IRONSCALES documented something structurally different: a phishing email against a US school district that passed SPF, DKIM, and DMARC for adobe.com because Adobe’s own infrastructure genuinely sent it. No spoofing, no lookalike domain, no borrowed reputation. Just a legitimate product feature, pointed at a target.
A Real Adobe Feature, Aimed by an Attacker
Adobe Acrobat lets any account holder share a document and trigger an automated notification to whatever address they type in. An attacker used that feature exactly as designed. They uploaded a file named EDITABLERollandReadPhonicsMathFactsTargetedInstruction-1, a name built to read as a legitimate K-12 curriculum resource, and shared it with staff across a school district. Adobe’s system sent the resulting notification from [email protected], routed through the Amazon SES infrastructure Adobe is authorized to send from, and signed with Adobe’s own DKIM key. Every technical check a receiving mail server runs came back clean, because every one of those checks was answering the question it was built to answer: did adobe.com authorize this message. It had.
Every Link Also Pointed at Adobe
The email did not carry a suspicious external URL either. The primary call-to-action and the supporting links all routed through postoffice.adobe.com/po-server/link/redirect, with the actual destination encoded inside an HS512-signed JWT in the URL’s target parameter. A gateway checking link reputation saw Adobe’s own redirect domain and had no static indicator to flag, because the malicious destination was hidden inside an encoded token rather than exposed as plaintext. Between a genuine sender identity and a genuine-looking redirect host, the message had nothing left for a signature-based or authentication-based control to catch.
What Actually Caught It
IRONSCALES flagged the message on behavioral and contextual signals instead: this was a first-time sender to these recipients, the document name matched the target’s professional role with a precision that read as engineered rather than incidental, and the language patterns in the notification were consistent with social engineering rather than Adobe’s typical automated copy. Community threat data added the final piece, showing the same lure already quarantined at other organizations. Combined, those signals produced a phishing classification at 78 percent confidence. Four mailboxes across the district received the same message; all four were mitigated, and no credentials were harvested.
What This Means for Your Program
A clean SPF, DKIM, and DMARC pass tells you who authorized the message, not whether that sender’s own platform was used against you. Adobe did not fail here. Its authentication was accurate. The gap sits one layer up, in what a legitimate account holder is allowed to do with a legitimate feature.
Any service that lets an account holder trigger a notification to an arbitrary address is a delivery channel an attacker can rent for free. Document-sharing tools, e-signature platforms, calendar invites, and collaboration notifications all fall into this category, and all of them will authenticate cleanly because the platform itself is the sender of record.
Behavioral detection is not a luxury layer on top of authentication. On messages like this one, it is the only layer that has a chance. A first-time-sender flag, a too-precise document name, and cross-tenant pattern matching did the work that SPF, DKIM, and DMARC structurally could not do.
DMARC aggregate reports will not surface this pattern, because there is nothing to surface. The message was authorized, correctly, by the domain it claims to represent. This is a detection and awareness problem sitting downstream of your own domain’s authentication posture, not a gap in it.
The Takeaway
DMARC answers one question well: is this message authorized by the domain it claims to be from. Here, the honest answer was yes, and the message was still a credential-theft attempt built to look like a curriculum file a school employee would open without a second thought. As more everyday business tools add share-and-notify features, expect more of this pattern: attackers who stop trying to beat authentication and start renting it instead, one legitimate feature at a time.
DMARC tells you whether mail claiming to be your domain was actually authorized to send. It cannot tell you when someone abuses a trusted platform’s own legitimate features to reach your people, which is exactly why visibility into your own authenticated mail flows still matters. Excello Mail gives you a clear, continuous view of everything sending as your domain, so you know your own authentication posture is solid even while threats like this one keep evolving elsewhere. Sign up for free to Excello Mail and get that visibility in place.