A DMARC record at p=none is a burglar alarm that only writes to a log. It tells you who is sending mail as your domain, but it stops none of them. Moving to p=reject makes the alarm lock the door, and that is also why people hesitate: set it too early and your own invoices, newsletters or password resets can vanish. The way through is a staged plan, driven by what your record and reports actually say.
Policy plus reporting.
DMARC is a TXT record at _dmarc on your domain. It does two jobs. First, it sets a policy for mail that claims to come from you but fails authentication: none leaves it alone, quarantine sends it to spam, and reject refuses it. Second, it asks the big mailbox providers to send daily aggregate reports to the address in its rua tag, listing every server that sent mail using your domain and whether it passed.
A message passes DMARC when SPF or DKIM passes for a domain that matches the From address. That matching is called alignment, and it is where most real-world failures come from, because many services send with their own domain in the envelope or signature unless you set them up otherwise.
Every tag, in plain English.
DMARC Checker finds the record, falls back to the parent domain when you check a subdomain, and lays out every tag with its meaning. The checks list flags a missing p tag, invalid values, a pct below 100, a missing rua address, and report addresses on another domain that have not published the authorisation record receivers look for. That last one is easy to miss: without it, many providers quietly skip sending reports to a third-party address.
The same check probes more than 30 common DKIM selectors, such as google, selector1 and k1, and shows each key it finds with its type and approximate size. It also reports whether SPF and a BIMI logo record are published. If your DKIM selector is custom, open a message you sent, find s= in the DKIM-Signature header, and enter it in the selector field.
Reports first, policy later.
A small retailer starts with v=DMARC1; p=none; rua=mailto:dmarc@example.com. After two weeks the reports show four sources: Google Workspace, their shop platform, a newsletter tool and an unfamiliar server in another country. Google passes. The shop platform sends order emails with its own domain in the envelope and no DKIM for example.com, so it fails alignment. The newsletter tool passes DKIM because it was set up with the retailer's domain. The unfamiliar server is someone spoofing them.
They enable custom DKIM on the shop platform, wait a week, and the reports show it passing. They move to p=quarantine with pct=50, then pct=100 a week later. When two more weeks of reports show only their own three services, they switch to p=reject. The spoofed mail now bounces, and nothing of their own was lost on the way.
These are the ones that cause lost mail or stalled projects most often:
Write the record, then copy it.
When your record is missing or needs a change, the generator below the results writes one for you. Choose the policy and subdomain policy, add the report address, set the percentage and alignment, and copy the result into a TXT record at _dmarc. If a record already exists, the generator starts from its current values, so a step up from none to quarantine is a single change.
Check again after the record's TTL has passed. The policy card should show the new value, and the checks list should be down to the notes you have decided to live with.
DMARC relies on its neighbours.
DMARC can only pass when SPF or DKIM does. SPF Record Checker counts your DNS lookups, expands every include and tests a sending IP, which is the fastest way to find why a service fails SPF. MX Lookup confirms where incoming mail goes and flags missing reverse DNS on your servers. Together the three cover everything a receiving server checks before deciding whether your message deserves the inbox.
Try it now
The tool is one click away. No sign up, no upload, no payment.
Open DMARC Checker