Skip to main content
A DMARC lookup reads the Domain-based Message Authentication, Reporting and Conformance record published as a TXT record at _dmarc.yourdomain.com. DMARC tells receiving mail servers what to do with messages that fail SPF or DKIM alignment — none (monitor only), quarantine (divert to junk), or reject — and where to send authentication failure reports.
Run a one-off check at spotzee.com/tools/dmarc-lookup — enter any domain, get the enforcement policy, alignment modes, and reporting addresses instantly.
This guide is written for the API audience. Each call to POST /generic/email/dmarc-lookup deducts a small per-call amount from your Spotzee credit balance. See the Spotzee pricing page for live figures.

​
Why this matters

DMARC is the layer that binds SPF and DKIM authentication to the From header — the address the recipient actually sees. Without it, a sender can pass SPF on a different envelope domain while the visible From is entirely spoofed. With p=none, you gather reports but do nothing. With p=quarantine or p=reject, you close the door on domain spoofing. Mailbox providers have sender-authentication requirements for bulk mail. Check current provider guidance before changing policy. For regulated communications, retain the published record and any reports as evidence of your domain-authentication settings. But most organisations still haven’t finished the rollout. A domain stuck at p=none is doing the monitoring work without getting any protection. A domain at p=quarantine; pct=50 is enforcing policy on half of failing messages. Neither is the destination.

​
How it works

1

Query the _dmarc. subdomain

The API looks up TXT records at _dmarc.yourdomain.com, formed from the submitted domain.
2

Locate the v=DMARC1 record

The API collects TXT values containing v=DMARC1. Review the returned raw record and its syntax before relying on it as a valid policy.
3

Parse the policy tag

Read p= in the returned record to identify the requested policy: none, quarantine or reject. The lookup does not validate that the entire record is well formed.
4

Read alignment modes

Read adkim= and aspf= in the returned raw record to inspect alignment settings. The API does not parse or assess these tags for you.
5

Surface reporting addresses

Read rua= and ruf= in the raw record for aggregate and failure-report destinations. The API does not verify that reports are delivered.

​
What to watch for

Check these fields in order. The first failure you find is almost always the most important.
  • No record exists. No DMARC record means no enforcement and no reporting. Publish p=none; rua=mailto:dmarc@yourdomain.com as the starting point, then read the aggregate reports before escalating.
  • Policy is p=none. Monitoring mode provides zero enforcement. You’ll see failures in reports but messages still reach the inbox. Set a timeline to move to p=quarantine.
  • pct= below 100. A partial percentage means only that fraction of failing messages gets the stated policy — the rest are treated as p=none. Useful during rollout, but it must reach 100 before you can claim enforcement.
  • No rua= address. Without an aggregate reporting address, you’re flying blind. You can’t tell if your policy change will break legitimate senders, and you can’t see who is spoofing you. Add rua= before raising the policy level.
  • Subdomain policy unset. If sp= is absent, subdomains inherit the root policy. That’s usually fine. But if you’re deploying new subdomains for transactional mail, they’ll be subject to p=reject from day one — which can surprise a new ESP that hasn’t set up DKIM signing yet.
  • Strict alignment on a complex setup. adkim=s or aspf=s requires an exact From-header match. If your domain sends via subdomains or multiple ESPs using different signing domains, strict mode will cause false DMARC failures. Check this before tightening.

​
FAQs

A DMARC lookup queries the TXT records at _dmarc.yourdomain.com and retrieves the v=DMARC1 record. The API returns an exists flag and any matching raw dmarcRecord strings. Read the tags in those strings to assess policy, alignment and reporting. An empty result means the lookup found no matching DMARC record.
p=none is a monitoring-only policy. Receivers run the DMARC check and generate reports, but take no action — messages that fail authentication still reach the inbox. It’s the safe starting point for rollout, but it provides no spoofing protection. You need to progress to p=quarantine or p=reject for enforcement.
rua= is the aggregate reporting address. Receivers send daily XML digests showing which IPs sent mail claiming to be from your domain and whether each passed or failed. ruf= is the forensic reporting address for individual failure reports, sometimes including message headers or body content. Start with rua=. ruf= is optional and not supported by all providers.
Receivers treat the domain as having p=none by default. Authentication failures are not enforced and no reports are sent. The domain is effectively unprotected from spoofing. Anyone can send mail with that domain in the From header without triggering a DMARC failure at the receiver.
The standard rollout path: publish p=none with an rua= address, review aggregate reports until you can identify every legitimate sender, add missing senders to SPF or DKIM, move to p=quarantine; pct=10 and raise the percentage gradually, then shift to p=reject once false positives drop to zero. Set the timing from the aggregate reports and your own sending patterns.
This guide covers DMARC record syntax and the rollout path in depth. For a broader picture of your domain’s authentication posture, the email health check guide audits SPF, DKIM, DMARC, BIMI, MTA-STS, and blacklist status in one scan. Run both when setting up a new sending domain or diagnosing a deliverability problem.

​
Try it

Run a one-off DMARC record check at the DMARC lookup tool, or call the Extended API at POST /generic/email/dmarc-lookup for batch and automated workflows. Both surfaces resolve the same live DNS record.