⏰ Support Available: Mon-Fri 4:00pm-6:00am | Weekends 24/7
DMARC compliance, properly
Most people arrive here for one of two reasons. Either your mail started landing in spam and somebody said the word DMARC at you, or you are partway through a cyber insurance renewal that asks whether DMARC is at enforcement and you are not certain what to put.
Different questions, same piece of work. Here is what the rules actually say, why a DMARC record on its own does not answer either question, and how to get to enforcement without stopping your own invoices.
Three acronyms, one sentence each
SPF
A list in your DNS of the servers allowed to send email using your domain name.
DKIM
A signature added to each message that proves it really came from your domain and was not altered on the way.
DMARC
A published instruction telling receiving mail servers what to do with mail claiming to be from you that fails those two checks, and asking them to report back on what they saw.
That is as much as you need to read this page. If you want the longer version there is a plain-language walkthrough in SPF, DKIM and DMARC explained for business owners, and what DMARC is and why your business needs it covers why it exists at all.
What the bulk sender rules actually require
Google and Yahoo both brought these in during February 2024 and both still enforce them. Microsoft followed for Outlook.com in May 2025. The requirements are close to identical, and the differences are in who gets caught.
Mail sent to personal Gmail accounts
- Who is caught
- Close to 5,000 messages or more to personal Gmail accounts inside any 24 hours. Google counts across your whole primary domain, so mail from a subdomain adds to the same total, and it is not limited to marketing. Once you are classified as a bulk sender, that does not expire.
- What is required
- Every sender, at any volume, needs SPF or DKIM, valid forward and reverse DNS on the sending host, TLS in transit, and a spam complaint rate under 0.3 per cent.
- Bulk senders need both SPF and DKIM, a published DMARC record, and the From address aligned with either the SPF domain or the DKIM domain.
- Marketing and subscription mail from a bulk sender needs one-click unsubscribe.
- Worth knowing
- The guidelines do not apply to mail sent to Google Workspace accounts. If you sell to businesses and almost everything you send goes to business addresses, Google's rule may genuinely never catch you.
Yahoo
Yahoo, AOL and the other mailboxes Yahoo runs
- Who is caught
- Yahoo will not say. Its own documentation defines a bulk sender as one sending a significant volume and states plainly that it will not specify a volume threshold.
- What is required
- SPF and DKIM both, with a DKIM key of at least 1024 bits.
- A valid DMARC policy of at least p=none, and DMARC has to pass. Relaxed alignment is accepted.
- Spam complaint rate under 0.3 per cent.
- A working list-unsubscribe header with one-click for marketing mail, and unsubscribes honoured within two days.
- Worth knowing
- That is worth sitting with, because it removes the option of calculating your way out. You cannot look at your send volume and conclude you are under Yahoo's line, because Yahoo has not drawn one.
Microsoft
Mail sent to Outlook.com, Hotmail and Live addresses
- Who is caught
- Over 5,000 messages a day to Outlook.com, Hotmail and Live addresses.
- What is required
- SPF, DKIM and DMARC, on the same pattern as the other two.
- Non-compliant mail has been going to the junk folder since 5 May 2025.
- Microsoft has said rejection follows, without naming a date.
- Worth knowing
- Easy to overlook in Australia, where a lot of long-standing personal addresses are hotmail.com.
Why more businesses are caught than expect to be
The number people picture is a monthly marketing list, and they compare it against 5,000 and relax. Two things make that the wrong sum. It counts all mail from the domain, so invoices, statements, booking confirmations, password resets and the newsletter add together. And it is a daily peak rather than an average, so a business that normally sends four hundred a day can cross the line on the one day a year it emails everybody, and Google's classification does not lapse afterwards.
Then there is the part nobody plans for. You do not choose when you send a lot of email. A product recall, a price change, a data breach notification or an outage update all mean writing to every customer at once, and that is exactly the day you cannot afford your mail to be filtered.
Why a DMARC record is not the same as DMARC working
This is the single most common misunderstanding, and it is easy to have, because two different questions get answered with the same check.
A DMARC record has a policy in it. Set to none, it means: watch mail claiming to be from us, tell us what you see, and deliver it either way. Set to quarantine it means put the failures in junk. Set to reject it means refuse them at the door. Only the last two do anything. At p=none a stranger can still send email as your domain and it will still be delivered, exactly as before you published the record.
The awkward bit, said plainly
p=none satisfies Google and Yahoo. Google's own documentation says the DMARC enforcement policy can be set to none, and Yahoo asks for at least p=none. So a business can be fully compliant with the bulk sender rules and still be completely spoofable.
That is the trap. Somebody checks the DNS, finds a DMARC record, ticks the deliverability box, and reasonably assumes the spoofing box is ticked too. It is not, and the two boxes are on different forms.
p=none is not a failure. It is the correct first step and skipping it is how people break their own mail. It is just not a destination, and a record that has sat at none for two years is not a project in progress, it is a project that stopped.
The Australian Signals Directorate is unambiguous about where you should end up: its guidance is that DMARC records be configured so that mail failing the checks is rejected, subdomains included. There is more on the gap between having a record and enforcing one in why p=none is not enough.
The cyber insurance questionnaire
Cyber cover in Australia is written off a proposal form, and those forms have grown a technical section. What they ask varies by insurer and by policy, so nobody can tell you your form will ask about DMARC. What is consistent is the shape of the questions: is multi-factor authentication enforced on email, is email authentication configured, are backups tested, is remote access protected.
Where DMARC appears, the wording usually goes past whether you have it. It asks whether it is at enforcement, or whether it is set to quarantine or reject. That phrasing is deliberate, and it is the reason a business with a p=none record cannot honestly tick it.
Why a hopeful yes is worse than a no
An answer on a proposal form is not paperwork. It is a statement the insurer relies on when deciding whether to cover you and at what price, and under the Insurance Contracts Act 1984 a business buying cover has a duty of disclosure. Where an answer turns out to be wrong, the insurer has remedies available to it, and those can extend to reducing what it pays or declining the claim.
The timing is what makes it bad. Nobody audits your DMARC record when you buy the policy. It gets looked at after an incident, by an assessor who is already reading your DNS history, at the precise moment the cover matters. A yes given optimistically eighteen months earlier by somebody who checked that a record existed is a very poor thing to be defending then.
This is general information, not advice on your policy. If you are unsure how a question should be answered, that is a conversation with your broker, and brokers would far rather have it before the form is signed. A no with a remediation date attached is a normal, unremarkable answer. A yes that does not hold up is not.
What it takes to answer yes truthfully
A DMARC record published on your domain with the policy set to quarantine or reject, SPF and DKIM in place and aligned so your real mail passes, and subdomains covered rather than left open. That is it. It is not a large piece of work, but it is a sequenced one, and the sequence is the next section.
If the same form also asked about multi-factor authentication, admin accounts or external sharing, those sit inside the Microsoft 365 Health Check, which covers the wider set rather than email authentication alone.
Getting to enforcement without breaking your mail
This takes weeks. Not because the changes are slow, each one is a DNS edit that takes a minute, but because the middle step is waiting and reading, and there is no way to compress it. Anyone offering to take you to reject this afternoon is offering to skip the part that stops it going wrong.
Publish a record that reports, and change nothing else
If there is no DMARC record, one goes up at p=none with an address for aggregate reports. If there is a record already, which there often is, it usually needs the reporting address added. Nothing is enforced at this point and nothing can break, which is the point of starting here.
Read the reports for a full month, not a fortnight
Aggregate reports arrive daily from the receiving providers and show every source sending as your domain, along with whether it passed. A fortnight catches the everyday senders. It misses the monthly invoicing run, the quarterly statement, and the annual notice, and those are the ones that hurt.
Identify every legitimate sender, including the forgotten ones
This is the actual work and it is the reason the timeline is weeks. Each source in the reports is either yours, a supplier sending on your behalf, or somebody spoofing you, and you have to know which before you can enforce anything. Expect at least one you had forgotten about.
Fix alignment on each one, one at a time
Add the sender to SPF, or set up DKIM signing with your domain, or both. One at a time, checking the reports after each change, so that if something moves you know what moved it.
Move to quarantine, which is the smallest real step
DMARC used to let you apply a policy to a percentage of your mail and raise it gradually. The 2026 revision of the standard removed that, so the graduated path is now the policy levels themselves: quarantine sends failures to junk, which is visible and recoverable, and reject refuses them outright, which is neither. There is also a testing mode that applies your published policy one step softer than it reads, and it is worth knowing it exists because a domain publishing reject with testing on is quarantining right now, not sitting idle.
Then reject, and keep reading the reports
Reject is the setting that actually stops somebody sending as you. It is also the setting that is unforgiving of a sender you missed, which is why it comes last. The reports keep arriving afterwards, because you will add new tools and each one is a new source.
Four to eight weeks is the honest range for a business of ten to a hundred people, and the variable is not effort, it is how many things turn out to be sending as you. Businesses that have been running a while and have picked up tools along the way sit at the longer end, which is the opposite of what people expect.
What breaks when it is rushed
Publishing p=reject before you know who sends as you does not stop attackers. It stops you. These are the six that turn up most often, and each one is somebody's mail quietly disappearing.
The accounting system that sends invoices as you
Xero, MYOB or whatever sits in that seat is sending from your domain to your customers. It usually needs its own SPF entry or its own DKIM key, and it is the single most expensive thing to get wrong, because the failure mode is that your invoices stop arriving and nobody tells you.
The booking or job management tool
Confirmations, reminders and quotes go out under your name from a platform somebody set up two years ago. Nobody thinks of it as email because it does not look like email, it looks like the software working.
The mail merge somebody in sales set up
A third-party sending tool connected to a personal login, sending from the company domain, that no one else knows about. These are the ones aggregate reports are actually for, and they turn up in almost every review.
The online store
Order confirmations, shipping notices and password resets, all from your domain, often through a platform that signs mail with its own domain by default rather than yours. That is the alignment problem in miniature.
Payroll, HR and recruitment portals
Payslip notifications and applicant emails sent on your behalf. Low volume, easy to miss in a two-week reporting window, and very noticeable to staff when they stop.
The list you use once a year
The Christmas message, the annual price rise notice, the AGM notice. It will not appear in a fortnight of reports, which is exactly why the reporting window has to cover longer than a fortnight.
None of these announce themselves. Mail rejected under DMARC does not bounce back to the person who thought they sent it, because the thing that sent it was a piece of software with nobody watching its inbox. You find out when a customer rings to ask where their invoice is, and by then it has been happening for a fortnight.
Where to start
The first thing worth knowing is where you currently stand, and that is a reading exercise rather than a change: what your SPF, DKIM and DMARC records actually say today, which of your senders pass and which do not, and what a questionnaire could truthfully be told right now.
That is the Email Security Health Check, $299 GST inclusive and fixed. It reads your domain from the outside, sets out what is missing, and gives you a written plan in order. Nothing changes in your DNS on the strength of it until you decide to.
If you would rather the whole path done for you, from first record to reject with the reports read in between, that is quoted after the check, because the price depends entirely on how many senders turn up and I would be guessing before then.
The reading part does not have to be a project either. Hamilton365 runs its own DMARC monitoring service that collects the aggregate reports, checks your records daily and tells you when a new sender appears, from $29 per domain per month GST inclusive. That is the part of this page that never actually finishes, because you will keep adding tools and each one is a new source.
Questions about DMARC compliance
Ask about your domain
Tell me the domain and what prompted this. If the answer is that you are already fine, you will get told that.
Renewal date closing in? Call 0403 401 250 or email jamie@hamilton365.com.au