MyDMARC vs.
DMARCly in 2026

In MyDMARC, Microsoft 365 and Google Workspace appeared quickly enough for weekly review, and SendGrid and Mailchimp were visible after their aggregate reports arrived. The unknown sender still needed manual classification, and the DKIM pass on the marketing subdomain was clear only after we drilled into the domain view. The SPF pass with visible From mismatch was visible, but the product did not turn it into an owner-ready fix without our notes.

DMARCly gave us more to configure, but it also gave us more coverage once the account was organised. Microsoft 365, Google Workspace, SendGrid, Mailchimp, and the support desk sender were easier to compare by source, and the forwarded mail SPF failure had a better trail for separating relay behaviour from spoofing. The unauthorised spoof sample stood out clearly, and the added Safe SPF, MTA-STS, TLS-RPT, API, and reputation options made the tool more useful for operators.

With MyDMARC, we added the corporate domain, marketing subdomain, and parked domain in one sitting, then waited for reports to populate. The unknown sender was easy to spot as an outlier, but classifying it meant keeping a separate owner note and checking whether it belonged to the support desk sender. The forwarded mail SPF failure was visible, yet we had to explain the relay path ourselves before deciding not to treat it like spoofing.

DMARCly made the first setup feel denser because domain groups, DNS checks, Safe SPF, and reporting settings all asked for attention. That extra structure helped in week three, when we needed to isolate the parked domain, confirm the Mailchimp marketing flow, and explain why forwarded mail failed SPF while DKIM still protected the visible From domain. The unknown sender took fewer clicks to compare against known vendors.

During setup, MyDMARC gave us enough direction to publish DMARC records for the three domains and verify that reports were arriving. The DNS handoff to a non-specialist still needed our own wording, especially for the parked domain and the support desk sender. Priority email support only appeared on the Pro tier, and we did not see a public enterprise onboarding path for a portfolio beyond 20 monitored domains.

DMARCly's support expectations were easier to map to account size because email support, live chat support, and enterprise controls were listed by tier. The DNS handoff still needed careful explanation, but Safe SPF and MTA-STS gave us clearer topics to escalate. Enterprise onboarding looked more defined for access control and API use, although the tool still expected the operator to understand the authentication cases.

MyDMARC was most suitable for the SMB version of our setup: one corporate domain, one marketing subdomain, and a parked domain that only needed spoof visibility. Account separation and client handoff were not strong parts of the workflow, so an MSP would need external notes for ownership, recurring reporting, and client-ready remediation. For an enterprise portfolio, the lack of public detail above 20 domains made planning harder.

DMARCly fit the operator use case better because domain groups, API access, SSO, and higher domain limits gave us a cleaner account model. An MSP could group clients or business units more clearly and use recurring reports with fewer manual exports. The tradeoff is that SMBs with one or two domains pay for a broader tool than they need unless SPF flattening, MTA-STS, reputation checks, or API access are already on the roadmap.