DMARC Reports: How to Read and Use Them

DMARC (Domain-based Message Authentication, Reporting & Conformance) tells mailbox providers how to treat mail that claims to be from your domain. After you publish a DMARC DNS record with an rua reporting address, receiving mail servers send daily aggregate reports—usually as XML attachments. Help article 10240 explains how to interpret those reports and put them to work when you send from systeme.io.

Note: When you authenticate your domain on systeme.io, the required SPF and DKIM records are set up for sending through the platform. DMARC reports then confirm that Gmail, Yahoo, Microsoft, and other receivers see your legitimate mail as authenticated—and highlight abuse or misconfiguration when something fails.

• A published TXT record at _dmarc.yourdomain.com with rua=mailto:… ( How to Create a DMARC Record, 2241).
• Domain authentication (316) completed on systeme.io —including DMARC if prompted during DNS setup.
• An inbox that receives rua reports (ideally a dedicated address on the same domain, e.g. dmarc@yourdomain.com).

• Frequency: Roughly every 24 hours per reporting organization (Google, Yahoo, etc.)—so multiple emails per day is normal.
• Format: Email with a .xml file inside a .zip or .gz attachment; subject lines often look like Report Domain: yourdomain.com Submitter: google.com.
• Content: No message bodies from your subscribers—only metadata: IPs, volumes, SPF/DKIM results, and policy disposition.
• Spam folder: Automated attachments sometimes land in junk—check there if reports stop appearing.

Receiving a report does not automatically mean your domain is broken; it means a provider is sharing visibility, as described in article 10240.

Article 10240 walks through a sample XML structure. These fields matter most:

• report_metadata / org_name: Who sent the report (e.g. google.com, emailsrvr.com).
• report_id: Unique ID for that file.
• date_range: Reporting period (start/end timestamps) the summary covers.
• policy_published: Your DMARC policy as seen by the receiver—often p=none, aspf/adkim alignment mode, pct.
• row / source_ip + count: Which server sent how many messages using your domain.
• policy_evaluated: Authentication status—dkim and spf pass or fail, plus disposition (e.g. none under p=none).
• auth_results: Detail per protocol—for systeme.io sends you may see DKIM like inbound.systeme.io with result=pass when configuration is correct.

Example pattern from 10240 when mail is healthy:

<policy_evaluated>
  <disposition>none</disposition>
  <dkim>pass</dkim>
  <spf>pass</spf>
</policy_evaluated>

1. Locate the DMARC email and download the attachment; unzip if needed and open the .xml in a text editor.
2. Identify the reporting ISP (org_name) and report_id.
3. Note the date range (reporting period).
4. Read policy_published for your domain and current p= policy.
5. For each record, check source_ip and count—do you recognize the sender (your ESP, Google Workspace, etc.)?
6. Inspect policy_evaluated: both SPF and DKIM should pass for legitimate systeme.io campaign traffic.
7. Drill into auth_results if one check fails—misaligned domains or missing DNS often show up here.