DMARCLytics vs.
Splunk TA-DMARC add-on in 2026

In our Microsoft 365 and Google Workspace traffic, DMARCLytics grouped the core business mail quickly and made SendGrid and Mailchimp easy to separate after two report cycles. The unknown sender needed a manual trust or investigate decision, but the trusted sender controls gave us a clear place to record it. The SPF pass with visible From mismatch was easier to explain than the forwarded mail case because the UI separated authentication results and visible sending identity better than it explained forwarding paths.

Splunk TA-DMARC add-on did the ingestion work: IMAP polling, XML validation, JSON or key=value output, CIM Authentication fields, source IP resolution, and DKIM result logging. Microsoft 365, Google Workspace, SendGrid, and Mailchimp became useful only after we built searches and lookup tables, and the DKIM pass on a subdomain needed custom SPL to roll up into a sender view. It handled malformed data defensively, but it did not provide DMARC-specific policy movement, hosted records, or a built-in sender classification workflow.

Onboarding the corporate domain, marketing subdomain, and parked domain took one session because the DNS records and verification states were on the same path. We found the unknown sender by filtering the sender distribution view, then added a note for ownership. Explaining forwarded mail with SPF failure took longer because the UI showed the failure clearly but did not make the forwarding reason obvious enough for a non-specialist.

The Splunk add-on felt like a technical pipe, not an application. The three domains were easy to separate only after we chose index conventions and source types, and the unknown sender became findable after we wrote SPL around source IP, header domain, and org domain. Explaining forwarded mail with SPF failure was accurate once the event existed, but we had to build the explanation ourselves.

During setup, the DNS handoff was easy to package: copy the RUA target, confirm reporting, then move into hosted DMARC or hosted SPF if the plan allowed it. Email support fit the Starter-style path, while priority support and a dedicated DMARC engineer were relevant for the ten-domain and enterprise scenarios. The gap was clarity: pricing and plan labels conflict, so escalation expectations need confirmation before procurement.

Splunk TA-DMARC add-on had no product support path in our test because the listing is marked not supported and the repository is archived. DNS handoff was outside the add-on entirely, and OAuth mailbox setup, forwarder placement, index permissions, alert routing, and dashboard creation belonged to our Splunk administrators. For enterprise onboarding, that is acceptable only when the organization already funds Splunk operations.

DMARCLytics handled our primary domain, marketing subdomain, and parked domain as a small portfolio, which fit a single company or a lean IT team. Account separation was basic unless we moved into higher-tier or custom plans, and the Agency/MSP language needed confirmation because it was not a clean public plan. Recurring reporting was useful for executives, but client handoff would need standardized notes outside the product.

Splunk TA-DMARC add-on is not an SMB tool unless the company already runs Splunk. It can fit enterprise security teams because account separation, domain grouping, retention, exports, and recurring reporting can be built with Splunk indexes, roles, scheduled searches, and dashboards. For an MSP, that flexibility has value, but every client handoff depends on custom conventions and operations discipline.