Help

DMARC lets a domain owner publish a policy telling receiving mail servers what to do with messages that fail SPF/DKIM authentication, and asks for reports back.

The weakest DMARC policy: failing mail is delivered exactly as if no DMARC record existed. You still get reports, but nothing is blocked.

Mail that fails DMARC is not rejected outright — receivers are asked to treat it as suspicious, typically by routing it to spam/junk.

The strongest DMARC policy: mail that fails DMARC authentication is rejected during the SMTP transaction and never delivered.

The pct tag applies your quarantine/reject policy to only a percentage of failing mail, letting you roll out enforcement gradually.

sp lets a domain set a different DMARC policy specifically for its subdomains, overriding the main p= tag for anything not exactly the organizational domain.

adkim controls how strictly the DKIM signing domain must match the visible From: domain: r (relaxed, default) allows a matching organizational domain; s (strict) requires an exact match.

aspf controls how strictly the SPF-authenticated domain must match the visible From: domain: r (relaxed, default) allows a matching organizational domain; s (strict) requires an exact match.

rua is the mailto: address (or addresses) where receivers send the daily aggregate reports this tool ingests and parses.

Alignment is DMARC's extra requirement on top of SPF/DKIM passing: the domain that was actually authenticated must match the domain shown to the recipient in the From: header.

Daily XML summaries, one row per distinct sending IP, with SPF/DKIM/disposition results — never individual message content, subject lines, or recipients.

header_from is the domain in the visible "From:" field a recipient actually sees — the one DMARC alignment checks against, not the technical envelope sender.

SPF is a DNS TXT record listing which mail servers are allowed to send on behalf of your domain, checked against the envelope sender address.

The sending IP is explicitly authorized by the domain's SPF record.

The sending IP is explicitly NOT authorized — the record ends in -all (hard fail) and no mechanism matched.

A weak "probably not authorized" signal from a record ending in ~all — receivers are asked to accept but flag the mail, not reject it.

The domain explicitly declines to make a statement about this sender — equivalent to having no SPF opinion either way.

No SPF record exists for the domain at all, so no check could be performed.

A transient DNS error (timeout, SERVFAIL) prevented SPF evaluation from completing — retrying later would likely succeed.

A permanent problem with the SPF record itself — malformed syntax, or exceeding the 10-DNS-lookup limit — that will not resolve without fixing the record.

SPF evaluation aborts with permerror once it has performed more than 10 DNS lookups (nested includes, a/mx/ptr/exists mechanisms) resolving one record.

The mechanism at the end of an SPF record deciding what happens when nothing else matched: -all (fail), ~all (softfail), ?all (neutral), +all (pass — effectively no restriction, avoid).

SPF authenticates the envelope MAIL FROM domain, which is often invisible to the recipient — DMARC alignment then checks whether that matches the visible From: domain.

DKIM cryptographically signs outgoing mail with a private key; receivers verify the signature against a public key published in DNS, proving the message wasn't altered in transit and really came from that domain.

The signature verified successfully against the public key published for that selector — the message is intact and really was signed by that domain.

The signature did not verify — either the message was modified after signing, the wrong key was used, or the DNS key record is missing/wrong.

The s= tag in a DKIM-Signature header names which key was used — receivers look it up at <selector>._domainkey.<domain> to find the matching public key.

DKIM authenticates whichever domain is in the signature's d= tag — DMARC alignment then checks whether that matches the visible From: domain.

DNS has no way to list every DKIM selector a domain has ever used, so a health-check probe can only confirm the selectors it already knows about, never certify "DKIM is fully configured."

The check ran successfully and found the expected, healthy configuration.

The check ran successfully but found something suboptimal — not broken, but worth attention.

The check ran successfully and confirmed a real problem — a missing record, a broken handshake, an actual blocklist hit.

The check itself couldn't complete — a DNS timeout, an unconfigured API key, a network failure. This is unknown, not a pass and not a fail.

Informational only — the check observed something worth noting that isn't a pass/warn/fail judgment (e.g. a feature simply isn't configured, which may be intentional).

Confirms the domain has resolvable MX records pointing at reachable mail servers — the basic prerequisite for receiving any mail at all.

Confirms the domain's zone is signed with DNSSEC, which protects DNS answers (including your SPF/DKIM/DMARC records themselves) from being tampered with in transit.

MTA-STS enforces that inbound mail to your domain is delivered over an encrypted, certificate-validated connection — checked here by looking for the DNS record and fetching the policy file.

Confirms the domain publishes a TLS-RPT DNS record requesting reports on transport-security failures — separate from actually ingesting those reports.

BIMI lets your brand logo appear next to your mail in supporting email clients — but only once DMARC enforcement is strict enough that the logo claim is trustworthy.

Performs a real SMTP connection to the domain's mail server and confirms it offers STARTTLS with a valid, matching certificate.

Checks whether the domain's sending IP(s) are listed on Spamhaus ZEN, an IP-based reputation blocklist many receivers consult before accepting mail.

Checks whether the domain name itself (not an IP) is listed on Spamhaus DBL, a domain-based reputation blocklist.

Confirms the sending IP's reverse-DNS hostname resolves forward back to the same IP — a basic legitimacy signal many receivers require before even considering a message.

When rua= points at a mailbox on a different domain than the one being monitored, that destination domain must explicitly authorize accepting reports for this domain via its own DNS record.

Low severity. A source you've already labeled as a known sender is failing SPF specifically, but DKIM or alignment still make the message pass DMARC overall.

Low severity. A known sender is failing DKIM specifically, while SPF or alignment still keep the message passing DMARC overall.

Low severity. A known sender's SPF and/or DKIM mechanism itself passed, but the authenticated domain doesn't align with your visible From: address.

Medium severity, domain-wide. A live SPF lookup count against your published record exceeds RFC 7208's 10-DNS-lookup limit.

High severity. A source not on your allowlist is failing both SPF and DKIM, in volume, over the standard analysis window.

High severity. The same pattern as R5, but spanning several distinct report days — evidence of an ongoing campaign rather than a one-off spike.

Medium severity. Currently at p=none with no known-sender authentication failures observed — the data suggests it's safe to move to quarantine.

Medium severity. Currently at p=quarantine with no known-sender authentication failures observed — the data suggests it's safe to move to reject.

High severity. The domain's live DNS DMARC record no longer matches the policy you explicitly approved as the known-good baseline.

Medium severity. A domain flagged as never sending mail is showing real report volume — either the flag is stale, or someone is spoofing it.

Medium severity. The domain hasn't published a subdomain policy, and reports show a strict subdomain being spoofed in header_from.

Informational, no action needed. A known mail forwarder is showing the exact SPF-fail pattern forwarding always produces — this is expected, not a problem.

Fires when a domain hasn't received any reports for longer than the configured window — the dead-man's-switch for a stalled ingestion pipeline or a receiver that stopped reporting.

Fires when the domain's live DNS DMARC record no longer matches the policy you explicitly approved as the baseline — the same condition as recommendation rule R9, checked independently every day.

Fires when any single unclassified sender exceeds a volume threshold — a lightweight daily tripwire for a spike from an unrecognized source.

Fires when today's DMARC pass rate has dropped meaningfully below a trailing baseline average — an early signal something broke, even before any single rule fires.

What the domain's DMARC record actually says in live DNS right now, auto-read by the health check — not something you edit directly in this tool.

The policy you've explicitly signed off on as the domain's known-good state — set only by a deliberate admin action, never automatically.

Where you want the domain's DMARC policy to eventually be — the goal this tool's R7/R8 recommendations check readiness against, editable directly by an admin.

This tool never auto-seeds a baseline policy, even when onboarding a brand-new domain — an admin has to explicitly click "Approve as baseline" once a published policy has actually been observed.

Mark a domain as never legitimately sending mail — any report traffic for it is then, by definition, spoofed, which is exactly what recommendation R10 watches for.

Whether a source IP is "known" changes what a finding means, not just how severe it is — a known sender's auth failure is a config fix; an unknown sender's is a possible spoofing attempt.

A background pass that labels every source IP seen in reports as known infrastructure, a recognized email service provider, or unknown — using reverse DNS and network ownership, not just the allowlist.

A manually maintained list of IP/CIDR ranges you trust as legitimate senders for a domain (or globally) — edited on the Allowlist page, Admin tier.

Poll the configured mailbox over IMAP, decompress and sniff the format, parse it, store it, then archive the original file and file the email away — all idempotent, so re-running never double-counts.

Enforced at the database layer with a content hash and a uniqueness constraint — not application logic — so re-running ingestion twice never double-counts a report.

A tiny compressed file crafted to expand to an enormous size when decompressed — a classic denial-of-service technique this tool has to defend against, since the report-submission address is public DNS anyone can mail.

The landing page: a posture card per monitored domain, an Attention panel for what needs you today, and recent activity across every domain.

Everything about one domain: policy status and controls, the pass/fail trend, health-check results, per-source-IP traffic, open recommendations, and recent reports.

One ingested DMARC report, broken down to the individual source-IP records it contains.

Add or remove known-senders rules — IP/CIDR ranges you trust as legitimate senders, scoped to one domain or applied globally.

Super-admin-only account management: invite, change role, disable/re-enable, delete, force logout, trigger a password reset, or reset MFA.

A read-only, Super-Admin-only feed of every recorded governance action — who did what, and when.

Your own account: change password, set up or remove an authenticator app and recovery codes, add or remove passkeys.

Status, the three distinct policy fields, and the deactivate/reactivate and approve-baseline actions.

Set the p/sp levels you're working toward and the non-sending flag — this only records intent, it never touches DNS itself.

Daily message volume for this domain, split into what passed DMARC (via SPF or DKIM alignment) and what didn't, over the trend window.

The latest point-in-time DNS/network posture probe — one badge per check, independent of any report data.

A checklist restating this domain's DMARC health check in DMARCbis (RFC 9989) terms: the deprecated pct= tag, organizational-domain coverage, and any new optional tags.

Every sending IP seen for this domain in the trend window, with enrichment, known/unknown labeling, volume, and DKIM/SPF pass rates.

This domain's currently open R1-R12 findings, each citing the exact evidence that triggered it.

The most recently ingested DMARC aggregate reports for this domain — click one to see its individual per-IP records.

In May 2026 the IETF published RFC 9989/9990/9991, obsoleting the original RFC 7489 and moving DMARC from Informational to a Proposed Standard. Existing v=DMARC1 records keep working unchanged.

Classic DMARC used the Public Suffix List to find a domain's "organizational domain" for policy inheritance. RFC 9989 replaces that with a DNS Tree Walk — this tool implements it, and a subdomain with no record of its own can now correctly show as covered rather than failing.

RFC 9989 removed pct= as a defined tag entirely, and rf=/ri= simply no longer appear in the current tag set. None of this is urgent — existing records with these tags still work; it's a good candidate for your next DNS edit, not something to change today.

RFC 9990 aggregate reports can optionally include a few new fields — this tool now captures and stores them when a reporter sends them, though they're not yet shown anywhere in the dashboard.