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

MyDMARC handled Microsoft 365 and Google Workspace as recognizable sources after the first report cycle, then made SendGrid and Mailchimp easier to review on the marketing subdomain. The unknown sender on the parked domain entered a classification workflow rather than staying as a raw IP, and the SPF pass with visible From mismatch was visible enough to assign a fix to the sending owner. The gaps were around non-reporting controls: no hosted SPF, no hosted MTA-STS, and no blocklist (blacklist) monitoring appeared in our test.

Splunk TA-DMARC collected the aggregate XML and exposed useful event fields for Microsoft 365, Google Workspace, SendGrid, Mailchimp, and the support desk sender. Its strength was that the unauthorized spoof sample and DKIM pass on a subdomain were searchable in the same environment as other security logs. The tradeoff was manual work: unknown sender classification required lookup tables or SPL enrichment, and forwarded-mail SPF failure needed an analyst to explain the DMARC outcome.

Onboarding the corporate domain, marketing subdomain, and parked domain in MyDMARC took about 35 minutes before reports started landing. The DNS setup steps were clear, the unknown sender was easy to find after the first parked-domain report, and the forwarded-mail SPF failure was readable because the DKIM pass still explained why DMARC passed. The interface was less useful when we wanted deep alert routing or client-style account separation.

TA-DMARC took about 3 hours to configure because mailbox polling, index selection, parsing validation, and dashboard cleanup all needed attention. Finding the unknown sender was straightforward after we wrote a saved search, but explaining the forwarded-mail SPF failure required reading raw SPF, DKIM, and policy fields together. For a Splunk team this is acceptable; for a business owner it adds translation work.

During setup, MyDMARC gave us enough DNS handoff detail to send record updates to a domain administrator without rewriting the instructions. Priority email support was tied to the higher public plan, and the path for larger enterprise onboarding was less explicit than the product workflow itself. For our three test domains, the support expectation was adequate, but complex account separation or custom reporting would need confirmation before purchase.

TA-DMARC required self-directed setup. The add-on was archived, the public listing identified it as not supported, and any escalation around parsing, mailbox polling, or dashboard behavior would fall back to internal Splunk knowledge or platform support. That is workable for an enterprise security team with Splunk administrators, but it is a poor fit for an SMB that wants a DMARC vendor to own onboarding.

MyDMARC worked best when one team owned the corporate domain and marketing subdomain together. Domain grouping was enough for our test, recurring reporting was simple through exports, and sender handoff was understandable for Microsoft 365, SendGrid, and Mailchimp owners. It was weaker for MSP use because account separation, client grouping, and recurring client notes felt more manual than purpose-built.

TA-DMARC worked best when Splunk was already the operational system. Account separation can be modeled with indexes, roles, dashboards, and saved searches, and scheduled reporting can be built for business units or clients. That flexibility is useful for enterprise security operations, but it shifts handoff design, recurring report wording, and client-facing explanation onto the team running Splunk.