⏰ Support Available: Mon-Fri 4:00pm-6:00am | Weekends 24/7

Free · no sign up · nothing stored

Can somebody send email as your business?

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.

What the check looks at

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.

The four answers you can get

Most Australian small business domains that have had any attention at all land on the third one and stay there.

Protected

p=reject

Mail 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.

Partial

p=quarantine

Failing 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.

Monitoring

p=none

Receivers 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.

Unprotected

no valid record

There 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.

How to read a DMARC record

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.au

Only two of those tags are required, and only one of them decides whether anything is protected.

The tags a DMARC record can carry, what each one does, and which are required
TagWhat it doesStatus
vVersion. Always DMARC1, and always the first tag. A record that does not start with it is ignored completely.Required
pThe policy for your domain, and the only tag that decides whether you are protected. One of none, quarantine or reject.Required
ruaWhere 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
spA different policy for subdomains. Omit it and subdomains inherit p, which is usually what you want.Optional
npA policy for subdomains that do not exist. Useful, because a forger will happily invent one.Optional
adkimHow exactly the DKIM signature has to match your domain. r is relaxed and the default, s is strict.Optional
aspfThe same alignment choice for SPF. r is relaxed and the default, s is strict.Optional
rufWhere individual failure reports go. Few receivers send them and they can carry message content, so most domains leave it out.Rarely used
riHow often you want aggregate reports, in seconds. The default is 86400, which is daily, and almost nobody changes it.Optional
tTesting. 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
pctRemoved 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.

What the checker finds most often

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.

What one lookup cannot tell you

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.

The question the checker cannot answer

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.

Questions about checking a DMARC record

If the answer was not reject

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.