Check your DMARC record
Enter a domain to look up its DMARC record, validate every tag, and see exactly what's blocking enforcement — free, no signup. A healthy record starts at v=DMARC1 and ends at p=reject.
What is a DMARC record?
A DMARC (Domain-based Message Authentication, Reporting, and Conformance) record is a DNS record that helps protect email domains from unauthorized use, such as spoofing. It does this by specifying how emails that fail SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) checks should be handled (e.g., rejected or quarantined). Additionally, DMARC provides feedback to domain owners about the emails being sent from their domain, helping them identify and address security issues.
How to read your result
| Result | What it means | What to do |
|---|---|---|
| v=DMARC1; p=reject | Full enforcement — receivers refuse mail that fails DMARC. This is the end state. | Keep rua reporting on and watch for new senders before you onboard them. |
| p=quarantine | Enforcement, softened: failing mail lands in spam instead of being refused. | Watch reports for false positives for a few weeks, then move to p=reject. |
| p=none | Monitoring only — spoofed mail is still delivered. The record reports but protects nothing. | Fix SPF/DKIM alignment for every sender in your reports, then step up to quarantine. |
| No DMARC record found | Receivers apply no policy, so anyone can spoof the domain. Also fails Google and Yahoo's 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 | Receivers that find multiple records treat the domain as having none at all (RFC 7489). | Delete every TXT record at _dmarc except one. |
| Syntax error or unknown tag | Receivers may ignore the whole record. v=DMARC1 must be the first tag, tags are semicolon-separated. | Rebuild the record with the free DMARC generator and re-publish it. |
| pct below 100 | The policy applies to only a sample of failing mail — and many receivers ignore pct entirely. | Remove the pct tag once reports look clean; full coverage is the goal. |
| No rua tag | No aggregate reports — you can't see who is sending as your domain, so every policy change is a guess. | Add rua=mailto:… so enforcement decisions are driven by data. |
| sp weaker than p | Subdomains carry a looser policy than the organizational domain — spoofers simply move there. | Remove sp so subdomains inherit p, or set sp=reject explicitly. |
A checker tells you — Palisade fixes it
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 breaking real mail. Palisade automates that walk — it monitors the reports, fixes alignment sender by sender, and moves each domain to p=reject when it's safe, then keeps it there.
For MSPs it's built multi-tenant: every client domain checked, remediated, and enforced from one console, with per-domain pricing that drops as you scale.
Related checks and terms
p=nonep=quarantinep=rejectadkim / aspfdmarc=failDMARC software that does the work
Palisade reads your DMARC reports, fixes SPF and DKIM alignment sender by sender, and walks every domain to p=reject automatically — across all your clients, from one console.
First domain free forever
Email authentication knowledge base
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
- The Percentage tag is relevant exclusively for domains operating under a ‘quarantine’ or ‘reject’ policy. It specifies the proportion of email failures to which the chosen policy should apply. The remainder is managed under a less stringent policy. For instance, with ‘pct=70’ set on a domain with a ‘quarantine’ policy, this policy is enforced on only 70% of failed emails, while the other 30% are treated as if under a ‘none’ policy. Similarly, for a domain with ‘p=reject’ and ‘pct=70’, the ‘reject’ policy is applied to 70% of failures, with the remaining 30% defaulting to ‘quarantine’.
- 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.