DMARC Analyzer
DMARC Analyzer helps you analyze dmarc policy and configuration, for email authentication analysis, policy checks, and delivery troubleshooting.
Advertisement · Anuncio
Advertisement · Anuncio
Technical Analysis & Guide
What It Does
DMARC (Domain-based Message Authentication, Reporting & Conformance) Check analyzes your domain's DMARC policy, which tells receiving servers what to do with emails that fail SPF or DKIM checks.
Why It Matters
- →Policy Enforcement: Controls how unauthorized emails are handled
- →Reporting: Receives feedback about email authentication failures
- →Brand Protection: Prevents domain impersonation attacks
- →Visibility: Monitors who is sending emails using your domain
How to Read Results
- p=policy: none (monitor), quarantine (spam), or reject (block) — start with none and progress to reject
- pct=percentage: Controls what percentage of failing mail the policy applies to (default 100)
- rua=: Aggregate report email address — receives daily XML summaries of all authentication results
- ruf=: Forensic report email address — receives per-message details for authentication failures
- sp=: Subdomain policy — overrides the p= policy for subdomains of the main domain
- adkim= / aspf=: Alignment mode — r (relaxed) allows subdomain match, s (strict) requires exact match
Technical Background
DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) builds on SPF and DKIM to provide comprehensive email authentication. A DMARC policy record is a DNS TXT record published at _dmarc.example.com. The policy specifies: p=none (monitor only, collect reports), p=quarantine (route to spam folder), or p=reject (refuse the email entirely). DMARC alignment requires that either the SPF-authenticated domain or the DKIM signing domain aligns with the From: header domain — this prevents display name spoofing that SPF and DKIM alone cannot stop.
DMARC reporting provides two feedback types: aggregate reports (rua=) delivered daily as XML files summarizing all email traffic, and forensic reports (ruf=) providing per-message details for authentication failures. Organizations analyze aggregate reports using tools like DMARC Analyzer, Dmarcian, Valimail, or Google Postmaster Tools to identify unauthorized senders, discover legitimate services that need SPF/DKIM configuration, and track policy enforcement progress.
Best practice follows staged deployment: start with p=none to collect reports without affecting mail flow, analyze reports for 2-4 weeks to identify all legitimate senders, configure SPF and DKIM for all legitimate sending sources, move to p=quarantine at pct=10 (10% of failing mail) and gradually increase, then advance to p=reject for maximum protection. Common pitfalls include forgotten mail services (newsletters, CRM, support systems) not yet authenticated, and subsidiary domains lacking DMARC records. DMARC at p=reject is required by Google and Yahoo for bulk senders sending over 5,000 messages per day.
Forensic DMARC reports (ruf=) provide rich data for security incident investigation: they reveal the IP address that sent the unauthorized email, the From: and Return-Path: headers, the DKIM signature (or lack thereof), SPF result, and the receiving mail server. Privacy regulations in some jurisdictions restrict ruf= usage because forensic reports contain actual email header data. Aggregate reports (rua=) are privacy-safe and should always be configured. DMARC policy inheritance: a policy at example.com applies to subdomains, but explicit subdomain policies (sp= tag) can override. Attackers frequently exploit domains that have DMARC at p=none or no DMARC record at all — moving to p=reject is the strongest defense against domain impersonation.
Common Errors and How to Fix Them
- ProblemThe DMARC TXT record was added at the root (example.com) instead of _dmarc.example.com, so receivers never find it.
- FixCreate the record with host name '_dmarc' (most panels append the domain automatically) and value like 'v=DMARC1; p=none; rua=mailto:[email protected]'.
- ProblemThe domain jumped straight to p=reject and invoices from the billing system and tickets from the helpdesk started bouncing.
- FixGo back to p=none with rua reporting, identify every legitimate source in the aggregate reports, align each one with SPF or DKIM, then move to p=quarantine (optionally with pct) and finally p=reject.
- ProblemAggregate reports are sent to an address on another domain (rua=mailto:[email protected]) and nothing arrives.
- FixRFC 7489 section 7.1 requires the receiving domain to authorize it with a TXT record at example.com._report._dmarc.vendor.example containing 'v=DMARC1'. Reporting services usually publish this for you once the domain is registered with them.
- ProblemTwo TXT records exist at _dmarc, for example one created by a hosting wizard and one added manually.
- FixWith more than one DMARC record, receivers ignore DMARC for the domain entirely. Keep a single record combining the desired tags.
- ProblemThe rua value lacks the URI scheme ([email protected]).
- FixReport addresses must be URIs: 'rua=mailto:[email protected]'. Several destinations are separated by commas, each with its own 'mailto:' prefix.
- ProblemThe policy has sat at p=none for years, so spoofed messages are still delivered to inboxes.
- Fixp=none only monitors. Once reports show that your real traffic passes aligned SPF or DKIM, schedule the move to quarantine and then reject; that is the step that actually stops impersonation.
Frequently Asked Questions
What is the difference between relaxed and strict alignment?
Alignment compares the From domain with the domain authenticated by SPF (aspf) or DKIM (adkim). Relaxed, the default 'r', accepts any match within the same organizational domain, so mail.example.com aligns with example.com. Strict 's' requires an exact match. Relaxed suits nearly everyone; strict mainly breaks legitimate subdomain senders, which is why this tool warns when it is set.
What does the pct tag actually do?
pct sets the share of failing messages to which the policy applies. With 'p=quarantine; pct=25', a quarter of failing mail is quarantined and the rest is treated as the next weaker policy, here none. It is a ramp-up tool, not a permanent setting. The DMARCbis revision of the standard drops pct in favor of a simpler t= testing flag.
Why do I receive aggregate reports but almost no forensic (ruf) reports?
Failure reports can contain message headers and personal data, so most large mailbox providers stopped sending them for privacy reasons. Aggregate (rua) reports, daily XML summaries of source IPs and SPF/DKIM/DMARC outcomes, remain widely supported and are what you should rely on to discover senders and plan policy changes.
Do subdomains need their own DMARC record?
Not necessarily. If a receiver finds no record at _dmarc.sub.example.com, it uses the organizational domain's record, applying sp= if present or p= otherwise. Set 'sp=reject' to lock down unused subdomains while keeping a softer main policy, or publish a separate record for a subdomain that needs different reporting addresses.
Is DMARC mandatory for sending to Gmail and Yahoo?
Since February 2024 both providers require bulk senders, those sending roughly 5,000 or more messages a day to their users, to publish DMARC with at least p=none, authenticate with SPF and DKIM, and achieve alignment with the From domain. Smaller senders must still pass SPF or DKIM. A DMARC record has effectively become a baseline requirement for reliable delivery.
Academic Documentation
Protocol context and primary references
DMARC.org
Domain-based Message Authentication standard
Open source →
SPF Project
Sender Policy Framework documentation
Open source →
IETF
Internet Engineering Task Force
Open source →
RFC Editor
Official RFC documentation
Open source →
IANA
Internet Assigned Numbers Authority
Open source →
M3AAWG
Operational guidance for email authentication and abuse handling.
Open source →
REST API Documentation
v1.0GET /api/tools/dmarc-check
curl -X POST https://epcybertools.com/api/tools/dmarc-check \
-H "Content-Type: application/json" \
-d '{"domain":"google.com"}'
{
"success": true,
"results": [
{ "test": "Sample Check", "status": "pass", "message": "All clear" }
]
}
Usage Examples
# Check DMARC record
dig TXT _dmarc.example.com
# Short output
dig +short TXT _dmarc.example.com
# Verify via nslookup
nslookup -type=TXT _dmarc.example.com