Check a DMARC record, or build one
A DMARC record is one line with up to eleven settings, and two of them decide whether it does anything at all. This reads them out in plain words, then checks the one thing that silently stops your reports from arriving.
- Runs from your browser, not our server
- No sign-up
- No watermark
Loading the tool…
How it works
- Type your domain and press Check.
- Read the settings and the findings: p= (the policy) is what receivers act on, and pct= limits how much of your mail it applies to.
- If your reports go to an address at another company, check the permission block — without that record, no reports will ever arrive.
Why nothing is uploaded
Every operation on this page is done by code running inside your browser tab, using the same engine that renders web pages. The file is read from disk into your tab’s memory, transformed there, and written back out as a download. It is never sent anywhere — not to us, not to a third party.
Verify it yourself
- Open your browser’s developer tools (F12) and select the Network tab.
- Load your file and run the tool.
- The only requests you will see fetch the tool’s own code — and, for a few heavy tools, their open-source engine from a public CDN — plus one small page-view ping to loreatec.jp (page address and title, nothing more). None of them carry your file.
Frequently asked questions
I set up DMARC and no reports ever arrived. Why?
If the report address (rua) is at a different domain from yours — an analytics provider, your agency, a personal mailbox — that domain has to publish a record saying it accepts reports for you: yourdomain._report._dmarc.theirdomain with the value v=DMARC1. Receivers check it before sending, and silently send nothing when it is missing. This page checks it for you. The other common cause is simply a missing “mailto:” in front of the address.
What do adkim and aspf actually change?
They set how closely the domain that passed SPF or DKIM must match the From address people see. Relaxed (the default) accepts any subdomain of the same organisation — mail.example.com counts for example.com. Strict requires an exact match. Relaxed is right for almost everyone; strict is for organisations that control every subdomain and want to prevent a compromised one from being used.
Is p=none useless?
It is the necessary first step and a poor last one. With p=none nothing changes for your mail, but you receive the reports — exactly what you need for the few weeks it takes to find every legitimate sender. Left at none for years it protects nothing: anyone can still send as your domain, and now you have a record saying you know.
What is sp= for?
A separate policy for subdomains. Without it, subdomains inherit p=. It matters because attackers use subdomains that were never set up to send at all — invoice.yourdomain.com — where there is nothing to break by setting sp=reject even while the main domain is still at none.
What about pct?
It applies the policy to only a percentage of the failing mail, so you can move to quarantine at 10 % and watch. It is a ramp, not a destination: at pct=50 with p=reject, half of the forgeries still get through.