DMARC for SaaS founders: why your sending sources multiply without you noticing
Your SaaS product is sending email from more sources than you know about, and at least one of them is misconfigured. Transactional mail, marketing drips, support replies, and calendar notifications all go out under your domain from separate services, each requiring its own SPF authorization and DKIM signature. The only way to see the full picture is DMARC aggregate reports: daily XML summaries from Gmail, Outlook, and Yahoo listing every IP that claimed to be you, and whether authentication passed or failed. Nobody reads them voluntarily because they arrive as gzipped XML, so the misconfigured source stays misconfigured until deliverability breaks badly enough to notice.
How the sending sources multiply
A typical SaaS product sends from multiple sources at the same time:
- Transactional mail: password resets, billing notifications, new signup welcome emails via Resend or SES
- Marketing mail: onboarding drips, product updates, newsletter via Mailchimp or a similar tool
- Support replies: tickets answered from your domain via Intercom or Help Scout
- Internal team mail: meeting invites, calendar notifications via Google Workspace
Each of these is a separate sending source. Each one needs to be authorized to send from your domain (SPF), and each one needs a valid DKIM signature that aligns with your domain. When those are in place, DMARC passes. When they aren't, DMARC fails.
The problem is that these sources do not accumulate by policy. They accumulate by action. A new marketing hire signs up for a campaign tool and connects it to your domain. A support agent adds a new email integration. Someone enables a transactional notification you weren't aware of. Each time, the setup screen says something like "configure your sending domain" and shows a technical form that the person filling it out may or may not complete correctly.
Why you don't know about the misconfigured one
If a sending source is misconfigured, the failure is quiet. The email may still get delivered, because your DMARC policy is likely still at p=none (monitoring only). The user whose password reset landed in spam may or may not file a support ticket. If they do, the ticket says "I didn't get the email," which means you start debugging the wrong thing: queue depth, send rate, the user's spam filter, anything except DMARC alignment.
The misconfigured source is invisible unless you look at your aggregate reports.
DMARC aggregate reports are daily summaries sent by major mail receivers: Gmail, Outlook, Yahoo, iCloud. They list every IP address that sent mail claiming to be from your domain, how many messages it sent, and whether SPF and DKIM passed or failed. They are the only way to see your full sending picture without already knowing what to look for.
The catch is that aggregate reports arrive as gzipped XML. Parsing one is a minor engineering project. Reading all of them every day is not something anyone does voluntarily. So the data exists, nobody reads it, and the misconfigured source stays misconfigured until something downstream breaks badly enough to notice.
What SPF and DKIM records alone cannot tell you
Your engineer configured SPF and DKIM for Resend. You know that part is right. What your SPF and DKIM records cannot tell you is whether the Mailchimp connection your marketing hire set up last quarter is aligned, whether the Help Scout integration is signing with your domain or theirs, or whether there are any sending sources appearing in your reports that nobody on your team authorized.
SPF and DKIM are configuration. DMARC reports are observability. The configuration tells receivers what should be authorized. The reports tell you what is actually happening.
One misconfigured sender affects the whole picture in two ways. First, their failures reduce your overall alignment percentage, which is the metric receivers use when deciding how aggressive to be with your mail. Second, if you ever want to move your DMARC policy from p=none to p=quarantine or p=reject for actual spoofing protection, you cannot do it safely until that source is fixed. You can't fix what you can't see.
What monitoring gives you
A DMARC monitoring service does one thing the records themselves don't: it reads the reports for you and surfaces what matters.
The alignment rate across all senders in one number. Unknown sending sources flagged when they appear. An alert when something that was passing starts failing. A weekly summary that tells you either "your mail stream is healthy" or "here is the specific source you need to look at."
You still need your engineer to fix the underlying misconfiguration when one is found. But finding it is the hard part, and it no longer requires anyone to manually parse XML every morning. Use the SPF/DKIM/DMARC checker to see the current state of your domain's authentication records, or load an individual report into the DMARC analyzer to see what a single XML file contains.
For the broader context on how alignment works and what each policy level means, DMARC for indie developers covers the mechanics in detail. If your setup involves multiple ESPs and you want the full authentication picture, Email deliverability guide for indie SaaS walks through SPF, DKIM, and DMARC configuration end to end.
You don't need to understand the XML
The aggregate reports are not written for you. They're written so machines can parse them. You don't need to read them: you need to know that a tool is reading them and will tell you when something worth acting on appears.
That is the actual goal: knowing your mail stream is healthy without having to think about it, and getting a specific alert when it isn't. Not a daily dashboard to check. Not a compliance score to improve. An alert that says "Mailchimp alignment dropped to 40% this week, here's the source" so your engineer can fix it before your deliverability does.
DMARCdrift is free for one domain. Point your rua= address at us and the first digest arrives within a week.