DMARC Reject: The Policy Everyone Tests, Only 25% Enforce
TL;DR
Most New Zealand government agencies are still not ready for the October 2025 rule that requires DMARC to be set to reject (SecurityBrief, 2025). Proofpoint has described reject as a baseline safeguard rather than an optional extra, since it is the only setting that prevents fake emails from ever reaching an inbox (Proofpoint, 2025). Yet adoption is lagging, with only around 25 percent of agencies taking the step to enforce it. The majority remain in monitoring or quarantine modes, where suspicious emails are logged or diverted but not truly stopped.
This is not only a government problem. In my work with medium and large companies I have seen the same hesitation play out. DMARC is easy to configure and straightforward to monitor, but the moment enforcement begins to disrupt mail flow with partners, vendors, or clients, it is quickly rolled back. Organisations end up stuck in what feels like a safe middle ground, watching for spoofing without fully preventing it, even though this leaves them exposed to the very risks DMARC was designed to address.
The barrier, in most cases, is not the technology. It is the organisational tolerance for disruption. Moving to reject forces a company or an agency to confront the complexity of who is actually sending on its behalf, to fix misaligned systems, and to coordinate across teams that do not normally interact. Until that work is accepted as part of the cost of resilience, most will keep putting off the final step.
Left in “Monitor” Mode: A Playground for Adversaries
With DMARC stuck in “monitor” or “quarantine” mode, suspicious mail is logged but not blocked. From an attacker’s perspective, that is a gift.
In one case I reviewed, an adversary used Proofpoint’s own hosted relay to spoof emails inside the target environment. The process was simple enough that it could be replicated by anyone with basic tools.
Important note:
I am outlining the process here to illustrate risk, not to encourage misuse. Attempting this against live systems could result in your IP address being blocked or blacklisted.
How the attacker did it:
Look up the MX record: This can be done with a simple nslookup -type=mx victimdomain.co.nz or by using a public tool like MXToolbox. Either way, the relay host is revealed, often something like mx1.pphosted.com for Proofpoint customers.
Find valid email addresses: Attackers rarely guess these. They scrape them from the company website, press releases, or LinkedIn profiles. Even a simple “[firstname].[lastname]@company.co.nz” format can be confirmed with a quick search.
Craft the spoof: Pick two known addresses—for example, ceo@victimdomain.co.nz as the sender and finance@victimdomain.co.nz as the recipient.
Deliver through the relay: If the organisation has no DMARC reject policy, and Proofpoint’s rules are not tuned to block this, the spoofed message is accepted and delivered as though it came from inside the company. Here is how the basic command was replicated using examples:
Windows PowerShell Copyright (C) Microsoft Corporation. All rights reserved. PS C:\> nslookup -type=mx victimdomain.co.nz Non-authoritative answer: victimdomain.co.nz MX preference = 10, mail exchanger = mx1.pphosted.com PS C:\> Resolve-DnsName -Type MX victimdomain.co.nz Name Type TTL Section NameExchange ---- ---- --- ------- ------------ victimdomain.co.nz MX 300 Answer mx1.pphosted.com PS C:\> Send-MailMessage -From "ceo@victimdomain.co.nz" ` > -To "finance@victimdomain.co.nz" ` > -Subject "Quarterly Report" ` > -Body "See attached" ` > -SmtpServer "mx1.pphosted.com" # Message accepted by remote server # Note: Send-MailMessage is marked obsolete in newer PowerShell versions, # but is present in Windows PowerShell and still commonly used.
When I reviewed the logs, Proofpoint did capture the activity. But because the customer’s DMARC was set only to monitor, the email passed as legitimate. The SOC didn’t raise an alert because it looked like a normal internal message. That is why leaving DMARC in monitor mode is a good and necessary start, but is not enough.
Why the Government Mandated Reject
The Secure Government Email (SGE) framework was designed to lift every agency to the same baseline, not just in theory but in enforceable technical controls. It closes the long-standing gaps where domains were left in monitor mode, SPF records ended in softfail, or encryption quietly downgraded in transit. By mandating DMARC reject and related standards, the Department of Internal Affairs has effectively removed the option to delay (Digital.govt.nz, 2025).
| Control | Requirement | Purpose |
|---|---|---|
| TLS (Implicit, ≥1.2) | All mail must use TLS 1.2 or higher, with non-TLS rejected | Encrypts mail in transit, prevents downgrade attacks |
| TLS-RPT | Enable reporting for TLS failures | Visibility into delivery and encryption issues |
| SPF | Records must end in -all |
Ensures only authorised servers can send mail |
| DKIM | All outbound mail must be signed | Verifies message integrity and authenticity |
| DMARC | Policy set to p=reject; adkim=s recommended |
Blocks spoofed messages outright, enforces alignment |
| MTA-STS | Enabled and set to enforce | Prevents STARTTLS downgrade, validates destination |
| DLP | Enforce in line with NZISM and PSR | Stops classified material (above IN-CONFIDENCE) leaking |
| Non-email domains | SPF -all, blank DKIM, DMARC reject |
Prevents unused domains being spoofed |
The government’s intent does not seem to be piecemeal improvement but a wholesale uplift. Every setting listed above is designed to eliminate ambiguity, whether that is the “softfail” SPF records that attackers could abuse, the relaxed DMARC alignment that let bulk mail pass unchecked, or the non-email domains that made easy spoofing targets. By enforcing reject across the board, agencies are forced to bring their environment up to standard. That same pressure inevitably extends to vendors and partners, which means the framework does not just protect government, it raises expectations across the economy.
What Breaks When Reject is Turned On
Mail flow! (Duh, we know this)).
The real reason organisations pause at DMARC reject is not disbelief, it is that every unaligned sender gets cut off. Marketing tools, HR apps, help desk systems, they all stop working if they are not prepared. Such failures are more than pain points, they shine a light on weak links in your mail flow
This is my take on the most practical guidance I have seen and used. The Do and Don’t list below is deliberately simple, and I would encourage teams to work with their partners or vendors if feasible, whether that is Microsoft, Proofpoint, or consultants who have a track record of implementing DMARC reject. Contact me if you have different opinions or experiences, I would be glad to hear them.
Do
- Inventory every sender before you enforce reject, including third-party platforms, internal apps, and subdomains.
- Review DMARC aggregate reports and raise alignment to ~98%+ before moving from monitor to quarantine, then to reject.
- Validate SPF ends in
-alland DKIM is enabled on all outbound paths, including bulk mailers. - Phase your rollout. Start with lower-risk subdomains or a staging domain, then expand.
- Treat breakages as signals. Fix shadow SMTP relays, legacy connectors, and unregistered senders rather than rolling back.
- Lock down non-email domains with SPF
-all, blank DKIM (p=), and DMARCp=reject. - Document ownership for each sender and add ongoing checks to change control so drift does not reappear.
Don’t
- Flip to
p=rejectglobally without testing. You will block legitimate traffic and lose trust. - Ignore DMARC data. Unknown sources and misalignment hide in aggregate reports if no one reviews them.
- Assume vendors align by default. Marketing, CRM, ticketing, and payroll systems often fail alignment until configured.
- Leave subdomains or parked domains unmanaged. Attackers will target the path of least resistance.
- Rely on quarantine or monitor forever. Users release bad mail from quarantine and phishing still lands.
- Bypass with “temporary” allow rules. These become permanent and undo the control.
- Blame DMARC for outages. The control reveals broken mail flows, it does not create them.