Build the case around demonstrated control improvements
A DMARC business case can explain visibility, sender governance and protection against specific unauthorized domain use without inventing how much fraud was prevented. The strongest case connects an observed problem to a proposed control change, identifies the legitimate sending workflows that could be affected and defines how the outcome will be verified. It does not convert every rejected message into a prevented financial loss or promise that authentication eliminates business email compromise.
RFC 9989 states that DMARC addresses specific forms of exact-domain spoofing, not visually similar domains, display-name attacks or content analysis. Those limits belong in the business case, not only in a technical appendix. This article proposes an evidence-led planning method. No policy was changed, sender tested, loss estimated or financial commitment made.
Describe the baseline problem with its coverage limits
Start with the domains and legitimate sending workflows the organization knows about. Record which services are owned, which are unresolved and which authentication paths have evidence. Keep configured intent separate from observed receiver results. A list of SPF and DKIM records is not proof that every workflow uses them correctly, while a passing sample does not establish complete coverage across all mail and receivers.
RFC 9990 defines aggregate reporting that can contribute observations about authentication. Those reports are valuable evidence, but their source and period coverage must be stated. Missing reports do not prove absence of traffic. Unknown senders may include unauthorized activity, forgotten legitimate systems or incomplete interpretation. Classify them with evidence before using their counts in a business justification.
Separate objectives from financial claims
Useful objectives can include assigning owners to legitimate senders, reducing unresolved authentication failures, establishing a reviewed policy and improving the repeatability of change verification. Each should have a defined measure, baseline period and evidence source. The objective may be operational or security-related without a monetary figure. A business case does not become weak merely because it refuses to fabricate prevented losses.
If a financial model is needed, use approved organizational inputs and disclose assumptions. Staff time, subscription costs and implementation effort may be measurable with appropriate records, but they were not measured here. A hypothetical loss multiplied by a rejected-message count is not a defensible estimate of savings. The message might never have reached a person, induced action or caused a loss even without the proposed policy. The counterfactual needs evidence, not rhetorical certainty.
Build a sender-by-sender readiness matrix
Create a row for each legitimate workflow with business purpose, owner, visible From domain, expected envelope and signing identities, current evidence, unresolved failures and change dependency. Record the intended aligned authentication path under RFC 9989. Distinguish the supplier's claim that a feature is enabled from a trusted receiver's observation of a real authorized sample. No sample was collected for this draft.
The matrix should identify which workflows are ready for the proposed policy and which need remediation or a documented exception. Avoid treating a high aggregate pass rate as proof that a small but critical workflow is safe. A low-volume billing or recovery process can be commercially important even if it contributes little to the denominator. Readiness should therefore consider business impact and coverage, not only an overall percentage.
Specify the policy diff and authorization
Write the proposed change as an exact policy difference with the affected domain, intended behavior, prerequisites and rollout decision. The policy should reflect the current standard and actual receiver applicability rather than copied legacy assumptions. Identify who owns DNS publication, who approves business risk and who verifies the result. A technical recommendation is not itself authorization to change production.
Document the stop and rollback criteria before execution. A policy adjustment can affect legitimate mail if readiness assumptions are wrong, while restoring a DNS value may not instantly replace cached observations or undo mail already handled. Do not promise a risk-free rollout. Preserve the previous configuration and dependent service information so an authorized operator can make a reasoned recovery decision if actual evidence warrants it.
Define post-change evidence at the right boundary
Plan to collect authoritative publication evidence, trusted received-message observations for representative workflows and aggregate trends over an appropriate defined period. RFC 8601 explains why Authentication-Results evidence must come from a trusted receiver boundary. A copied pass line without provenance is not enough to prove the intended path worked after a change.
Also review provider delivery diagnostics where available, but preserve their meaning. SendGrid's event reference defines delivered as successful delivery to the receiving server, not inbox placement or human reading. Such evidence can help distinguish authentication changes from other delivery issues without proving a causal increase in business outcomes. Record other concurrent changes that could explain an observed trend.
A business-case worksheet
Create sections for the observed baseline, coverage limitations, operational problem, proposed policy diff, sender readiness, owners, approvals, expected benefits, implementation effort, risks and verification plan. Keep measured values, assumptions and unmeasured outcomes visibly separate. Include a decision field for unresolved critical senders and a specific criterion for proceeding or pausing. The worksheet should make uncertainty actionable rather than conceal it.
For every claimed benefit, ask what evidence would support it and what evidence would contradict it. Better sender ownership can be demonstrated through a completed inventory and approvals. Improved alignment coverage requires comparable observations and stable definitions. Prevented fraud or monetary loss requires a much stronger causal basis and should not be inferred from protocol counts alone. This proposed framework contains no actual ROI calculation or fabricated performance statistic.
Fictional diagnosis: a tempting prevented-loss number
A fictional project team sees many messages in a report category it believes to be unauthorized and proposes multiplying that count by an average fraud amount. A reviewer rejects the calculation because the dataset does not establish how many messages would have been delivered, read, believed or acted on. It also does not yet resolve whether every source in the category is unauthorized.
The proposed revision focuses on verifiable outcomes: completing sender ownership, resolving legitimate failures, approving a policy change and retaining post-change evidence. If the organization later has independently supported incident and financial data, a qualified owner can assess whether any additional claim is justified. This scenario is fictional; no report counts, fraud amounts, prevented losses or project savings were observed or calculated.
State what DMARC does not replace
The IC3 cloud-email BEC advisory, published in 2020, supports independent verification of unusual business requests and account protections. Those controls remain relevant because a compromised authorized account can send authenticated mail, and a different domain can impersonate a business without failing its own authentication. A DMARC business case should acknowledge complementary controls rather than claim to replace them.
The catalogue requires a sender-by-sender readiness matrix, policy diff, approval record and post-change results. Those original artifacts remain open. Human specialist review, source applicability, production routes, accessibility and owner release also remain open. This draft supplies an evidence framework and fictional exercise, not a completed rollout or a financial guarantee. Publication requires authorized operational evidence and claims bounded to what that evidence actually demonstrates.