How do you read a DMARC check result (p, pct, rua, ruf, alignment)?

A DMARC result is a set of tags, not one verdict

AdminKit’s DMARC check fetches the TXT record published at _dmarc.<yourdomain> and parses each tag RFC 7489 defines, explaining what each one currently tells receivers to do. There’s no single pass/fail reading of a DMARC record the way there is for one authenticated message — the record is a policy statement, and reading it means understanding what each tag contributes, together, to how receivers will treat mail that fails SPF or DKIM alignment for your domain.

p: the headline policy

The p tag is the core of the record: none asks receivers to take no action beyond reporting, quarantine asks them to treat failing mail as suspicious (typically routed to spam), and reject asks them to refuse it outright. RFC 7489 §6.3 is explicit that p=none carries no enforcement effect at all — a domain that has only ever published p=none is not protected from spoofing in any practical sense, even though a DMARC record technically exists. Reading a result with p=quarantine or p=reject is the signal that enforcement is actually happening.

sp: a separate policy for subdomains

sp lets a domain apply a different policy to subdomains than to the domain itself. If absent, subdomains inherit whatever p specifies. This is useful in a specific, common situation: an organization’s main domain sends business-critical mail and needs a cautious, staged rollout to p=reject, while its many unused or rarely-used subdomains have essentially no legitimate mail traffic to break — publishing sp=reject locks down a large source of spoofing risk (mail spoofed from random subdomains) well before the main domain’s policy catches up.

pct: how much of the failing mail is actually affected

pct applies the current policy to only a percentage of mail that fails alignment, with the remainder falling back to the next-weaker treatment. A result showing p=reject; pct=25 means only a quarter of failing mail is actually rejected right now — the rest is treated more leniently. This exists specifically to let a domain test a stricter policy’s real-world impact on a fraction of traffic before committing fully, and reading pct alongside p is necessary to know how much enforcement is genuinely in effect; p=reject with a low pct is a much softer real-world setting than the policy name alone suggests.

rua and ruf: where reports go

rua is the address (usually a mailto: URI) that receives daily aggregate reports — XML summaries of pass/fail volume by sending source — and is the practical foundation for knowing whether a stricter policy is safe to adopt. ruf is a separate, optional address for forensic (per-message) reports; RFC 7489 §6.3 defines the two independently, and most large mailbox providers support rua far more widely than ruf, due to the privacy sensitivity of sharing message-level detail. A result with a policy but no rua address means the domain has enforcement without the visibility needed to safely tune it — worth fixing even on an already-enforced domain.

adkim and aspf: how strict the alignment check is

Alignment is the check that the domain actually validated by SPF or DKIM matches the domain shown in the message’s visible From: address — without it, an attacker could pass SPF for their own unrelated domain while spoofing yours in From:. RFC 7489 §3.1 defines alignment as relaxed by default: mail.example.com aligns with example.com. Setting adkim=s or aspf=s requires an exact domain match instead, with no subdomain exception — a deliberate tightening some organizations apply to their primary sending domain once they’ve confirmed every legitimate subdomain sender authenticates under the exact domain rather than a variant.

Putting a result together

A fully read DMARC result answers three questions at once: what happens to failing mail right now (p, sp, pct), who finds out about failures (rua, ruf), and how strict the match has to be to count as a pass (adkim, aspf). Run AdminKit’s DMARC check against your own domain to see all of these read together in plain language, and see SPF, DKIM and DMARC explained for how the record fits with SPF and DKIM. If your record already has a monitored rua address and you’re ready to move past p=none, reading DMARC aggregate reports and rolling out to p=reject safely covers the staged path from monitoring to full enforcement.