DMARC Record Checker
Enter a domain to check its DMARC record, validate the policy, and get recommendations to improve email security.
Enter the domain from your email's From address (e.g., yourcompany.com)
Checking DMARC record...
Querying DNS records
Your DMARC analysis is ready
Enter your email to see the full breakdown. We'll send you a copy, that's it, no marketing emails.
Lookups performed via public DNS. No spam, no mailing list, just your analysis.
Your DMARC record looks good.
Policy Overview
DMARC Record
Record Tags
| Tag | Value | Meaning |
|---|
What is DMARC?
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is an email authentication protocol built on top of SPF and DKIM. Defined in RFC 7489, DMARC allows domain owners to publish a policy that tells receiving mail servers what to do when an email fails authentication checks. It also provides a reporting mechanism so domain owners can monitor how their domain is being used across the internet.
Without DMARC, even if you have SPF and DKIM configured, there is no way to tell receiving servers to reject or quarantine emails that fail those checks. DMARC bridges this gap by adding policy enforcement and visibility. It is the single most effective tool for preventing domain spoofing and phishing.
DMARC records are published as DNS TXT records at _dmarc.yourdomain.com. When a receiving server gets an email from your domain, it checks this record to determine the policy and alignment requirements.
How DMARC Works
DMARC adds a policy layer on top of SPF and DKIM authentication. Here is how the process works from start to finish:
1. Email arrives at the receiving server
When an email claims to be from your domain, the receiving mail server first performs SPF and DKIM checks independently. SPF verifies the sending IP is authorized, while DKIM verifies the message signature.
2. Server looks up your DMARC record
The receiver queries DNS for a TXT record at _dmarc.yourdomain.com. This record contains your DMARC policy and configuration.
3. Alignment is checked
DMARC requires that either SPF or DKIM not only passes but also aligns with the domain in the visible From header. Alignment can be "strict" (exact domain match) or "relaxed" (organizational domain match, allowing subdomains). The email passes DMARC if at least one of SPF or DKIM both passes and aligns.
4. Policy is applied
If the email fails DMARC, the receiving server applies your published policy: none (monitor only, deliver normally), quarantine (send to spam/junk), or reject (refuse delivery entirely). The pct tag controls what percentage of failing messages the policy applies to.
5. Reports are sent
Receiving servers send aggregate reports (XML files) to the addresses specified in your rua tag. These reports show which IPs are sending email as your domain and whether they pass or fail authentication. Forensic reports (ruf) provide details about individual failures.
DMARC Tags Explained
A DMARC record is made up of tag-value pairs separated by semicolons. The v and p tags are required; all others are optional.
| Tag | Example | Required | Description |
|---|---|---|---|
v | v=DMARC1 | Yes | Version identifier. Must be DMARC1 and must be the first tag in the record. |
p | p=reject | Yes | Policy for the domain. Values: none (monitor), quarantine (spam folder), reject (refuse delivery). |
sp | sp=quarantine | No | Policy for subdomains. If not set, inherits the p value. Useful when subdomains need different treatment. |
pct | pct=50 | No | Percentage of failing messages the policy applies to (1-100). Default is 100. Used for gradual policy rollout. |
rua | rua=mailto:dmarc@example.com | No | Aggregate report destination(s). Comma-separated mailto: URIs. These XML reports show authentication results. |
ruf | ruf=mailto:forensics@example.com | No | Forensic (failure) report destination(s). Provides details about individual DMARC failures. Few providers send these. |
adkim | adkim=s | No | DKIM alignment mode. r = relaxed (default, allows subdomains), s = strict (exact domain match only). |
aspf | aspf=s | No | SPF alignment mode. r = relaxed (default, allows subdomains), s = strict (exact domain match only). |
fo | fo=1 | No | Failure reporting options. 0 = report if all fail (default), 1 = report if any fail, d = DKIM failure, s = SPF failure. |
rf | rf=afrf | No | Forensic report format. Default is afrf (Authentication Failure Reporting Format). Rarely changed. |
ri | ri=86400 | No | Aggregate report interval in seconds. Default is 86400 (24 hours). Most receivers ignore custom values. |
Common DMARC Mistakes
1. Staying on p=none indefinitely
Many domains set up DMARC with p=none to start monitoring, which is correct. The mistake is never progressing to quarantine or reject. A none policy provides zero protection against spoofing. It tells receivers "I don't care if authentication fails, deliver the email anyway." Use the monitoring period to identify and fix legitimate sources, then move to enforcement.
2. No reporting addresses
Publishing a DMARC record without a rua tag means you get no aggregate reports. Without reports, you have no visibility into who is sending email as your domain, whether legitimate sources are passing authentication, or whether attackers are spoofing you. Always include at least one rua address.
3. Jumping to p=reject too fast
Setting p=reject before ensuring all legitimate email sources pass DMARC will cause legitimate email to be rejected. Follow the recommended path: start with p=none and rua reporting, review reports for 2-4 weeks, fix any alignment issues, then move to p=quarantine, and finally to p=reject.
4. Forgetting about subdomains
Without an sp tag, subdomains inherit the main domain's policy. If your main policy is p=reject but you use subdomains for marketing email that isn't properly authenticated, those emails will be rejected. Use the sp tag to set a separate policy for subdomains when needed.
5. Misunderstanding alignment
DMARC doesn't just require SPF or DKIM to pass—it requires alignment. This means the domain authenticated by SPF (the Return-Path domain) or DKIM (the d= domain in the signature) must match the domain in the visible From header. Third-party services that send on your behalf may pass SPF for their own domain but fail DMARC alignment because the domains don't match.
Frequently Asked Questions
What happens if I don't have a DMARC record?
Without a DMARC record, receiving servers have no instructions on what to do when SPF or DKIM fails. Your domain is effectively unprotected against spoofing. Anyone can send emails that appear to come from your domain, and receivers have no policy to reject them. Additionally, you won't receive any aggregate reports about email authentication results, leaving you blind to how your domain is being used or abused.
Do I need SPF and DKIM before setting up DMARC?
You need at least one of SPF or DKIM properly configured before DMARC can pass, because DMARC relies on these protocols for authentication. In practice, you should have both. SPF validates the sending server, DKIM validates the message integrity, and DMARC ties them together with a policy. Setting up DMARC without SPF or DKIM means all your email will fail DMARC checks.
What's the difference between p=none, p=quarantine, and p=reject?
p=none means "do nothing with failing emails, just send me reports." It's the monitoring-only mode. p=quarantine means "send failing emails to the spam/junk folder." p=reject means "refuse to deliver failing emails entirely." The recommended progression is none → quarantine → reject, giving you time to identify and fix legitimate sources before enforcement blocks real email.
How do I read DMARC aggregate reports?
DMARC aggregate reports are XML files sent by receiving mail servers. They contain data about which IPs sent email using your domain and whether those emails passed or failed SPF, DKIM, and DMARC. Reading raw XML is difficult, so most people use a DMARC report analyzer tool. Our free DMARC XML Analyzer lets you upload these files and instantly see a visual breakdown of your authentication results.
Can DMARC prevent all phishing?
DMARC prevents exact-domain spoofing, where an attacker sends email with your exact domain in the From address. However, it cannot prevent "lookalike" or cousin domain attacks (e.g., using "examp1e.com" instead of "example.com"), display name spoofing (where the sender name looks like yours but the email address is different), or phishing from compromised legitimate accounts. DMARC is a critical layer of defense but should be part of a broader security strategy.