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

OnDMARC grouped Microsoft 365 and Google Workspace into recognizable source names within the first reporting cycle, and it separated SendGrid and Mailchimp traffic after we added expected DKIM selectors. The unknown sender did not remain as a raw IP list; we could tag it, compare its authentication history, and attach a remediation note. In the DKIM pass on a subdomain case, OnDMARC showed why the message still needed policy review on the parent domain.

Splunk TA-DMARC add-on ingested aggregate reports from the report mailbox and preserved the XML fields we needed for custom searches. Microsoft 365 and Google Workspace appeared as searchable events, but source naming depended on our lookup tables. SendGrid and Mailchimp separation required SPL work, and the SPF pass with visible from mismatch was visible in raw fields without a DMARC-specific guided fix.

OnDMARC treated the primary corporate domain, marketing subdomain, and parked domain as related but separate assets, which made the setup sequence easy to explain to DNS owners. The unknown sender was visible in the sender list after enough reports arrived, and we could mark it for investigation without leaving the product. The forwarded mail SPF failure was explained as a forwarding pattern instead of a plain failure count, which helped avoid a false escalation.

Splunk TA-DMARC add-on felt familiar once the data reached Splunk, but the first useful view required more work. We had to confirm mailbox polling, validate parsing, decide index naming for the three domains, and build searches to find the unknown sender. The forwarded mail SPF failure was present in event fields, but explaining it to a non-Splunk stakeholder required a custom panel and written notes.

With OnDMARC, the expected support path was clear during setup: add the domains, publish DNS records, review senders, then decide policy movement. Our DNS handoff for the parked domain had enough context for a separate infrastructure owner to act without a long meeting. Enterprise onboarding also had clearer escalation paths for SSO, role control, and review cadence.

Splunk TA-DMARC add-on is marked not supported, so the useful support model was internal. We could rely on Splunk administrators for data ingestion and searches, but DMARC-specific questions such as how to treat a support desk sender or the unauthorized spoof sample needed our own judgement. DNS handoff, escalation wording, and enterprise onboarding notes all had to be written by the team running the test.

OnDMARC worked best for an enterprise or mid-market team that owns DMARC outcomes rather than just log collection. Account separation and domain grouping were usable, though authorization groups took planning when we imagined many departments or client domains. Recurring reporting was easier to prepare for executives, and SMB handoff worked when the buyer had one DNS owner and a short sender list.

Splunk TA-DMARC add-on worked best for an operations team that already has Splunk indexes, role design, and reporting patterns. For MSP use, client grouping was possible only through Splunk architecture choices, so tenant separation and recurring reports had to be designed up front. Enterprise teams with strong Splunk ownership get useful evidence; SMBs without Splunk skill get a heavy setup burden.