The spam came from a domain nobody owned anymore

By the zmam.ai team · · updated

Summary

  • A forgotten SPF `include:` pointing at an expired domain let attackers re-register it and send fully SPF-authenticated mail as trusted brands.
  • At its peak the SubdoMailing operation sent an estimated 5 million emails a day from ~8,000 hijacked domains.
  • What an external scan would have shown: a dangling `include:` resolving to an unregistered domain, visible in public DNS, free to fix.

In February 2024, researchers at Guardio Labs noticed something that should have been impossible. Spam was arriving in inboxes wearing the credentials of some of the most trusted names on the internet — MSN, McAfee, eBay, VMware, The Economist, Cornell University, even UNICEF. And it was not faking those credentials. It was passing every check. SPF: pass. DMARC: aligned. The mail was, by every technical measure your inbox uses, genuinely authorized by the brands it claimed to come from.

The brands had no idea. They had not been hacked. No password was stolen, no server breached. The attackers had simply found the keys that these companies left in the door years ago and forgot about.

The two forgotten doors

Guardio named the operation SubdoMailing and the actor behind it ResurrecAds. At its peak the campaign was sending an estimated five million emails a day from roughly 8,000 hijacked domains and 13,000 subdomains, per Guardio’s analysis. It worked by abusing two kinds of stale DNS that almost every large organization has lying around.

The first is the dangling SPF include:. When a company signs up with an email vendor — a marketing platform, a survey tool, a ticketing system — it adds that vendor to its SPF record with an include: line, which says “mail from this vendor’s servers is allowed to use my domain.” Years later the company stops using the vendor, but nobody ever removes the include:. If that vendor’s domain then expires, an attacker can re-register it. Now the attacker controls a domain that the victim’s still-live SPF record explicitly trusts — and everything that domain authorizes, the victim authorizes too. Guardio found one victim whose SPF record, fully expanded, recursively authorized 17,826 IP addresses.

The second door is the classic dangling CNAME. A subdomain like promo.brand.com is pointed with a CNAME at some external service. The service is shut down, the CNAME is left behind, the attacker registers the now-unclaimed target, and the subdomain is theirs to send from. One subdomain in Guardio’s report had been quietly pointing at an abandoned host since 2001.

Stitch the two together and you have an email infrastructure that is, on paper, owned by Fortune 500 companies and major universities — and in practice operated by a spam syndicate routing through thousands of residential proxy IPs. Secondary reporting from BleepingComputer and SecurityWeek, summarizing Guardio, put the sending fleet at around 22,000 unique IPs.

Why your filters waved it through

This is the unsettling part. Spam filters lean heavily on authentication. A message that passes SPF and aligns with DMARC inherits the reputation of the sending domain — and the whole point of SubdoMailing was to borrow reputations that took decades to build. The mail did not need to sneak past the filters. The filters were doing exactly their job; the inputs they trusted had been quietly poisoned upstream, in DNS records the brands had stopped looking at.

There is no CVE for this. Nothing was “vulnerable” in the software sense. It is a lifecycle failure — the slow entropy of a domain’s DNS over years of mergers, vendor changes, and abandoned projects.

What the outside view would have shown

Here is what makes SubdoMailing the perfect argument for looking at your own domain from the outside: every one of these conditions was visible in public DNS, for free, before the attackers got there.

None of these checks send a single email or touch a single server. They read records the whole internet can already see. That is precisely the kind of review zmam.ai runs — and the kind of finding that, caught early, costs nothing to fix and everything to ignore.

If you want the background on how these records actually work, start with SPF, DKIM, and DMARC explained and DNS records that affect your security .

Sources