DMARCly vs.
DMARC-SRG in 2026

DMARCly named Microsoft 365 and Google Workspace quickly, then grouped SendGrid and Mailchimp traffic after we marked those senders as expected. The SPF pass with visible From mismatch was obvious in the drilldown, and the DKIM pass on a subdomain was visible, but the forwarded mail SPF failure still needed a human note explaining that DKIM protected the message.

DMARC-SRG ingested the same aggregate reports and showed rows by domain, reporter, source IP, SPF result, and DKIM result. Microsoft 365 and Google Workspace were visible through report origins and IP patterns, not clean service names, and SendGrid, Mailchimp, the unknown sender, and the DKIM subdomain case required manual tagging. The unauthorized spoof sample was visible as failed SPF and DKIM, but there was no guided remediation workflow.

DMARCly onboarding took about an hour for the corporate domain and marketing subdomain once RUA records were published; the parked domain was quiet enough that the policy prompts were conservative. The unknown sender appeared as a separate source after the next aggregate report landed, and the forwarded mail SPF failure was findable in drilldowns, although the UI did not write the explanation for a non-technical owner.

DMARC-SRG onboarding took longer because the server, database, mailbox ingestion, and cleanup schedule had to be configured before useful reports appeared. Finding the unknown sender meant filtering by source IP and reporter, then adding our own classification note outside the product. The forwarded mail case was visible only as an SPF failure with DKIM pass, so we had to explain forwarding in our handoff.

During setup we expected DMARCly support to handle subscription, DNS, and account questions, and the product's plan table made that support boundary clear. The DNS handoff still required our own screenshots and owner notes for SPF mismatch and forwarding, but there was a named vendor path for escalation. Enterprise onboarding looked clearest on the top tier because SAML SSO, access control, API access, and expanded domain groups are packaged there.

DMARC-SRG support felt like project ownership, not vendor onboarding. The team running it must maintain PHP, MariaDB or MySQL, IMAP ingestion, cleanup, backups, and web access controls. For enterprise review, we found no commercial SLA, managed DNS handoff, or formal escalation path, which changes the cost even though the software is free.

DMARCly handled our corporate domain, marketing subdomain, and parked domain as a small portfolio, and domain groups made recurring exports clean enough for monthly review. It was less MSP-specific than a client portal because account separation leaned on domain groups, administrator access, and higher-tier controls. For an SMB or mid-market team, that was acceptable; for a busy MSP, handoff notes and client-specific alert routing still needed process outside the tool.

DMARC-SRG fit a technical SMB that wants ownership of data and has someone to maintain the application. It did not give us account separation, recurring client reports, or built-in handoff notes for multiple customers. For MSP work, each client would need separate operational handling, which increases effort when unknown senders, parked-domain spoofing, and forwarded mail need explanations.