A successful authentication test can support a control assertion. It cannot establish universal regulatory compliance. Build the evidence around a specific service, requirement and observation period, then explain the parts that remain outside the test. This makes the pack useful to auditors without turning a technical result into an unsupported legal conclusion.
Separate design from operation
A control design describes the intended safeguard: approved billing mail uses an aligned signing identity, changes require review and failures reach an accountable owner. Operating evidence shows that these steps actually occurred during a stated period. A policy document alone shows intent; a single successful test shows only its tested path and time.
RFC 9989 defines DMARC's relationship to SPF, DKIM and alignment. It does not provide a certification regime for an organization’s legal obligations. The organization must identify the applicable framework, requirement version, scope and competent reviewer before making a compliance conclusion.
Build a control matrix
For each control, record its objective, service, owner, execution frequency, evidence reference and exception handling. Add the exact requirement citation only after the responsible compliance function validates it. Mark an unmapped control as unmapped rather than inventing a requirement number.
Use three internal example objectives, not statutory citations. C-1 covers billing authentication; C-2 covers payroll monitoring; C-3 covers review approval. All external framework mappings remain unmapped until a qualified reviewer validates them.
- C-1: assume a fictional sample From invoice@billing.test with trusted DKIM pass d=billing.test, hence exact alignment. Label the scenario evidence present only by assumption; no actual message, receiver record or observation date is supplied here. The billing owner must attach those before asserting real operation.
- C-2: payroll evidence absent. Record missing, not failed and not covered by C-1. The payroll owner must select evidence spanning its actual operating cycle.
- C-3: review approval absent. Record unapproved; a complete technical sample cannot substitute for the authorized review decision.
Judge the sample honestly
State how samples were selected and whether they cover routine, low-volume, failure and exception paths. If an observation window excludes month-end payroll, say so. Retain the actual test and trusted receiver results; do not infer delivery from an aggregate row. RFC 9990 describes aggregate feedback, which can support monitoring but is not proof of every business transaction.
This is a written classification example, not an executed matrix or approval-forgery test. It supplies no real organizational evidence. Replace every stipulated sample with retrievable records before making an operating assertion, and preserve sample limits rather than converting missing entries into a percentage-compliant score.
Record the conclusion and remaining work
If a real retained billing sample supports it, a bounded statement would be “the sampled billing route showed an aligned pass; payroll evidence and the review approval remain open.” In this written example even the billing result is only assumed. Do not substitute “fully compliant.” Assign the missing payroll test to its service owner and the review decision to the authorized approver, with deadlines appropriate to the actual business cycle.
Compliance specialists determine whether the evidence meets a particular obligation and what additional controls are required. Authentication does not resolve compromised legitimate accounts, fraudulent requests sent from attacker-owned domains, payment-approval weaknesses or retention requirements. Keep the technical control's value clear while documenting these boundaries. Recheck the mapping when the service, regulation, framework or implementation changes.