Free DMARC Tester & Record Checker
Run DMARC checks for any domain: find the public TXT record, validate its policy and tags, and see record-level issues to fix. Live DNS, read-only, and no signup.
What does a DMARC checker prove?
A DMARC checker queries the public TXT record at _dmarc.yourdomain.com, validates its syntax and policy tags, and translates values such as p, sp, rua, aspf, and adkim. It proves what DNS publishes at that moment. It cannot prove that production messages pass DMARC or identify every legitimate sender.
How to read your result
| Result | What it means | What to do |
|---|---|---|
| v=DMARC1; p=reject | Full enforcement request: participating receivers are asked to reject mail that fails DMARC. | Keep rua reporting on and watch for new senders before you onboard them. |
| p=quarantine | Enforcement request, softened: receivers are asked to treat failing mail as suspicious, often by placing it in spam. | Review a representative business sending cycle and verify every legitimate sender before considering p=reject. |
| p=none | Monitoring only: the domain requests reports but no enforcement handling for failed messages. | Fix SPF/DKIM alignment for every sender in your reports, then step up to quarantine. |
| No DMARC record found | The domain publishes no DMARC handling preference or aggregate-report request and does not meet the DMARC-policy portion of current bulk-sender requirements. | Publish v=DMARC1; p=none with a rua address at _dmarc.yourdomain.com today, then walk it up. |
| More than one DMARC record | Multiple records are discarded during DMARC policy discovery under RFC 9989. | Delete every TXT record at _dmarc except one. |
| Syntax error | A malformed required tag or value can make the policy unusable. v=DMARC1 must be first and p must contain a valid policy value. | Review the specific parsing error, rebuild the affected tag, and publish one usable record. |
| Unknown tag | RFC 9989 requires receivers to ignore unrecognized tags and continue processing recognized tags; an unknown tag alone does not invalidate the record. | Confirm that the tag is intentional. Remove it if it is a typo or no longer serves an interoperable purpose. |
| Legacy pct tag | RFC 9989 removed pct because receivers applied intermediate percentages inconsistently. | Use reports and controlled policy changes to stage enforcement; remove legacy pct after reviewing interoperability. |
| No rua tag | No aggregate reports are requested, reducing the evidence available for sender inventory and policy changes. | Add rua=mailto:… so enforcement decisions are driven by data. |
| sp weaker than p | When this record is selected at an Organizational Domain or PSD, existing subdomains can receive a looser requested policy than the organizational domain. | Inventory legitimate subdomain senders, then retain an intentional sp policy or let the applicable parent policy control them. |
What this checker can prove
The checker proves what public DNS returns at the DMARC policy name and whether the record's tags parse into a usable policy. Its interpretation follows the current RFC 9989 DMARC standard. It cannot prove that a production message passed SPF or DKIM, discover every legitimate sender, or predict a receiver's private handling decision. Use the email header analyzer for a real production message and the DMARC report analyzer for aggregate-report evidence. If the record itself is missing or malformed, build a replacement with the DMARC generator.
For a benchmark beyond one domain, Palisade's State of DMARC 2026 analyzes enforcement across the top 100,000 domains and documents the methodology behind the result.
From a public result to an enforcement workflow
A one-shot check shows you today's problem. Getting to enforcement is the actual work: reading aggregate reports, aligning SPF and DKIM for every legitimate sender, and tightening the policy without disrupting real mail. Palisade turns those reports into a prioritized workflow so operators can identify senders, investigate alignment failures, review proposed record changes, and progress each domain toward enforcement with evidence.
For MSPs it's built multi-tenant: every client domain checked, remediated, and enforced from one console, with portfolio-based per-client-domain pricing whose rate improves as you scale, without metering client email volume.
Related checks and terms
p=nonep=quarantinep=rejectadkim / aspfdmarc=failDMARC software that does the work
Palisade organizes DMARC report evidence into prioritized sender and alignment work, helping operators review changes and move domains toward enforcement from one console.
1 domain free up to 1,000 emails/month
Email authentication knowledge base
What does a DMARC checker look up?
A DMARC checker queries the public TXT record at _dmarc.yourdomain.com and validates its tags, including p, sp, rua, aspf, and adkim. It can show the policy currently published in DNS. It cannot prove that a production message passed SPF, DKIM, or DMARC.
Does p=reject guarantee that every failed message is rejected?
No. p=reject expresses the domain owner's request that receivers reject messages that fail DMARC. Receiving systems make the final handling decision. Before publishing p=reject, verify every legitimate sending stream produces an aligned SPF or DKIM pass.
Can this checker prove that my email passes DMARC?
No. A public record can be valid while a real sender still fails because its Return-Path or DKIM signing domain does not align with the visible From domain. Test a message sent through the production stream and inspect its Authentication-Results header.
What is DMARC alignment?
DMARC alignment compares the visible From domain with an authenticated SPF domain or DKIM signing domain. A message passes DMARC when SPF or DKIM both passes and aligns. Relaxed alignment permits the same organizational domain; strict alignment requires an exact domain match.
Why are multiple DMARC records invalid?
DMARC policy discovery expects one usable TXT policy record at a given name. Under RFC 9989, if multiple DMARC policy records remain at the same target, they are discarded. Consolidate the tags into one record at _dmarc and remove the duplicates.
Is p=none enough?
p=none is useful for monitoring and collecting reports, but it requests no enforcement handling for messages that fail DMARC. Use the reports to inventory and align legitimate senders, then move deliberately to quarantine and reject when the evidence is clean.
How should I use aggregate reports before enforcement?
Use aggregate reports to identify sending sources, assign each legitimate source an owner, and investigate SPF, DKIM, and alignment failures. Confirm important streams with real message headers, then change policy only after a full business sending cycle shows that legitimate mail is ready.
What changed in RFC 9989?
RFC 9989 replaced RFC 7489 as the Standards Track DMARC specification in May 2026. It uses DNS tree-walk discovery, includes np, psd, and t tags, and removes the legacy pct tag. Aggregate and failure reporting are specified separately in RFC 9990 and RFC 9991.
Does DMARC stop every phishing or BEC attack?
No. DMARC can reduce direct spoofing of a protected domain at participating receivers, but it does not stop lookalike domains, display-name impersonation, compromised accounts, or every phishing technique. It is one domain-authentication control, not a mailbox filter or complete anti-phishing system.
Every tag you can include in a DMARC record and what each one controls.
- vVersion
- The Version tag is essential in a DMARC record and must strictly be set to ‘DMARC1’. If this value is not correctly specified or if the tag is absent, the DMARC record will not be considered valid and will be disregarded.
- pDMARC policy
- The DMARC policy setting is crucial and accepts three possible values: ‘none’, ‘quarantine’, or ‘reject’. By default, it is set to ‘none’, which means it doesn’t actively intervene with emails that fail authentication. This setting primarily serves to gather DMARC reports, aiding in understanding the existing email traffic and its authentication status. On the other hand, the ‘quarantine’ option flags unauthenticated emails as dubious, and ‘reject’ outright prevents their delivery.
- ruaAggregate report destination
- The destination for sending aggregate reports is specified using a ‘mailto:’ URI, which Email Service Providers (ESPs) utilize to dispatch failure reports. While this tag is not mandatory, omitting it means you will not receive any reports.
- rufForensic report destination
- The destination for Forensic (Failure) report transmission is designated by a ‘mailto:’ URI, which is employed by Email Service Providers (ESPs) for the delivery of failure reports. Although this tag is not obligatory, failing to include it will result in not receiving any reports.
- spSubdomain policy
- The policy for subdomains defaults to inheriting the main domain’s policy tag (p=), as previously described, unless explicitly stated otherwise. Similar to the domain policy, the permissible values for subdomains are ‘none’, ‘quarantine’, or ‘reject’. However, this option is not commonly employed in current practices.
- adkimDKIM alignment
- The alignment of the DKIM signature, indicated by this tag, refers to the congruence between the DKIM domain and the originating domain in the ‘Header From’. The acceptable values for this tag are ‘r’ for relaxed and ‘s’ for strict. The default setting, ‘r’, permits a partial match between these domains, whereas the ‘s’ setting demands an exact match of the domains.
- aspfSPF alignment
- This tag pertains to the SPF alignment, which concerns the compatibility between the SPF domain (the sender) and the domain in the ‘Header From’. It allows two settings: ‘r’ for relaxed and ‘s’ for strict. By default, it is set to ‘r’, which tolerates a partial match between the domains. In contrast, the ‘s’ setting necessitates an exact correspondence of the domains.
- foForensic reporting options
- The options for forensic reporting include ‘0’, ‘1’, ‘d’, and ‘s’. The default setting is ‘0’, which triggers a forensic report only when both SPF and DKIM alignments do not pass. Use ‘1’ if the outcome of either SPF or DKIM is anything other than a pass. The option ‘d’ is selected to generate a report specifically for DKIM validation failures, and ‘s’ is used for SPF-related issues. To actually receive these forensic reports, it’s necessary to specify the ‘ruf’ tag.
- rfFailure report format
- The format for failure report generation can be set to either ‘afrf’ or ‘iodef’, as these are the two permissible options.
- pctPercentage (historic)
- The legacy Percentage tag asked receivers to apply a quarantine or reject policy to only part of the mail that failed DMARC. RFC 9989 removed pct because receivers implemented partial enforcement inconsistently. New records should omit it and stage rollout with aggregate reports, whole-policy changes, and low-volume subdomains.
- riReporting interval
- The Reporting interval specifies how often XML reports are received, measured in seconds. The standard setting is 86400 seconds, which equates to daily reporting. However, it’s important to note that despite the specified interval, Internet Service Providers (ISPs) typically send these reports on their own schedules, which in most cases, is also once a day.