Free tools · Email domain setup
How to Read DMARC Aggregate Reports
DMARC aggregate reports group authentication observations from receiving systems. Use them to identify legitimate senders and investigate unexpected sources. They are not a list of opens, individual recipients or guaranteed delivery events.
Real public DNS lookup. No signup, mailbox connection or API key needed.
Check your published DMARC record
Enter your own public domain. The illustrated examples below are not preloaded and no lookup runs until you submit.
Look up your public DMARC record.
Enter your domain to see the published record and any issues found. Results appear here after a real DNS lookup.
DMARC record generator
Create a TXT record from the settings you choose. This builder runs in your browser and produces text for you to review. It does not update DNS.
Your TXT record
Add the settings you intend to publish, then generate the text. Compare it with your existing record before making changes with your DNS provider.
What to do next
1. Confirm where reports go
Check your published rua destination below. Use a controlled reporting mailbox or service. AskQuokka does not collect or open report attachments through this page.
2. Read the reporting period and source
Identify the reporting organisation, date range, source_ip and message count. Match source IPs to known systems using your providers' evidence; the IP alone does not prove authorisation.
3. Compare authentication and alignment
policy_evaluated records the receiver's DMARC-aligned SPF/DKIM conclusions and disposition. auth_results gives underlying mechanism results. A raw SPF pass can still be unaligned with the From domain.
4. Investigate before changing policy
Prioritise legitimate sources with failures and verify representative received messages. A passing DMARC disposition is not proof of Inbox delivery. Keep the report evidence when planning an enforcement change.
A fictional row, shown as a readable summary
Source IP: 192.0.2.10 Count: 12 Header From: example.com Policy-evaluated DKIM: pass Policy-evaluated SPF: fail Disposition: pass
The address is reserved for documentation. This RFC 9990-style row illustrates an aligned DKIM pass alongside an SPF failure. It is not an uploaded XML report, a customer result or proof that twelve messages reached the Inbox. Older report formats can use different disposition labels.
Report availability varies
Receivers decide whether to send reports. Mailbox acceptance, timing, external-destination authorisation and provider support can affect what you receive. A missing report does not prove that no mail was sent.
Keep report data controlled
Aggregate reports contain infrastructure and authentication details. Review attachments with your own approved reporting tools. This page checks public DNS and does not offer XML upload or report storage.
Questions
Does the checker parse my report?
No. The example explains report fields. The embedded checker inspects the public DMARC policy that requests reports; it does not upload, unpack or parse attachments.
Does every failed source mean an attacker?
No. A source can be an incorrectly configured authorised service, forwarding infrastructure or unwanted traffic. Investigate before deciding what it represents.
Checking sends your public domain to AskQuokka. Record generation and copying run in this tab. No DNS settings are changed and no email is sent. Domain inputs and lookup results are not included in tool analytics.
Official references
References checked 23 October 2026. Use your provider's current domain-specific values.
More setup and troubleshooting guides
Free DMARC Record Generator and Setup Guide
Generate DMARC TXT record text from your domain, policy and reporting address, then check public DNS. No account, API key or DNS access needed.
DMARC Policy of Reject: Meaning and Rollout
Understand what p=reject requests, check your published DMARC policy and review alignment before moving from monitoring to enforcement.