How do I check that my DMARC is working?

21 June 2026 · 14 min read

"Is my DMARC working?" is one of those questions that hides a second, harder one inside it: working to do what, exactly? A DMARC record can be syntactically perfect, published at the right place, and visible to the whole internet, and still be doing almost nothing useful for you. Equally, a record can be quietly protecting your domain from impersonation while you assume it is broken because you never see a confirmation message anywhere. There is no green tick that the email ecosystem hands you. DMARC is a set of instructions you publish in DNS, and "working" means those instructions are being read correctly, your legitimate mail is passing the checks underneath them, and receiving mail servers are acting on them the way you intend.

This article walks through how to verify each of those layers in order, from the cheapest checks to the most thorough. You will read your published record and confirm it parses, use a free checker to validate syntax and surface common mistakes, confirm that your real sending sources are passing alignment in aggregate reports, and finally understand what "working" actually means at each policy stage: p=none, p=quarantine, and p=reject. The whole point is to give you evidence rather than hope, because flipping a DMARC policy to enforcement on faith is how outages happen.

What "working" means: three separate things people conflate

Before any tools, it helps to separate three claims that get mashed together as "DMARC is working":

The record is published and valid. Your _dmarc TXT record exists, resolves, and has correct syntax. A receiver that looks for your policy will find one it can parse.
Your legitimate mail passes DMARC. Real messages you send, from your real sources, are producing a pass result because either SPF or DKIM authenticates and aligns with the domain in the visible From address.
Receivers are enforcing your policy. Mail that fails is being treated the way you asked: quarantined or rejected, not silently delivered.

These are independent. You can have (1) without (2): a valid record while half your mailstreams fail. You can have (2) without (3): everything passes, but your policy is still p=none, so spoofed mail is delivered anyway. A real verification checks all three, and crucially, checks (2) across every source that sends as your domain, not just the one you happened to test from your own laptop. For a deeper grounding in the moving parts, the /glossary defines each term, and /glossary/dmarc covers the protocol itself.

Step 1: Read your published DMARC record

Your DMARC policy lives in a single TXT record at a fixed hostname: _dmarc.yourdomain.com. Not at the apex, not at dmarc.yourdomain.com, but at the underscore-prefixed _dmarc label. This trips people up constantly, because a record published at the wrong host is invisible to every receiver and the domain behaves as if it has no DMARC at all.

You can look it up from any terminal:

dig +short TXT _dmarc.yourdomain.com

On Windows:

nslookup -type=TXT _dmarc.yourdomain.com

A typical monitoring-stage record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r

Reading it tag by tag tells you a lot about whether it can do anything:

v=DMARC1 must be first, exactly. If it is missing or misspelled, the whole record is ignored and you effectively have no DMARC.
p= is the policy: none, quarantine, or reject. This is the single most important field for the "are receivers enforcing it" question.
rua= is the address that receives aggregate (RUA) reports. Without an rua, you are flying blind. You can have a perfect record and never see a single piece of evidence about who is sending as your domain. The mailbox in rua is what makes verification possible at all. See /glossary/aggregate-report-rua for the format these reports arrive in.
sp= sets a different policy for subdomains; if absent, subdomains inherit p. Worth knowing about because spoofers love unused subdomains. See /glossary/subdomain-policy-sp.
pct= applies your enforcement policy to only a percentage of failing mail. pct=100 (the default) means the policy applies to everything. A stray pct=10 is a common reason a "reject" policy seems to do almost nothing. See /glossary/dmarc-pct.
adkim= and aspf= control alignment strictness, r for relaxed (the sensible default) or s for strict. More on alignment below; the term itself is at /glossary/dmarc-alignment.

Two records is a failure mode worth calling out. If dig returns two separate v=DMARC1 strings at _dmarc, receivers will treat the policy as undefined and ignore both. There must be exactly one DMARC record. The same applies to the syntax: a DMARC1 record with a typo in p (for example p=rejct) is invalid, and most receivers will fall back to treating the domain as having no policy.

If dig returns nothing, the record is either not published, published at the wrong host, or has not propagated yet. DNS changes can take anywhere from a few minutes to a few hours depending on your TTL. If you have just made a change, confirm propagation across resolvers rather than trusting one cached answer; the /tools/dns-propagation-checker shows you what different public resolvers currently return.

Step 2: Validate it with the free DMARC checker

Reading the record by eye catches the obvious problems. A checker catches the subtle ones and saves you from memorising the tag grammar. Paste your domain into the /tools/dmarc-checker and it will fetch the live _dmarc record, parse every tag, and tell you in plain terms what your policy currently does and where it is weak.

A good check confirms the things you cannot easily eyeball:

The record is found at the correct host and there is exactly one of it.
v=DMARC1 is present and first, and every tag is recognised and well-formed.
The rua (and ruf, if present) addresses are syntactically valid mailto URIs. A malformed rua means reports silently go nowhere.
The effective policy after pct is what you think it is. A record reading p=reject; pct=10 is doing the job of a near-none policy for 90% of fraudulent mail, which is rarely the intent.
Whether your policy is at monitoring or enforcement, so you know which question to ask next.

The checker is also the fastest way to verify a change after you make it. Edit the record, wait for your TTL, re-run the checker, and confirm the new policy is live before you do anything else. If you are still drafting the record itself, the /tools/dmarc-generator builds a valid one from your choices so you do not have to hand-assemble the tags.

But here is the limit you must internalise: a checker validates the record, not your mail. It cannot tell you whether the invoices your finance team sends through a third-party portal are aligning. It cannot see your marketing platform, your helpdesk, or your CRM. The record passing the checker is necessary but nowhere near sufficient. That is what Step 3 is for, and it is the step most people skip.

Step 3: Understand alignment, because that is what actually passes or fails

DMARC does not invent its own authentication. It sits on top of /glossary/spf and /glossary/dkim and adds one rule: the authenticated identifier must align with the domain a human sees in the From header. This alignment requirement is the entire reason DMARC stops spoofing, and it is the single most common reason legitimate mail "fails DMARC" despite SPF and DKIM both being set up.

There are two ways to pass DMARC, and you only need one of them:

SPF alignment. SPF authenticates the Return-Path (envelope sender) domain. DMARC then requires that domain to match the visible From domain. With relaxed alignment, the organisational domains must match (mail.yourdomain.com aligns with yourdomain.com); with strict, they must be identical. The catch: many sending platforms use their own domain in the Return-Path, so SPF authenticates bounces.somevendor.net while your From says yourdomain.com. SPF passes, but it does not align, so it contributes nothing to DMARC. See /glossary/return-path.
DKIM alignment. DKIM signs the message with a key published under some domain, recorded in the d= tag of the signature. DMARC requires that d= domain to align with the From domain. Because DKIM survives forwarding and is not tied to the envelope, DKIM alignment is the more robust of the two, and getting it right is usually what makes a tricky third-party source pass. See /glossary/dkim-selector for how the keys are published.

A message passes DMARC if either SPF aligns or DKIM aligns. It fails only when neither does. So when a source fails, the diagnostic question is precise: is SPF authenticating but not aligning, is DKIM not signing with your domain at all, or is the source genuinely not yours? You answer that from the reports, not from the record.

You can sanity-check the two underlying mechanisms independently with /tools/spf-checker and /tools/dkim-checker. SPF in particular has a hard limit of ten DNS lookups, and exceeding it causes a permerror that breaks SPF for everyone, which then removes one of your two routes to DMARC pass. The /glossary/spf-10-lookup-limit and /glossary/permerror entries explain why that matters more than it looks.

Step 4: Confirm alignment in your aggregate reports

This is the heart of real verification. Aggregate reports, the RUA XML files sent to the address in your rua tag, are the only source of truth for which sources send as your domain and whether each one passes DMARC. Every major mailbox provider (Google, Microsoft, Yahoo and others) sends them daily once you publish an rua. They contain no message content, just counts: for each sending IP, how many messages were seen, what the From domain was, and whether SPF and DKIM passed and aligned.

Raw RUA XML is not meant to be read by humans. It is dense, per-IP, and one report per provider per day, so a real domain produces a steady trickle of files that need aggregating. Paste one into the /tools/dmarc-report-analyzer and it decodes the XML into a readable breakdown: each sending source, its volume, and a clear DMARC pass or fail with the alignment detail behind it. That is where you discover the things a record checker can never show you.

When you read a report, you are looking for a specific, reassuring picture:

Every source you recognise is passing. Your mail server, your Google Workspace or Microsoft 365 tenant, your email marketing tool, your invoicing system, your support desk, each appears and each shows DMARC pass via SPF alignment, DKIM alignment, or both.
You recognise every high-volume source. An unfamiliar IP sending thousands of messages as your domain is either a forgotten legitimate service (a CRM someone set up two years ago) or an impersonator. Both need handling before you enforce.
The failing volume is understood. Some failures are benign: a mailing list that rewrites messages, a one-off forward. You want to know that the failing bucket is noise, not a live business mailstream you are about to start blocking.

The mistake to avoid is declaring victory after one report from one provider. Different sources send at different cadences. The monthly billing run, the quarterly newsletter, the password-reset mail that only fires when someone forgets, all of these can be invisible in a single day's data and then show up failing right after you move to enforcement. Watch a representative span of reports, ideally covering a full business cycle, before you trust the picture. For the workflow of turning this evidence into a source inventory, /how/audit covers the discovery stage in depth.

Step 5: Interpret "working" at each policy stage

Now the layers come together. What "working" means depends entirely on which policy you have published, and the bar rises at each stage.

At p=none: working means you are collecting evidence

At p=none, DMARC instructs receivers to take no action on failing mail. Nothing is quarantined, nothing is rejected. People often read this and conclude DMARC is "not working", but at this stage that is exactly correct behaviour. The job of p=none is purely to switch on the reporting flow so you can see who sends as your domain. See /glossary/dmarc-policy.

So at p=none, "working" means a narrow, checkable thing: aggregate reports are arriving at your rua address. If reports are flowing and you can see your sources in the analyser, monitoring is working perfectly, even though it is providing zero protection against spoofing. The danger of this stage is comfort. A domain can sit at p=none for years, generate tidy reports, and offer impersonators a completely open door the entire time. p=none working is the start of the journey, not the end of it. /how/monitor covers what to watch for during this phase.

At p=quarantine: working means failing mail lands in spam

At p=quarantine, receivers are asked to treat failing mail as suspicious, typically delivering it to the recipient's spam or junk folder rather than the inbox. This is real, partial enforcement.

"Working" here means two things at once, and you verify both:

Your legitimate mail still reaches the inbox, because it passes DMARC and is unaffected by the quarantine instruction. You confirm this from continued pass results in the reports and by checking that real recipients are still receiving your mail normally.
Mail that fails is being quarantined. You can confirm receivers are acting by checking the disposition counts in aggregate reports, where the applied policy on failing mail shows as quarantine rather than none.

A p=quarantine policy is genuinely doing its job when spoofed mail is landing in spam while none of your real sources have started failing. If a legitimate mailstream you missed in the audit suddenly appears in the failing bucket, that is the warning to pause and fix alignment for that source before going further, not to push on regardless.

At p=reject: working means impersonation is bounced outright

p=reject is the destination. Here, receivers are asked to refuse mail that fails DMARC at the SMTP layer, so spoofed messages claiming to be from your domain are bounced and never delivered at all. This is the policy that actually stops the /glossary/bec and invoice-fraud attacks that abuse your name, and it is the one that email-security requirements and bulk-sender rules increasingly demand. See /requirements for who mandates it.

"Working" at p=reject is the highest bar:

All your legitimate sources pass DMARC, every one of them, every time, so that none of your real mail is caught by the reject instruction. This is why the audit has to be exhaustive before you arrive here. A source you forgot does not get a spam folder as a safety net; its mail simply vanishes.
The reports show failing mail being rejected, with the applied disposition reading reject, confirming receivers are honouring the policy.
Your pct is 100, so the policy covers all failing mail and not a slice of it.

When all of that holds, DMARC is doing the full job: legitimate mail flows untouched, and anyone forging your domain has their mail refused at the door. The safe way to reach this state without an outage is to ramp deliberately, none to quarantine to reject, and to use pct to phase in enforcement gradually while watching the reports at each step. The mechanics of that ramp are in /how/enforce.

A practical verification checklist

Putting the steps into a sequence you can run end to end:

Resolve the record. dig +short TXT _dmarc.yourdomain.com returns exactly one v=DMARC1 string.
Validate syntax. /tools/dmarc-checker reports no errors and shows the effective policy after pct.
Confirm reporting is on. The record has a valid rua and reports are arriving.
Check the foundations. /tools/spf-checker shows SPF under the ten-lookup limit with no permerror; /tools/dkim-checker shows valid signing keys for each source.
Read the alignment picture. /tools/dmarc-report-analyzer shows every legitimate source passing via aligned SPF or DKIM, across a representative span of days.
Match expectation to policy. At none, reports flow. At quarantine, failing mail is junked and yours is not. At reject, all your mail passes and forgeries are bounced.

If every line holds, DMARC is genuinely working, not just published.

Common reasons it looks broken when it is fine (and vice versa)

A few patterns account for most confusion:

"My test email passed, so I am done." One source passing tells you nothing about the other eight. Verification is per-source, and the reports are the only complete inventory.
"The checker is green but spoofing still gets through." A valid record at p=none provides no protection at all. Green record, open door. Check your p value, not just the syntax.
"My mail is failing and I do not know why." Almost always alignment: SPF authenticating the vendor's Return-Path domain instead of yours, or DKIM signing with the vendor's d= domain. Fix it by enabling DKIM signing with your domain on that source, which usually means publishing a /glossary/dkim-selector the vendor gives you.
"Reports stopped arriving." Check that the rua mailbox still exists and is not full, and that the address survived your last record edit.
"It works for the apex but not a subdomain." Subdomains follow sp if present, otherwise inherit p. An unused subdomain with no explicit policy is a favourite spoofing target. See /glossary/subdomain-policy-sp.

Where DMARC Engine fits

Everything above is verifiable by hand, and the free tools at /tools/dmarc-checker, /tools/spf-checker, /tools/dkim-checker and /tools/dmarc-report-analyzer will take you a long way for a single domain checked occasionally. The work that does not fit into an occasional manual check is the ongoing part: aggregating reports from every provider every day, spotting a new failing source the moment it appears, and timing the ramp from none to reject so that no legitimate mail is ever caught.

That continuous side is what /products/dmarc is built for. It hosts your record, ingests and parses your aggregate reports automatically, watches alignment across every source, and emails you when something changes, so that "is my DMARC working?" stops being a question you have to re-investigate by hand and becomes something you are simply told. You can manage all of it from the dashboard at app.dmarcengine.com. The standard for "working" is the same whether you verify manually or have it monitored for you: the record is valid, every legitimate source passes through alignment, and receivers are enforcing the policy you actually intend.