DMARC Reporting, Data Privacy, and GDPR Considerations

What Data Does DMARCreport.com Process?

DMARCreport.com processes DMARC Aggregate (RUA) reports by default. RUA reports are XML-based statistical summaries generated by mailbox providers (such as Google, Microsoft, and Yahoo) that describe email authentication results for your domain.

RUA reports are statistical infrastructure data — they tell you which servers sent mail on behalf of your domain and whether authentication passed, not who sent or received messages or what was said.

Example RUA Aggregate Report

Below is a typical DMARC aggregate report in XML format. The highlighted comments show that every data element is infrastructure metadata with zero PII:

<?xml version="1.0" encoding="UTF-8"?>
<feedback>

  <report_metadata>
    <org_name>google.com</org_name>                   <!-- Reporting provider, not a person -->
    <email>noreply-dmarc-support@google.com</email>   <!-- Provider's automated reporting address -->
    <report_id>16842749567390121367</report_id>
    <date_range>
      <begin>1706745600</begin>                        <!-- Report start (Unix timestamp) -->
      <end>1706832000</end>                            <!-- Report end (Unix timestamp) -->
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>example.com</domain>                       <!-- Your domain -->
    <adkim>r</adkim>                                    <!-- DKIM alignment mode -->
    <aspf>r</aspf>                                      <!-- SPF alignment mode -->
    <p>reject</p>                                      <!-- Your published DMARC policy -->
    <pct>100</pct>                                      <!-- Policy applied to 100% of mail -->
  </policy_published>

  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>             <!-- Mail server IP (not a person) -->
      <count>1524</count>                              <!-- Number of messages -->
      <policy_evaluated>
        <disposition>none</disposition>                 <!-- Action taken by receiver -->
        <dkim>pass</dkim>                              <!-- DKIM authentication result -->
        <spf>pass</spf>                                <!-- SPF authentication result -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>           <!-- From: domain only, no address -->
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
        <selector>s1</selector>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>

</feedback>

RUF (Forensic) Reports

DMARCreport.com supports RUF (forensic/failure) report processing, but it is not enabled by default. RUF reports can contain message headers and potentially limited PII such as email addresses.

In practice, most major mailbox providers — including Google and Microsoft — no longer generate or send RUF reports due to privacy concerns. RUF data is exceedingly rare in today's email ecosystem. If your organization requires RUF processing, it can be enabled upon request.

GDPR and Data Privacy

Because DMARC aggregate reports contain only infrastructure metadata (IP addresses, domain names, authentication results, and message counts), they do not contain personal data as defined under GDPR Article 4(1). There are no email addresses, names, message contents, or other identifiers of natural persons present in RUA data.

While source IP addresses can in some contexts be considered personal data under GDPR (per the Breyer ruling, CJEU C-582/14), in the context of DMARC aggregate reports these IPs represent mail server infrastructure (e.g., Google's outbound MTAs, your organization's mail gateway) rather than individual end-user devices. They are not reasonably linkable to natural persons.

Data Hosting and Residency

This means:

• EU-originating data remains within EU jurisdiction at all times
• No reliance on cross-border transfer mechanisms (SCCs, adequacy decisions, etc.) is required for data at rest or in processing
• Data residency requirements under GDPR and national data protection laws are satisfied by default

Data Processing Agreement (DPA)

DuoCircle provides a Data Processing Agreement for customers who require one. Given that RUA data does not contain PII, many organizations find that a DPA is not technically required for DMARC aggregate reporting. However, we understand that compliance teams may require a DPA as part of standard vendor onboarding procedures, and we are happy to accommodate.

If your organization requires a DPA with specific schedules (Subject Matter and Details of Processing, Technical and Organizational Measures, Cross-Border Transfer Mechanisms, Region-Specific Terms), please contact our team to discuss your requirements.

PoC Configuration: RUA vs. RUF

The standard and recommended configuration for DMARCreport.com uses RUA (aggregate) reports only. This is the default for all deployments, including proof-of-concept (PoC) configurations.

RUA-only configuration means:

• Only statistical aggregate data is received and processed
• No message-level data is ever ingested
• No PII enters the system under any circumstance
• No additional privacy risk beyond standard DNS record publication

Frequently Asked Questions