Publish the right records in DNS, and the ability of anyone on the internet to send mail that appears to come from your exact domain disappears. Not is reduced, not is flagged — disappears, at every major receiver, permanently, with no per-user licence attached to it. DMARC at enforcement is one of the few controls in security that is genuinely a one-time build with an ongoing maintenance tail rather than a subscription. The catch is that most organisations do the first 80 per cent, publish a monitoring-only policy, and stop there — which delivers reporting and nothing else.
This is a walkthrough of what the three moving parts actually do, what enforcement changes, what it explicitly does not cover, and the specific places Australian SMEs get stuck.
What the three parts actually check
Email authentication is three separate mechanisms that people talk about as one thing. They check different fields and fail for different reasons.
| Mechanism | What it publishes | What it proves |
|---|---|---|
| SPF | A TXT record listing the IP addresses and services allowed to send for your domain | The connecting server was authorised to send for the domain in the envelope sender (the `Return-Path`), not the address the recipient sees |
| DKIM | A public key in DNS at `selector._domainkey.yourdomain.com.au` | The message carries a valid cryptographic signature from the domain named in the signature's `d=` tag, and key headers were not altered in transit |
| DMARC | A TXT record at `_dmarc.yourdomain.com.au` | That the domain SPF or DKIM verified **matches the domain in the `From:` header the human actually sees**, and tells receivers what to do when it does not |
The third row is the whole point and it is the part that gets skipped. SPF and DKIM on their own authenticate domains the recipient never looks at. A phishing message can pass SPF perfectly — because the attacker's own sending domain has a valid SPF record — while displaying accounts@yourcompany.com.au in the From line. DMARC is the rule that says those two must be the same organisation, and that a mismatch is a failure with consequences.
This is called alignment. DMARC offers relaxed alignment, where the organisational domain must match but subdomains may differ, and strict alignment, where the domains must be identical. Relaxed is the sensible default for almost everyone.
The policy ladder, and why p=none is not a destination
A DMARC record carries a policy tag. There are three values.
p=none tells receivers to do nothing differently and send you aggregate reports. It is a diagnostic mode. It stops no spoofing whatsoever. A domain sitting on p=none is, from an attacker's perspective, an unprotected domain that happens to generate paperwork.
p=quarantine tells receivers to deliver failing mail to junk. It is a reasonable holding position while you chase down the last few legitimate senders, and it does block the majority of consumer-grade impersonation, but junk folders get read.
p=reject tells receivers to refuse the message at the SMTP conversation. This is enforcement. Once you are here, a message with your exact domain in the From header that cannot prove alignment does not land anywhere at Gmail, Outlook, Yahoo, or any receiver honouring DMARC. That is the win.
There is also a pct= tag that applies the policy to a percentage of failing mail, which is genuinely useful for a staged rollout, and an sp= tag that sets policy for subdomains independently. Set sp=reject on parked and non-sending domains and subdomains — attackers reach for mail.yourcompany.com.au and yourcompany.net.au precisely because nobody thinks to configure them.
The large mailbox providers have pushed this along. Google and Yahoo began requiring bulk senders to publish a DMARC record from February 2024, and Microsoft introduced comparable requirements for high-volume senders into its consumer Outlook domains during 2025. Those rules mandate the existence of a policy, not enforcement, which is a large part of why so many domains now sit at p=none.
What enforcement does not do
Being clear about this matters, because organisations that reach p=reject sometimes treat email fraud as solved and stop funding the controls that catch the rest.
Lookalike domains are untouched. DMARC governs your domain. It has nothing to say about yourcompany-au.com, your-company.com.au, or a homoglyph substitution that reads identically at a glance. An attacker who registers a near-miss domain can publish perfect SPF, DKIM and DMARC on it and sail through.
Display-name fraud is untouched. A message from a free Gmail account with the display name set to your finance manager's full name passes every authentication check, because it is authentically from that Gmail account. Most mobile mail clients show the display name and hide the address entirely.
A compromised mailbox is untouched. If an attacker has valid credentials and session tokens for a real account in your tenant, their mail is your mail. It is signed, aligned and authenticated. This is the mechanism behind most serious business email compromise: no spoofing occurs at all.
Inbound protection is untouched. Publishing DMARC protects recipients from mail claiming to be you. Whether your own tenant honours other people's DMARC policies on inbound mail is a separate configuration in Microsoft 365 or your mail gateway, and it is worth confirming rather than assuming.
So the honest framing is this: DMARC enforcement removes an entire attack technique cheaply and permanently, and the techniques that remain need different controls — impersonation and lookalike-domain detection in your mail security stack, and a payment verification process that does not rely on email at all. Getting the sequencing and the surrounding controls right across a Microsoft 365 estate is the sort of work our cyber security engineering team handles alongside conditional access and mailbox auditing, because these controls only make sense as a set.
The five failure modes that keep domains stuck
Senders nobody remembers
The blocker is almost never SPF syntax. It is discovering that Xero, MYOB, Mailchimp, DocuSign, a recruitment platform, a marketing agency, a Salesforce instance, a printer scan-to-email relay and someone's personal SendGrid account all send mail using your domain. Aggregate reports surface these as IP addresses and volumes, and each one has to be traced to a business owner, authorised or shut off, and configured for alignment. Turning on enforcement without completing this exercise breaks invoicing.
The SPF ten-lookup limit
SPF permits a maximum of ten DNS lookups during evaluation. Each include: for a third-party service consumes at least one, and several consume more internally. Exceed it and the record returns a permanent error — which, at enforcement, means every message relying on SPF fails. Organisations hit this limit faster than they expect, and the fix involves flattening or restructuring the record rather than appending another include.
DKIM signing left on defaults
Microsoft 365 signs outbound mail by default with a key belonging to your onmicrosoft.com tenant domain. That signature is valid and it does not align with your custom domain, so it contributes nothing to DMARC. Custom-domain DKIM has to be explicitly enabled with its CNAME records published. Google Workspace similarly requires a key to be generated and published per domain. Third-party platforms each need their own signing configured, and many make it optional and off by default.
Forwarding and mailing lists
SPF breaks when a message is forwarded, because the forwarding server's IP is not in your record. DKIM usually survives forwarding but breaks when a list server modifies the subject line or appends a footer. This is why DMARC passes if either mechanism aligns, and it is why DKIM is the more durable of the two. Expect a residual band of legitimate failures in reports from forwarded mail — the judgement call is distinguishing that noise from a real sender you have missed.
Nobody reads the reports
Aggregate reports arrive as gzipped XML from dozens of receivers daily. Without a platform to parse and aggregate them, they are unusable, and the project stalls at exactly the point where the remaining work is identifying the last few per cent of legitimate senders. Report processing tooling is inexpensive relative to almost anything else in a security budget, and it is what converts a monitoring policy into an enforcement decision you can defend.
Pair it with the controls that catch the rest
Enforcement should trigger two other pieces of work. First, impersonation protection tuned to your actual executives and finance staff, so lookalike domains and display-name matches are caught inbound. Second, a payment verification rule with no email in the loop: any change to bank details or any payment over an agreed threshold is confirmed by voice call to a number already on file, and the rule applies to the managing director the same as everyone else. That second control is free and it is the one that actually stops the loss.
Where to start
Look up your current position before anything else. Query the TXT record at _dmarc. on your primary domain and read the policy tag. If there is no record, you have no reporting and no protection. If the tag says p=none, you have reporting only. If it says quarantine or reject, check whether a pct= value is quietly limiting it to a fraction of traffic, and check your parked domains and subdomains, which are usually the ones left open.
If you would rather not run the sender discovery yourself, we will inventory every system sending as your domains, rebuild SPF within the lookup limit, enable aligned DKIM across Microsoft 365 and each third-party platform, and take you to p=reject on a staged plan with reporting in place throughout — and tell you upfront which of your senders will need remediation work and which domains can go straight to enforcement. Ask us for a scope and a fixed number, including a plain answer on whether your current setup is already doing the job.