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

DMARCly gave us a dedicated DMARC workflow for Microsoft 365, Google Workspace, SendGrid, Mailchimp, and the support desk sender. Microsoft 365 and Google Workspace were grouped cleanly on the corporate domain, SendGrid and Mailchimp were visible on the marketing subdomain, and the parked domain made the spoof sample easy to isolate. The SPF pass with visible from mismatch was flagged as a DMARC failure in the right place, although the unknown sender still needed manual classification before we were comfortable assigning an owner.

Splunk TA-DMARC add-on focused on ingestion and field availability. It brought XML aggregate reports into Splunk, resolved source IPs, mapped events into searchable fields, and let us join Microsoft 365, Google Workspace, SendGrid, and Mailchimp traffic with other logs. The tradeoff was that classification stayed with us: the unknown sender needed a lookup table, and the DKIM pass on a subdomain was visible as data rather than a guided finding.

DMARCly took the three test domains through setup with clear DNS records, visible verification states, and a natural split between the corporate domain, marketing subdomain, and parked domain. Finding the unknown sender took drilldown work, but it stayed inside the DMARC reporting flow. The forwarded mail SPF failure was visible, yet it needed a human explanation before we would send it to an application owner.

Splunk TA-DMARC add-on felt like a data pipeline first and a DMARC workflow second. Onboarding required mailbox configuration, index decisions, sourcetype checks, and search validation before the three domains became usable. The unknown sender was findable with searches, and the forwarded mail SPF failure made sense after comparing SPF, DKIM, and disposition fields, but neither task had a guided path.

DMARCly's support model fit the SaaS DMARC buying motion. The DNS handoff was clear enough for the primary domain and marketing subdomain, and the parked domain setup needed little explanation. Our setup question about the support desk sender received a practical answer on the next business day, while enterprise items such as SSO, API access, and access control were clearly tied to the highest tier.

Splunk TA-DMARC add-on required a different support expectation. The add-on was marked not supported, and our setup work depended on Splunk admin knowledge for mailbox access, indexing, parsing, and saved searches. Escalation for DMARC interpretation, DNS ownership, and enterprise onboarding was not part of the add-on experience.

DMARCly worked well for the primary corporate domain and marketing subdomain because domain groups, sender views, and published limits were easy to explain to non-specialists. For MSP use, the lower tiers felt constrained by domain group counts, user limits, and handoff notes. Recurring reporting was usable, but client-ready explanations for the forwarded mail SPF failure and unknown sender still needed manual writing.

Splunk TA-DMARC add-on fit the enterprise operator who already has Splunk indexes, RBAC, saved searches, and dashboard standards. Account separation and domain grouping were possible, but only after designing the Splunk structure. MSP handoff and recurring client reports required custom dashboards, scheduled exports, and an internal owner for every classification rule.