Where this stands: Within a day of our LinkedIn post going live on August 20, 2026, Eden Park removed spamcontrol.co.nz from its DMARC record without notifying us. We had been given an Eden Park IT manager as a contact a few months earlier, and on August 24, after the post had passed 90,000 impressions, this contact replied for the first time. We offered to either hand over the roughly one year of aggregate reports we held or delete them. Eden Park asked us to delete them, which we did on August 26. The domain is now out of their DNS.
The original owner turned out to be Fujitsu, which had run spamcontrol.co.nz as a New Zealand email-filtering service and retired it in June 2021, but the reference had remained in Eden Park's DNS. We still hold the domain and have offered to transfer it back to Fujitsu. iTnews covered the case here.
What the record looked like
The DMARC record for edenpark.co.nz was:
v=DMARC1; p=none; sp=none; rua=mailto:abuse@spamcontrol.co.nz, mailto:dmarc_agg@vali.email; ruf=mailto:abuse@spamcontrol.co.nz; rf=afrf; pct=100; ri=86400;
p=none and sp=none indicate there is no DMARC enforcement. A message can fail DMARC as @edenpark.co.nz and the published policy still won’t ask the receiver to quarantine or reject it. Whatever filtering happens after that is the receiver's own.
rua= is where aggregate reports go. Every day, Google, Microsoft, Yahoo and other providers send a summary of every message they have received claiming to be from edenpark.co.nz, sending IPs, volumes, and information on whether SPF and DKIM passed. One of the two addresses pointed at spamcontrol.co.nz.
ruf= is where forensic reports go. These carry message-level detail for failures. The only address in that tag had the domain spamcontrol.co.nz. The remaining tags are defaults.
What spamcontrol.co.nz used to be
The domain’s certificate transparency logs show quarantine, smtp and smtp2 subdomains, which suggests a hosted email filtering service. The Wayback Machine has nine snapshots of a live site starting May 22, 2010 and ending August 10, 2018.
We cannot be sure how long Eden Park's record had pointed at a dead domain. The registry history for a .co.nz domain is much harder to trace than a .com domain. What we do know is that the last archived capture is from August 2018, and when we looked in September 2025, the domain was unregistered and available to anyone with a registrar account and a few dollars.
What we found once we owned the domain
Once we had access to the domain, we could see that there was nothing to break into. Eden Park's own DNS was instructing the world to send the reports to whoever held spamcontrol.co.nz, so once we owned it, we started receiving those reports. We only accepted mail to the report address, as everything else sent to the domain was rejected at SMTP.
No forensic reports arrived during the period we held the domain; the major providers do not send them.
Over the reporting window shown in the dashboard below, the domain received 12,615 report records for edenpark.co.nz. Compliance ran at 96.28% aligned, with DKIM passing on 96.3% of traffic and SPF passing on 85.4% of traffic. That gap is typical of a domain whose mail is carried by hosted platforms: DKIM does the work and SPF fails wherever the envelope domain belongs to the vendor rather than to Eden Park.
The per-IP view shows a weekly rhythm. The four busiest sources are UK-hosted IPv6 addresses, each peaking around 100 messages a day, with a smaller US-hosted source underneath. The aggregate volume is modest, peaking around 600 messages a day. This is typical of a working business domain for a venue that deals with a lot of outside organizations.
With p=none and sp=none, the record asks receivers to do nothing. The 0.22% of traffic falling under "policy enforced" represents spoofed messages that a few receivers either quarantined or rejected on their own and then reported.
How aggregate reports turn into a partner directory
Aggregate reports are designed to tell a domain owner who is sending emails out as them. On their own, the reports don't say who the domain emails. The recipient side comes from envelope_to, a field that some reporters populate and some don't (Microsoft's Enterprise Outlook reports include it whereas Google's do not).
In the records table below, every row with google.com as the report origin shows a dash in the envelope-to column, while the rows from Enterprise Outlook and the multi-origin rows carry counts. The largest sending source shows 928 distinct envelope-to values across 383 source IPs.
By deduplicating envelope-to values across the reporting period, we were able to compile a list of roughly 600 organizations that Eden Park exchanges mail with: sponsors, sports associations, event and catering companies, construction contractors, traffic management firms, government agencies, and celebrity and talent agents.
Any one of those entries means little on its own. However, considering all 600 together, as they are updated daily, essentially forms a map of who Eden Park does business with: who handles construction, who runs event traffic control, which caterer is current, how often the venue deals with government, and who owns sales and marketing. That is a list an attacker would otherwise have to build by hand. With p=none on the domain, spoofed @edenpark.co.nz emails can be sent to any one of these business contacts, with nothing in the record stopping such spoofing.
We didn't act on any of the data beyond confirming the scope of the exposure.
Disclosure
We first reported this to Eden Park's published security and IT contacts in October 2025. Over the following months, we tried leadership mailboxes, LinkedIn outreach to IT and security staff, and personal contacts at a New Zealand MSP, who ended up putting it in front of an Eden Park IT manager. On August 7, 2026, we reported it to the NCSC, New Zealand's national cybersecurity center, which immediately acknowledged the report. The domain came up for renewal that month, so we renewed it, because letting our registration expire would hand the same visibility to whoever registered it next.
We published our findings on LinkedIn on August 20, the record was changed on August 21, and Eden Park replied to us for the first time on August 24.
During this process, we found other New Zealand organizations experiencing the same problem, including one on a govt.nz domain. Those were reported and fixed.
Nobody we spoke with at Eden Park appeared to own the DNS record. Whoever wrote it was most likely the vendor, and the vendor was gone.
Who owned spamcontrol.co.nz
We can’t confirm this through the registry data, but the public evidence is consistent: The subdomain history matches a hosted filtering and quarantine service, and publicly indexed business-directory listings show several Fujitsu New Zealand employees with @spamcontrol.co.nz addresses. This suggests that the service was run by or for Fujitsu NZ, and that Eden Park's DMARC record was written while Eden Park was a customer of it. At some point, the service was retired, the domain lapsed, and the record stayed.
If you ran this service or know who did, we would like to transfer the domain to you. There is currently no mail flowing to it other than the last of the report feeds, and we have no use for it beyond keeping it out of the wrong hands.
The same failure, three times this year
Eden Park is the third organization we've written about in 2026 with an expired domain in a DMARC reporting address, with the other two being:
- doverpmi.com: a lapsed corporate domain still receiving DMARC reports and live mail for two operating brands.
- gca-emailauth.org: the collection address in published DMARC guidance; this was expired, but the guidance was still live and 86 domains were still reporting to it.
This failure turns up constantly. DMARC gets set up once, usually by a vendor, and then nobody reads the record again. The vendor changes, the domain lapses, and the reports keep flowing to whoever picks it up. We find these errors because we scan DNS for this specific issue.
Check your own domain
Look up the TXT record at _dmarc.example.com. Take every domain in the rua= and ruf= addresses. Confirm each one is registered, owned by you or by a vendor you currently pay, and has a working mailbox behind it. While you're there, look at the policy. If it still says p=none, the reports are telling you about spoofing that the record is doing nothing to stop.
If you have more than a handful of domains, dmarc.cc will check the reporting addresses in bulk for free.
SH Consulting audits DMARC records and reporting destinations for clients every week. If you want yours checked, book a call.
Alex Shakhov is the founder of SH Consulting, an email security and deliverability consultancy. SH Consulting monitors DMARC for 1,300+ domains across 900+ companies.
