A recently disclosed New Zealand example highlights a DMARC problem that organisations should be checking for right now: what happens when the domain receiving your DMARC reports expires and somebody else registers it?
DMARC is widely recognised as an important control for protecting organisations against email spoofing and impersonation. New Zealand’s National Cyber Security Centre recommends organisations correctly configure SPF, DKIM and DMARC to protect their email domains.
But there is another part of DMARC that deserves considerably more attention.
The reporting destinations.
A recent investigation by SH Consulting found that Eden Park’s DMARC configuration had been sending reports to spamcontrol.co.nz, a domain that had been retired years earlier and subsequently became available for registration.
The researchers registered the domain.
The result was that DMARC reports intended for Eden Park started arriving with them.
The problem wasn’t hacking Eden Park
This is what makes the incident particularly interesting.
There was no vulnerability to exploit. No password was cracked. No firewall was bypassed.
Eden Park’s DNS record was simply telling email providers where to send its DMARC reports.
The published record included:
rua=mailto:abuse@spamcontrol.co.nz
and
ruf=mailto:abuse@spamcontrol.co.nz
The spamcontrol.co.nz domain had originally been associated with an email-filtering service operated by Fujitsu and had subsequently been retired. The domain eventually expired.
The DNS record at Eden Park, however, remained.
According to SH Consulting, once they registered the expired domain, the DMARC reports simply started arriving.
That’s a sobering lesson for any organisation using third-party email security, filtering or DMARC services.
The security control can outlive the supplier that originally implemented it.
What exactly can be exposed?
DMARC aggregate reports aren’t normally copies of people’s emails.
That doesn’t mean they are harmless.
Aggregate reports can contain information about the infrastructure sending email on behalf of an organisation, including sending IP addresses, message volumes and SPF/DKIM authentication results.
More importantly, some reporting systems include information about the recipient or destination of messages.
In the Eden Park case, SH Consulting reported receiving 12,615 DMARC report records. Analysis of the data allowed them to identify approximately 600 organisations that Eden Park exchanged email with, including sponsors, sporting organisations, contractors, government agencies and other business relationships.
That turns what many organisations might consider “just email security telemetry” into something considerably more useful to an attacker.
It can become a relationship map of the organisation.
Who does the organisation communicate with?
Which suppliers are involved?
Which government agencies are contacted?
Which partners are regularly exchanging email?
Which organisations are appearing in the mail flow?
That information can be extremely useful when constructing convincing phishing or business email compromise campaigns.
The New Zealand risk
This shouldn’t be treated as an isolated Eden Park problem.
SH Consulting says it found other New Zealand organisations with the same configuration issue during its investigation, including an organisation using a govt.nz domain. Those organisations were notified and fixed.
The underlying problem is relatively straightforward.
An organisation engages a supplier to provide an email filtering or DMARC service.
The supplier asks the organisation to add something like:
rua=mailto:dmarc@some-vendor-domain.co.nz
DMARC gets set up, the organisation pats itself on the back and says “job well done!” then everyone takes their eye off the ball and years later, the supplier changes its service.
Perhaps the contract ends.
Perhaps the product is retired.
Perhaps the supplier is acquired.
Perhaps the domain is simply allowed to expire.
The organisation’s DNS record remains unchanged.
Eventually, somebody else registers the abandoned domain.
The organisation has now unintentionally delegated its DMARC reporting data to whoever owns that domain.
And unlike a traditional security vulnerability, nothing may generate an alert when this happens.
Check your rua and ruf records
Every New Zealand organisation should review its DMARC records and specifically examine the reporting destinations.
Look up the TXT record for:
_dmarc.yourdomain.co.nz
Then examine the rua and ruf fields.
For example:
rua=mailto:dmarc@example.com
and:
ruf=mailto:forensics@example.com
Don’t just check whether the email addresses look familiar.
Check the domains.
For every reporting domain, ask:
- Is the domain still registered?
- Who owns it?
- Do we still have a relationship with the organisation that owns it?
- Is the service still being used?
- Is the mailbox still active?
- Is the domain controlled by our organisation?
- Was the domain originally associated with a supplier that no longer exists?
- Is the DNS record still required?
- When was the last time this configuration was reviewed?
If you discover a reporting address pointing to an old supplier or defunct domain, remove or replace it immediately.
Don’t forget subdomains
Organisations should also consider their subdomains.
DMARC supports separate policies for subdomains through the sp tag, and organisations can have many domains and subdomains that were created for previous projects, applications, campaigns or suppliers.
The New Zealand Government’s Secure Government Email framework recommends strong DMARC configurations, including p=reject, and specifically highlights the importance of maintaining valid DMARC configuration across email-enabled domains.
That provides a useful benchmark even for organisations outside government.
p=none is another warning sign
There is another issue worth checking while you’re there.
If your DMARC record contains:
p=none
then DMARC is essentially operating in monitoring mode.
The organisation can receive reports about authentication failures, but the policy itself isn’t telling receiving mail systems to quarantine or reject messages that fail DMARC.
The Eden Park record used p=none and sp=none. SH Consulting noted that the policy therefore wasn’t enforcing DMARC against spoofed messages.
There are legitimate reasons for starting with p=none while deploying DMARC. It allows an organisation to understand its legitimate email sources and resolve authentication problems before enforcement.
But it shouldn’t become the permanent state of the control.
The general DMARC deployment approach is to start with monitoring, analyse the results, fix legitimate sending services, and progressively move towards quarantine and ultimately reject where appropriate.
Treat DNS as part of your security estate
The bigger lesson here isn’t just “check DMARC.”
It’s manage DNS records as security controls.
A DNS record created five or ten years ago may still have security implications today.
This is particularly important when organisations have:
- Changed email providers
- Retired email filtering services
- Changed managed service providers
- Been through mergers or acquisitions
- Rebranded
- Retired business units
- Decommissioned applications
- Allowed old domains to expire
- Changed DMARC reporting providers
A security review that only checks whether a DMARC record exists isn’t enough.
You need to check what the record actually does and who it trusts.
A simple DMARC health check for New Zealand organisations
If you manage a .nz domain, put this on your security team’s checklist:
1. Find every DMARC record
Check _dmarc for your primary domains and relevant subdomains.
2. Review every rua destination
Identify every domain receiving aggregate DMARC reports.
3. Review every ruf destination
If forensic reporting is configured, identify every destination receiving those reports.
4. Validate ownership
Make sure every reporting domain is still owned by your organisation or a current, trusted provider.
5. Remove legacy suppliers
If a reporting destination belongs to a former provider, remove it.
6. Check the DMARC policy
Determine whether you are operating with p=none, quarantine or reject, and whether the current setting reflects your security requirements.
7. Put DMARC into ongoing DNS governance
Don’t treat the record as a one-off implementation task. Include it in periodic security reviews and supplier offboarding processes.
The uncomfortable question
One of the most useful questions to ask your security or infrastructure team is:
“If every domain in our DMARC reporting addresses expired tomorrow, who would receive our email security reports?”
If the answer isn’t immediately obvious, it’s probably time to review the configuration.
The Eden Park case demonstrates that an attacker doesn’t necessarily need to compromise an organisation to obtain useful information about its email infrastructure.
Sometimes they just need to register the domain the organisation forgot about.
And in an environment where phishing, business email compromise and supplier impersonation remain significant threats, handing an unknown third party a continually updated map of your organisation’s email relationships is an avoidable risk.
Check your DMARC records. Check them today.
About the Author
