check@auth.mxio.io: How to Test SPF, DKIM and DMARC on a Real Message

What is check@auth.mxio.io?

check@auth.mxio.io is mxio's email authentication tester. It is a real mailbox: send it a message from any system you want to check, and it replies with what receivers saw — the SPF result for the address that actually connected, every DKIM signature and whether it verified, and whether either one aligned with the domain in your From: header, which is what decides DMARC. The reply links to a full report, kept for 30 days.

You don't need an account and there is no form. If you'd rather start from a page than an inbox, the email authentication tester mints a one-time address that does exactly the same thing.

It is safe to mail. The address only reads the message you send it, replies once to the address you sent from, and never signs you up for anything. If you received a report from check@auth.mxio.io that you didn't ask for, somebody forwarded it to you — the report itself says which domain it is about.

The rest of this guide is what the reply means and how to act on it.

Two questions, and no single tool answers both

There are two different questions hiding inside "is my email authentication working," and mixing them up is how people end up rewriting a record that was never broken.

Is my configuration right? That is a DNS question. Do you have an SPF record, does it stay inside the ten-lookup budget, is there a DKIM key published for the selector you sign with, does your DMARC record parse. Every checker on the internet, ours included, reads your DNS and answers this.

What happened to the message I just sent? That is a runtime question, and DNS cannot answer it. It depends on which server actually connected, which envelope sender it used, whether a signature survived the path, and whether any of that lined up with the address in your From: header.

The two legitimately disagree. A domain with flawless records can still send a message that fails DMARC — because that particular message went out through a system nobody added to the record. A message can also pass DMARC while the configuration underneath it is one key rotation away from failing. Neither result is wrong; they are answers to different questions.

Sending the test

The email authentication tester answers the second question by looking at a real message instead of guessing from your records.

Two ways in, and they run the identical analysis:

1. Email check@auth.mxio.io from whatever system you want to test — your mail client, your phone, your CRM, your invoicing app. Nothing to fill in. The reply comes back to the address you sent from.
2. Open the tester and click Start a check. It mints a one-time address, and the page updates when your message lands.

Send from the system you actually care about. A message typed in your webmail proves your webmail is configured; it proves nothing about the app that mails your invoices, which is usually the one that is broken.

What comes back

The reply, and the report page it links to, are in two halves that stay clearly separated:

Inside the first half you get the sending IP, the SPF result for the domain SPF actually checked, every DKIM signature with its selector and whether it verified, and the DMARC outcome — plus the raw SPF and DMARC records as they stood when your message arrived, quoted so you can check us.

The part most checkers skip

A results table saying spf=pass is true and close to useless. SPF passing is not the same as SPF counting.

DMARC does not pass because SPF passed. It passes when SPF or DKIM both authenticates and aligns with the domain in your From: header. Those are two separate conditions, and the gap between them is the most common confusion in email authentication:

SPF passed, but it passed for bounce.mailer.net, and your From address is at example.com. Those do not align, so the SPF pass did not count towards DMARC.

That is a real sentence from a real report. Plenty of platforms send with their own bounce domain in the envelope, which is perfectly normal — it just means SPF is authenticating them, not you, and DKIM has to carry the message on its own. If you want the mechanics in full, see DMARC alignment failure.

Which leg is carrying your mail

When DMARC passes, the next question is on what. The report says so explicitly, because the three answers have very different futures:

• On both SPF and DKIM. The durable position. Either one can carry the message alone, so a forward, a relay change, or a key rotation costs you nothing.
• On DKIM alone. SPF is contributing nothing. If signing stops, or a key is rotated without publishing the new one, this mail stops passing.
• On SPF alone. DKIM is carrying none of the load. Anything that breaks SPF alignment — a forward, a relay, a change of sending path — takes DMARC with it.

A single-leg pass is not a failure. It is a single point of failure, which is a different thing and worth knowing before it fails.

What it deliberately will not tell you

It will not turn a lookup error into a verdict. If a DNS query does not complete, the report says the check did not complete — not "you have no DMARC record." A transient resolver failure and a missing record are different problems with different fixes, and guessing between them sends people off to fix something that was never wrong.

It will not tell you what a receiver will do. It reports what happened to this message. Every receiver applies your policy its own way, and nobody can honestly promise you an outcome at Gmail from a test you ran against us.

It will not read your DMARC reports. Testing one message tells you about one message. Finding out who else sends as your domain — the forgotten form handler, the vendor nobody told you about — needs DMARC aggregate reports, which is a different job.

If a provider handles your mail

If your domain routes through a filtering or hosted-mail provider that we recognise, the report also checks the records that provider specifically needs, and says so when they are right, not only when they are wrong. A check that speaks up only on failure leaves you unsure it looked at all.

It also never calls a valid record broken. A perfectly good SPF record that simply omits one include is reported as exactly that — a missing authorisation, not a syntax error.

Where to go next

If the test surfaced a problem, the fix is usually one of three:

• SPF passed for the wrong domain. Nothing to fix in the record itself; get DKIM signing and aligned so your mail does not depend on the envelope path.
• Running out of SPF lookups. Each include, a, mx and redirect costs one, nested lookups count too, and the limit is ten. SPF flattening resolves the chain; the count climbs back as your providers change their own records, which is why it wants maintaining rather than fixing once.
• DMARC is watch-only. A p=none record is telling receivers to watch and report, not to act on messages that fail your checks. The path to enforcement runs through your reports: confirm your real senders pass first, then move to quarantine, then reject. Tightening before that sends your own mail to spam.

Then send another message. The tester is built to be run twice — once to see the problem, once to prove you fixed it.