⏰ Support Available: Mon-Fri 4:00pm-6:00am | Weekends 24/7
Managed DMARC, taken all the way to reject
Every mailbox provider that receives your email already sends back a daily report on who has been sending as your domain. They arrive as XML attachments that nobody reads, which is a shame, because they are the only view you get of somebody impersonating your business.
Hamilton365 collects those reports, reads them, and uses what they show to move your policy up until failing mail is refused outright. Monitoring is the first week of that, not the destination.
Already a customer? Sign in to your dashboard
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 enough to read this page. The longer version is in SPF, DKIM and DMARC explained for business owners.
Publishing a record is easy. Reading what comes back is not.
Putting a DMARC record in your DNS is a ten minute job. The part that defeats people is everything after it.
Aggregate reports arrive daily, one from each provider that received your mail, as compressed XML. A single day for a small business might be six files. Each lists sending IP addresses, message counts, and whether SPF and DKIM passed and aligned. There is no summary, no history, and nothing to tell you which entries are your accounting system and which are somebody in another country sending invoices with your name on them.
So most small businesses do one of two things. They point the reporting address at a mailbox nobody opens, or they leave the reporting tag off entirely and publish a record that reports to no one. Either way the record exists, the box is ticked, and the thing DMARC was built to show you is not being looked at by anybody.
Getting to reject is the product
Plenty of tools will show you a dashboard. Several will do it free. What almost none of them will do is get your domain to the end, and the end is the only part that stops anything: until the policy says reject, every receiving mail server has been told to notice somebody impersonating you and deliver it anyway.
Two things make that possible here, and they are both worth understanding before you buy.
Failing mail is not one number
Most tools decide whether you can enforce by looking at one figure: the percentage of your mail that passes. That reads sensibly and is backwards, because it treats every failure the same way when failures point in opposite directions.
Your failing mail splits three ways. Some of it is somebody impersonating you, which is the reason to enforce rather than a reason to wait. Some of it is your own mail that is genuinely misconfigured, and that is the only thing that should ever hold a rollout up. The rest is mail nobody has looked at yet, which is neither, and folding it into either one is how a tool gives confident advice about something it has not examined.
A domain sitting at 86% aligned pass, where every single failing message is one host in another country sending invoices with your name on them, is ready to enforce today. A tool gating on pass rate says hold, fix your authentication first. Following that advice keeps the domain unprotected in order to keep delivering the forged mail. This is not hypothetical; it is what the readiness analysis was built after finding.
So each sending source gets judged as approved, not approved, or not yet reviewed, and readiness is worked out from the mail that would actually break rather than from the mail that fails. When something does block the rollout, you get told which sender and how much of your mail it carries, not a percentage to stare at.
One DNS record, edited once, and never again
Rollouts die at a predictable place, and it is not the technical part. It is the fortnight where the change is right, agreed and sitting in somebody's queue, because the person who can edit the DNS is a web developer who has three other jobs on.
You can avoid all of it. Instead of publishing a DMARC record, you publish a single pointer at Hamilton365, once, while you are already in your DNS. From that moment every policy change is mine to make, and each step up happens the day the evidence supports it rather than three weeks later.
It is optional, and plenty of customers keep their own record and take the exact line to publish at each step instead. Both get to the same place. One of them takes longer for reasons that have nothing to do with email.
Hosted or not, the jump to reject will not go out unless the readiness analysis agrees, and it will not go out without your domain name typed back to confirm it. Making enforcement one click is only an improvement if a one click mistake cannot refuse your own invoices. The one exception is a domain you do not send from at all, where there is nothing to break and waiting protects nobody.
Not sure where your domain sits today? The free DMARC check reads your live records and tells you in a few seconds. It takes no sign up and records nothing.
What I watch for you
Every source sending as you
One view per domain: how much of your mail passes, which systems are sending it, and whether each one is passing on SPF, DKIM or neither. The senders worth knowing about are the ones that were not there last month, and those are the hardest thing to spot in raw reports.
Daily DNS checks that read the whole record
SPF, DKIM and DMARC are validated every day, and validated properly: whether your SPF is over the lookup limit that makes it fail outright, whether a DKIM key has been revoked or left at half strength, whether a subdomain quietly sits at a weaker policy than the domain above it. BIMI is reported too, without being pushed, because it needs enforcement first and the certificate cost makes it a later question for most.
Alerts when something changes
A record disappearing or being weakened, a sending source appearing that was not there yesterday, or authentication failures climbing. DNS records get edited by web developers and marketing platforms far more often than anyone expects, and usually without telling you.
Who is actually behind an address
A report tells you that 40.107.11.23 is failing. That is useless on its own, so sending addresses are resolved back to the service that owns them and you get "Microsoft 365" instead. A name is only shown when the address confirms it in both directions, because reverse DNS is published by whoever controls the address and anyone can point theirs at Microsoft.
And who announces it, when there is no name
The hosts worth worrying about usually publish no reverse DNS at all, which is exactly where naming fails. The network that announces an address is not the sender's to choose, so the answer becomes "claims to be Microsoft, announced by a hosting company in Romania". That sentence is the finding, and it is the one a bare IP address could never give you.
A report you can forward
A PDF covering the domain's posture, its sending sources and where it stands on enforcement. Written for the reader who will not log into a dashboard, which is usually an insurer or whoever sent you a security questionnaire. It states plainly what DMARC data can and cannot evidence, because somebody may make a decision on it.
A record of what was sent
Browsable history rather than a rolling two week window, plus a timeline of every change to your published records. When mail broke on a Tuesday, the useful question is what changed on the Monday, and that is a question most tools throw the answer to away.
Built to the current standard, which is newer than most tools
DMARC changed in May 2026. RFC 9989 replaced the original 2015 specification, and it is the first version of DMARC published as a standards-track standard rather than an informational document. A lot of what is on the market is still built to the old one. This is built to the new one.
The practical difference is how a policy gets rolled out. The old specification let you apply your policy to a percentage of your mail and raise it over time. That has been removed from the standard. In its place is a testing mode, and it is worth understanding properly, because the name invites exactly the wrong assumption.
Switching testing on applies the policy one step softer than the one you published. Reject behaves as quarantine. Quarantine behaves as none. So a domain publishing reject with testing switched on is having its failing mail put in junk folders right now. That is a genuinely useful place to stand for a few weeks, because junk is recoverable and rejection is not, but it is a real setting with real effects.
Anyone who describes it to you as reporting only has misread the specification, and the difference between those two readings is whether you think your mail is being touched. Your dashboard shows which setting you are actually on.
RFC 9989 was published in May 2026 and obsoletes RFC 7489. The three policy values, none, quarantine and reject, are unchanged from the original.
How getting started works
Four steps, and only one of them needs anything from you.
I set up your domain
Nothing changes on your side and nothing is published yet. This is the part where the reporting address is created and the domain is added.
One DNS record goes up
It starts in monitor-only mode and sends the reports to Hamilton365. Nothing is enforced at this point, so nothing can break. I can publish it if you have access to give, or hand you the exact line to pass to whoever looks after your DNS. This is also the moment to decide whether to point that record at Hamilton365 and be done with DNS entirely, or keep it in your own hands and take a new line at each step.
Reports start arriving, usually within a day or two
The dashboard fills in as providers report back. The first fortnight is mostly discovery, and there is nearly always at least one sender nobody remembered. The monthly and annual ones take longer to appear, which is the real reason this is not a two week exercise.
We step the policy up
Quarantine first, then reject, guided by what the reports show rather than by a calendar. A business with a handful of senders is often a few weeks. One that has picked up tools over ten years takes longer, and the length is set by how many things turn out to be sending as you, not by how hard the changes are.
What this stops, and what it does not
At enforcement, DMARC stops somebody sending email that claims to come from your exact domain. That is a real and common attack and it is worth closing properly.
It does not stop three other things, and any tool that suggests otherwise is overselling itself.
A lookalike domain
Somebody registers a near miss of your name and sends from that instead. Their DMARC passes, because it is genuinely their domain. Yours is not involved.
Display-name spoofing
The sender's name reads as yours, but the address underneath is a free webmail account. Nothing about your DNS has any say in what a stranger types into the name field.
An account that has actually been broken into
That mail is properly authenticated, because it really is from you. DMARC will pass it, correctly, and it is the single most expensive kind of email fraud in Australia.
Monitoring closes the first and gives you early warning of some of the second. If you are dealing with the third right now, start at business email compromise response instead and come back to this afterwards. Hardening comes after containment, not instead of it.
What the service actually receives
Worth being clear about, particularly if you are in a regulated profession and somebody will eventually ask you.
What is in a report
- Sending IP addresses
- Message counts per source
- The domains involved
- SPF and DKIM pass or fail results
What is not
- Subject lines
- Message bodies
- Attachments
- Recipient addresses
Hamilton365 never sees the contents of your email through this service, because that information is not in the reports and never has been. If you are a law firm, accounting practice, conveyancer or real estate agency working through what your wider obligations look like, the Privacy Act readiness assessment covers the tenant rather than the DNS.
Where it is kept, and for how long
Both the database and the archive of raw reports were created in Cloudflare's Oceania region, so the data is at rest in the region rather than merely served from it. Being straight about the limit of that: Cloudflare sells a contractual restriction that legally pins data to one jurisdiction for the EU and for US government work, and does not sell one for Australia. So this is a deliberate configuration rather than a contractual guarantee, and anybody who tells you otherwise about a service built on a global platform is worth a second question.
Parsed report data is kept for 13 months, so any month can be compared against the same month a year earlier. The raw report emails are kept for 90 days. Nothing is kept indefinitely and there is no setting that would allow it.
There is no analytics, no error reporting and no session recording in the dashboard. The only other company involved is the one that delivers alert email. That list is published, along with the retention periods actually being applied, at the trust page, which needs no sign in because the person who usually wants it is an adviser rather than a customer.
Signing in
Every account needs a password and a code from an authenticator app. There is no option to turn that off, for you or for me, because an account holding a view of your mail flow is worth protecting properly and optional multi-factor authentication is the kind that never gets switched on.
You can choose to trust a browser for 30 days so you are not typing a code on every visit.
What it costs
Per domain, GST inclusive, and all three figures are on this page so you are never guessing what the next step up costs. The difference between the first two is not how much you care about being spoofed, it is how many places your mail leaves from.
Monitor
You read the dashboard. I set it up and keep it running.
$29
per domain per month, GST inclusive
or $319 a year, which is eleven months for twelve
Best for
Sole traders and small teams whose mail leaves from one or two places, typically Microsoft 365 plus something like Xero. Few sources means few surprises, and the dashboard is usually enough on its own.
- Full dashboard access
- Daily SPF, DKIM and DMARC validation
- Alerts on record changes and new senders
- Complete report history, not a rolling window
- The DNS record published for you at the start
Monitor and Manage
I read the reports and make the changes. You get told what happened.
$99
per domain per month, GST inclusive
three month minimum, then month to month
Best for
Businesses sending campaigns, newsletters, statements or booking confirmations, where mail leaves from several platforms and the list keeps growing. More sources means more that can change without anyone noticing, and that is the part that takes a person.
- Everything in Monitor
- I review the reports and investigate new sending sources
- DNS changes made for you as senders come and go
- Guided progression to quarantine and then reject
- Kept at enforcement as you add new tools
Additional domains
For the ones you own and do not send from.
$12
per domain per month, GST inclusive
added to either tier
Best for
Anyone who owns more than one domain, which is most businesses once they count. These are the quickest wins on the whole list: with no mail to break, they can go to reject the same afternoon rather than after weeks of watching.
- The .com you bought alongside the .com.au
- The old trading name nobody has retired
- The one registered so a competitor could not have it
- Locked down properly: reject, no sender authorised, signing keys revoked
- Watched in reverse, so a message that passes raises the alarm
When the record itself is the problem
SPF record repair, $595 per domainGST inclusive, one off
There is a limit built into SPF that almost nobody meets until it bites. Deciding whether a message is really from you, a receiving mail server will make ten DNS lookups and no more. Past ten it stops and treats the whole record as faulty, and faulty does not mean no answer given. It means every message you send fails that check.
Records cross the line by ordinary accumulation. Every service you have ever signed up to adds an entry, each entry can pull in more entries behind it, and none of it shows from the outside: a record can read as two short lines and still need seventeen lookups. The free SPF and DMARC checker counts them and shows you where every one goes, including the ones hidden inside somebody else's record.
Everything else on this page is quoted after a look at your senders, because the price depends on how many turn up. This one is the exception. The lookup count can be read from public DNS in a few seconds, so the size of the job is known before it starts and the price can be fixed.
- Every entry resolved and priced, so you can see where the lookups go
- A rebuilt record that sits inside the limit and still updates itself when your providers change their addresses
- Published, then verified against what receivers actually see
- A written before and after, in plain terms, for whoever asks
What it does not cover. If the cause sits inside a provider's own record, I cannot make them change it. I will tell you which provider, and give you the wording to send them.
No flattening. The usual fix is to copy a provider's addresses into your own record. Those addresses sit behind a name precisely so the provider can change them without telling you, and once they are copied somebody has to keep copying them forever. When that stops, your mail starts failing quietly and it is nobody's job to notice. I fix the structure instead and leave the record able to look after itself.
Included at no charge with six months of Monitor and Manage, which is $594 over the same period.
Getting an existing domain to enforcement is quoted separately
If your domain has been running for years and has picked up senders along the way, the work of finding all of them and fixing alignment on each one is a project rather than a subscription. It is quoted after the $299 Email Security Health Check, because the price depends entirely on how many senders turn up and any number before then would be a guess.
A domain starting from nothing usually does not need that. It goes straight onto monitoring and moves up from there.
Questions about DMARC monitoring
Get set up
Tell me your domain and I will read its DNS records before I reply, so the first thing you get back says something about your situation rather than mine.
Already a customer? Sign in to your dashboard
Questions first? Call 0403 401 250 or email [email protected]