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

In Everest, Microsoft 365 and Google Workspace grouped cleanly under recognizable mail streams after DNS records were verified, and SendGrid and Mailchimp were easy to separate because the drilldowns tied IP ranges, DKIM domains, and pass rates together. The support desk sender needed a manual owner note, and the unknown sender stayed unresolved until we cross-checked headers. For the SPF pass with visible from mismatch, Everest surfaced the authentication result, but the policy implication was clearer after a manual review of the domain mismatch rather than from an automated remediation path.

Splunk TA-DMARC ingested aggregate XML from mailbox collection, mapped events into Splunk fields, and made the Microsoft 365, Google Workspace, SendGrid, and Mailchimp streams searchable by source IP, DKIM domain, and report sender. It did not label services for us, so the unknown sender required a lookup table, and the DKIM pass on a subdomain needed a saved search to explain why the organizational domain still matched. The benefit was auditability: every forwarded mail SPF failure and spoof sample could be reconstructed from indexed events.

Onboarding the primary corporate domain, marketing subdomain, and parked domain in Everest took one working session once DNS access was ready. The DMARC reporting view made the parked domain's spoof sample stand out because legitimate traffic was near zero, but finding the unknown sender took several drilldowns between source, domain, and authentication views. The forwarded mail SPF failure was visible, yet we still had to explain to a nontechnical owner why DKIM domain match saved the message.

Splunk TA-DMARC setup felt like a Splunk data onboarding project: create the mailbox input, validate XML parsing, confirm index routing, and build views for each domain. The unknown sender was easier to investigate once we added a reverse DNS and ASN lookup, but that lookup was ours to maintain. Explaining the forwarded mail SPF failure required a custom panel that paired SPF fail with DKIM pass and final DMARC disposition.

During the Everest test, the expected path was sales and customer success led onboarding, with DNS changes handed to the internal admin and questions routed through enterprise support. That helped when we asked for a clean handoff around Microsoft 365 and SendGrid domain matching, but it also meant the parked-domain enforcement question waited for scheduled review rather than being resolved inside the product. Escalation was viable for enterprise teams, although pricing and packaging depended on a sales conversation.

Splunk TA-DMARC did not give us a product support path for DMARC decisions because the add-on is not supported and archived. Setup help came from reading add-on docs, checking Splunk input errors, and treating DNS handoff as our own runbook. Escalation would sit with the internal Splunk owner or platform support contract, not with a DMARC specialist who can review an SPF mismatch or spoof sample.

Everest handled account separation better than a basic DMARC report viewer because child accounts and dashboards let us separate the corporate domain, marketing subdomain, and parked domain. For enterprise use, recurring reporting was credible because reputation, blocklist/blacklist, and authentication signals could sit in one executive view. For MSPs and SMBs, the workflow felt heavier: client handoff notes and source-owner tasks lived outside the core DMARC path, and the quote-based buying motion did not match a small recurring service package.

Splunk TA-DMARC fit best where the buyer already had Splunk ownership, index strategy, and alert routing. Account separation worked through indexes, roles, and dashboards, but that meant MSP client grouping and recurring reports had to be designed by the operator. For SMBs, the add-on was too bare unless they already had Splunk; for enterprise security teams, it put the spoof sample and forwarded-mail edge cases in the same investigation system as other authentication events.