Try the DMARC Lookup

DMARC Lookup — Check Your Domain's Email Policy & Anti-Spoofing Protection

By sadiqbd · June 6, 2026

DMARC Lookup — Check Your Domain's Email Policy & Anti-Spoofing Protection

DMARC is where email authentication policy gets enforced

SPF and DKIM are the verification mechanisms. DMARC is what ties them together and tells receiving mail servers what to do when they fail. Without DMARC, even perfectly configured SPF and DKIM records don't actively protect your domain from being used in phishing — email servers will verify but not act on failures. With DMARC at enforcement, they will.

A DMARC lookup retrieves your domain's DMARC policy record and shows you exactly what policy is in place — and what receiving servers are doing with your emails.

What DMARC Does

Domain-based Message Authentication, Reporting, and Conformance does three things:

  1. Alignment — checks that the domain in the From: header (the domain recipients see) aligns with the domain authenticated by SPF and/or DKIM. Alignment means a spoofer using a legitimate SPF or DKIM setup for a different domain can't impersonate your From domain.

  2. Policy — specifies what receiving servers should do with emails that fail DMARC alignment: nothing (none), send to spam (quarantine), or reject (reject).

  3. Reporting — instructs receiving servers to send aggregate (RUA) and forensic (RUF) reports back to an address you specify, giving you visibility into who's sending email using your domain.

The DMARC DNS Record

DMARC is published as a TXT record at _dmarc.[domain]:

_dmarc.example.com  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; pct=100"

Key tags:

Tag Meaning
v=DMARC1 DMARC version
p= Policy: none, quarantine, or reject
rua= Aggregate report destination (daily XML reports)
ruf= Forensic report destination (per-failure reports)
pct= Percentage of emails subject to the policy (default 100)
sp= Subdomain policy (defaults to same as p=)
adkim= DKIM alignment mode: r (relaxed) or s (strict)
aspf= SPF alignment mode: r (relaxed) or s (strict)

DMARC Policy Levels

p=none (monitoring mode): Emails are delivered normally regardless of DMARC result. Reports are sent to rua= and ruf=. This is the starting point — you observe what's happening before enforcing policy. It provides zero protection against spoofing.

p=quarantine: Emails failing DMARC are sent to the recipient's spam/junk folder. Partial protection — phishing emails reach inboxes less often but aren't blocked outright.

p=reject: Emails failing DMARC are rejected outright at the receiving server. This is full protection. Spoofing attempts using your domain are blocked before delivery.

The progression: Start at none, monitor reports to understand your email sending landscape, ensure legitimate senders are authenticated, then move to quarantine, then reject.

How to Use the DMARC Lookup on sadiqbd.com

  1. Enter the domain — the domain you want to check.
  2. Run the lookup — the tool queries _dmarc.[domain].
  3. Read the result — the full DMARC record with each tag interpreted in plain language.

What the Lookup Results Mean

Record found with p=reject: Full DMARC enforcement. Spoofed emails claiming to come from this domain are rejected. This is the target state.

Record found with p=quarantine: Partial enforcement. Better than none, but not full protection. Consider moving to p=reject after confirming all legitimate email flows pass authentication.

Record found with p=none: Monitoring mode only. No active protection. Reports are being collected (if rua= is set), but failing emails are delivered normally.

Record not found: No DMARC policy. Receiving servers do their own thing with authentication failures — typically deliver regardless of SPF/DKIM result. Your domain can be freely spoofed in phishing attacks.

pct= less than 100: The policy applies to only that percentage of non-authenticating emails. A common transitional approach — e.g. pct=50 applies the policy to half of failing emails while you build confidence in your authentication setup.

Real-World Examples

Diagnosing why emails are being rejected

A company's automated transactional emails (from a third-party platform) are being rejected by Gmail. DMARC lookup reveals p=reject, and the emails are failing because:

  1. The third-party platform sends from noreply@example.com (From header)
  2. The platform's own DKIM key is for platform.com, not example.com
  3. SPF doesn't include the platform's sending IPs

DMARC alignment fails → emails rejected per p=reject policy.

Fix: either add the platform's sending IPs to example.com's SPF record, or enable DKIM signing for the example.com domain through the platform, to achieve alignment.

Checking a competitor or phishing-target domain

Is a domain vulnerable to email spoofing? Look up their DMARC record. If p=none or the record is missing, phishing attacks using their From address would not be blocked by DMARC. Useful for security assessments and threat intelligence.

Confirming reporting is configured

The rua= tag determines whether you receive aggregate reports. If it's missing, you're deploying DMARC without visibility into failures — flying blind. Always include rua= pointing to an address you actively monitor (or a DMARC reporting service like Postmark, Dmarcian, or Valimail).

Common DMARC Mistakes

Moving to p=reject too fast. Before enforcing rejection, you need to ensure all legitimate email flows (marketing platforms, CRMs, helpdesk systems, transactional email services) are properly authenticated and DMARC-aligned. Premature enforcement can block your own legitimate email.

Not monitoring rua= reports. Aggregate reports reveal exactly which sources are sending email on your domain's behalf, and whether they're passing or failing authentication. Without reading these, you're deploying DMARC blind.

Forgetting subdomains. p= applies to the root domain. The sp= tag controls subdomain policy. If you have p=reject but sp=none, subdomains remain unprotected.

Relaxed vs. strict alignment. The default (adkim=r, aspf=r) relaxed mode allows the root domain and its subdomains to align. Strict mode (s) requires exact domain matching. For most organisations, relaxed is appropriate; strict is for high-security contexts.

Frequently Asked Questions

Does DMARC prevent all email spoofing? DMARC prevents spoofing of the exact From header domain at DMARC-checking receiving servers. It doesn't prevent display name spoofing (where the sender name is your brand but the email address is different), cousin domain spoofing (lookalike domains like examp1e.com), or attacks at non-DMARC-checking mail servers.

What's the difference between DMARC none and not having DMARC at all? Functionally identical for deliverability and security — both provide zero enforcement. The difference is that p=none with rua= gives you aggregate reports; no record gives you nothing. Always add DMARC even at p=none to start collecting data.

How do I get DMARC aggregate reports in a readable format? Aggregate reports are XML files delivered to the rua= address daily. They're not human-readable as raw XML. DMARC reporting tools (Dmarcian, Postmark, Google Postmaster Tools, and free options) parse these into dashboards. Set up a reporting tool from day one.

Is it safe to go directly to p=reject? Only if you're confident all legitimate email is authenticated and DMARC-aligned. For a new implementation, start at p=none, collect reports for 2–4 weeks, ensure all senders pass, then move to quarantine, then reject.

Is the DMARC lookup free? Yes — completely free, no sign-up required.

DMARC is the difference between "we have SPF and DKIM" and "we have email authentication that actually protects our domain." The lookup tool shows you exactly what policy is in place — and whether it's doing its job.

Try the DMARC Lookup free at sadiqbd.com — check any domain's DMARC policy and reporting configuration instantly.

Try the related tool:
Open tool