DMARC Analyzer

You are preparing a production cutover from monitoring to enforcement and need to know whether the published record can survive receiver scrutiny. Marketing still sends through a CRM, product mail uses a transactional provider, and finance runs an on-prem relay. Before you raise `p` from `none` to `quarantine`, DN01 shows whether the TXT at `_dmarc.example.com` is syntactically valid, whether duplicate tags would invalidate the record, and whether `pct` already limits enforcement. That single DNS publication is what billions of inboxes evaluate; a typo in `p=` or a second stray DMARC TXT can silently weaken protection across every channel.

Deliverability tickets often blame DMARC even when SPF passes in isolation. A message can publish a valid SPF record and still fail DMARC when the envelope From, header From, and DKIM signing domain do not align under the published `aspf` and `adkim` modes. DN01 surfaces alignment defaults: when tags are omitted, the analyzer assumes relaxed alignment (`r`) and warns you that receivers may accept broader domain matches than you expect. Pair the DMARC result with DKIM Validator to see whether selectors sign the organizational domain and with DNS Checker to confirm SPF includes are not over-broad.

Security and fraud teams use DMARC as an anti-spoofing control for executive domains, partner portals, and look-alike brands. If `_dmarc` is missing entirely, DN01 returns a clear diagnostic—`no DMARC record found at _dmarc.<domain>`—and recommends publishing `v=DMARC1` with a starting policy. That missing state is not treated as a tool failure; it is the exact condition receivers see when phishing can reuse your domain without a published rejection policy. Document the finding, publish monitoring with `rua`, then schedule enforcement after aggregate reports prove legitimate sources pass.

Managed service providers run DMARC reviews across dozens of customer zones during onboarding or renewal. Manual `dig` lookups do not scale when you must compare `sp` against `p`, verify report mailboxes, and spot invalid `pct` strings across a portfolio. DN01 returns a consistent JSON-shaped report with duration, tag inventory, and human recommendations so operators can paste results into change tickets. The SEO result page for a domain also gives stakeholders a stable link that describes current publication without exposing internal DNS tooling.

Subdomain-heavy architectures—`news.example.com`, `billing.example.com`, `eu.example.com`—depend on `sp=` when child zones send mail with their own SPF and DKIM setup. If `sp` is absent, receivers fall back to `p` for subdomains, which surprises teams that thought a child zone was isolated. DN01 shows both values side by side and flags invalid subdomain policies the same way it flags bad organizational policies. When `sp=reject` is stricter than `p=quarantine`, you can see that asymmetry immediately instead of discovering it from bounced campaigns.

Compliance and vendor questionnaires increasingly ask for evidence of email authentication maturity, not just checkbox answers. Auditors want to know whether aggregate reporting is configured (`rua`), whether enforcement is partial (`pct` less than 100), and whether the record is valid today—not last quarter. DN01 answers those questions from live DNS, stores the raw TXT for screenshot evidence, and separates hard errors (duplicate tags, invalid policy names) from warnings (monitoring mode, relaxed alignment). That distinction helps you explain what must be fixed before enforcement versus what is a deliberate staging posture.

Incident response after a spoofing wave often starts with “is our DMARC wrong or missing?” rather than with mailbox samples. When multiple TXT strings at `_dmarc` include more than one `v=DMARC1` fragment, receivers may treat the configuration as invalid and ignore enforcement. DN01 selects the first matching record for parsing but still reports duplicate tag errors inside a single string, helping you distinguish split-brain DNS from harmless historical TXT. Re-check after TTL once authoritative nameservers agree, then validate signing paths with DKIM Validator before returning to `reject`.

If DN01 reports no DMARC record, query `_dmarc.yourdomain.tld` specifically—not the apex TXT used for SPF. Many teams accidentally publish SPF at the root and assume DMARC inherits it. Confirm the record at every authoritative nameserver if you recently migrated DNS providers; stale NS delegations are a common reason one resolver sees `v=DMARC1` while another returns NXDOMAIN. DN01’s missing-record response is intentional diagnostics, not a failed API call, so treat it as a publication task.

When `valid` is false despite `found` true, read the errors array before changing policy. Duplicate `p=` tags, unknown policy tokens, non-integer `pct`, or `pct` outside 0–100 all invalidate the record for strict parsers. Remove duplicate tags in the DNS panel, keep a single semicolon-separated TXT, and avoid splitting DMARC across multiple TXT strings unless your provider concatenates them correctly. After edits, wait for TTL and rerun the analyzer to confirm `valid` flipped to true.

Warnings about `p=none`, missing `rua`, or relaxed alignment do not always mean mail is failing today—they describe exposure. `p=none` monitors authentication outcomes without telling receivers to quarantine or reject failures. Missing `rua` means you will not receive aggregate XML reports that show which sources pass or fail DMARC. If warnings mention relaxed alignment, decide whether you need `adkim=s` or `aspf=s` for stricter domain matching before moving to `reject`.

If live DNS disagrees with what your DNS vendor dashboard shows, compare the raw record field against `dig +short TXT _dmarc.domain`. Caching resolvers, regional anycast differences, and partial zone imports can make dashboards lie. DN01 queries through the platform resolver at request time; paste the raw TXT into change control if you need proof of the externally visible value.

When legitimate mail fails after tightening policy, DMARC may be correct while SPF or DKIM paths are not. Use DNS Checker to review SPF includes and flattening limits, then DKIM Validator to confirm active selectors sign the From domain with keys that are not expired. Partial enforcement via `pct=50` can also make failures look random; DN01 warns when pct is below 100 so you can correlate with sample message headers.

DMARC sits on top of SPF and DKIM. SPF validates the envelope path; DKIM validates a cryptographic signature; DMARC asks whether either result aligns with the domain visible in the From header and what to do if both fail. DN01 does not send mail or evaluate individual messages—it inspects only the DNS policy that tells receivers how to treat misaligned traffic. That is why pairing this tool with DKIM Validator and DNS Checker completes the story: publication, signing, and alignment are three separate checks.

The `p=` tag is mandatory. Policies must be `none`, `quarantine`, or `reject`; any other value is flagged as invalid. `none` is appropriate for initial monitoring but DN01 warns that it does not instruct receivers to block failing mail. `quarantine` typically sends failures to spam folders, while `reject` asks receivers to drop messages outright. Your escalation path should follow evidence from `rua` reports, not calendar deadlines alone.

The `pct` tag limits what fraction of failing messages the policy applies to. Values below 100 mean enforcement is deliberately partial—useful for staged rollouts but confusing during troubleshooting because some failures still deliver. DN01 parses `pct` as an integer and errors when the value is not numeric or exceeds the 0–100 range. Full enforcement for production brands usually ends at `pct=100` once reports are clean.

Aggregate reports go to `rua` URIs, usually `mailto:` addresses that must be registered with your report processor. DN01 lists every comma-separated destination and warns when `rua` is absent, because without reports you are enforcing blind. Forensic `ruf` reports are optional and privacy-sensitive; many organizations omit `ruf` even when `rua` is present. The analyzer surfaces both when published.

Alignment tags `adkim` and `aspf` control whether strict (`s`) or relaxed (`r`) domain matching is required. When omitted, DN01 defaults both to relaxed and warns that receivers may accept organizational domain and subdomain combinations you did not intend. Strict modes are common before `reject` because they reduce the chance that a look-alike subdomain passes while the header From shows the apex brand.

Validity in DN01 means the record is free of blocking parse errors at inspection time. A monitoring record with `p=none` and missing `rua` can still be marked found with warnings—useful signal for risk reviews. Treat `valid=false` as a stop-ship DNS defect until fixed, because some receivers ignore malformed policies entirely.

Command-line `dig TXT _dmarc.example.com` shows raw strings quickly but leaves policy interpretation to the operator. You must manually remember that duplicate `p=` tags invalidate the record, that `sp` overrides subdomain behavior, and that missing `rua` blocks reporting. DN01 encodes those rules and returns recommendations in the same pass, which is faster for handoffs between DNS and mail teams.

DNS Checker on DN01 displays all TXT records for a zone, which helps when SPF, DKIM, and verification tokens live alongside DMARC. It does not score DMARC policy risk or highlight partial `pct` enforcement. Use DNS Checker when you need full zone context; use DMARC Analyzer when the question is specifically authentication policy at `_dmarc`.

Mailbox aggregate XML reports show historical sending sources and failure rates, but they arrive daily or weekly and reflect past traffic. They do not prove what DNS publishes right now after an emergency change. DN01 answers the live publication question in seconds, while reports remain essential for deciding whether to tighten `p`.

Vendor-hosted DMARC consoles provide dashboards and report parsing, yet external auditors and DNS operators still need a neutral lookup of the TXT consumers see on the open internet. DN01 is independent of any report mailbox and works even when `rua` is missing—exactly the scenario where you need confirmation that monitoring was never configured.

Online TXT validators sometimes check generic SPF syntax but not DMARC-specific tag rules. DN01 is built around the Go parser used by the production API, so the SEO page and API share the same validation logic for `p`, `sp`, `pct`, duplicates, and alignment defaults.

Spreadsheet inventories of customer DMARC posture go stale the moment a registrar update or CDN DNS edit lands. A shareable DN01 result URL gives support and delivery teams a current snapshot with query name, raw record, and timing metadata without shell access.