DMARC · Email Authentication · Email Security · Email Deliverability

DMARC Checker: Validate Your Record and Fix Common Errors

Q: What does a DMARC checker check?

A DMARC checker reads the public TXT record at `_dmarc.yourdomain.com`, validates the version and policy tags, checks reporting and alignment syntax, detects duplicates, and often surfaces related SPF and DKIM findings. It cannot prove inbox placement from DNS alone.

Q: How do I find my DMARC record?

Look up the TXT record at `_dmarc.yourdomain.com`, either with a DNS command such as `dig TXT _dmarc.example.com` or with a DMARC checker. The result should contain `v=DMARC1` and a valid `p=` value.

Q: Is p=none a DMARC failure?

`p=none` is a valid monitoring policy, but it does not ask receivers to quarantine or reject failing mail. If a security scanner says that your “DMARC policy is not enabled,” it usually means enforcement is not active, not necessarily that the record is syntactically broken.

Q: Do I need a rua tag?

DMARC can be published without `rua`, but aggregate reports are the main way to discover legitimate and unauthorized senders during rollout. Add a reporting destination that you can monitor or process.

2026-08-31 · InboxPlacement.io Team

A DMARC checker validates the DNS record published at _dmarc.yourdomain.com, explains syntax and policy findings, and points you toward the next fix. It is the fastest way to catch a missing record, invalid tag, duplicate TXT record, or reporting and alignment problem.

What it cannot do on its own is prove that every message will reach the inbox. Inbox placement requires sending a real message and checking authentication results and mailbox placement at the providers you care about.

This guide explains what a DMARC checker tests, how to read each warning, which fixes are safe, and how to move from p=none to enforcement without blocking legitimate email.

What Does a DMARC Checker Verify?

A good checker reads your public DNS records and validates the parts of your email authentication setup that can be observed without sending a message.

Checks a DMARC checker can perform

Confirm that a TXT record exists at _dmarc.yourdomain.com.
Confirm that the record begins with v=DMARC1 and contains a valid p= policy.
Validate tag syntax for rua, ruf, pct, aspf, adkim, and related options.
Detect duplicate or multiple DMARC records at the same hostname.
Flag malformed mailbox URIs, unsupported values, and common record-format problems.
Check whether the policy applies to subdomains through sp=.
Surface related SPF and DKIM findings that can affect DMARC alignment.

What it cannot prove from DNS alone

Whether every legitimate sending service is covered by SPF.
Whether an outbound message is actually signed with DKIM.
Whether SPF or DKIM will align on a real message's headers.
Whether aggregate or forensic reports will arrive in the configured mailbox.
Whether a receiver honors every optional DMARC tag.
Whether your email will land in the inbox, Promotions, or spam.

Those limits matter. A clean DNS result means the configuration is valid to inspect; it does not replace a real-message test.

How to Check Your DMARC Record

Enter the domain used in the visible From: address, such as example.com.
Look for a TXT record at _dmarc.example.com. The record should begin with v=DMARC1.
Check the policy tag: p=none, p=quarantine, or p=reject.
Review rua and ruf reporting destinations. Addresses should use the mailto: URI format.
Check alignment modes: aspf=r or s for SPF, and adkim=r or s for DKIM.
Look for duplicate records, unsupported values, missing semicolons, or an incorrectly published hostname.
Read the related SPF and DKIM results before changing the DMARC policy.

You can also inspect the record from a terminal:

dig TXT _dmarc.yourdomain.com

For a real example, the InboxPlacement.io checker reports the overall security score, record count, and individual SPF and DMARC findings. In the example below, the DMARC record is present and set to quarantine, while the checker still recommends follow-up work on reporting and policy configuration.

InboxPlacement.io DMARC checker record overview showing a 55/100 security score, SPF warnings, a quarantine DMARC policy, and three alerts

Example DMARC checker results. The domain and record values shown are illustrative; review your own sending sources before changing policy.

How to Read Every Important DMARC Tag

`v=DMARC1`: the version

This required tag identifies the record as DMARC. It must appear at the beginning of the record. If it is missing or misspelled, receivers will not process the policy as a valid DMARC record.

`p=`: the policy for the domain

The policy tells receiving servers what to do when a message fails DMARC:

Policy	Meaning	Best use
`p=none`	Monitor failures but do not ask receivers to quarantine or reject them	Initial discovery and reporting
`p=quarantine`	Ask receivers to treat failing messages as suspicious, commonly placing them in spam	First enforcement stage
`p=reject`	Ask receivers to reject failing messages	Mature enforcement after testing

p=none is a sensible starting point, but it does not stop spoofed messages. It is monitoring, not enforcement.

`rua=`: aggregate reports

rua tells receivers where to send aggregate DMARC reports, usually as XML attachments. A typical value is:

rua=mailto:dmarc-reports@example.com

Use a mailbox or report processor that someone will actually review. If the destination belongs to a different organizational domain, that destination may also need to publish an authorization record before receivers send reports there.

`ruf=`: forensic reports

ruf requests detailed failure reports. Many receivers do not send them, and forensic reports can contain message or personal data. It is optional, so use it only when the privacy, legal, and operational tradeoffs are understood.

`pct=`: gradual policy rollout

pct=10 asks receivers to apply the policy to approximately 10% of failing messages. It can reduce rollout risk, but it is not a substitute for reviewing reports. Use pct=100 once the policy has been proven against real sending traffic.

`sp=`: the subdomain policy

sp= sets a different policy for subdomains. Without it, subdomains generally inherit the organizational domain's policy. Use it when subdomains have different senders or different readiness levels.

`aspf=` and `adkim=`: alignment strictness

Both tags accept relaxed (r) or strict (s) alignment:

Relaxed alignment: related domains can align when they share the same organizational domain.
Strict alignment: the authenticated domain must exactly match the visible From: domain.

Relaxed alignment is usually the safer starting point for third-party senders. Strict alignment can improve control, but only after every legitimate sender is configured for it.

Common DMARC Errors and Safe Fixes

1. Multiple DMARC TXT records

Problem: Two TXT records are published at _dmarc.example.com, often because a second record was added instead of editing the first. Multiple DMARC records make policy processing unreliable; RFC 7489 says receivers should not apply a policy when multiple records are returned.

Before:

"v=DMARC1; p=none; rua=mailto:reports@example.com"
"v=DMARC1; p=quarantine; rua=mailto:reports@example.com"

Fix: Keep one canonical DMARC TXT record and combine only the tags you actually need:

v=DMARC1; p=none; rua=mailto:reports@example.com

2. Missing or misspelled `v=`

Problem: A record such as p=none; rua=mailto:reports@example.com is not a valid DMARC record.

Fix:

v=DMARC1; p=none; rua=mailto:reports@example.com

The version tag belongs at the start of the record.

3. A reporting address without `mailto:`

Problem:

v=DMARC1; p=none; rua=reports@example.com

Fix:

v=DMARC1; p=none; rua=mailto:reports@example.com

Apply the same URI format to ruf. If reports go to an external reporting service, follow that service's domain-authorization instructions.

4. Raising the policy before senders are ready

Problem: Moving directly to p=reject can block legitimate messages from a CRM, marketing platform, helpdesk, or transactional provider that has not been aligned.

Safer intermediate record:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Collect reports, authenticate every legitimate sender, then move to quarantine with a controlled pct value.

5. SPF warnings mistaken for DMARC failures

DMARC depends on SPF or DKIM alignment, so a checker may surface SPF issues alongside the DMARC record. For example, the screenshot below flags a hard -all qualifier and the number of DNS lookups used. Those are SPF findings, not DMARC tags. Investigate them, but do not change SPF blindly: -all can be appropriate once every authorized sender is covered.

InboxPlacement.io DMARC checker showing detailed warnings for aggregate reporting, forensic reporting, relaxed alignment, subdomain policy, and a missing DKIM selector

The detailed checker view separates DMARC recommendations from a DKIM record error so you can fix the right layer first.

A Safe Path from p=none to Enforcement

Step 1: Inventory every legitimate sender

List your email service provider, CRM, marketing tools, invoicing system, support platform, website, and transactional services. Include forgotten systems and subdomains.

Step 2: Publish a monitoring record

Start with a valid record and an aggregate reporting destination:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

The DMARC policy itself does not need to be enforced yet. The goal is to discover what is sending on behalf of the domain.

Step 3: Analyze reports for several weeks

Group sources by IP, sending domain, SPF result, DKIM result, and DMARC alignment. Investigate sources you do not recognize separately from legitimate vendors that simply need configuration changes.

Step 4: Fix SPF and DKIM for legitimate sources

Add authorized services through the provider's documented SPF include or delegation method.
Stay within SPF's 10-DNS-lookup limit.
Enable DKIM signing in each sending service.
Publish the required DKIM selectors in DNS.
Confirm the DKIM d= domain is aligned with the visible From: domain under your chosen adkim mode.

Step 5: Test real messages

Send representative messages from every stream. Inspect the Authentication-Results, Return-Path, and DKIM-Signature headers. A DNS checker can confirm that records exist, but only a real message can confirm that the sender is authenticating and aligning as expected.

Step 6: Move to quarantine gradually

After legitimate sources are accounted for, use a record such as:

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.com

Monitor reports and mailbox results, then increase pct gradually. The exact timing depends on your sending volume and reporting cadence; do not advance on a calendar alone.

Step 7: Move to reject when evidence supports it

When legitimate traffic is consistently aligned and quarantine is not producing unexpected failures, move to:

v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@example.com

Keep monitoring after enforcement. New vendors, DNS changes, forwarding paths, and subdomain launches can introduce new failures.

How SPF and DKIM Alignment Affect DMARC

DMARC passes when either SPF or DKIM passes and the authenticated domain aligns with the domain in the visible From: header.

SPF alignment

SPF authenticates the envelope-from or return-path domain. With relaxed alignment, a related subdomain can align. With strict alignment, the domains must match exactly.

For example, a message with From: billing@example.com and a return path at bounce.vendor.example.net will not be SPF-aligned with example.com, even if the vendor's SPF authentication passes.

DKIM alignment

DKIM uses the signing domain in the d= value. A message can pass DKIM cryptographically but still fail DMARC if that signing domain is not aligned with the visible From: domain.

DKIM alignment is often valuable for forwarded mail because forwarding can change the envelope path and break SPF while leaving a valid DKIM signature intact.

What to Do After Fixing the Record

A DMARC checker answers, “Is the DNS configuration valid and what should I fix?” The next test answers, “What happens to my real email?”

Send an authenticated test message from each sending stream.
Review the message headers for SPF, DKIM, DMARC, and alignment results.
Run an inbox placement test across major mailbox providers.
Compare inbox, spam, and missing-delivery results by provider.
Continue reviewing aggregate reports after every new sender or DNS change.

For a broader DNS review, see Domain Forensic Analysis: What Your Domain Reveals About Email Risk. For the enforcement decision itself, read When to Change Your DMARC Policy: The Safe Path from p=none to p=reject.

Frequently Asked Questions

What does a DMARC checker check?

A DMARC checker reads the public TXT record at _dmarc.yourdomain.com, validates the version and policy tags, checks reporting and alignment syntax, detects duplicates, and often surfaces related SPF and DKIM findings. It cannot prove inbox placement from DNS alone.

How do I find my DMARC record?

Look up the TXT record at _dmarc.yourdomain.com, either with a DNS command such as dig TXT _dmarc.example.com or with a DMARC checker. The result should contain v=DMARC1 and a valid p= value.

Is p=none a DMARC failure?

p=none is a valid monitoring policy, but it does not ask receivers to quarantine or reject failing mail. If a security scanner says that your “DMARC policy is not enabled,” it usually means enforcement is not active, not necessarily that the record is syntactically broken.

Do I need a rua tag?

DMARC can be published without rua, but aggregate reports are the main way to discover legitimate and unauthorized senders during rollout. Add a reporting destination that you can monitor or process.

Do I need a ruf tag?

No. Forensic reporting is optional, many providers do not send it, and reports may contain sensitive message data. Aggregate reporting through rua is the usual starting point.

Can a DMARC checker confirm that my email will land in the inbox?

No. It can validate DNS configuration and identify likely problems. To measure inbox placement, send a real message and check where it lands across representative mailbox providers.

How long do DMARC DNS changes take to appear?

Many DNS changes become visible within minutes or hours, depending on TTL and resolver caching. Allow up to 48 hours for broad propagation, and recheck from more than one resolver if a result appears inconsistent.

Check Your DMARC Record and Verify Delivery

Use a DMARC checker to validate the record first, then use real-message and inbox placement testing to confirm that your authentication setup works in practice. InboxPlacement.io helps you connect DNS findings, authentication results, and mailbox placement so you can fix the highest-impact issue first.

Check your DMARC setup at InboxPlacement.io →