DMARC · Email Authentication · Email Security · Email Deliverability
DMARC Checker: Validate Your Record and Fix Common Errors
· 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.
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.
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 →
Related: DMARC Monitoring Explained: Protect Your Domain from Email Spoofing · The Complete Guide to DMARC Monitoring in 2025 · Email Deliverability Checker: What Each Test Reveals
Sources
- DMARC specification (RFC 7489)
- DKIM specification (RFC 6376)
- SPF specification (RFC 7208)
- DMARC.org
- Google Workspace email authentication requirements
- Yahoo sender best practices