DMARC Checker
See whether a domain is protected against email spoofing. The checker fetches the DMARC record, explains every tag and reports what receivers will actually do with mail that fails authentication.
- Encrypted connection
- No sign-up
- Free to use
How to use DMARC Checker
- Enter the domain that appears in the From address of your email.
- Select Check DMARC.
- Read the verdict: no record, monitoring only, or enforced.
- Go through the checks and the tag table to see what to change, for example a missing report address or a weak subdomain policy.
DMARC Checker features
Clear policy verdict
States whether failing mail is delivered, sent to spam or rejected.
Tag-by-tag explanation
Every tag in the record with its value and meaning.
Subdomain handling
Applies the organisational domain's record and its sp tag when a subdomain has no record of its own.
Report address checks
Verifies that external report destinations have authorised reports for the domain.
Mistake detection
Finds duplicate records, invalid policies, partial rollouts and unknown tags.
Live lookup
Reads _dmarc records directly from DNS when you run the check.
When to use DMARC Checker
- Preparing a domain for the sender requirements of large mailbox providers.
- Checking progress on the way from p=none to p=reject.
- Auditing the domains of a company, including ones that send no mail.
- Understanding why messages from a domain land in spam or are rejected.
DMARC Checker FAQ
What is DMARC?
Domain-based Message Authentication, Reporting and Conformance is a policy a domain publishes in DNS. It tells receivers what to do with messages that claim to come from the domain but pass neither SPF nor DKIM for that domain, and where to send reports about such messages.
What is the difference between none, quarantine and reject?
With p=none the receiver changes nothing and only sends reports. With p=quarantine failing messages are treated as suspicious, usually by placing them in the spam folder. With p=reject they are refused during delivery. Only quarantine and reject protect against spoofing.
What is alignment?
DMARC requires that the domain which passed SPF or DKIM matches the domain in the visible From address. In relaxed mode, the default, a subdomain of the same organisation counts as a match. In strict mode the domains must be identical. Alignment is what stops an attacker from passing SPF with their own domain while showing yours in the From line.
Why should I add a rua address?
Aggregate reports show every source that sends mail using your domain and whether it passes authentication. Without them you cannot know whether moving to quarantine or reject would block legitimate senders, such as a billing system someone forgot about.
Do subdomains need their own DMARC record?
No. A subdomain without a record inherits the policy of the organisational domain, or the sp value if that tag is present. Publish a separate record for a subdomain only when it needs a different policy.
How do I move safely to p=reject?
Publish p=none with a rua address and read the reports for a few weeks. Fix SPF and DKIM for every legitimate source. Then switch to quarantine, optionally with pct to apply it gradually, and finally to reject once the reports show only unauthorised senders failing.
What a DMARC record controls
SPF and DKIM each answer a narrow question: was this server allowed to send for the return-path domain, and does this signature verify for the signing domain? Neither looks at the From address a person reads. DMARC connects them to that address. A message passes DMARC if SPF or DKIM succeeds and the domain that succeeded aligns with the From domain. If neither does, the receiver applies the policy the domain owner published.
The record sits at _dmarc followed by the domain name and starts with v=DMARC1. The p tag is mandatory. Everything else refines the behaviour: sp sets a different policy for subdomains, pct applies the policy to a percentage of failing mail during a rollout, adkim and aspf choose strict or relaxed alignment, and rua and ruf name the mailboxes that receive reports.
Reports are the part people skip and later regret. Aggregate reports arrive as XML files, usually once a day from each large receiver, and list the sending addresses, volumes and authentication results seen for your domain. If you send them to an address at another organisation, such as a report-processing service, that organisation must publish a small authorisation record; otherwise receivers will not deliver the reports. This checker tests for that record.
A domain that sends no email deserves a record too. Publishing “v=DMARC1; p=reject” together with an SPF record of “v=spf1 -all” makes it useless to anyone trying to impersonate it, and takes two minutes.