How to Add DMARC Monitoring to Your MSP SIEM Stack

Why DMARC monitoring matters for MSPs

When a domain runs p=reject or p=quarantine, any source sending email without proper SPF and DKIM alignment will fail authentication. Those failures show up in DMARC aggregate reports -- but only if you're collecting them.

Most MSPs don't have a systematic collection process. A DMARC failure might be happening right now while your team is reviewing Huntress alerts and Sophos logs with no visibility into what the authentication layer is flagging.

What DMARC reports tell you

DMARC aggregate reports (sent to your RUA address) arrive on a schedule -- typically every 24 to 72 hours depending on the receiver. Each report contains XML with counts of:

Emails that passed or failed DMARC
SPF and DKIM individual results
Source IP addresses sending mail for your domain

The failure data is what matters most. A sudden spike in DMARC failures from a single source IP often means either:

A third-party sender was added without proper authentication setup, or
Someone is spoofing your client's domain

Both are actionable. Neither shows up in your SIEM by default.

Option 1: Native DMARC tool with API integration

The most practical approach for most MSPs is a dedicated DMARC monitoring tool that parses reports, sends alerts on authentication failures and policy changes, aggregates results across all client domains in one view, and provides API or webhook access to connect into your existing stack.

For example, DMARCFlow (starting at 1 EUR/month) handles the report parsing and alerting layer directly. You can connect it to Huntress, Microsoft Sentinel, or any platform that accepts webhook data. The key advantage for MSPs: you get a dashboard that makes per-client DMARC status scannable without manually opening XML reports.

This approach works well when:

You manage 5 to 500 client domains
You want alerting without building custom XML parsing pipelines
Your team needs a quick view of client email authentication health

The tradeoff: you're adding another tool. But the tool does the hard part -- parsing and alerting -- so you don't have to maintain custom logic.

Option 2: SIEM-native DMARC report ingestion via IMAP/SMTP

If your MSP runs Huntress, Splunk, Microsoft Sentinel, or a similar platform, you can route DMARC reports through your SIEM by setting up a dedicated IMAP inbox for RUA reports and having your SIEM poll it.

The approach:

Create a dedicated email address for DMARC reports (e.g., dmarc-reports@your MSP domain)
Configure your clients' DMARC records to send RUA reports to that address
Set up an IMAP poller in your SIEM to fetch new messages
Parse the XML attachment and extract failure events

This is more work than using a native DMARC tool. DMARC XML is verbose and schema variations exist between senders (Microsoft 365 vs Google Workspace format the same data differently). You'll need to maintain the parsing logic as senders change formats.

It works when you have an existing SIEM team who can own the pipeline and you want all security events in one place without a separate tool.

The honest downside: maintaining XML parsing for multiple email providers is ongoing work. Most MSPs find this approach faster to prototype than to operate at scale.

Option 3: Syslog or webhook forwarding to a log aggregation platform

Some DMARC monitoring tools and a few enterprise platforms support forwarding authentication events as syslog messages or webhooks to a central logging system.

This approach suits MSPs that already run:

Datadog
Splunk Cloud or Enterprise
Elastic (ELK stack)
Microsoft Sentinel (via webhook or log analytics)

You configure the forwarding in your DMARC monitoring tool, and failure events appear as log entries alongside your firewall, endpoint, and identity logs.

The challenge: raw DMARC events are voluminous and noisy. Without alert tuning, you'll end up with dashboards that show every SPF softfail from a bulk sender -- not the targeted spoofing attempt you actually care about.

This works best with a team that can build and tune alerting rules, not just collect logs.

Implementation checklist: DMARC monitoring per client

Before you start, decide which clients need active monitoring. Not every client needs the same level of attention.

Minimum setup (all clients):

[ ] Confirm every client domain has a DMARC record (even p=none is better than nothing)
[ ] Point RUA reports to a central inbox or monitoring account your MSP controls
[ ] Set up an alert for when DMARC failures exceed 10% of total volume in a 24-hour period

Standard setup (clients with tighter security needs):

[ ] Deploy a DMARC monitoring tool that parses reports and sends alerts
[ ] Enable alerts for p=none → p=quarantine or p=reject policy changes
[ ] Set up weekly or daily digest for clients who don't need real-time alerts
[ ] Track third-party senders: flag when a new source IP starts sending on behalf of a client's domain

Advanced setup (enterprise MSP clients):

[ ] Integrate DMARC events into your SIEM via webhook or API
[ ] Correlate DMARC spikes with threat intelligence feeds
[ ] Build client-specific dashboards showing authentication health over time

Which DMARC events to alert on

Not everything needs an urgent page at 2 AM. Prioritize alerts that indicate active risk:

Alert immediately:

Spike in DMARC failures from a new source IP -- possible spoofing in progress
DMARC policy change from p=none to p=quarantine or p=reject -- legitimate change or someone hijacking your client's domain settings
Multiple client domains failing DMARC simultaneously -- bulk compromise or provider issue

Review daily:

Consistent low-level DMARC failures from the same source IP -- third-party sender misconfiguration
DKIM failures on a domain that previously passed -- key rotation gap or signing issues
SPF alignment failures on bulk email providers -- often from mailing lists or forwarded mail

FAQ: DMARC monitoring for MSPs

Can I parse DMARC reports directly in Splunk or Microsoft Sentinel?

Yes, but you need to handle the XML parsing yourself. Microsoft Sentinel has a DMARC connector in the Content Hub. For other platforms, you can write a custom parser or use a tool that converts the XML to JSON before ingestion. The parsing logic needs maintenance as provider formats evolve.

How often do DMARC aggregate reports arrive?

Most receivers send reports daily, but some send them less frequently -- sometimes only after a threshold of messages is reached. Report delays of 24 to 72 hours are normal. If you need real-time visibility, you need a monitoring tool that polls the receiver's API directly rather than waiting for email delivery.

What is the minimum DMARC setup every MSP should have per client?

At minimum: a p=none DMARC record with an RUA address your MSP controls. That gives you visibility into who's sending mail for your client's domain. From there, you can grow into active monitoring as the client's email security matures.

How do I monitor DMARC for clients using Microsoft 365 vs Google Workspace?

Both platforms send DMARC reports automatically once you publish the record. The reports go to the address specified in your rua= tag. Microsoft 365 reports tend to be more detailed and consistent. Google Workspace sometimes sends fewer but larger reports. Either way, the collection mechanism is the same: an email address or a tool that receives the XML.

Can I get DMARC alerts without a dedicated monitoring tool?

You can, but it requires more plumbing. You need an inbox that receives the XML reports, a way to parse them, and alerting logic on top. Most MSPs find that the overhead of maintaining that pipeline exceeds the cost of a dedicated tool, especially at scale.