DMARC Checker

How DMARC works in email delivery

Domain-based Message Authentication, Reporting and Conformance (DMARC) is an email authentication protocol defined in RFC 7489. It builds on SPF and DKIM by adding a policy layer that tells receiving mail servers what to do when email claiming to be from a domain fails authentication checks. DMARC also introduces a reporting mechanism that gives domain owners visibility into who is sending email on their behalf and whether those emails are passing authentication.

DMARC works by publishing a policy record as a TXT record at a specific DNS location: _dmarc.example.com. The record contains tags separated by semicolons. The most important tag is p= which sets the policy: none (monitor only, no action), quarantine (mark as spam), or reject (refuse delivery). The policy applies only when the email fails both SPF and DKIM authentication, or when the authenticated domain does not align with the domain in the From header.

Alignment is a key concept in DMARC. SPF authentication alone checks the envelope sender domain, but DMARC goes further by requiring that the domain in the From header aligns with the domain that passed SPF or DKIM. For SPF alignment, the domain in the From header must match the domain in the envelope sender (Return-Path). For DKIM alignment, the domain in the From header must match the domain in the DKIM signature's d= tag. Alignment can be strict (exact match only) or relaxed (subdomains are allowed to match), controlled by the aspf= and adkim= tags respectively.

DMARC also supports a subdomain policy (sp=) that applies to all subdomains of the organisational domain, independent of the main domain policy. The pct= tag allows a gradual rollout by applying the policy to only a percentage of failing messages. The rua= and ruf= tags specify email addresses where receiving servers send aggregate and forensic reports. Aggregate reports contain XML summaries of authentication results across all email received for the domain, while forensic reports contain copies of actual failing messages.

Deploying DMARC is a multi-step process that should be approached carefully. The recommended strategy is to start with a monitoring policy (p=none) and review aggregate reports for several weeks to identify all legitimate email sources. This ensures that no legitimate email is disrupted when the policy is tightened. Once all authorised senders are identified and authenticated with SPF and DKIM, the policy can be moved to p=quarantine with a low percentage, gradually increasing to 100 percent. The final step is p=reject, which provides the strongest protection against domain spoofing. Many organisations stay at p=reject once they are confident in their email authentication posture.

DMARC reporting is invaluable for security teams. Aggregate reports received via rua include information about the sending IP, the number of messages, the SPF and DKIM authentication results, and the disposition applied. By analysing these reports, domain owners can detect unauthorised use of their domain, identify misconfigured email senders, and verify that their email delivery partners are correctly authenticating messages. Forensic reports received via ruf contain full copies of failing messages, which can be used to investigate specific incidents of spoofing or misconfiguration.

DMARC tags explained

Common DMARC mistakes

The most common mistake is publishing a p=reject policy without first verifying that all legitimate email senders are authenticated with SPF and DKIM. This results in legitimate email being rejected, including transactional emails like password resets, order confirmations, and newsletters. Another frequent error is misconfiguring the DMARC record location — the record must be at _dmarc.example.com, not at the apex domain itself. Some administrators also forget to set up DKIM signing before deploying DMARC, meaning no email will pass DKIM checks.

A third common issue is failing to monitor DMARC reports after deployment. Many organisations set up a p=none policy with rua and ruf but never check the reports, missing the opportunity to identify unauthorised senders or misconfigured email streams before tightening the policy. It is also common to see syntax errors in DMARC records — missing semicolons, incorrect tag formatting, or mailto: without the colon. Use this DMARC checker to validate your record before publishing.

DMARC best practices

Start with p=none and monitor aggregate reports for at least two to four weeks. Use a DMARC report analysis tool to parse the XML reports and identify all legitimate sending sources. Ensure every legitimate sender has SPF and DKIM configured correctly. Gradually increase the policy to p=quarantine with a low pct value, monitor for issues, and increase the percentage over time. Once you are confident that no legitimate email is failing, move to p=reject. Set up rua reporting permanently so you can continuously monitor for new unauthorised senders. Consider implementing a subdomain policy with sp=reject to protect subdomains that do not send email. Remember that DMARC is only effective when combined with properly configured SPF and DKIM — all three protocols work together as a complete email authentication framework.

Frequently asked questions