Parse DMARC XML into Time Series Data

Q: Do I need a dedicated email address to receive DMARC reports?

Yes. You must designate a mailbox (typically dmarc@yourdomain.com) where reporting senders deliver aggregate reports.

Why DMARC XML reports alone aren’t enough for deliverability monitoring

You’re getting DMARC XML reports. That’s good. But if you’re still opening them in a text editor, scrolling through nested XML tags, trying to spot a spike in failures, you’re missing the point.

DMARC reports are raw telemetry—structured data from your domain’s authentication checks—but they’re not insight. They don’t tell you when a sender started sending from a compromised IP or if your phishing attempts are increasing week over week. They just give you numbers in a format meant for machines, not humans.

Without parsing, aggregation, and time-series transformation, these reports remain locked in their original form: a static file full of IP addresses, counts, and verdicts. No trends. No alerts. No visibility. You’re looking at a log, not a dashboard.

Key takeaways

DMARC XML reports contain rich authentication data but require parsing to reveal actionable trends.
Raw XML lacks built-in visualization, making it inaccessible to non-technical teams.
Converting DMARC data into time series enables real-time monitoring, alerting, and long-term deliverability tracking.

What is the end goal of parsing DMARC XML into time series data?

You turn passive DMARC logs into real-time visibility: track daily failure trends, spot sudden spikes in spoofing attempts, detect unauthorized senders, and catch policy drift before attackers exploit your domain. This lets you respond to threats before they impact deliverability or brand trust. With time-series data, you move from reactive alerts to proactive monitoring.

Turning Logs into Actionable Signals

DMARC reports alone are just raw data. Parsing their XML format into timestamped metrics transforms them into a running health check for your domain’s email security. A sudden 20% jump in authentication failures? That’s not noise—it’s a signal. Maybe a compromised account is sending, or a third-party vendor’s system misconfigured. With time-series tracking, you see the pattern, not just the outlier.

Let’s say your alignment rate drops to 85% over three days. That’s a red flag—your legitimate emails might be failing SPF or DKIM checks. Without time-series context, you’d miss the trend. But with it, you can correlate it with a change in your email infrastructure or a migration of marketing tools. This helps isolate issues faster and with less guesswork.

Enabling Automation and Integration

You can’t monitor what you can’t visualize. That’s why parsing DMARC XML into structured time series is essential for dashboards. Tools like Grafana or Datadog ingest this data to show real-time trends, set up automated alerts for anomaly detection, and trigger incident response workflows.

Many teams use scripts or ELK stack setups to process these logs. But integrating with a platform that handles parsing and normalization—from the raw XML to measurable, time-stamped values—cuts down on engineering effort. For example, MailTester’s integration ecosystem supports workflows that tie email verification and inbox placement data into broader monitoring systems.

Even without custom tools, the core value is in visibility. The Internet Society’s public data on domain-based email authentication shows that domains with active DMARC policies see lower spoofing rates—provided the data is actively monitored. Raw reports alone don't stop fraud. Only when you track failures over time can you act early.

Ultimately, the goal isn't to receive more reports. It’s to reduce the window between a threat emerging and your response. That’s why parsing DMARC into time series turns security data into a living, breathing part of your delivery strategy.

How to parse DMARC XML reports into time series data: the full process

Download aggregate DMARC reports sent to a dedicated email address, extract key fields like date, source IP, alignment status, and failure reason using a script like Python with lxml, then group and aggregate these records by time interval (hourly, daily). Convert the grouped data into a structured time series format and export it to a time series database or dashboard for monitoring email deliverability trends and detecting anomalies.

Step-by-step pipeline

Set up a dedicated email alias like [email protected] to receive DMARC aggregate reports. These reports are sent daily by receivers and contain data about email authentication outcomes. Using a specific alias makes automated collection easier and protects your reporting inbox from clutter.
Store incoming reports in a secure cloud storage bucket (like AWS S3 or Google Cloud Storage) with retention policies. Retention should cover at least 90 days to allow for long-term analysis of authentication trends and incident investigations. Ensure access is restricted and logs are monitored.
Write a parser script (e.g., in Python with lxml) to extract structured fields from the XML payload: record-date, policy domain, source IP, SPF alignment, DKIM alignment, failure reason, and count of messages. These fields reveal whether emails are failing due to SPF, DKIM, or alignment issues.
Group records by time interval—typically daily or hourly—and by attribute: source IP, policy domain, alignment type, and failure reason. This allows you to see patterns, such as whether a single IP is consistently causing SPF failures or if DKIM failures cluster around certain domains.
Convert the grouped data into a time series format: timestamp (ISO 8601), metric name (e.g., "SPF Failures per Day"), value (count), and context tags (IP, domain). This structure is ideal for visualization and alerting in monitoring tools.
Export the parsed time series data to a system like InfluxDB, OpenTSDB, or a visualization platform such as Grafana or Datadog. This enables real-time tracking, anomaly detection, and historical trend analysis—critical for maintaining sender reputation.

Why this matters for deliverability

A well-parsed time series from DMARC reports lets you detect issues before they hurt deliverability. For example, a sudden spike in DKIM failures at 3 a.m. might indicate a compromised domain or misconfigured sending system. Correlating this with sending volume and user engagement helps prioritize fixes. The process follows the DMARC specification and is commonly used by teams with strong email compliance programs.

The 6 steps described in “Step-by-step pipeline”, in order.

For teams building or scaling verification workflows, tools like MailTester's bulk email verification help clean lists before sending, reducing the risk of generating DMARC failures due to invalid or risky addresses. A clean send list reduces the burden on your DMARC monitoring pipeline.

Common DMARC XML fields and their time-series equivalents

You can parse DMARC XML reports into time series by treating each <record> as a data point tied to a source IP and time window. Extract the <date> (YYYYMMDD) and <time> fields to build granular timestamps, then aggregate failures by hour or day. Track <spf> and <dkim> results—pass, fail, none, or neutral—to monitor alignment success. Count <auth_results> failures to identify trends in authentication breakdowns. Use <source_ip> to map unauthorized senders or misconfigured third parties, helping you detect malicious activity or configuration drift over time. This transforms passive report data into actionable, time-ordered visibility.

Mapping XML fields to time-series metrics

Each <record> in a DMARC report represents a single authentication outcome from one source IP during a defined time window. To turn this into a time series, combine <date> and <time> to form a precise timestamp. These timestamps can be rolled up—by hour for real-time monitoring or by day for trend analysis—to track performance across time. The raw granularity allows you to detect anomalies such as sudden spikes in failures, which may signal a compromised system or misconfiguration.

Focus on <spf> and <dkim> results in the <auth_results> section. A value of "pass" means the authentication check succeeded. "Fail" means it didn't, "none" means no policy was set, and "neutral" means the result was inconclusive. Tracking how these values evolve over time reveals patterns—like a gradual increase in "fail" entries indicating a misaligned sender or a domain-wide policy change that's not yet enforced. You can model these outcomes as time-stamped events to build alerts or dashboards.

The <source_ip> field is critical. It identifies the origin of the email during the reported interval. Compare it against known legitimate IPs to detect spoofing or unauthorized use. If a single IP consistently reports "fail" results for SPF and DKIM, it might indicate a compromised system or a third-party sender not following your email policy. Using this data at scale lets you correlate IP behavior with authentication results and flag risks before they impact deliverability.

For deeper insights, correlate DMARC data with your sending activity and bounce logs. A spike in "fail" results paired with high bounce rates might point to a misconfigured transactional system or a spam campaign. This correlation is essential for maintaining sender reputation and inbox placement. Real-time visibility into these patterns helps prevent blacklisting and improves long-term email trust signals.

Understanding the full DMARC report structure—defined in RFC 7489—ensures you process each field accurately. Tools like MailTester's inbox placement tests can help validate whether messages that pass DMARC actually reach inboxes, closing the loop between authentication and delivery.

Real-world time series metrics from DMARC data

You can turn DMARC XML reports into actionable time series by extracting daily authentication failure rates, tracking top failing source IPs, categorizing failure types, monitoring pass rates across subdomains, and flagging new unauthorized IPs. These metrics reveal patterns in sender behavior, expose misconfigurations, and detect early signs of phishing or spoofing. Use them to build a real-time dashboard that measures email security health over time.

Key metrics to extract from DMARC reports

Track daily SPF or DKIM failure rate per domain — a sudden spike often indicates a compromised email channel or unauthorized sending source.
Identify the top source IPs by failure count — consistent failures from a single IP may point to a rogue outbound service or a hijacked system.
Classify failure types: policy rejection, alignment failure, or soft fail — alignment issues frequently stem from incorrect DKIM signing or improper SPF mechanisms.
Measure authentication pass rate by subdomain (e.g., mail.example.com vs. app.example.com) — low pass rates on specific subcomponents signal misconfigurations unique to that service.
Monitor for new unauthorized IPs appearing in reports — frequent appearances of previously unseen IPs suggest potential spoofing attempts or compromised third-party tools.

How to operationalize these signals

Once parsed, these metrics become time series data you can visualize in tools like Grafana, Datadog, or custom dashboards. Daily rolling averages help smooth noise, while anomaly detection flags sudden shifts. The goal isn’t just to detect failure — it’s to identify trends before they hurt inbox placement.

For example, if DKIM alignment fails consistently on mail.example.com but not on support.example.com, it suggests a misconfigured email service or missing signing key for that specific subdomain. Similarly, a new IP showing up daily in DMARC reports with high failure counts may be a phishing vector or an unapproved bulk mailer.

Industry standards like RFC 7483 define DMARC report formats — understanding the structure is essential for reliable parsing and visualization. Tools like MxToolbox or Emailage (via their email risk APIs) offer insights into IP reputation, which can complement DMARC data when detecting malicious senders.

While DMARC gives you forensic visibility, combining it with real-time verification helps catch problems before they send: validate your email list regularly using a bulk verification tool to prevent abuse from known bad addresses or disposable domains.

For organizations managing multiple domains or high-volume sends, automating DMARC feed parsing into time series reduces manual effort and increases detection speed. Let’s focus on what matters: catching issues early, not chasing symptoms.

Tools that help parse DMARC XML into time series data

You can parse DMARC XML reports into time series data using custom scripts in Python with libraries like lxml or xml.etree.ElementTree, open-source tools such as dmarc-parser on GitHub, or scalable cloud-based ETL services like AWS Glue and Google Cloud Dataflow. These tools extract alignment failures, SPF/DKIM pass rates, and aggregate data over time for trend analysis. For deeper insights, you can feed parsed results into SIEM platforms like Splunk or the ELK stack to correlate email deliverability issues with security events. MailTester doesn’t parse DMARC XML directly, but it helps validate whether your email policies are effective by testing inbox placement and verifying delivery success at scale.

Custom Scripts with Python

Let’s say you're handling DMARC reports daily. Using Python’s built-in xml.etree.ElementTree or lxml lets you write lightweight, repeatable scripts to extract key fields—like policy enforcement, percentage of aligned messages, or failure types—into CSV or JSON. This approach gives full control over data transformation and is ideal for teams already working in Python. It also supports direct integration with dashboards or internal monitoring systems.

Open-Source and Cloud-Based Solutions

Open-source tools like dmarc-parser offer pre-built parsing logic and often include export options for tools like Grafana or Excel. These are valuable when you want to quickly analyze trends across domains without reinventing the wheel. For larger organizations, cloud ETL platforms such as AWS Glue or Google Cloud Dataflow allow automated, scalable pipelines that process incoming DMARC reports from S3 or Pub/Sub, transforming them into time-series databases for long-term tracking. These also handle schema evolution and error recovery automatically.

For compliance and threat detection, exporting parsed DMARC data to SIEMs like Splunk or the ELK stack enables correlation with other security telemetry. This helps you spot patterns—like coordinated spoofing campaigns or misconfigured senders—across your email ecosystem.

While MailTester doesn't parse DMARC XML, it supports a related goal: validating your deliverability posture. You can use its inbox placement testing to simulate how your emails land in real user inboxes, helping confirm that your DMARC policy is not only set but actually protecting your delivery reputation. For continuous quality control, its bulk verification and real-time API can clean and validate sender lists so only high-integrity addresses are used—a critical step before testing real-world delivery performance.

How MailTester complements DMARC-based monitoring

DMARC reports tell you whether your emails pass technical alignment checks, but they don’t tell you if those emails actually land in the inbox. MailTester’s inbox-placement testing shows whether your messages reach the primary inbox under real-world conditions—bypassing filters, spam traps, and content-based blocks that DMARC doesn’t detect. This gives you a complete picture: technical compliance from DMARC, real-world delivery from MailTester.

DMARC shows alignment. MailTester shows delivery.

DMARC parsing tells you if SPF and DKIM are configured correctly across your sending domains. But a pass in DMARC doesn’t mean your email gets delivered—it only means the technical signals align. Many legitimate messages fail to reach the inbox because of content filtering, sender reputation, or mailbox provider heuristics. Gmail, for example, applies strict content rules that aren’t visible in DMARC reports. MailTester sends real test emails to inboxes across Gmail, Outlook, Apple Mail, and others, showing whether your message arrives, is flagged, or is diverted to spam.

Use both: technical health and real-world performance

Imagine your DMARC reports show 98% alignment on outgoing emails. That sounds good—until you test delivery and find only 70% of messages actually reach the inbox. The gap reveals a mismatch: your infrastructure is technically sound, but real-world filters are blocking you. This is where combining DMARC with inbox placement testing becomes essential. With MailTester, you verify not just configuration, but effectiveness.

Let’s say you’ve configured SPF and DKIM across subdomains. DMARC says everything’s compliant. But a MailTester inbox test might catch that a specific brand domain gets quarantined due to aggressive content filtering—something DMARC never sees. You can then tweak the message body, sender name, or authentication setup, and re-test until delivery improves. This is how you move from reporting compliance to ensuring deliverability.

For teams using DMARC, MailTester fills the missing layer: validation under real mailbox conditions. You’re not just compliant—you’re delivering. This combination is what industry experts like Return Path (now Validity) have long emphasized: alignment is necessary, but not sufficient, for inbox placement. Return Path research consistently shows a gap between technical compliance and actual inbox placement, especially for high-volume senders.

For a quick test of how your messages perform, try MailTester’s inbox placement tester. It gives you a real-world readout across major providers—no jargon, no guesswork, just delivery proof.

Avoiding common pitfalls in DMARC report parsing

You’ll only get accurate time series data from DMARC reports if you handle variation in report frequency, incomplete reports, failure severity, and data quality upfront. Ignoring any of these risks skewed insights, invisible blind spots, or broken pipelines. Let’s break down the essentials.

Report frequency and aggregation

Don't assume all DMARC reports arrive daily—some senders send weekly, others only after a policy breach. Adjust your aggregation window to match the actual cadence; otherwise, spikes or dips appear artificially.
Track report timestamps strictly. A report marked “2024-04-01” but received on “2024-04-08” should be assigned to its proper date, not the receipt time, to preserve time series integrity.

Report completeness and failure context

Not every missing report means a security issue. If you expect daily reports and skip three in a row, that’s a signal. But if you’re set up for weekly reporting, don’t treat a gap as a failure—validate your expected cadence first.
Treat failures differently by source. A single DKIM failure from a third-party CRM used in bulk emails may be normal due to non-standard signing. But a sudden spike in failures across domains? That’s a red flag for configuration drift or credential leakage.
Malformed XML—common in reports from poorly implemented email systems—can break parsers or inflate metrics. Always validate the XML schema and strip invalid entries before analysis.

Even the cleanest DMARC data can mislead without proper validation. Use tools that confirm report structure and consistency—like the ones built into email deliverability monitoring frameworks, or services that analyze the health of your sending setup in real time.

For example, when sending transactional emails, ensure your signing practices align with the DMARC spec and use verified senders. You can test the delivery potential of individual addresses using MailTester’s email checker—helps spot issues early before they show up in reports.

Don’t parse blindly. Build in checks for time gaps, source context, and data integrity. That’s how you turn raw XML into reliable time series for monitoring deliverability health.

How to visualize DMARC time series for team collaboration

You can visualize DMARC time series data in Grafana by ingesting XML reports into a time series database like Prometheus or InfluxDB. Plot failure rates over time with configurable thresholds, set up alerting rules for spikes in SPF/DKIM failures, and group metrics by subdomain or service to track ownership. Use line graphs to surface seasonal trends, policy changes, or anomalies after infrastructure updates. This shared visibility helps teams respond quickly and collaboratively.

Set up dashboards to track trends and ownership

Once you’ve parsed DMARC reports, store them in a time series database. Grafana connects directly to these systems, letting you build interactive dashboards that show failure rates per day, week, or month. Let’s say you want to monitor your marketing domain separately from your support domain — you can slice the data by subdomain and assign ownership through labeled graphs.

Use line graphs to highlight patterns. A sudden spike in SPF failures after a migration? A seasonal drop in DKIM alignment during holiday campaigns? These trends become obvious when plotted over time. The key is consistency — ensure reports are processed hourly or daily to keep the data current and actionable.

Enable alerts for faster incident response

Set up alerting rules inside Grafana using PromQL or similar query languages. For example, if the daily SPF failure rate exceeds 5% for three consecutive days, trigger a Slack notification. This keeps engineering, security, and email teams informed without constant monitoring.

Use thresholds based on your historical average. A 5% failure rate might be normal for a high-volume sender; 15% probably isn’t. You can even add alerts for sudden drops in aggregate report volume, which could mean the sender stopped sending mail or the reporting process broke.

For a real-world example, the IETF’s RFC 7483 outlines DMARC’s reporting structure, including how to interpret alignment results and failure details. This standard helps ensure your parsing logic aligns with expected formats across senders. You can learn more from the IETF’s official specification.

Team collaboration improves when everyone sees the same data. Sharing dashboards across departments reduces blame-gaming and encourages proactive fixes. If your marketing team sees a spike in failures from their domain, they can react before the entire list gets flagged by ISPs.

While Grafana handles visualization, tools like MailTester can help validate the underlying sender infrastructure. If you’re verifying large lists before sending, use our bulk verification to clean your database and reduce the chance of alignment failures due to invalid or spoofed addresses.

What to do when DMARC time series show a sudden rise in failures

If your DMARC time series shows a sudden spike in failures, start by identifying the source IP from the report’s aggregate data. Compare it against known legitimate senders. If it’s from a third-party vendor or an internal application not in your email flow, investigate whether their configuration has changed. A spike often reveals a misconfigured system, unauthorized sender, or a breakdown in authentication alignment. Let’s walk through the key steps to diagnose it.

Check the source IP and sender context

Review the IP address in the DMARC report. Look at the source_ip field in the XML. Cross-reference it with your known sending environments—internal servers, marketing platforms, CRM integrations, or outsourced email providers. If the IP is new or unfamiliar, it may be from an unapproved service or a compromised account.
Validate the IP’s legitimacy. Use tools like MxToolbox to check if the IP is in a known blocklist or associated with spam activity. A sudden spike from a previously clean IP could signal a hijacked service or misconfiguration.

Inspect SPF, DKIM, and DMARC policy enforcement

Verify SPF and DKIM records. Misaligned or expired SPF records are common causes of failure. Check that your SPF includes only authorized sending IPs and that the record is under 10,000 characters (the RFC limit). DKIM signatures must be valid and align with the from domain. A recent change here can explain a sudden drop.
Confirm DMARC policy status. If the policy was previously set to none, but now shows quarantine or reject, the spike may be due to enforcement being activated, not a new attack. This is a common shift when organizations mature in their email security posture.
Test delivery from the suspect IP. Use an email-verification tool to simulate outbound delivery from that IP. MailTester’s inbox placement test lets you check how messages land in real inboxes and identify why they might be flagged as spam or rejected.

Even a single misconfigured application can inflate DMARC failure rates, leading to reputational harm. Catching the root cause early prevents cascading delivery issues.

Once you isolate the source, correct the configuration—update SPF, adjust DKIM signing, or disable the non-compliant sender. Monitor the next DMARC report cycle to confirm alignment. Automation helps, but always validate changes with real-world testing.

Summary: Parsing DMARC XML into time series is essential for modern deliverability

Raw DMARC reports contain data, but no insight. Without parsing, they remain static logs—unusable for proactive monitoring or trend analysis.

Turning reports into monitors

Converting DMARC XML into time series transforms them from passive records into active monitors. This enables you to spot alignment failures, detect spoofing attempts, and track sender reputation over time.

Integrating with real-world validation

Pair parsed time series data with inbox placement testing via tools like MailTester. This confirms whether technical fixes actually improve delivery in real user inboxes—not just in logs.

When combined, these practices create a closed-loop system: identify misconfigurations, verify delivery, correct alignment, and measure impact across days and domains.

Sources

Only 22.9% of top domains enforce DMARC with p=quarantine or p=reject, while 29.2% remain in monitoring-only p=none mode that blocks nothing. — EasyDMARC 2026 DMARC Adoption & Enforcement Report (2026)
Google reported 265 billion fewer unauthenticated messages sent to Gmail users in 2024 — a 65% reduction — after its bulk-sender rules took effect, with 500,000+ top domains publishing DMARC records in response. — Google (via MailOver bulk-sender requirements guide) (2024)

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What is the best way to parse DMARC XML reports automatically?

Use a script in Python with lxml to extract records, group by time and IP, then export to a time series database or dashboard tool.

How often should I check DMARC XML reports for time series analysis?

Daily aggregation is standard; for real-time alerting, process reports hourly. Frequency depends on send volume and policy sensitivity.

Can DMARC XML reports detect if my emails are going to spam?

Not directly. They identify alignment failures and unauthorized senders but don’t measure spam filtering decisions. Combine with inbox-placement testing.

Why do I see DKIM failures in DMARC reports when my DKIM is set up correctly?

Common causes include misaligned header domains, incorrect signing headers, or mismatched key selectors. Verify signing and alignment in the report details.

Do I need a dedicated email address to receive DMARC reports?

Yes. You must designate a mailbox (typically [email protected]) where reporting senders deliver aggregate reports.

How do I know if my DMARC parsing is working correctly?

Test the output with sample reports. Validate metrics against known data—e.g., a known spam source should appear in failure logs.

What is the difference between SPF, DKIM, and DMARC?

SPF validates the sending IP; DKIM verifies message integrity; DMARC enforces policies based on SPF/DKIM results and delivers reports.

Can I use MailTester to debug DMARC report issues?

MailTester doesn’t process DMARC reports. It tests whether emails actually land in the inbox, helping confirm if DMARC-aligned sends are effective.

Are DMARC reports sent from every sender?

No. Only organizations with valid DMARC policies in DNS and compliant mail infrastructure submit reports. Report coverage varies.

Is it safe to store DMARC XML reports in the cloud?

Yes, if stored securely with proper access controls. Avoid plaintext logs in public buckets. Use encryption at rest and access logs.

How long should I keep DMARC reports for time series analysis?

Retain for at least 90 days to detect seasonal patterns and long-term anomalies. Use automated clean-up policies to prevent clutter.

Can I detect spoofing attempts using DMARC time series?

Yes. Sudden spikes in non-aligned senders or new IPs using your domain are strong indicators of impersonation or account compromise.