Free DMARC checker — lookup, validate, and decode the DMARC policy for any domain.

Six independent classes of output per DMARC check. Policy parsing and alignment-mode detection are the headlines; the reporting-URI inspection and percent-rollout reading are the differentiators that surface what most checkers miss.

SPF and DKIM each answer one narrow question. DMARC is what tells receivers what to do with the answer — and what to report back to you. Without DMARC, you have authentication but no enforcement and no visibility. Five reasons it matters in 2026:

• Without DMARC, attackers can spoof your domain at zero cost. SPF lists allowed IPs; DKIM signs content. Neither says what receivers should DO when both fail. Without a DMARC policy, receivers fall back to per-mailbox heuristics — Gmail, Outlook, and Yahoo each make their own decision, and the decision usually favors delivering the spoofed mail to inbox or junk rather than rejecting it.
• `p=none` is monitor-mode, not protection. Most domains we audit publish DMARC at `p=none`. That's a useful starting point — it gets you aggregate reports without rejecting any mail — but it provides zero spoofing protection. Real protection requires moving to `p=quarantine` or `p=reject`. Most teams stall in monitor mode for years.
• Major providers now require DMARC for bulk senders. Google and Yahoo's 2024 bulk-sender requirements mandate a published DMARC policy for any sender over 5,000 messages/day. Microsoft's 2025 update extended similar requirements. A missing or `p=none` DMARC at scale now translates directly to deliverability degradation.
• Aggregate reports are how you find shadow senders. Without `rua=`, you have no visibility into who's sending mail as your domain. With it, daily XML reports from Gmail, Microsoft, Yahoo, and ~30 other receivers show you every sending IP that hit them — including the third-party tools your marketing team set up six months ago and never told you about.
• Misconfiguration is silent. A typo in `rua=`, a malformed `pct=`, missing cross-domain authorization for an outsourced DMARC service — none of these fail loudly. Reports just don't arrive, or the policy reads as something subtly different from what you intended. Validation is the only way to know.

A DMARC check is a TXT query plus a structural parse plus a few outbound checks. We follow the same algorithm a receiving mail server would when deciding whether and how to apply policy to inbound mail.

• Stage 1 — Fetch the DMARC record Query TXT at `_dmarc.<domain>`. Filter for records starting with `v=DMARC1`. If the lookup is at a subdomain and returns NXDOMAIN, fall back to the organizational domain's record (per RFC 7489 § 6.6.3). Detect multiple DMARC records — that's an instant disqualification at any receiver.
• Stage 2 — Parse the tags DMARC records are semicolon-separated `tag=value` pairs. Required: `v=DMARC1` and `p=`. Optional: `sp`, `pct`, `rua`, `ruf`, `adkim`, `aspf`, `fo`, `rf`, `ri`, `ado` (rare). Every tag is parsed against its valid-values list — unknown tags or invalid values are flagged.
• Stage 3 — Score the policy strength `p=none` → 0 (monitor only). `p=quarantine` → 1 (junk failed mail). `p=reject` → 2 (block failed mail). Combined with `pct`, the effective enforcement is `pct%` of policy. A record saying `p=reject; pct=0` is functionally equivalent to `p=none` regardless of what the policy tag says.
• Stage 4 — Validate reporting URIs Parse `rua=` and `ruf=` URIs. Validate `mailto:` syntax. When the reporter domain differs from the published domain (e.g. `rua=mailto:reports@dmarc-service.com`), check for the `<domain>._report._dmarc.<reporter>` cross-domain authorization record. Missing authorization = silently dropped reports.
• Stage 5 — Read alignment modes Default `adkim=r` and `aspf=r` (relaxed, organizational-domain match). Strict (`s`) requires exact match between authenticated domain and `From:` domain. Most setups should be relaxed; strict is appropriate only when senders are guaranteed to use the exact same domain.
• Stage 6 — AI review Feed the parsed record, alignment, policy strength, and URI checks to the analyzer. Surfaces severity-ranked issues with concrete recommendations: move from `p=none` to `p=quarantine`, raise pct from 10 to 100, fix dangling rua addresses, etc.

Three terms, three layers. DMARC sits on top of SPF and DKIM and makes the enforcement decision. The shortest framing: SPF authorizes IPs, DKIM signs messages, DMARC sets policy.

• SPF — Sender Policy Framework Lists which IPs can send mail for your domain. Lives at the apex as a TXT record. IP-based; breaks under forwarding. See the SPF Checker for full chain expansion and 10-lookup-limit analysis.
• DKIM — DomainKeys Identified Mail Cryptographically signs outgoing messages with a private key; receivers verify against the public key in DNS. Content-based; survives forwarding. See the DKIM Checker for per-selector lookup and key-strength scoring.
• DMARC — Domain-based Message Authentication, Reporting, and Conformance Tells receivers what to do when SPF or DKIM fails. Lives at `_dmarc.<domain>`. Adds reporting so you find out who's authenticating as you. Policy-based — coordinates the underlying mechanisms. This is the tool you're looking at.
• Alignment is the DMARC-specific concept DMARC passes only when SPF or DKIM aligns — meaning the authenticated domain matches the `From:` domain. SPF can pass on a different envelope sender, DKIM can pass with a different signing domain — but DMARC fails unless one of them aligns with the visible From. This is what makes DMARC harder to set up than either underlying mechanism.
• What this tool covers DMARC only. For SPF, see the SPF Checker. For DKIM, see the DKIM Checker. For a combined health view across all three plus deliverability gradings, see the Email Authentication tool.

A DMARC record is a sequence of `tag=value` pairs separated by semicolons. Only `v=DMARC1` and `p=` are required; everything else is optional with sensible defaults. The defaults usually do the right thing — but knowing them matters when you debug.

• v=DMARC1 — Version (required, first) Identifies the record as DMARC version 1. Must be the literal string `v=DMARC1` and the first tag. Without it, the TXT record is just text, not DMARC.
• p= — Main policy (required) Tells receivers what to do when a message fails DMARC. `none` (monitor only — useful while bootstrapping, no protection), `quarantine` (mark as suspicious, typically junk), `reject` (block entirely). Production goal: `p=reject`.
• sp= — Subdomain policy (optional) Overrides `p=` for subdomains. If absent, subdomains inherit `p=`. Use case: enforce `p=reject` on the main domain but `sp=quarantine` on subdomains during transition, or `sp=reject` on subdomains while `p=none` on the apex while migrating.
• pct= — Rollout percentage (optional, default 100) Apply the policy to only this percentage of mail; the remainder gets the next-weakest treatment. `p=reject; pct=10` means 10% of failing mail is rejected, 90% is quarantined. Useful for gradual rollout — start at 1%, ramp up. Trap: pct=100 is the safe default; teams often forget to raise pct from 10 after testing.
• rua= — Aggregate report URI (optional, strongly recommended) Where to send daily aggregate XML reports. Almost always a `mailto:` URI. Without `rua`, you publish a policy and have no visibility into who's authenticating against you. Major receivers (Google, Microsoft, Yahoo) send aggregate reports daily.
• ruf= — Forensic report URI (optional, rarely supported) Per-failure reports with message details. Few receivers (Microsoft is notable in supporting it) actually send forensic reports anymore due to privacy concerns. Usually safe to omit.
• adkim= — DKIM alignment mode (optional, default `r`) `r` (relaxed) — DKIM signing domain can be any subdomain of the From domain. `s` (strict) — DKIM signing domain must exactly match the From domain. Relaxed is correct for ~99% of setups.
• aspf= — SPF alignment mode (optional, default `r`) Same as `adkim`, but for SPF. `r` allows the SPF envelope-sender to be on a subdomain of From; `s` requires exact match. Strict aspf breaks any sender using a sending subdomain (e.g. `mail.example.com` instead of `example.com`).
• fo= — Failure-reporting options (optional, default `0`) When to send forensic reports. `0` (default) — only when both SPF and DKIM fail. `1` — when either fails. `d` — when DKIM signature fails verification. `s` — when SPF fails. Combinable (`fo=d:s`). Only matters if `ruf=` is set and receivers actually send forensic reports.
• rf= and ri= — Report format and interval (optional) `rf=afrf` is the only widely-supported value (AFRF = Authentication Failure Reporting Format). `ri=86400` is the default aggregate-report interval (24 hours). Some receivers ignore `ri=` and send daily regardless.

Moving from `p=none` to `p=reject` is the entire point of DMARC — and the single most common place teams get stuck. The fear is real: turn on enforcement, break legitimate mail, get yelled at. The right way to do it is incremental, evidence-based, and takes weeks to months. The wrong way is to flip it on a Friday.

• Step 1 — Publish `p=none` with `rua=` Goal: gather data. Set `p=none; rua=mailto:reports@yourdomain.com; pct=100`. Wait at least 2 weeks. Aggregate reports will start arriving daily from Gmail, Microsoft, Yahoo, and dozens of others. Each report lists every sending IP that authenticated as your domain.
• Step 2 — Inventory every legitimate sender From the aggregate reports, identify every sender — your ESP, your marketing platform, your transactional service, your help-desk, your calendar, every internal tool. For each, verify SPF authorizes the sending IP and DKIM is set up with a strong key. Use the SPF Checker and DKIM Checker on each.
• Step 3 — Fix the failures Reports will show senders failing SPF or DKIM. For each: either add them to SPF, add their DKIM selector, or stop using them. Don't move to enforcement until every legitimate sender passes either SPF or DKIM with alignment.
• Step 4 — Move to `p=quarantine; pct=10` Enforce on a small slice. Monitor reports daily for the first week. If aggregate counts show legitimate senders being quarantined, roll back to `p=none`, fix, retry. If not, ramp pct.
• Step 5 — Ramp pct toward 100 pct=10 → pct=25 → pct=50 → pct=100. Spend at least a week at each step. The receiving infrastructure caches DMARC policy for hours; changes take a day or two to fully propagate.
• Step 6 — Move to `p=reject; pct=100` Maximum enforcement. Spoofing attempts now get rejected outright. Continue monitoring aggregate reports forever — new senders get onboarded, services migrate, IPs change. DMARC at `p=reject` is not a 'set and forget' state; it's an ongoing operational signal.
• Common stuck points (1) `pct=10` stuck because nobody raised it; (2) `p=none` stuck because the rollout never started; (3) subdomain mail breaking because `sp=` wasn't set; (4) third-party ESP using a sending subdomain that needs alignment configured. This tool surfaces all four.

Every field — parsed record, policy scoring, alignment modes, reporting URIs, tests, AI findings — is available as JSON. Useful for DMARC-rollout monitoring, vendor onboarding, M&A diligence, and continuous policy enforcement.

curl 'https://api.domainscan.in/v1/domain/dmarc?domain=microsoft.com'

const res = await fetch(
  'https://api.domainscan.in/v1/domain/dmarc?domain=microsoft.com'
);
const dmarc = await res.json();

console.log(dmarc.dmarc);                       // raw DMARC TXT
console.log(dmarc.parsed.parsed.p);             // 'reject'
console.log(dmarc.parsed.parsed.pct);           // 100
console.log(dmarc.parsed.parsed.rua);           // ['mailto:dmarc@...']
console.log(dmarc.parsed.parsed.adkim);         // 'r' | 's'

// Effective enforcement score
const pmap = { none: 0, quarantine: 1, reject: 2 };
const policyScore = pmap[dmarc.parsed.parsed.p] ?? 0;
const pct = dmarc.parsed.parsed.pct ?? 100;
const effective = policyScore * (pct / 100);
console.log(`Effective enforcement: ${effective.toFixed(2)} / 2.0`);

// Tests
const failures = (dmarc.tests || []).filter(t => !t.passed);
failures.forEach(t => console.warn(t.test, '—', t.result));

{
  "dmarc":  "v=DMARC1; p=reject; rua=mailto:...; pct=100; adkim=r; aspf=r",

  "parsed": {
    "parsed": {
      "v":     "DMARC1",
      "p":     "none | quarantine | reject",
      "sp":    "none | quarantine | reject",
      "pct":   100,
      "rua":   ["mailto:..."],
      "ruf":   ["mailto:..."],
      "adkim": "r | s",
      "aspf":  "r | s",
      "fo":    "0 | 1 | d | s",
      "rf":    "afrf",
      "ri":    86400
    },
    "descriptions": {
      "p":   "Reject failing mail",
      "sp":  "Inherits main policy",
      "pct": "100% rollout"
    }
  },

  "tests": [
    { "test": "Multiple DMARC Records", "result": "...", "passed": true },
    { "test": "Policy Strength",        "result": "...", "passed": true },
    { "test": "Reporting URI Present",  "result": "...", "passed": true },
    { "test": "Cross-domain Authorization", "result": "...", "passed": true },
    { "test": "Percent Rollout",        "result": "...", "passed": true }
  ]
}

Six patterns we see most often:

• What is DMARC and what does it do? DMARC (Domain-based Message Authentication, Reporting, and Conformance, RFC 7489) is an email-authentication standard that sits on top of SPF and DKIM. It tells receiving mail servers what to do when SPF or DKIM fails — none (monitor only), quarantine (mark as suspicious), or reject (block). It also adds reporting so you find out who's sending mail as your domain. Without DMARC, you have authentication primitives but no policy and no visibility.
• What's the difference between p=none, p=quarantine, and p=reject? `p=none` is monitor-only — failing mail is delivered, you just get reports. `p=quarantine` tells receivers to mark failing mail as suspicious (typically delivered to junk/spam). `p=reject` tells receivers to block failing mail entirely. Production goal is `p=reject` at `pct=100`. Most domains stall at `p=none` for years.
• What does the pct tag do and why does it matter? `pct=` is the rollout percentage. `p=reject; pct=10` means only 10% of failing mail is rejected; the other 90% gets the next-weakest treatment (quarantine). Used to gradually ramp enforcement during deployment. Trap: many setups go to `pct=10` for 'testing' and never raise it — the published policy reads as `reject` but only 10% is actually enforced.
• What's the difference between adkim=r and adkim=s? Alignment strictness for DKIM. `r` (relaxed, default) — the DKIM signing domain can be any subdomain of the From domain. `s` (strict) — the DKIM signing domain must exactly match the From domain. Relaxed is correct for ~99% of setups. Strict breaks any sender using a different signing domain (most ESPs do).
• Why am I not receiving DMARC aggregate reports? Common causes: (1) `rua=` not present in the published record, (2) `rua=` typo or invalid email, (3) the receiving mailbox is full or filtering DMARC reports as spam, (4) the reporter domain differs from the published domain and the cross-domain authorization record at `<domain>._report._dmarc.<reporter>` is missing, (5) the domain doesn't receive enough mail to generate reports yet — small senders get sparse reports.
• What is DMARC alignment and why does it fail? DMARC passes only when SPF or DKIM aligns — meaning the authenticated domain matches the `From:` domain in the visible header. SPF can pass on a different envelope sender, DKIM can pass with a different signing domain, but DMARC requires alignment with the visible From. Most DMARC failures aren't SPF or DKIM failures — they're alignment failures, often because an ESP sends with the envelope-from on its own domain rather than yours.
• Do I need DMARC if I have SPF and DKIM? Functionally yes — without DMARC, receivers have authentication signals but no policy. They fall back to mailbox-provider-specific heuristics that vary unpredictably. With DMARC, you publish explicit enforcement intent that all major receivers honor. Also: post-2024, Google and Yahoo's bulk-sender requirements make DMARC mandatory for senders above 5,000 messages/day.
• Can I publish multiple DMARC records? No — RFC 7489 explicitly forbids it. Multiple DMARC records at `_dmarc.<domain>` cause receivers to ignore the entire DMARC check, treating the domain as if no policy existed. This is a frequent misconfiguration; if you want different policies for different subdomains, use the `sp=` tag in a single record at the organizational domain or publish a separate `_dmarc.<subdomain>` record per subdomain.
• What is BIMI and how is it related to DMARC? BIMI (Brand Indicators for Message Identification) is a separate standard that displays your brand logo next to authenticated mail in supporting clients. BIMI requires DMARC at `p=quarantine` or `p=reject; pct=100`. Without strict DMARC, BIMI does nothing. BIMI is often the business motivation that finally gets DMARC enforcement deployed.