What a DMARC record decides
Domain-based Message Authentication, Reporting and Conformance does one job: it tells receivers what to do when a message claiming to be from your domain fails both authentication checks. That is a narrow instruction, and the narrowness is the point — DMARC does not authenticate anything itself. It reads the results of SPF and DKIM and applies a policy you published.
The direct consequence is that DMARC cannot be tightened safely until authentication works for every legitimate sender. A policy of reject applied to a domain whose helpdesk platform is not in its SPF record does not stop spoofing; it stops the helpdesk platform’s mail. That is why the sequence matters more than any individual setting.
The record name is _dmarc, and that is not optional
DMARC is published as a TXT record whose name is _dmarc prepended to the domain. The underscore prefix puts it in a name space that cannot collide with a host name, which is a deliberate design choice and also the reason people fail to find their own record: searching for the domain itself returns nothing relevant.
Records published on a subdomain’s own _dmarc name apply to that subdomain, and the organisational domain’s record governs subdomains that have no record of their own unless the sp tag says otherwise. That inheritance rule is where multi-subdomain setups usually have a gap.
The tags that matter
The p tag is the policy and the only mandatory one. It takes three values. none means monitor only: failures are reported but nothing is done, so mail is delivered as before. quarantine means treat failures as suspicious, and most large receivers implement that as a spam folder rather than a rejection. reject means refuse the message outright, which is the state a working setup eventually reaches.
The sp tag sets a separate policy for subdomains, which is worth setting whenever subdomains send mail independently. Without it, a subdomain with no record of its own inherits the organisational policy, which may be stricter or weaker than that subdomain can tolerate.
The rua tag requests aggregate reports: periodic XML summaries of what receivers observed, sent to the address you name. This is the tag that makes the whole exercise useful. Without it the policy is being applied blind, and there is no way to discover which senders fail before tightening it. The ruf tag requests forensic reports, which most large receivers do not send, and which raise privacy questions because they include message content.
The pct tag applies the policy to a percentage of failing messages. It exists as a gradual roll-out control, and a record still carrying pct=25 alongside p=reject is refusing only a quarter of what it appears to refuse.
The step-up that actually works
The reliable path is a loop rather than a sequence. Publish p=none with an rua address and wait for reports. Read them to inventory every sender, including the forgotten marketing platform and the ticket system that sends from a no-reply address. Fix SPF or DKIM for each one. Then move to quarantine and read the reports again. Only after a reporting period with no unexplained failures does reject become safe.
The reason this matters is that the failure is asymmetric. Applying reject too early causes loss that is hard to attribute, because the sender never sees an error — the receiving side simply refuses, and legitimate mail disappears quietly. The email deliverability test shows which of the pieces are in place before you take that step, and the DMARC policy guide walks through the roll-out in more detail.
What the report shows and what it cannot
Every tag found is listed with its value and its effect, and the verdict block states the policy, the subdomain policy, the percentage in force, and whether reporting is requested. Invalid values are named rather than silently ignored, because a receiver that does not recognise a value treats the record as having no policy for that tag.
What it cannot do is read your reports. Aggregate reports arrive by mail at the address you named, and interpreting them — which senders fail, which IPs belong to which platform — is work that happens outside this page. It also cannot confirm that the addresses you listed actually send mail, or that the alignment is configured correctly for a provider that uses a different domain in the envelope sender.
It does not test delivery, and it does not tell you whether your sending addresses are on any blocklist, which is a separate question covered by the IP blacklist check. Where a message is placed after passing authentication is decided by reputation rather than policy, which is the subject of why legitimate email goes to spam.