DMARC reports are XML files that receiving mail servers send you, grouping messages sent under your domain by source IP, with SPF, DKIM and DMARC results. To read one, ask three questions of every row: who sent it, how many messages, and did it pass in alignment with your visible From domain? The answers tell you whether p=reject is safe.
Why DMARC reports sit unread
The usual story goes like this. Someone in IT, or an outside contractor, published a _dmarc record with p=none and a rua address. What the records are and how to publish them is covered in our SPF, DKIM and DMARC guide. From then on, compressed XML attachments arrive every day from Google, Microsoft, Yahoo and others. Nobody opens them, the mailbox fills up and the policy stays in monitoring mode for months.
The obstacle is interpretation rather than technology. Raw XML is a wall of IP addresses, Unix timestamps and nested pass/fail values. Nothing tells you at a glance which row is your accounting software's invoice notification and which is a fraudster sending in your name. This article gives you a method for telling them apart.
What it costs to leave reports unread
Leaving DMARC at p=none leaves your domain open to impersonation: a monitoring policy reports spoofed mail but does not stop it. EasyDMARC's 2026 DMARC Adoption Report, which scanned 1.8 million domains, found that 52.1% have a DMARC record but only about 23% enforce a quarantine or reject policy.
The same report found that only around 9% of domains combine an enforcement policy with reporting. (EasyDMARC, 2026 DMARC Adoption Report)
The gap has a price. According to the FBI IC3 2025 Internet Crime Report, phishing/spoofing was the most-reported crime type, with 191,561 complaints. A spoofed "our bank details have changed" email sent from your own domain to your customers is the shortest route to bank detail change fraud.
Deliverability suffers too. According to Microsoft's announcement for high-volume senders, from 5 May 2025 domains sending more than 5,000 emails a day to Outlook.com, Hotmail and Live addresses need SPF, DKIM and a DMARC policy of at least p=none, aligned with SPF or DKIM. If nobody reads the reports, a legitimate sender that fails alignment also goes unnoticed, and nobody can explain why its mail lands in junk. Our guide to emails going to spam treats report reading as one part of that wider deliverability picture.
Anatomy of an aggregate (rua) DMARC report
An aggregate report is an XML document defined in RFC 7489. It usually arrives once a day from each reporting provider, compressed as gzip or zip. It has three top-level parts: report metadata, the published policy and one record per sending source. The fields that matter:
| Block / field | What it tells you | What to look for |
|---|---|---|
report_metadata → org_name, date_range | Who sent the report and the period it covers (UTC, Unix time) | Are the big providers reporting every day? |
policy_published → p, sp, adkim, aspf, pct | The policy the receiver saw in your DNS that day | Is it the record you expect; is the subdomain policy (sp) right? |
row → source_ip, count | Which IP sent how many messages | High-volume IPs you do not recognise |
policy_evaluated → disposition, dkim, spf | The aligned DMARC result and what the receiver did | High-volume rows showing fail |
identifiers → header_from | The visible From domain | Are your subdomains appearing too? |
auth_results → domain, result under dkim / spf | The raw SPF and DKIM result and the domain it passed for | Is that domain yours, or your provider's? |
The key to reading reports lies in the last two rows. A common mistake is to see spf result=pass under auth_results and relax. If SPF passed for your newsletter platform's own domain, policy_evaluated still shows spf as fail, because DMARC requires the authenticated domain to align with header_from. What counts is the aligned result, not the raw one.
The disposition field shows what the receiver actually did: none, quarantine or reject. Seeing none while your policy is p=none is expected. Sometimes a reason such as forwarded or mailing_list appears, meaning the receiver deliberately relaxed your policy for that traffic.
Forensic (ruf) reports
Alongside aggregate data you can also request forensic reports (ruf) for individual messages that fail DMARC. These carry message headers and sometimes fragments of content. Many large providers do not send them for privacy reasons. Where they do arrive, the addresses and subject lines are personal data, so set access and retention rules within your data protection compliance programme; in Turkey that means the KVKK, the country's GDPR-style data protection law.
How to read DMARC reports: a seven-step working method
- Confirm the reports are arriving. If your
ruaaddress sits on another domain (a report analysis service, for example), that domain must publish a_report._dmarcverification record showing it accepts reports for you; otherwise providers will not send them. - Do not read XML by hand; parse it. Extract the attachments and load them into a table: provider, date,
source_ip,count,header_from, aligned and raw results. Combine several weeks of data before drawing conclusions. - Turn IP addresses into senders. Use reverse DNS (PTR) and network ownership to label each source: "our mail server", "e-invoicing provider", "CRM", "unknown".
- Put aligned and raw results side by side. Raw
passwith alignedfailmeans the problem is domain matching, not authorisation. - Place every source in one of the groups below. The classification table follows this list.
- Fix it with whoever owns the source. Ask the service provider to sign with DKIM on your own domain, or move the envelope sender (Return-Path) to one of your subdomains.
- Track the aligned pass rate weekly. When almost all legitimate volume passes in alignment, move to
p=quarantine; once that holds steady, go top=reject, usingpctto phase the change if needed.
Source classification table
| What you see | Likely meaning | Action |
|---|---|---|
Your own IP, aligned DKIM and SPF pass | Healthy legitimate traffic | None; keep monitoring |
Known service, raw pass, aligned fail | SaaS tool signing with its own domain | Custom-domain DKIM and Return-Path in that service |
Known service, SPF and DKIM fail | Sender missing from your inventory | Add to SPF, publish its DKIM key in DNS |
SPF fail, aligned DKIM pass, source is a forwarding server | Forwarding or a mailing list | DMARC still passes via DKIM; make sure DKIM is on for every source |
Unknown IPs, everything fail, scattered networks and countries | Someone impersonating your domain | Do not "fix" these; p=reject exists to stop them |
The hardest call is telling "unknown" apart from "forgotten". Watch a suspicious IP for a week: if its volume follows office hours and someone remembers a tool, it is probably a forgotten sender. The usual suspects are web forms, invoice notifications and old multifunction printers; the invoicing side is covered in our guide to e-invoice integration in Turkey.
One attack never appears in your reports at all: mail from a domain that merely looks like yours. That domain is not yours, so its reports do not come to you. We deal with that gap in lookalike domain attacks.
How Digital Bridge handles DMARC reporting
Most of a DMARC project is not writing records but reading reports and fixing senders with their owners. Within our cyber security consultancy, we run it like this:
- Discovery: We review the SPF, DKIM, DMARC and PTR records for your domains, parse the reports you already have and build a list of sources.
- Classification and fixes: We label each source with your teams. Where mail from an ERP, CRM or custom application needs changing, our system integrations team corrects the sending configuration.
- Pilot domain: We move a low-volume domain or subdomain to
rejectfirst to prove the method, then tackle the main domain. - Ongoing visibility: If you want report data in your own reporting environment, we can turn the aligned pass rate into a metric on a BI dashboard; which metrics earn their place is discussed in BI dashboard KPIs. If you centralise security events, DMARC summaries can also feed your SIEM and log management pipeline.
If you are changing mail platforms, the old server's IPs will keep appearing in reports for a while; sequencing the move as in our email migration guide cuts down on false alarms. We do not sell off-the-shelf packages: after a needs analysis, we set out scope, phases and fees in a written proposal.
Two-way visibility with Smart360 and SmartMail
DMARC reports show how other people's servers treat your mail. SmartMail, the business email product in the Smart360 family, handles the other half: how you treat incoming mail.
- Domains and DNS in one panel: Domains and DNS settings are managed from the Smart360 admin panel alongside users and departments, so fixing a gap a report reveals does not mean switching tools.
- A shared mailbox for reports: You can set up the
ruaaddress as a shared mailbox in SmartMail and give only the IT team view permission. Delete rights are off by default for new assignments, so reports do not disappear by accident. - The same logic on inbound mail: SmartMail assesses every incoming message against 12 signals, starting with its own SPF/DKIM/DMARC and PTR checks. Lookalike domains, display-name impersonation and Reply-To mismatches are weighed too, so a message that passes DMARC from a domain resembling yours is still flagged. The outcome is a report with written reasons.
Authentication and domain checks run in software, so they keep working even when the AI usage allowance runs out. For user-side warning signs, see how to spot phishing emails.
Your next step
Collect the last month of reports sent to your rua address and work through the first three steps above; the shorter your list of unknown sources, the easier the reject decision becomes. If you are configuring a domain from scratch, setting up email with your domain shows the right order, and if you are re-evaluating your provider, read how to choose business email. To parse your reports together and draw up a p=reject timeline, get in touch. More on this subject is collected in our Business Email & Documents hub.