DMARC Analyzer
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is an email authentication protocol that builds on SPF and DKIM to provide domain-level protection against email spoofing, phishing, and other forms of email abuse.
DMARC Analyzer Tool
Our DMARC Analyzer tool helps you check if your DMARC record is correctly configured and valid.
Use DMARC AnalyzerWhat is DMARC?
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication protocol that builds on SPF and DKIM to provide domain-level protection against email spoofing and phishing. DMARC allows domain owners to specify how email receivers should handle messages that fail SPF and DKIM authentication checks, and provides a reporting mechanism for visibility into email authentication results.
DMARC addresses a key limitation of SPF and DKIM: neither protocol provides a way to tell receiving mail servers what to do with messages that fail authentication. DMARC fills this gap by allowing domain owners to publish policies that specify how receivers should handle authentication failures.
How DMARC Works
- Authentication: When an email is received, the receiving mail server performs SPF and DKIM authentication checks.
- Alignment: DMARC adds an additional check called "alignment" to verify that the domains used in SPF and DKIM match the domain in the From header that is visible to the recipient.
- Policy Application: The receiving server looks up the DMARC record for the domain in the From header to determine what policy to apply to messages that fail authentication.
- Reporting: The receiving server generates reports about authentication results and sends them to the email address specified in the DMARC record.
- Action: Based on the DMARC policy, the receiving server takes action on messages that fail authentication (deliver, quarantine, or reject).
DMARC Record Format
A DMARC record is a TXT record in your domain's DNS. The record is published at a specific location:
_dmarc.[domain]For example, if your domain is "example.com", the DMARC record would be published at:
_dmarc.example.comThe content of the DMARC record typically looks like this:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:forensic@example.com; pct=100; adkim=s; aspf=sWhere:
| Tag | Description | Example |
|---|---|---|
v | Protocol version | v=DMARC1 |
p | Policy for the domain (none, quarantine, reject) | p=reject |
rua | Email address for aggregate reports | rua=mailto:dmarc-reports@example.com |
ruf | Email address for forensic reports | ruf=mailto:forensic@example.com |
pct | Percentage of messages subject to policy | pct=100 |
sp | Policy for subdomains | sp=reject |
adkim | DKIM alignment mode (s=strict, r=relaxed) | adkim=s |
aspf | SPF alignment mode (s=strict, r=relaxed) | aspf=s |
DMARC Policies
The DMARC policy (p tag) specifies how receiving mail servers should handle messages that fail DMARC authentication. There are three possible values:
none (p=none)
No specific action is requested. Messages that fail DMARC authentication are delivered as normal. This policy is useful for monitoring and collecting data without affecting email delivery.
quarantine (p=quarantine)
Messages that fail DMARC authentication should be treated with suspicion. They are typically delivered to the spam or junk folder rather than the inbox.
reject (p=reject)
Messages that fail DMARC authentication should be rejected outright. They are not delivered to the recipient at all.
DMARC Alignment
DMARC introduces the concept of "alignment" to ensure that the domains used in SPF and DKIM match the domain in the From header that is visible to the recipient. There are two types of alignment:
SPF Alignment
The domain used in the MAIL FROM command (Return-Path) must match the domain in the From header. The alignment mode is specified by the aspf tag:
- Strict (aspf=s): The domains must be an exact match.
- Relaxed (aspf=r): The domains must share the same organizational domain (e.g., mail.example.com and example.com would align).
DKIM Alignment
The domain in the DKIM signature (d= parameter) must match the domain in the From header. The alignment mode is specified by the adkim tag:
- Strict (adkim=s): The domains must be an exact match.
- Relaxed (adkim=r): The domains must share the same organizational domain.
DMARC Reporting
One of the key features of DMARC is its reporting mechanism, which provides visibility into email authentication results. There are two types of reports:
Aggregate Reports (rua)
Aggregate reports provide a summary of authentication results for a domain over a period of time (typically daily). They include information such as:
- The IP addresses that sent email on behalf of the domain
- The number of messages received from each IP address
- The SPF and DKIM authentication results for each IP address
- The DMARC policy applied to messages from each IP address
Aggregate reports are sent to the email address specified in the rua tag.
Forensic Reports (ruf)
Forensic reports provide detailed information about individual messages that failed DMARC authentication. They include information such as:
- The full headers of the message
- The authentication results for the message
- The reason for the authentication failure
Forensic reports are sent to the email address specified in the ruf tag.
Note: Forensic reports may contain sensitive information, including the content of email messages. Many mail providers do not send forensic reports due to privacy concerns.
Implementing DMARC
Implementing DMARC involves several steps:
- Implement SPF and DKIM: DMARC builds on SPF and DKIM, so you need to implement these protocols first.
- Create a DMARC record: Start with a monitoring policy (
p=none) to collect data without affecting email delivery. - Publish the DMARC record: Add the DMARC record to your domain's DNS at
_dmarc.[domain]. - Analyze DMARC reports: Review the aggregate reports to identify legitimate sources of email that are failing authentication.
- Update SPF and DKIM: Configure SPF and DKIM for all legitimate sources of email.
- Gradually increase the DMARC policy: Once you're confident that all legitimate email is passing authentication, gradually increase the DMARC policy from
p=nonetop=quarantineand eventually top=reject.
Here's an example of a gradual DMARC implementation plan:
| Stage | DMARC Record | Duration |
|---|---|---|
| Monitoring | v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com | 1-3 months |
| Quarantine (10%) | v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.com | 1-2 weeks |
| Quarantine (50%) | v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@example.com | 1-2 weeks |
| Quarantine (100%) | v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com | 1-2 months |
| Reject (10%) | v=DMARC1; p=reject; pct=10; rua=mailto:dmarc-reports@example.com | 1-2 weeks |
| Reject (50%) | v=DMARC1; p=reject; pct=50; rua=mailto:dmarc-reports@example.com | 1-2 weeks |
| Reject (100%) | v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com | Ongoing |
DMARC Best Practices
Start with a monitoring policy
Begin with p=none to collect data without affecting email delivery. This allows you to identify legitimate sources of email that are failing authentication.
Use a dedicated email address for reports
Create a dedicated email address for receiving DMARC reports. These reports can be voluminous, so it's best to keep them separate from your regular email.
Implement SPF and DKIM properly
DMARC builds on SPF and DKIM, so it's essential to implement these protocols correctly. Ensure that all legitimate sources of email are authorized in your SPF record and are signing emails with DKIM.
Gradually increase the DMARC policy
Use the pct tag to gradually increase the percentage of messages subject to the policy. This allows you to test the policy on a subset of messages before applying it to all messages.
Monitor DMARC reports regularly
Regularly review DMARC reports to identify authentication failures and take corrective action. This is especially important when you're transitioning to stricter policies.
Set a policy for subdomains
Use the sp tag to set a policy for subdomains. This is important because attackers often target subdomains that may not have proper email authentication.
Common DMARC Issues
Alignment failures
Even if SPF and DKIM pass, DMARC can still fail if the domains don't align with the From header. This is a common issue when using third-party services that send email on your behalf.
Missing or incorrect DMARC record
If your DMARC record is missing or has syntax errors, it won't be properly processed by receiving mail servers. Use our DMARC Analyzer tool to check your record for errors.
Legitimate email failing authentication
If you implement a strict DMARC policy without properly configuring SPF and DKIM for all legitimate sources of email, legitimate messages may be rejected or quarantined.
Forwarded email
Email forwarding can break DKIM signatures and SPF alignment, causing DMARC to fail. This is a common issue with mailing lists and email forwarding services.
Report processing
DMARC reports can be difficult to process and analyze without specialized tools. Consider using a DMARC report analyzer to help interpret the data.
DMARC Validation Tool
Our DMARC Analyzer tool helps you check if your DMARC record is correctly configured and valid. It checks for:
- Syntax errors
- Missing required tags
- Invalid policy values
- Reporting configuration
- Other common DMARC issues
Next Steps
To learn more about email authentication, explore:
- SPF Validator - Learn how to create and validate SPF records
- DKIM Validator - Understand DKIM implementation and validation
- Email Authentication Best Practices - Comprehensive guide to email security