Free Tools

DMARC Checker

Check your domain's DMARC record, policy strength, subdomain policy, and enforcement coverage.

Why DMARC matters

Without DMARC, any server on the internet can send email with your domain in the From address. Recipients have no automated way to know the message is fraudulent. Phishing campaigns, supplier impersonation attacks, and BEC (business email compromise) all rely on this gap.

DMARC closes that gap by publishing a policy in DNS — at  _dmarc.yourdomain.com — that instructs receiving mail servers to check SPF and DKIM alignment, and what to do when those checks fail: deliver, quarantine, or reject.

The rua= reporting tag provides aggregate visibility into every source sending mail as your domain — including sources you didn't know existed. That data is the foundation of a safe migration from  p=none to  p=reject.

Common DMARC issues

No DMARC record

The domain publishes no TXT record at  _dmarc.. Receiving servers apply their own local policies — often deliver — and you receive no reporting.

Fix: publish v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com to start collecting data.

Policy stuck at p=none

p=none means DMARC is monitoring but not enforcing. Spoofed messages are still delivered to recipients. Many organizations publish p=none to begin with and never advance it.

Fix: analyse rua= reports, align all legitimate senders, then advance to p=quarantine then p=reject.

Partial enforcement (pct < 100)

A pct value below 100 means only a fraction of failing messages are actioned. This is useful during rollout but must not become permanent — it leaves a predictable bypass window.

Fix: raise pct gradually from 10 → 50 → 100 as you confirm clean delivery reports.

Subdomains unprotected

When sp= is absent or set to none, subdomains can be used for spoofing even when the apex domain has a strict policy. Forgotten subdomains are common attack targets.

Fix: explicitly set sp=quarantine or sp=reject once subdomains are authenticated.

Monitor DMARC changes over time

DMARC records can change silently. A deployment that updates DNS may replace or corrupt the record. A vendor migration may introduce a new mail source that breaks alignment, causing legitimate email to be rejected under p=reject.

DomainRisk.io tracks the full DMARC record and policy on every scan. Any change — a policy downgrade, a pct reduction, a record going missing — triggers an alert so you catch regressions before they affect deliverability or let attackers through.

Frequently asked questions

What is DMARC?
Domain-based Message Authentication, Reporting and Conformance (DMARC) is a DNS-based email authentication protocol published as a TXT record at _dmarc.<yourdomain>. It tells receiving mail servers what to do with messages that fail SPF and DKIM checks, and where to send reports about those failures. It is the primary mechanism for preventing email spoofing and domain impersonation.
What is the difference between p=none, p=quarantine, and p=reject?
p=none is monitoring mode — failing messages are delivered normally, and only reports are generated. It provides no protection against spoofing but is a safe starting point for gathering visibility. p=quarantine instructs receiving servers to flag or move failing messages to the spam folder. p=reject is full enforcement — failing messages are rejected outright and never delivered. Reject is the recommended end state for domains that send email.
What does pct= mean in a DMARC record?
The pct tag defines what percentage of messages are subject to the DMARC policy. pct=100 (the default) means the policy applies to all qualifying messages. A lower value such as pct=10 is a gradual rollout technique — only 10% of failing messages are actioned, giving you time to fix authentication issues before full enforcement. Always aim for pct=100 at your target policy.
What is the sp= tag and when does it matter?
The sp= tag sets the DMARC policy for subdomains independently of the apex domain policy. If sp= is absent, subdomains inherit the apex p= policy. This matters when you have subdomains used for transactional email that may not yet be fully authenticated — you can set a stricter p=reject on the apex while keeping sp=quarantine for subdomains during the transition.
Do I need SPF and DKIM to use DMARC?
DMARC relies on at least one of SPF or DKIM to be aligned with the From domain. Without both, DMARC enforcement may incorrectly reject legitimate email. Publishing a DMARC record at p=none first, then fixing SPF and DKIM alignment, then raising the policy is the standard deployment path. Deploying p=reject without confirmed SPF and DKIM alignment will block your own legitimate mail.
What happens to emails that fail DMARC when p=reject?
Receiving mail servers reject the message during the SMTP session and return a bounce to the sending server. The message is never delivered to the recipient's inbox. The failure is also captured in aggregate (rua=) and forensic (ruf=) DMARC reports sent back to the domain owner, providing visibility into who is sending mail using your domain.
How do I safely move from p=none to p=reject?
Start by publishing p=none with rua= pointing to a reporting mailbox or DMARC reporting service. Analyse aggregate reports for 2–4 weeks to identify all legitimate email sources. Configure SPF for each source and ensure DKIM signatures are in place. Once reports show a clean baseline, move to p=quarantine at pct=10, gradually increase pct to 100, monitor for bounces, then advance to p=reject. The full transition typically takes 4–12 weeks depending on your email complexity.
Continuous monitoring

Start continuous domain security monitoring

DMARC, SPF, DKIM, DNS, SSL, WHOIS and subdomains — monitored continuously with change alerts and an explainable risk score.

Start Free TrialSee all features

Scan limit reached

You've used your 5 free scans for this minute.

Create a free account for unlimited scans, continuous monitoring, full findings and remediation guidance.

Create a free account