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
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.
DMARC Deployment: How to Move from p=none to p=reject Without Breaking Email
Most DMARC records are at p=none — monitoring mode with no actual protection. Here's the safe four-phase path from p=none to p=reject, how to read aggregate reports, the February 2024 Google/Yahoo requirements, and common mistakes.
DMARC Lookup — Check Your Domain's Email Policy & Anti-Spoofing Protection
Learn how DMARC works, what the none/quarantine/reject policies mean, how to read a DMARC record, and how to use a free DMARC lookup to diagnose email authentication and spoofing protection.
