DMARC Lookup & Generator
Look up existing DMARC records for any domain or build a new v=DMARC1 TXT record with the interactive generator
Publish this as a TXT record on your domain's DNS. The host/name must be exactly _dmarc:
Frequently Asked Questions
none (monitor), quarantine (spam), or reject — and receive reports on authentication activity. It is published as a DNS TXT record at _dmarc.yourdomain.com.p=none to monitor without enforcing. Analyze the aggregate reports (rua) for 2-4 weeks to identify all legitimate email sources. Fix any SPF/DKIM misconfigurations. Then move to p=quarantine; pct=10 (quarantine 10% of failing mail) and gradually increase pct. Finally, move to p=reject once you're confident all legitimate mail passes. This phased approach prevents accidentally blocking legitimate email.r) allows the authenticated domain to be a parent of the From domain. For example, SPF passes if mail.example.com aligns with example.com. This is the default and works for most setups including email forwarding. Strict alignment (s) requires an exact domain match — mail.example.com would NOT align with example.com. Only use strict if you have a specific security requirement.p= tag:p=none — Monitor-only mode. No action is taken on failing emails — they are delivered normally. You receive aggregate reports to see what's happening. Use this when first setting up DMARC.
p=quarantine — Failing emails are sent to the spam/junk folder rather than rejected outright. Good intermediate step before full enforcement.
p=reject — Failing emails are rejected outright by the receiving server and never delivered. The strongest protection against spoofing. Required for BIMI logo display.
ruf (Forensic reports) — Per-message failure reports sent immediately when an email fails DMARC. They contain full email headers (and sometimes body) of failing messages, which is useful for debugging but raises privacy concerns. Many providers (Apple, Yahoo) no longer send ruf reports. Treat ruf as optional supplementary data.
rua= address to receive aggregate reports. A minimal starting record looks like:v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comRun this for 2–4 weeks and analyze the reports to identify every source sending email as your domain — your ESP, CRM, billing system, marketing tools, etc. Ensure they all have valid SPF and DKIM. Only then move to p=quarantine (start at
pct=10) and gradually increase. This phased approach prevents accidentally blocking legitimate email from services you forgot about.
From: header. This is what prevents display-name spoofing.Relaxed alignment (
adkim=r / aspf=r) — The organizational domain must match. mail.example.com aligns with example.com because they share the same organizational domain. This is the default and works for most setups.Strict alignment (
adkim=s / aspf=s) — The domains must match exactly. mail.example.com does not align with example.com. Use strict only if you have a specific security requirement — it can break email from third-party senders using subdomain envelopes.
p=reject or p=quarantine can break traditional mailing lists. When a list server resends a message, it preserves the original From: header (your domain) but sends from its own IP — which fails SPF. And if the list server modifies the message body (adds a footer, etc.), DKIM also fails. The result is DMARC failure and the message being rejected or quarantined at recipients' mail servers.Modern mailing list software handles this by rewriting the
From: header to the list's own domain (e.g. via lists.example.net) or using the ARC (Authenticated Received Chain) protocol to preserve authentication across forwarding. If you use mailing lists, check with the list provider for DMARC compatibility before enforcing a strict policy.
pct=100 (all failing emails). Setting pct=10 means the quarantine or reject policy only applies to approximately 10% of failing messages — the other 90% are treated as if the policy were p=none. This allows a gradual rollout: start at p=quarantine; pct=10, watch for legitimate email being caught, increase to 25%, 50%, 75%, 100% over several weeks. This is far safer than jumping straight to p=reject; pct=100. Once you reach pct=100, you can remove the tag entirely (it defaults to 100).
About This DMARC Lookup & Generator
This free DMARC tool has two modes. The Lookup tab queries the _dmarc.{domain} DNS TXT record and displays the full parsed breakdown of every tag. The Generator tab builds a valid DMARC record interactively, covering all tags including policy, subdomain policy, aggregate/forensic reporting addresses, alignment modes, and the percentage rollout parameter.
When to use this tool
- Verify that DMARC is published and check the current enforcement policy level
- Troubleshoot SPF/DKIM alignment failures causing email delivery issues
- Build a new DMARC record for a gradual rollout from
p=nonetop=reject - Review or update aggregate and forensic reporting addresses
DMARC Tag Reference
| Tag | Name | Default | Description |
|---|---|---|---|
v | Version | — | Must be DMARC1. Required. |
p | Policy | — | none, quarantine, or reject. Required. |
sp | Subdomain Policy | Inherits p | Policy for subdomains. Overrides p for subdomain mail. |
rua | Aggregate Report URI | None | Where to send daily aggregate XML reports (mailto:). |
ruf | Forensic Report URI | None | Where to send per-message forensic failure reports. |
pct | Percentage | 100 | Percentage of failing messages the policy is applied to. |
adkim | DKIM Alignment | r | r = relaxed, s = strict. |
aspf | SPF Alignment | r | r = relaxed, s = strict. |
fo | Failure Options | 0 | When to generate forensic reports: 0=both fail, 1=either fails, d=DKIM fail, s=SPF fail. |
ri | Report Interval | 86400 | Seconds between aggregate reports. Most providers ignore this and send daily. |
How DMARC Works
When a receiving mail server gets an email claiming to be from your domain, it follows this process:
Check SPF
Verify the sending server's IP address is listed in the domain's SPF record. This confirms the mail was sent from an authorized server.
Check DKIM
Verify the email's cryptographic DKIM signature against the public key in DNS. This confirms the message body wasn't altered in transit.
Apply DMARC Policy
If either SPF or DKIM passes and the authenticated domain aligns with the From header, DMARC passes. Otherwise the domain's p= policy is applied.
From: header. This is what prevents display-name spoofing.
DMARC Rollout Checklist
Follow this phased approach to reach p=reject safely without disrupting legitimate email.
-
1
Audit your email sendersList every service that sends email from your domain — ESP, CRM, ticketing, transactional email, billing tools, etc. Each one needs a valid SPF include and/or DKIM signature.
-
2
Publish SPF and DKIM for all sendersUse SPF Lookup & Generator to verify your SPF record includes all sending IPs. Use DKIM Checker to confirm all selectors resolve correctly.
-
3
Start with
p=none; rua=mailto:you@domain.comThis is monitor-only mode. No email is rejected. Collect aggregate reports for 2–4 weeks to build a complete picture of who is sending email as your domain. -
4
Move to
p=quarantine; pct=10Apply quarantine policy to 10% of failing messages. Watch reports for legitimate email caught by the policy. Fix any remaining authentication gaps. Increasepct=weekly (25 → 50 → 75 → 100). -
5
Reach
p=rejectOnce you're confident all legitimate email passes, setp=reject. Receiving servers will outright block unauthenticated mail claiming to be from your domain — the strongest protection against spoofing and phishing.
Common DMARC Mistakes to Avoid
Jumping straight to p=reject
Skipping the monitoring phase (p=none) risks blocking legitimate email from services you forgot were sending on your behalf — such as a CRM, HR system, or mailing list.
No rua= address
Without an aggregate report address you're flying blind. You won't know which servers are sending email as your domain, making it impossible to safely tighten the policy.
Strict alignment with third-party senders
Using adkim=s or aspf=s breaks many ESPs that send from subdomain envelopes. Keep alignment relaxed (r) unless you have a specific reason to tighten it.
Forgetting subdomains
DMARC applies to the organizational domain and all subdomains unless you set a separate sp= policy. If a subdomain sends mail, ensure it also has proper SPF and DKIM.
Publishing multiple DMARC records
A domain must have exactly one _dmarc TXT record. Publishing two records causes a DMARC permerror and most receivers will treat it as no DMARC record at all.
Ignoring email forwarding
Email forwarding often breaks SPF (the forwarding server's IP is not in your SPF record) and may re-sign DKIM. With p=reject, forwarded email may be lost. Consider this before enforcing.
The Email Authentication Stack
DMARC is the policy layer that ties together SPF and DKIM. All three work together to protect your domain from spoofing and improve deliverability.
| Protocol | What it authenticates | DNS Record | Our Tool |
|---|---|---|---|
| SPF | The sending server's IP address is authorized to send for the domain | TXT at root domain |
SPF Lookup & Generator |
| DKIM | The message was cryptographically signed by an authorized sender and not altered | TXT at {selector}._domainkey.{domain} |
DKIM Checker |
| DMARC | SPF/DKIM alignment with the visible From: header — sets enforcement policy and reporting |
TXT at _dmarc.{domain} |
This tool |
| BIMI | Displays the domain's brand logo in supporting email clients once SPF, DKIM, and DMARC all pass | TXT at default._bimi.{domain} |
BIMI Lookup & Generator |
| MX | Where inbound email for the domain should be delivered | MX at root domain |
MX Lookup |
Related Articles
View all articles
Why DMARC Forensic Reports Are Almost Never Deployed — ruf=, Privacy, and the pct= Gradual Rollout Strategy
DMARC forensic reports (ruf=) send full copies of failing messages to a specified inbox — which means receiving copies of phishing emails, confidential business email, and PII. Here's why ruf= is almost never deployed (Google and Microsoft don't send them, privacy obligations, volume), how the pct= percentage tag enables gradual p=reject rollout, and why external third-party DMARC reporting services need DNS verification before they can receive your reports.
What DMARC Aggregate Reports Actually Tell You — and How to Turn Raw XML Into an Authorized Sender Inventory
DMARC aggregate reports arrive as zipped XML — effectively unreadable without tooling — and the organizations generating the most complex reports are exactly those with the most to learn from them. Here's what each field in an aggregate report actually tells you, the two-type categorization of findings (legitimate-unauthenticated vs hostile), the recommended inventory-building process before moving to p=reject, and how third-party DMARC reporting services make this data actionable.
DMARC for Domains That Never Send Email: Why p=reject Can (and Should) Be Immediate
A domain that never sends email is, paradoxically, an easy spoofing target — recipients have no way to know "this domain never sends mail" without DMARC explicitly saying so. Here's why p=reject can be applied immediately (with zero risk) to parked/non-sending domains and subdomains, how sp= protects subdomains separately from the primary domain's policy, and why BIMI specifically requires p=quarantine or p=reject, not p=none.
DMARC Alignment: Why SPF and DKIM Can "Pass" While DMARC Still Fails
"SPF passes" and "DKIM passes" don't mean DMARC passes — DMARC additionally requires alignment between the visible From domain and the domain that actually passed SPF or DKIM. Here's the distinction between envelope sender and visible From, relaxed vs strict alignment, and why DMARC passes if EITHER SPF or DKIM is aligned — the key to debugging most DMARC failures with third-party senders.
Reading DMARC XML Reports: What Every Field Means and How to Spot Problems
DMARC aggregate reports are XML files that arrive by email and most people never open. Here's exactly what each field means, the common patterns and what they signal (SPF fail but DMARC pass, alignment failures, unknown IPs), and the tools that make reports readable.
