How to Verify DMARC Across Every Legitimate Email Sender

I verify DMARC coverage by identifying every legitimate sending stream, inspecting aligned authentication in messages delivered to representative receivers, and testing important forwarding and mailing-list routes. Enforcement is ready to advance when material failures have explanations and owners, and the team can detect and recover from rejected legitimate mail. DNS records alone do not establish that evidence.

A domain can have the right DNS records and still fail its customers' mail. The problem often appears after a team moves from monitoring to enforcement: invoices stop arriving, a help-desk platform sends as the company but signs for itself, or a forgotten marketing vendor uses a return path nobody recognizes. The DNS change gets blamed. The deeper failure was an incomplete account of who sends mail, which domain each system claims, and what a recipient can actually validate.

For an enforcement decision, I need an operational map of the sending estate. Each protocol answers a different question. SPF authorizes a domain's use in an SMTP envelope identity; DKIM binds selected headers and message body to a signing domain; DMARC evaluates whether an authenticated identifier aligns with the domain the reader sees in the From field (Kitterman, 2014; Crocker et al., 2011; Herr & Levine, 2026). A passing check is useful only when it is the right check for the right identity.

What an enforcement decision actually needs

My question is practical: when is there enough evidence to enforce a domain's mail policy without gambling on legitimate delivery? I use a sending-stream model to connect protocol behavior with business consequences. This is an analysis of standards and published research, followed by my proposed acceptance method; it isn't a report of a client deployment or a new experiment.

The unit of analysis is a sending stream: a business purpose, application or provider, visible author domain, SMTP envelope domain, DKIM signing domain, and route to a receiver. The organization may own the author domain while another party operates the infrastructure. SMTP defines a transport envelope, including a reverse path, whereas the Internet Message Format defines the message header's author field. An intermediary can change the former without changing the latter (Klensin, 2008; Resnick, 2008). This separation is why a passing SPF check for a provider's envelope domain does not establish authentication of the organization's displayed author domain. Alignment is the additional question DMARC asks.

My threat model distinguishes an unauthorized sender claiming the organization's exact domain from an attacker who has compromised an authorized account or provider. The first may fail both aligned authentication methods. The second can plausibly pass because the credentials or platform actually possess the authorization. A lookalike domain is a third case: its owner can configure valid authentication for that different domain. None of these cases is resolved by treating an authentication pass as proof that the message's request is safe. Domain authentication constrains one kind of impersonation; it does not adjudicate business intent.

Here is the decision rule I propose. If the organization has identified all material streams, observed aligned authentication in delivered samples, investigated failures, and tested important indirect paths, it has a basis for a controlled policy change, with residual delivery risk stated explicitly. If the inventory is incomplete, the same policy may reject legitimate mail. Evidence must include low-volume and seasonal streams. An aggregate report for a quiet month cannot prove that an annual tax notice will work. This is a proposed governance criterion, not a normative requirement in an RFC.

Start with every legitimate path that uses the domain

I would inventory human mailboxes, transactional applications, ticketing systems, scanners, payroll and billing services, marketing tools, monitoring alerts, developer platforms, and outsourced support. A list of vendors is not enough. For each stream, record the visible From domain, envelope sender domain, DKIM signing domain and selector, sending platform, business owner, expected recipients, approximate volume, and change contact. Include subdomains and services that send rarely. A once-a-year tax notice matters more than its volume suggests.

A useful inventory has evidence, not only answers from a questionnaire. Sample a legitimate message received outside the organization and inspect the authentication results at a trusted receiver. Confirm which identity passed SPF, which signature passed DKIM, and whether either aligned with the Author Domain. Herr and Levine's current DMARC specification defines relaxed and strict alignment in relation to that Author Domain; a signature from a provider's unrelated domain can pass DKIM while still failing DMARC alignment (Herr & Levine, 2026). That is a common reason a dashboard says “authenticated” while the organization's policy has another result.

I would keep a separate register for domains that should never send. A defensive policy for a parked domain is a different exercise from changing enforcement on a busy production domain. The first may be comparatively simple once ownership and DNS are confirmed. The second needs a stream-by-stream migration, a way to see breakage, and someone who can fix each sender.

Read the identities before trusting the result

SPF is often described as an approved-server list. Its scope is narrower: it evaluates the SMTP envelope sender or HELO identity, not the display name or necessarily the From address a person sees. Forwarding can change the connecting host and produce SPF failures unless the intermediary handles the envelope appropriately (Kitterman, 2014). I would not ask a business owner to infer author authenticity from an SPF pass on a provider-controlled bounce domain. I would ask whether the authenticated envelope identity aligns with the visible author domain for this stream.

DKIM gives a sender a way to sign selected message headers and the body with a key associated with a domain and selector in DNS. The selection of signed fields matters. An intermediary that modifies signed content can break validation; a valid signature also says nothing about whether the message's commercial claim is true (Crocker et al., 2011). The From field must be signed under RFC 6376 §5.4. I check that requirement in the message, along with whether the signing domain is controlled or explicitly delegated by the organization and the key and selector have a documented owner and rotation path. “DKIM enabled” in a vendor console is not evidence of alignment in a delivered message.

DMARC ties these mechanisms to the Author Domain. RFC 9989 was published in May 2026 on the IETF Standards Track, with Proposed Standard status; together with RFCs 9990 and 9991, it replaces RFC 7489. Publication does not establish that a particular receiver has implemented the revision. It accepts a valid aligned DKIM or SPF identifier, and it lets the domain owner request handling for mail that fails validation (Herr & Levine, 2026). That gives a domain owner a way to express policy, but receiver behavior is still a receiving system's decision. A published reject policy does not prove that every fraudulent message was rejected, and a DMARC pass does not prove the sender's account was not compromised. Authentication constrains spoofing of a domain; it is not an all-purpose fraud detector.

The evidence source itself needs a trust boundary. RFC 8601 defines the Authentication-Results header used to convey evaluations and discusses why a receiving system must distinguish trusted results from fields supplied by untrusted upstream hosts (Kucherawy, 2019). I would preserve a raw delivered message and identify the receiving service that added the trusted result. A screenshot of a vendor console saying “DKIM enabled” is not a delivered-message test. Nor is a pasted header useful if nobody can establish which hop produced it. For a material stream, record the test timestamp, message identifier, receiver, expected identities, actual SPF and DKIM results, alignment result, and any transformation along the route.

Relaxed and strict alignment require a conscious choice. Relaxed alignment can accept authenticated subdomains sharing an organizational domain with the author domain; strict alignment requires exact domain correspondence for the relevant identifier. A business unit using a delegated subdomain might pass one and fail the other. I would select the mode after examining legitimate flows and the abuse case, then test the proposed change. Strictness is not a maturity badge if its immediate effect is to break known legitimate mail (Herr & Levine, 2026).

Keep the HELO result separate from DMARC's SPF input. RFC 9989 §4.4.2 relies on the MAIL FROM identity; an unrelated HELO pass is not an alternative route to alignment. SPF itself also defines the null reverse-path case, which needs the protocol's identity construction rather than a guess based on the visible message. A testing worksheet should retain the actual inputs and the receiver's interpretation (Kitterman, 2014; Herr & Levine, 2026).

Why sender authorization is a governance problem

An SPF record can become a historical accumulation of vendor include terms. RFC 7208 constrains evaluation through a DNS lookup limit; nested includes matter. Exceeding that constraint can yield an error instead of a stronger policy (Kitterman, 2014). Each authorization should have a business owner and current purpose, and an operator should trace recursive lookups before publication. Replacing includes with a snapshot of provider IP addresses may reduce lookup depth but creates a maintenance obligation when those addresses change. The right design is one the organization can keep accurate and test.

The IP level is not the whole authorization boundary. Shared cloud infrastructure may allow many tenants to send through the same addresses, so the domain owner must understand the provider's tenant-level domain validation and signing controls. Wang and colleagues' BreakSPF study demonstrated attack opportunities involving permissive SPF configurations and shared infrastructure. Their measured population is specific to their method and sampled domains; it should not be applied as a prevalence figure for an individual client's estate (Wang et al., 2024). The relevant review questions are whether another tenant can claim the owner's envelope or author domain, who may configure those identities, and whether DKIM signing is bound to an authorized account. An approved IP range cannot answer them.

DKIM creates a parallel governance problem: who controls the signing key and selector? RFC 8301 revised algorithm and key-size requirements that had become unsuitable, while RFC 8463 added Ed25519-SHA256 and describes a transition using multiple signatures (Kitterman, 2018; Levine, 2018). I would document the algorithm actually used by each sender, key custody, selector ownership, rotation procedure, and retirement date. Rotation should be tested against important receivers before the old key is removed. Strong cryptography does not protect the organization if a dormant vendor account can configure an aligned signature or if the private key is poorly controlled.

Onboarding is therefore part of access governance. An application request to “send as the company” should specify purpose, owner, author domain, return path, signing domain, administrator roles, and offboarding trigger. The approving team should require a delivered test and a plan for removing DNS delegation or keys when the service ends. Offboarding is not simply disabling a user account; a stale DNS authorization or vendor signing arrangement may persist after the business relationship ends. This is an inference from what the protocols authenticate, not a control DMARC itself provides.

What reports reveal, miss, and expose

Aggregate reports give you receiver observations of authentication results and applied policy. RFC 9990 defines that reporting format separately from the base DMARC policy protocol (Brotman, 2026). I group observations by stream and owner so a failure becomes something a person can investigate. A new aligned source deserves an ownership check; alignment alone doesn't tell me who approved the service.

Aggregate reports should be treated as observations from participating receivers, not a census of all mail. A source IP can represent several tenants, and one stream can move among addresses. A report's failure count does not identify the business consequence of each message. I would join reports with sender-side logs, application inventories, and recipient tests, then classify a source as confirmed authorized, confirmed unauthorized, indirect path, configuration defect, or unresolved. An unresolved high-value stream is an enforcement blocker. Labeling all failures “attacks” inflates a security claim; labeling all familiar provider IPs “legitimate” weakens authorization.

Reporting also introduces an abuse surface. Ashiq and colleagues measured deployment and management of DMARC reporting across second-level domains under four top-level domains over thirteen months and examined hosting and reporting software. They identified configurations in which an attacker-generated message could cause substantial report amplification toward a victim mail server. Their result establishes a plausible class of deployment failure, not a claim that every report service is vulnerable (Ashiq et al., 2023). I would verify external report destinations, restrict changes to rua and ruf, monitor and rate-limit ingest, and avoid a report mailbox whose saturation would disrupt customer mail. RFC 9991's external-destination verification requirement reflects the risk of imposing reports on an unwilling destination (Jones & Vesely, 2026).

Privacy differs between aggregate and per-message reporting. RFC 9991 explains that failure reports can contain headers or even message content, including personal information, and that receivers may redact or decline to send them (Jones & Vesely, 2026). Requesting ruf is neither a guarantee of complete forensic evidence nor a reason to collect content without a defined need. I would start with aggregate reporting, bounded retention, limited access, and documented deletion; add failure reports only for a specific investigation benefit. A third-party processor should be evaluated for both access and retention. These choices are especially important when customer or employee correspondence may appear in the reporting stream.

The 2026 specification split is material to a current analysis. RFC 9989 now defines DMARC policy, RFC 9990 defines aggregate reporting, and RFC 9991 defines failure reporting; collectively they obsolete and replace RFC 7489 (Herr & Levine, 2026; Brotman, 2026; Jones & Vesely, 2026). A procedure that cites only the old document can still describe common legacy deployments, but it obscures which current text governs policy and which governs reporting. Version-aware references matter when a team turns article guidance into an implementation checklist.

The revision also changes how organizational domains are discovered. RFC 9989 §4.10 specifies a DNS tree walk where the earlier specification discussed public-suffix-list approaches. I would record the receiver implementation and discovered policy domain when testing a delegated subdomain, rather than assuming every receiver derives the same boundary immediately after publication. This is a migration concern, not a reason to improvise a new alignment algorithm (Herr & Levine, 2026).

Indirect flows and recipient behavior

Mailing lists and forwarders expose the limits of a sender-only account. A list may alter a signed subject or body, invalidating DKIM, and the final receiver may see the list server rather than the original sender for SPF. RFC 7960 documents these interoperability failures, including the possibility that rejections cause list software to remove a subscriber as apparently undeliverable (Martin et al., 2016). ARC, published as an Experimental RFC, can convey earlier authentication observations through intermediaries, but a receiver still must decide whether to trust that chain and its operators (Andersen et al., 2019). I would therefore test each material indirect route, identify who can modify it, and avoid describing ARC as a universal bypass.

Hu and Wang's end-to-end measurements across 35 email providers found variation in whether forged messages reached inboxes and how interfaces warned users. Their study was conducted in 2018, so it cannot establish current behavior at a named provider; its durable methodological lesson is that protocol result and user-visible disposition are different outcomes (Hu & Wang, 2018). A controlled test should capture both: whether an unauthorized message failed alignment, whether the receiver rejected or delivered it, and what the user saw. One mailbox is a sample, not proof about every recipient on the Internet.

The test matrix should cover direct delivery, a high-volume provider, a low-volume transactional application, any important list or forwarder, and a controlled unauthorized source. For each case, state the expected envelope and signing identities before sending. Preserve the message and receiver result afterward. When a path fails, identify the hop at which the identity or signed content changed. That turns “DMARC broke mail” into an actionable defect: wrong DKIM domain, invalid signature after modification, unexpected bounce domain, missing DNS authorization, or a receiver-specific policy choice.

A worked enforcement decision

Consider a hypothetical company with three material streams: staff correspondence, customer invoices, and an annual compliance notice. This is an illustrative test design, not a measured deployment. Staff mail arrives with an aligned DKIM signature. The invoice service passes SPF for its own bounce domain and DKIM for its own signing domain, neither aligned with the company's visible From domain. The annual notice has no recent receiver evidence because it hasn't run during the observation period. A volume-weighted dashboard could look excellent while two essential workflows remain unproven.

I would separate the authentication result from the release decision:

Stream	Evidence available	Unresolved issue	Decision before broader enforcement
Staff mail	Delivered samples with aligned DKIM	Important forwarding routes not yet sampled	Test those routes and record receiver disposition
Invoices	SPF and DKIM pass for provider domains	Neither authenticated identity aligns	Configure an authorized aligned identity, then retest delivery
Annual notice	Owner and schedule identified	No delivered sample of current configuration	Trigger a safe test through the actual sending path

The invoice repair should not become a broad authorization for everything on the provider's shared infrastructure. The desired outcome is a specific stream with a business owner and an aligned identity. Depending on provider capabilities, that might involve a delegated signing domain, an appropriate custom return path, or a different sending arrangement. Those options have different access and offboarding consequences. The protocol tells you what aligns; your contract and configuration determine who can use it.

For the annual notice, a hand-written message from an administrator's mailbox proves nothing about the application. The test must exercise the application's current template, sender configuration, credentials, and delivery path. A test recipient and harmless content can keep the exercise bounded. If the platform cannot do that without sending to real customers, record the constraint and choose an alternative with the application owner. Don't silently promote an untested stream because its traffic is rare.

Now suppose the invoice repair passes direct delivery but fails after forwarding. That is a separate branch of the test, with its own evidence. Preserve the message before and after the intermediary if you control both points; otherwise record the visibility limit. Decide whether the changed identity or content explains the failure, whether a different supported sender configuration resolves it, and whether the affected business workflow actually depends on that route. A provider's successful direct test does not close an indirect-flow defect.

The acceptance record should identify what changed between tests. If the DKIM selector changed at the same time as the return path, a passing result does not tell you which change mattered. Where practical, change one relevant variable at a time and retain the prior configuration. In an urgent incident, several changes may be necessary together; the report should then avoid claiming a causal isolation the exercise did not achieve. This distinction matters when somebody later proposes reverting only half the change.

Finally, set a rollback trigger that describes business harm and an authorized action. A sudden rise in unexplained failed invoices is actionable; a universal percentage chosen without a denominator is not. Restoring a prior policy also changes spoofing exposure and may take time to reach receivers through DNS caches. I would retain a separate emergency communication path for affected customers and give the owner a decision record containing the unresolved streams, tested receivers, and limits of the observation window. That is a defensible enforcement decision even though it cannot promise universal delivery.

Enforcement decision and competing priorities

A fast move to p=reject may reduce the period during which the exact domain can be spoofed. For a parked domain with no legitimate mail, a promptly restrictive policy can be sensible after ownership and DNS checks. For an active domain, the same action may reject payroll notices, receipts, or incident notifications. The defensible speed depends on stream coverage and the cost of failure. RFC 9989 supplies policy semantics, not the business inventory or risk appetite (Herr & Levine, 2026).

An operational gate should require a named owner for every known material stream, a delivered test showing aligned authentication for each, an explanation of material report failures, explicit treatment of indirect routes, a governed report destination, and a rollback trigger tied to lost legitimate mail. These are my proposed acceptance criteria, not requirements imposed by the standard. The observation window should be documented along with the workflows it could not cover. A policy change then becomes an experiment with a decision rule and a recovery owner, rather than an assertion based on the existence of DNS records.

One could argue that aligned DKIM alone makes SPF complexity irrelevant. DKIM is often more resilient to forwarding, provided the message is not modified, but a provider may sign with its own domain or a mailing list may change signed content. SPF can cover a direct path yet fail after forwarding. The mechanisms have different failure modes, and neither should be assumed reliable for an untested route (Crocker et al., 2011; Kitterman, 2014; Martin et al., 2016).

After enforcement, trend lines need interpretation. Falling failures can mean repairs succeeded, or that a receiver stopped reporting. Rising failures can mean impersonation, a vendor migration, or a new forwarding path. I would examine samples, sender logs, report-source coverage, and business support cases before calling either movement success or regression. The operational measure is whether an owner can explain and resolve a material failure without granting broad, unreviewed authorization.

I would report progress in terms the business can act on: the percentage of known legitimate streams with aligned authentication in a delivered test, high-value streams with a named owner, unresolved failures by cause, domains with an explicit sending policy, and policy changes that caused delivery failures. I would show the exception list with age and business consequence. A count of published DNS records is a setup measure. The question is whether a real message can pass for the right reason and whether a forged one gets the handling the organization intended.

What this evidence can and cannot establish

A delivered test is bounded by receiver and time. Aggregate reports may be delayed or absent; standards describe conforming behavior, not every deployment. The three cited measurement studies cover defined populations and periods, not the organization reading this paper. Local conclusions require current DNS, raw received messages, sender logs, report provenance, and owner confirmation. No claim here rests on a fabricated client experiment or universal delivery guarantee.

Exact-domain authentication also does not stop a lookalike domain, a compromised authorized mailbox, a deceptive message sent through a legitimate provider, or a receiver that declines to apply requested policy. These require separate evaluations. The strongest defensible claim is narrower: the organization can name the systems authorized to use its domain, demonstrate that important legitimate paths authenticate for the right identity, and observe how selected receivers handle controlled unauthorized claims. That is a meaningful security outcome because the evidence and its limits are explicit.

Email authentication works when the sender map, protocol identities, and business owners agree. If a policy change feels risky because nobody can name all the systems that send as your domain, request a briefing. I'll help turn the mail streams and authentication results into a decision you can defend.

Related reading

For the adjacent account-access problem, see phishing-resistant MFA and its recovery path. Domain authentication and account recovery address different ways an attacker can impersonate a sender.