⏰ Support Available: Mon-Fri 4:00pm-6:00am | Weekends 24/7
Type your domain. The checker reads your live SPF, DKIM and DMARC records and tells you, in plain English, what a receiving mail server is currently instructed to do with mail pretending to be from you.
No account, no email address, and the domain you check is not recorded anywhere.
It runs the same DNS lookups the paid service runs every night, against the same code, so the free answer is not a cut-down version of the customer answer. It resolves your SPF record and walks the include tree to count lookups against the limit, probes the common DKIM selector names, reads your DMARC policy, and checks the two transport security records.
Then it grades the domain on one thing only, which is the DMARC policy. SPF and DKIM decide whether an individual message authenticates. Only the policy decides what a receiver does when it does not, so a domain with immaculate SPF and DKIM and no DMARC record is wide open, and any score that averaged the three would hand it a respectable mark.
Most Australian small business domains that have had any attention at all land on the third one and stay there.
p=rejectMail that fails authentication and claims to be from this domain is refused outright. This is the finished state, and it is where a domain should end up.
p=quarantineFailing mail is delivered to junk rather than refused. A sensible place to stand for a few weeks on the way to reject, and a poor place to stop, because junk folders get read.
p=noneReceivers are asked to report and to take no action. Anyone can send mail appearing to come from this domain and have it delivered. If somebody is reading the reports this is the correct first step. If nobody is, the domain has the appearance of DMARC without the protection.
no valid recordThere is no DMARC record, or the one published cannot be read. Receiving mail servers have been given no instruction at all, so they fall back to their own judgement about mail claiming to be from this domain.
A DMARC record is a single line of text published at the name _dmarc in front of your domain. It is a list of tags separated by semicolons, and a very common one looks like this:
v=DMARC1; p=none; rua=mailto:reports@yourbusiness.com.auOnly two of those tags are required, and only one of them decides whether anything is protected.
| Tag | What it does | Status |
|---|---|---|
v | Version. Always DMARC1, and always the first tag. A record that does not start with it is ignored completely. | Required |
p | The policy for your domain, and the only tag that decides whether you are protected. One of none, quarantine or reject. | Required |
rua | Where the daily aggregate reports are sent. Leave it out and receivers are told not to generate reports for you at all, so monitoring mode monitors nothing. | The one most often missing |
sp | A different policy for subdomains. Omit it and subdomains inherit p, which is usually what you want. | Optional |
np | A policy for subdomains that do not exist. Useful, because a forger will happily invent one. | Optional |
adkim | How exactly the DKIM signature has to match your domain. r is relaxed and the default, s is strict. | Optional |
aspf | The same alignment choice for SPF. r is relaxed and the default, s is strict. | Optional |
ruf | Where individual failure reports go. Few receivers send them and they can carry message content, so most domains leave it out. | Rarely used |
ri | How often you want aggregate reports, in seconds. The default is 86400, which is daily, and almost nobody changes it. | Optional |
t | Testing. It applies your policy one level below what you published, so reject behaves as quarantine and quarantine behaves as none. It is not a dry run. | Read the effect, not the name |
pct | Removed from the standard by RFC 9989 in May 2026. If your record still carries it, it is doing nothing. Step the policy itself instead. | Gone |
The two that matter to a business owner are p and rua. The first decides whether a forged message gets delivered. The second decides whether you ever find out.
Almost none of these are anybody's fault. Email authentication is three separate systems that have to agree, each one added at a different time by a different person, and nothing tells you when one of them stops matching the others.
No DMARC record at all
Receivers have no instruction from you, so each one falls back on its own judgement about mail claiming to be yours. You also get no reports, so nothing tells you it is happening.
A policy of none with no reporting address
The most common result by a distance. The record looks like protection to anyone who glances at it, asks receivers to do nothing, and generates no reports for you to act on.
More than one SPF record
Two SPF records is a permanent error, not a merge. Receivers are entitled to fail every message you send. It usually happens when a new sending platform is added without folding its include into the existing line.
SPF needing more than ten DNS lookups
The limit is ten and it counts every include your record walks through, not just the ones you typed. Go over and SPF fails for all of your mail, whichever server sent it.
A reporting address on somebody else's domain with no authorisation record
If your reports go to a different domain, that domain has to publish a record agreeing to receive them. Without it the reports are silently never sent, and the dashboard you are paying for stays empty.
A testing tag on an enforced policy
A domain publishing reject with testing turned on is quarantining, not rejecting. It reads as finished and is not, which is the worst of both.
No DKIM signature found on the usual selector names
Not conclusive on its own, because a selector can be named anything. It is a strong hint that outbound mail is relying on SPF alone, which forwarding breaks.
The check reads what your records instruct receivers to do. It cannot tell you whether your own mail would survive that instruction, and that is the harder half of the problem by a wide margin.
If you moved this domain to reject tomorrow, would anything of yours stop arriving? Answering that means knowing every system that sends as you, which includes the accounting package, the booking tool, the mailing list, the CRM, the alarm monitoring company and whatever a previous web developer set up in 2019. A DNS lookup cannot see any of them. Only the aggregate reports can, and those take weeks to build a full picture, because the monthly and quarterly senders only appear when they send.
That gap is the reason domains sit at monitoring for years. Publishing the record is a ten minute job that anybody can do. Being confident enough to enforce it is the part that needs somebody watching the reports, and it is the whole of what Hamilton365 sells here.
Getting there is what the monitoring service does. Reports come to Hamilton365 rather than to a mailbox nobody opens, I read them, and the policy steps up as the evidence supports it rather than on a calendar. From $29 per domain per month, GST inclusive.
Want to run the checker again on another domain? Open the checker. Already a customer? Your dashboard is on the same site.
SPF, DKIM and DMARC explained
The three records in plain language, written for a business owner rather than an administrator.
DMARC in Australia, what is required
Whether any of this is actually mandatory here, who asks for it, and the two places the government guidance now sits behind the standard.
The Google and Yahoo sender rules
What the bulk sender requirements ask for, and whether they apply to the volume you send.
Email Security Health Check, $299
A one-off reading of the three records with the fixes written out, if you would rather do the work yourself.
Over the SPF lookup limit, $595
If the check says your record needs more than ten DNS lookups, every message you send is failing SPF. That one has a fixed price, because it can be scoped before it starts.
Business email compromise response
If mail is going out of a real account right now, start here instead. Containment comes before hardening.