Between June 1 and August 4, email security vendor INKY, now part of Kaseya, tracked a phishing campaign that ran in waves, mostly stopping on weekends, and landed 26,589 messages in 5,527 organizations. The largest single day came on June 3, when 2,432 messages reached 1,149 organizations at once. Every message followed the same template: a fake voicemail notification carrying an SVG attachment. What makes this campaign worth studying is not just the file-type trick inside it. It is that these messages failed SPF, DKIM, and DMARC at the Microsoft 365 perimeter, exactly as they should have, and were still delivered to the inbox anyway.
An Image File That Was Never an Image
SVG files are meant to be simple vector graphics, but browsers render them natively, including any HTML or JavaScript embedded inside. The attackers built a minimal graphic shell around obfuscated script that reconstructed its own strings at runtime and used deferred execution to make static inspection difficult. To get past attachment-type filters that key on file type, they declared the SVG’s MIME type as text/plain instead of image/svg+xml. A scanner checking the stated type saw an innocuous text file. The victim who opened it saw a browser tab quietly assemble a credential-harvesting page in front of them, built entirely in local script rather than fetched from a flagged URL. There was no malicious link in the message for a gateway to reputation-check at delivery time, because the page did not exist anywhere until the script built it.
Targeting Everyone, Precisely
The campaign shows little evidence of picking targets carefully. The median organization received two messages, and 32 percent received just one. What it did do with precision was personalize the lure text: 99.5 percent of messages worked the recipient’s own email address into the voicemail notification, and 95 percent spoofed the recipient’s own domain as the sender. A message that appears to come from inside your own organization, referencing your own address, reads as more credible than one from an outside domain, regardless of how many other companies got the identical template that same week.
DMARC Worked. Delivery Happened Anyway.
This is where the campaign stops looking like most of the ones we cover. Ordinarily the interesting failure is that DMARC never had a chance to evaluate anything, because the attack routed around identity entirely. Here, DMARC did its job. The spoofed messages had no legitimate authorization from the domains they claimed to be, so SPF, DKIM, and DMARC all failed at Microsoft’s perimeter, correctly and as designed.
The messages still reached inboxes because of how they were sent. The operators relayed them through SparkPost, a legitimate email service provider used by a huge number of real businesses for real mail. SparkPost’s sending infrastructure carries a strong reputation with mailbox providers, built up over years of mostly legitimate traffic passing through its IP ranges. Microsoft’s spam filtering treats a failed DMARC check as one signal among several feeding a Spam Confidence Level score, not as an automatic instruction to reject, unless the domain’s own policy and the receiving system’s configuration force that outcome. Against a sending platform with SparkPost’s standing, a failed authentication check was not enough to override it. INKY flagged every single message with a “Danger” verdict, and its phishing-content detection caught 100 percent of them. Seventy-five percent still carried a Microsoft SCL of 0 or 1, the range Microsoft treats as not spam.
What This Means for Your Program
A DMARC fail is a verdict, not automatically a rejection. Whether that verdict actually blocks delivery depends on how the receiving mail system weighs it against everything else it knows, including the reputation of the infrastructure the message traveled through. Publishing p=reject on your own domain is what forces receivers to treat your authentication failures as final, rather than as one input among many.
Watch your DMARC aggregate reports for ESP traffic you did not authorize. If your domain is being spoofed through a reputable platform like SparkPost, Mailgun, or SendGrid, your reports are one of the few places that pattern shows up before a customer or employee reports the email itself.
Do not let a trusted platform’s reputation stand in for a scan of what it is actually carrying. The same infrastructure that delivers your own marketing and transactional mail is available to anyone else with an account, and mailbox providers cannot always tell the difference at the moment a message arrives.
Flag file-type mismatches on attachments, not just file extensions. An SVG declared as text/plain is a specific, checkable inconsistency between what a file claims to be and what it actually is, and it is exactly the kind of signal a static extension check misses.
The Takeaway
Most of the campaigns we cover succeed by staying entirely outside what DMARC evaluates. This one is different: DMARC ran, DMARC failed the message, and the message got delivered regardless, because the infrastructure carrying it had earned enough trust elsewhere to outweigh that failure. A DNS record that says p=reject is a request. Whether a receiving system honors it as an instruction or treats it as a suggestion depends on everything else that message brings with it, and a legitimate platform’s reputation is apparently still enough to buy a failed authentication check a seat in the inbox.
DMARC aggregate reports are where you would first see your domain used as the spoofed identity in a campaign like this one, long before it becomes a support ticket or a wire transfer. Excello Mail turns those reports into a clear, continuous view of every source sending as you, authorized or not, so you can tell the difference between your own mail and someone else riding a trusted platform’s reputation into your recipients’ inboxes. Sign up for free to Excello Mail and put that visibility in place.