DMARC policy checker

A DMARC checker is a tool that looks up the DMARC DNS TXT record at _dmarc.yourdomain.com, validates its syntax, and analyzes the policy configuration. It verifies that your domain has proper protection against email spoofing and helps identify misconfigurations that could affect email deliverability or security.

DMARC has three main policies: 'p=none' (monitoring only -- emails are delivered normally but reports are generated), 'p=quarantine' (suspicious emails are sent to spam folder), and 'p=reject' (suspicious emails are blocked completely and never delivered). Most organizations start with p=none to monitor, then gradually move to quarantine and finally reject.

DMARC is crucial for email security because it allows domain owners to specify exactly how receivers should handle emails that fail SPF and DKIM authentication. Without DMARC, attackers can freely spoof your domain to send phishing emails. DMARC also enables aggregate reporting so you can see who is sending email as your domain, and it is required for BIMI logo display in Gmail and Apple Mail.

To fix this, you need to create a DMARC TXT record and add it to your domain's DNS settings with the hostname '_dmarc'. A simple starting record is: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com. You can use our DMARC Generator tool to create a properly formatted record. Allow 24-48 hours for DNS propagation after adding it.

The 'p=' tag sets the policy for your main domain (e.g., example.com), while 'sp=' sets a separate policy for subdomains (e.g., mail.example.com). If sp= is not specified, subdomains inherit the main domain policy. This allows you to enforce a strict policy on your main domain while being more lenient on subdomains, or vice versa.

Aggregate reports (rua) are XML reports sent by receiving mail servers that summarize DMARC authentication results for your domain. They include data on which IPs sent email as your domain, whether SPF/DKIM passed or failed, and the volume of messages. Configure them by adding rua=mailto:reports@yourdomain.com to your DMARC record. Use a DMARC report analyzer to parse these XML files.

Forensic reports (ruf) provide detailed information about individual email messages that failed DMARC authentication. Unlike aggregate reports which are summaries, forensic reports contain message headers or even full email content. They are useful for investigating specific authentication failures, but many providers do not send them due to privacy concerns.

DMARC alignment verifies that the domain authenticated by SPF or DKIM matches the From header domain visible to the recipient. Relaxed alignment (the default) allows subdomain matching -- so mail.example.com passes for example.com. Strict alignment requires an exact domain match. Alignment is what makes DMARC more effective than SPF or DKIM alone.

Most security experts recommend monitoring with p=none for 2-4 weeks minimum while reviewing aggregate reports. During this time, identify all legitimate email sources and ensure they pass SPF and DKIM with proper alignment. Once you are confident all legitimate senders are authenticated, move to p=quarantine with pct=25, gradually increasing to pct=100, then finally p=reject.

Yes, if implemented incorrectly. Moving to p=quarantine or p=reject before ensuring all legitimate senders pass authentication will cause those emails to go to spam or be rejected. This is why the gradual approach matters: start with p=none, use the pct= tag to apply the policy to only a percentage of messages, and use aggregate reports to verify before full enforcement.