DMARC Policy Analyzer

Deep analysis of your DMARC deployment, alignment modes, and reporting status.

Evidence ASSESSED

Checked against: DMARC aggregate report XML · RFC 7489 §7.2

RED TEAM 0 findings BLUE TEAM control did not hold

DMARC Deployment Lifecycle

A healthy DMARC deployment usually follows these phases:

Phase 1: Monitoring (p=none) - Collect reports and identify legitimate mail sources without impacting delivery.
Phase 2: Testing (p=quarantine) - Direct suspicious mail to the junk folder to verify alignment for all sources.
Phase 3: Enforcement (p=reject) - Block all non-aligned mail. This is the ultimate goal for domain protection.

Our DMARC Analyzer goes beyond retrieving your record. It grades policy strength, checks subdomain coverage, verifies that reporting addresses are usable, and tells you exactly what to change next to move safely towards full enforcement.

What is DMARC Analysis?

Retrieving a DMARC record tells you what it says. Analysing it tells you whether it actually protects your domain.

A record can be syntactically perfect and still provide no protection at all: p=none enforces nothing, pct=10 applies the policy to a tenth of mail, a missing sp= leaves subdomains inheriting a weak parent policy, and an absent rua= means you have no visibility into who is sending as your domain.

Analysis evaluates the record as a security posture rather than as a string — how much of your mail is covered, what happens to the rest, whether subdomains are protected, and whether you are collecting the data needed to tighten the policy further.

Grades the actual enforcement level rather than just parsing syntax
Checks subdomain coverage through the sp= tag
Verifies that reporting addresses are present and usable
Assesses the pct= value, which silently limits enforcement
Recommends the specific next step towards p=reject

Why Deep DMARC Analysis Matters

A large share of domains that publish DMARC never progress past p=none. The record exists, compliance checkboxes are ticked, and the domain remains entirely spoofable. Monitoring mode provides reports and nothing else.

Subdomains are the other common gap. Without an explicit sp= tag, subdomains inherit the parent policy — so a domain sitting at p=none leaves every subdomain unprotected too. Attackers know this, and invoices.yourdomain.com is a more convincing phishing origin than a lookalike domain.

Most published DMARC records never leave monitoring mode
p=none provides reporting only and stops no spoofing whatsoever
Subdomains inherit a weak parent policy unless sp= says otherwise
A pct= below 100 leaves most mail unenforced
Google and Yahoo bulk sender rules require a DMARC record to exist

How This DMARC Analyzer Works

The tool retrieves your record, parses every tag, and evaluates the resulting posture against best practice.

Validates the domain input against format and SSRF safety checks
Retrieves the DMARC record at _dmarc.yourdomain.com
Parses every tag: p, sp, rua, ruf, adkim, aspf, pct and fo
Evaluates effective enforcement, accounting for pct and subdomain policy
Produces a graded assessment with a prioritised list of improvements

How to Use the DMARC Analyzer

Enter your domain name in the input field
Run the analysis to retrieve and evaluate your record
Review the policy grade and the effective enforcement percentage
Check whether subdomains are explicitly covered
Work through the recommendations in the order given

Understanding Your DMARC Analysis

Analysis reports on policy strength, coverage and reporting. Here is what each finding means:

Field / Value	Meaning
`Policy: none`	Monitoring only. Reports are generated, no mail is affected, and your domain remains fully spoofable. A valid starting point, never an end state.
`Policy: quarantine`	Failing mail is delivered to the spam folder. Real protection, and a sensible intermediate step while you confirm no legitimate mail is caught.
`Policy: reject`	Failing mail is refused at the SMTP level and never reaches the recipient at all. The only setting that genuinely stops domain spoofing.
`Effective coverage`	Policy strength multiplied by the pct value. A record with p=reject and pct=10 leaves ninety per cent of failing mail unenforced.
`Subdomain policy`	The sp= tag. When absent, subdomains inherit p=. Setting sp=reject protects subdomains even while the parent is still in monitoring mode.
`Aggregate reporting`	The rua= tag. Without it you receive no data at all, and tightening the policy becomes guesswork.
`Forensic reporting`	The ruf= tag. Most large providers no longer send these for privacy reasons, so its absence is not a meaningful finding.

Common Problems & How to Fix Them

Monitoring mode stops nothing. If the record has been in place for months, the reports it generated should already have told you what you need.

Review your aggregate reports, confirm every legitimate source authenticates and aligns, then move to p=quarantine. Watch for a fortnight, then move to p=reject. The reports exist to be acted on, not archived.

Without sp=, subdomains inherit the parent policy. A parent at p=none leaves every subdomain unprotected, and attackers favour plausible subdomains such as billing.yourdomain.com precisely because of this.

Add sp=reject. Subdomains almost never send legitimate mail, so the risk of breaking anything is minimal, and it protects them immediately even while the parent policy is still being rolled out.

The pct tag applies your policy to only a fraction of failing mail. A record reading p=reject; pct=10 enforces against one message in ten and lets the rest through.

Use pct as a deliberate rollout tool — 10, then 25, then 50, then 100 over several weeks — and make sure it does not sit at a low value permanently. A policy that was tightened but never had pct raised is a common and invisible gap.

Without rua= you have no visibility into who is sending mail as your domain, which makes any policy change a guess.

Add rua=mailto:dmarc@yourdomain.com. Several services ingest these reports for free and present them as a dashboard, which is far more practical than reading raw XML.

Only one DMARC record is permitted. A second one causes a permerror and receivers ignore your policy entirely, leaving the domain unprotected despite appearing configured.

Delete the duplicates so exactly one record remains.

Best Practices

Treat p=none as a temporary diagnostic phase, not a destination
Set sp=reject early, since subdomains rarely send legitimate mail
Always publish rua= so you have data before changing policy
Use pct to roll out enforcement gradually, then raise it to 100
Review aggregate reports for at least two to four weeks before each policy step
Confirm every legitimate sender aligns before moving to quarantine
Publish an enforcing DMARC record on parked domains that send no mail

Security Recommendations

Recognise that p=none offers zero protection — it is a measurement mode, not a control
Protect subdomains explicitly with sp=reject rather than relying on inheritance
Audit every sending source in your aggregate reports before enforcing, so legitimate mail is not lost
Never set pct=0, which disables enforcement completely while appearing configured
Publish v=DMARC1; p=reject on domains that send no mail at all, including parked and legacy domains
Monitor reports continuously rather than only during rollout, since new unauthorised senders appear over time

Frequently Asked Questions

It evaluates the record as a security posture: how strong the policy actually is, how much mail it covers once pct is accounted for, whether subdomains are protected, whether reporting is usable, and what specific change to make next.

No. Monitoring mode generates reports but affects no mail, so your domain remains fully spoofable. It is a valid first step, but staying there indefinitely means you have visibility without protection.

Long enough to see a full business cycle in your aggregate reports, typically two to four weeks. The goal is to have identified every legitimate sending source and confirmed each one authenticates and aligns.

It applies your policy to only that percentage of failing messages. p=reject with pct=10 rejects one failing message in ten. It is designed for gradual rollout, but a record left at a low value provides far less protection than the policy tag suggests.

Without sp=, subdomains inherit the parent policy, so a domain at p=none leaves them unprotected. Subdomains such as billing.yourdomain.com are attractive to phishers precisely because they look legitimate. Since subdomains rarely send mail, sp=reject is low risk and immediate.

Not really. Most large providers stopped sending ruf= reports for privacy reasons, since they can contain message content. Aggregate reports through rua= carry the information that actually drives policy decisions.

A reasonable end state is v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc@yourdomain.com — full enforcement on the domain and its subdomains, applied to all mail, with reporting still active so you keep visibility.