DMARC / SPF / DKIM Analyzer & Aggregate Report Parser
Analyze email-authentication DNS records and parse DMARC aggregate XML reports into plain-English deliverability insights.
Live DNS lookups use a serverless lookup layer (Cloudflare DNS-over-HTTPS). DMARC aggregate report parsing happens entirely locally in your browser — uploaded files are never sent to a server. CodeAva does not need mailbox credentials or message content.
Live DNS record lookups use a serverless layer querying Cloudflare DNS-over-HTTPS — only the domain name is sent. DMARC aggregate report parsing happens entirely in your browser. Uploaded XML and .gz files are never transmitted to a server. CodeAva does not require mailbox access, message content, or delivery credentials.
Overview
SPF, DKIM, and DMARC are the three DNS-based email-authentication standards that modern mail infrastructure depends on. SPF declares which IP addresses or services are authorized to send mail on behalf of a domain. DKIM attaches a cryptographic signature to outgoing messages so receivers can verify they were not tampered with in transit. DMARC ties both together and adds a published policy — telling receivers what to do when a message fails alignment — while directing aggregate and forensic reports back to the domain owner.
A common misunderstanding is that passing SPF or DKIM is sufficient. DMARC alignment requires more: the authenticated domain must align with the visible From address. A message can technically pass SPF because it was sent through a third-party provider, yet still fail DMARC alignment because the authenticated envelope domain belongs to that provider, not your own domain. The same failure pattern applies to DKIM when a vendor signs messages with its own domain rather than yours.
DMARC aggregate reports are where alignment failures become visible, but the raw XML format is nearly unreadable without tooling. Reports list source IPs, message counts, SPF and DKIM authentication outcomes, DMARC dispositions, and alignment verdicts — often across dozens of sending sources. This tool parses those reports locally in the browser and translates each record into a plain-English summary so email admins and deliverability teams can quickly identify which sources need attention.
Use cases
When to use it
- Checking published SPF, DKIM, and DMARC recordsinspect the raw DNS TXT records and their parsed fields to confirm your email-authentication setup is syntactically correct and configured as expected.
- Spotting SPF lookup-limit risksthe SPF tab counts DNS-querying mechanisms and warns before the 10-lookup limit is exceeded — the threshold at which receivers may treat the record as a PermError.
- Understanding DMARC policy maturityreview whether DMARC is in monitor-only mode (p=none) or actively enforcing. The checklist tab shows readiness against common bulk-sender expectations.
- Diagnosing alignment failures from aggregate reportsupload a DMARC XML or .gz report to see which sending sources are passing or failing alignment, with plain-English explanations for each failure pattern.
- Identifying misaligned third-party sendersthe source breakdown groups report rows by IP, header-from, and DKIM/SPF domains so you can quickly identify which vendor or service needs a custom MAIL FROM or aligned DKIM configuration.
- Checking bulk-sender readiness for Gmail and Yahoothe readiness checklist reflects the published DNS configuration against the commonly cited requirements for commercial bulk senders.
When it's not enough
- Inbox placement guaranteesDNS authentication is one factor in delivery. Sender reputation, spam rate, content quality, and list hygiene are not visible from DNS records alone.
- Real-time message verificationthis tool evaluates published DNS policies, not individual messages. DKIM verification of a live message requires the message headers and signature.
- Replacing mailbox-provider feedback loopsDMARC aggregate reports show authentication results but not read rates, spam complaints, or sender scores. Use Google Postmaster Tools and Yahoo Sender Hub for those signals.
How to use it
- 1
Enter your domain and DKIM selector(s)
Type the domain name (e.g. example.com) and any DKIM selectors your mail provider uses (e.g. google, selector1, s1). Common selectors for Google Workspace are 'google'; Microsoft 365 often uses 'selector1' and 'selector2'.
- 2
Review the SPF, DKIM, and DMARC tabs
Each tab shows the raw record, parsed fields, and a severity-grouped issue list. The Checklist tab summarizes bulk-sender readiness.
- 3
Upload a DMARC aggregate report
Switch to the Aggregate Report Parser. Drop an .xml file from your rua= mailbox or a .gz compressed report from a DMARC reporting service. Both formats are decompressed and parsed locally.
- 4
Review source breakdown and alignment diagnoses
Each source IP group shows total volume, pass/fail split, header-from domain, DKIM signing domain, SPF envelope domain, and a plain-English alignment diagnosis.
- 5
Export and fix
Export the source table as CSV for sharing with your ESP or team. Fix misaligned senders by configuring a custom MAIL FROM on marketing platforms or adding aligned DKIM signing.
Common errors and fixes
SPF record has too many DNS lookups
Count the include, a, mx, ptr, and exists mechanisms — each costs one lookup. Nested includes from third parties also count. Options: flatten frequently-changing includes into ip4 ranges, use an SPF macro service, or consolidate sending through fewer services.
DKIM selector not found
Verify the selector name is correct (it is configured in your mail platform's DNS settings). DKIM records live at selector._domainkey.domain. The record may not have propagated — wait up to 48 hours after publishing.
DMARC is published but set to p=none
p=none is a monitoring-only policy — it collects aggregate reports but takes no filtering action. After reviewing aggregate reports and confirming all legitimate senders are aligned, move to p=quarantine and eventually p=reject.
SPF passes but DMARC still fails
SPF alignment requires the RFC5321.MailFrom (envelope sender / bounce address) domain to align with the visible From domain. Many ESPs send from their own bounce domain by default. Configure a custom MAIL FROM / return-path on the sending service to use your domain.
DKIM passes but DMARC still fails
DKIM alignment requires the DKIM d= signing domain to align with the visible From domain. If a vendor signs with their own domain (e.g. vendorname.com instead of yourdomain.com), configure the vendor to sign with a subdomain of your domain or set up aligned DKIM.
High failure rate in aggregate report
Look at the source breakdown. A high failure rate from a single IP block usually indicates a bulk ESP, transactional mail provider, or internal service that is not aligned. Work with the vendor to configure custom MAIL FROM and/or aligned DKIM.
No aggregate reports received
Ensure the DMARC record includes a valid rua= tag pointing to a mailbox you control. If the rua address is on a different domain, that domain must publish a DMARC external-destination record authorizing your domain to report to it.
Frequently asked questions
Related
What is a DMARC alignment failure and how do I fix it?
A DMARC alignment failure happens when the visible From domain in a message does not align with the domain authenticated by SPF or DKIM. A message can technically pass SPF because it was sent through a legitimate third-party service, and still fail DMARC because the authenticated domain — the ESP's own bounce address — does not match your sending domain.
The most common fix is to configure a custom return-path / MAIL FROM on your ESP or transactional mail provider so the envelope sender uses a subdomain of your domain (e.g. bounce.yourdomain.com), which then passes SPF alignment under relaxed mode. Alternatively, configure the provider to sign messages with a DKIM key on a subdomain of your domain, which satisfies DKIM alignment.
Use the Aggregate Report Parser to identify which sending sources are causing alignment failures, then work with each vendor to fix their configuration before moving DMARC from p=none to p=quarantine or p=reject.
Email sender requirement checklist
| Requirement | Low-volume senders | Bulk senders (>5k/day to Gmail) | Practical impact |
|---|---|---|---|
| SPF | Recommended | Required | Authorizes envelope senders. Required for DMARC alignment via SPF path. |
| DKIM | Recommended | Required (2048-bit RSA preferred) | Proves message integrity. Required for DMARC alignment via DKIM path. |
| DMARC | Recommended | Required (at minimum p=none) | Ties SPF+DKIM together and signals policy to receivers. |
| DMARC alignment | Best practice | Required for effective DMARC | Pass rates in aggregate reports guide safe policy escalation to reject. |
| TLS (STARTTLS / MTA-STS) | Recommended | Expected | Encrypts mail in transit. Widely expected by modern mail providers. |
| One-click unsubscribe | N/A for transactional | Required for subscribed marketing mail | List-Unsubscribe: header with one-click support (RFC 8058). Non-compliance risks filtering. |
| Low spam rate | Always | Always — threshold <0.10% | High complaint rates override authentication. Monitor via Google Postmaster Tools. |
Sender requirements evolve. Refer to Google Postmaster Tools documentation and Yahoo Sender Hub for the current published guidelines.
DMARC record examples
Monitoring only (start here)
v=DMARC1; p=none; rua=mailto:[email protected]
Collect aggregate reports without filtering any messages. Use this while auditing sending sources.
Phased enforcement (quarantine)
v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]
Apply quarantine to 10% of failing messages while continuing to monitor. Increase pct gradually as you confirm alignment.
Full enforcement (reject)
v=DMARC1; p=reject; rua=mailto:[email protected]
Only move to p=reject after confirming all legitimate senders are passing DMARC alignment in aggregate reports. Premature reject can block legitimate mail.