DMARC

Finding Every Legitimate Sender Before DMARC Enforcement Finds Them First

September 28, 2026

Rodney Hall, COO— AI-assisted and reviewed prior to publication.

Every domain that moves toward DMARC enforcement carries a hidden inventory problem. Somewhere in a client's sending footprint is a helpdesk tool, an invoicing platform, or a marketing service that has been sending mail on the domain's behalf for years without anyone tracking whether it authenticates properly. The workflow for finding and fixing those senders, not the DMARC record syntax itself, is what determines whether an enforcement rollout succeeds or turns into a rollback.

What is the actual risk of moving to DMARC enforcement too fast?

The risk is not theoretical bounce reports. It is real business mail, invoices, password resets, sales notifications, silently dropped by receiving mail servers because a legitimate sending service never had a compliant SPF or DKIM setup. Once a policy of p=reject is published, receiving mail servers are expected to discard messages that fail alignment with no further delivery attempt and no bounce reaching the sender in many cases.

That risk is exactly why the DMARC specification never mandates jumping straight to enforcement. RFC 7489, and its successor RFC 9990 published under the IETF's DMARC standards track work, define the aggregate report mechanism specifically so domain owners can observe sending behavior before committing to a blocking policy. The reports exist because the working group assumed, correctly, that most domains do not know their own sending footprint on day one.

The core operational answer: legitimate senders that fail authentication get identified by systematically reading DMARC aggregate reports for every source IP sending mail as the domain, cross-referencing each one against a maintained inventory of approved services, then fixing SPF and DKIM for each real gap before ever tightening the policy percentage or moving past p=none.

Why do legitimate senders fail authentication in the first place?

Most failures trace back to one of three causes: a third-party service sending mail from its own infrastructure without being added to the domain's SPF record, a service that supports DKIM signing but was never configured to use it, or a forwarding path that breaks SPF alignment entirely. None of these are exotic. They are the default state of a domain that has accumulated vendors over years without a central authentication register.

SPF has a structural constraint that makes the problem worse over time. RFC 7208 caps SPF evaluation at ten DNS lookups per check, and every include mechanism used to authorize a new SaaS vendor consumes part of that budget. Domains that have added marketing platforms, CRMs, and support desks one at a time for years frequently discover they are already near or past the limit, which produces a permerror that some receivers treat as an outright SPF failure regardless of whether the sender was legitimate.

DKIM failures are usually simpler but no less disruptive. A vendor may sign mail with a key that was rotated, or the sending platform may not support DKIM signing on the specific plan tier the client purchased. Either way, the message arrives with a broken or missing signature, and if that vendor is also not covered by SPF, DMARC has nothing left to align against.

The workflow: from raw reports to a clean sender inventory

The practical process an MSP runs looks the same whether the domain has three sending sources or thirty. It starts with data, not assumptions.

1. Collect aggregate reports at p=none. Publish a DMARC record with a rua address and let reports accumulate for several weeks before making any policy change. This monitoring period is the mechanism the specification itself relies on, not an optional courtesy.
2. Group failures by source IP and sending domain. Each aggregate report lists every IP that sent mail as the domain, along with SPF and DKIM results, so the data can be sorted into "known vendor," "unknown, investigate," and "clearly malicious" buckets.
3. Reconcile against a sender inventory. Every legitimate service, billing software, ticketing system, transactional email API, needs a name, an owner, and a documented authentication method. Anything failing that cannot be matched to an inventory entry gets a support ticket, not a policy exception.
4. Fix the specific failure per sender. Add the vendor's published SPF include or IP range, confirm DKIM signing is enabled on the vendor's side, and verify the fix in the next report cycle before considering it closed.
5. Only then raise enforcement. Move the pct tag in small increments and continue watching reports for any sender that was missed, since a domain's sending footprint rarely stays static during a multi-week rollout.

This is close to the sequence major mailbox providers now assume domains will follow. Google's guidance for high-volume senders states plainly that bulk senders must set up SPF and DKIM and publish a DMARC policy, even at the minimum p=none setting, before their mail is treated as fully trustworthy, which means the discovery workflow above is no longer optional groundwork. It is the baseline expectation for anyone sending meaningful volume to Gmail or Yahoo Mail addresses.

How long should this discovery and remediation phase take?

There is no fixed timeline in the DMARC specification, and vendors that promise a fixed number of weeks are guessing at a figure that depends entirely on how many sending sources a domain has. A single-domain client with two or three vendors can often complete discovery and remediation in a matter of weeks. A client with a dozen marketing, support, and billing integrations needs proportionally longer, because every one of those sources has to be found, verified, and fixed individually.

The mistake most rollouts make is treating the calendar, rather than the report data, as the signal to advance. A domain is ready to move from monitoring to quarantine when its known senders are consistently passing, not when a predetermined number of weeks has elapsed. Skipping that check is the single most common reason DMARC rollouts get rolled back after legitimate mail starts bouncing.

For MSPs managing this across dozens of client domains simultaneously, the volume of raw XML report data becomes the bottleneck long before the authentication fixes do. Reading individual aggregate reports by hand does not scale past a handful of domains, which is the reason automated report parsing and sender fingerprinting exist as a category of tooling in the first place. A technician who can see every client's failing senders on one screen, rather than pulling XML attachments out of a shared mailbox, closes the discovery phase in days rather than months.

Building this into a repeatable MSP process

The technical steps above only produce a durable outcome if they are treated as a process rather than a one-time project per client. Vendor lists change, marketing platforms get swapped, and a new sales tool can start sending mail from a domain within a week of being purchased without anyone flagging it to the person managing DMARC. A sender inventory that is not revisited becomes stale the moment the account team signs up for a new tool.

That is why the discovery workflow described here needs to run continuously, not just during the initial rollout. Teams that treat DMARC as a set-and-forget DNS record are the ones that get paged when a client's newsletter platform silently starts failing months after enforcement was already in place. Building this into standard onboarding, documented in a process like the one in ActiScan's getting-started guide, keeps the sender inventory current instead of letting it decay between audits.

For MSPs pricing this work into a managed security offering, the discovery and remediation phase is also the part of the engagement that is easiest to scope and bill, since it produces a concrete deliverable: a documented, verified list of every authenticated sender for a given domain. Reviewing what a scanning platform includes at each tier on the pricing page is a reasonable starting point for deciding how much of this monitoring to automate versus handle manually across a client base.

Domains that skip this workflow and publish p=reject on faith tend to find out about their gaps from an angry client rather than a report. Domains that run it properly get to enforcement with a documented paper trail of every sender that was found, fixed, and verified, which is also the artifact that makes DMARC a defensible line item rather than a guess. Technicians who want to see this workflow applied against a live domain can start with a free scan through ActiScan's signup page and work through the same discovery sequence on their own client list.

Further Reading

• wpmailsmtp.com
• dev.to