Define what the baseline is meant to prove
An authentication baseline is an approved description of intended configuration and the evidence supporting it at a particular time. It is not simply a screenshot of a DNS editor, a list of desired records or a claim that all future mail will authenticate. A useful baseline connects domains, sending services, record ownership, expected authentication paths and verification criteria. Versioning makes changes explainable; review determines whether the intended configuration still fits the business.
This article proposes a baseline and change-control workflow. No repository was created, configuration exported, DNS record edited or message tested. The protocol references establish what the configuration means, while the versioning process is an editorial operational recommendation rather than a claim that a standard mandates a particular tool. The baseline must remain separate from proof of current production behavior until actual observations are collected.
Capture identities and responsibilities before records
For each sending workflow, record the business purpose, domain owner, service operator, visible From domain, expected envelope identity and DKIM signing domain or domains. Identify who can approve a change and who can execute it. A DNS administrator may control publication while a supplier controls signing, and the business owner may determine whether a sending stream should exist. Those responsibilities should not be compressed into one ambiguous “owner” field.
RFC 9989 defines DMARC's domain-alignment relationships. A baseline should therefore identify the intended aligned path rather than recording only that SPF or DKIM is enabled. RFC 6376 defines the DKIM signing and selector model. Record the selectors and public lookup dependencies that matter, but never place private signing keys, API secrets or recovery credentials in a general configuration baseline.
Preserve the complete relevant record set
Record exact DNS owner names, types, complete values and TTLs as observed, with the zone and authoritative provider. Keep provider-editor notation separate from published DNS representation. For TXT data, distinguish multiple character strings within one record from multiple records in a set. A screenshot showing one selected row may omit other values and cannot necessarily support a safe replacement operation. Preserve enough structure to explain the complete intended change.
Azure DNS records documentation describes record sets, TXT strings and provider-specific metadata. It is useful evidence for Azure's model, not a universal schema for every provider. If the actual provider differs, verify its current representation and update behavior before applying the worksheet. A baseline can use a neutral representation while retaining the original provider export as evidence with its collection time and limitations.
Separate intended state from observed state
Use distinct sections for the approved target configuration and the observations collected from production. A desired SPF value is not evidence that an authoritative server published it. A DNS answer is not proof that a provider signed a message with the expected selector. A received-message result is not proof that every sending workflow uses the same path. Each observation should state its scope, time, collection method and the identity it covers.
When using Authentication-Results as verification evidence, follow the trust-boundary concerns in RFC 8601. Retain results from the relevant trusted receiver rather than accepting arbitrary sender-carried assertions. Keep redacted message evidence and full sensitive originals under appropriate access controls. The baseline should reference approved evidence locations, not accumulate confidential message bodies or credentials merely for convenience.
Make each revision an explainable decision
Assign an internal version identifier and record the prior approved version, change reason, intended diff, affected workflows, risk assessment and business sign-off. A readable diff should show additions, removals and replacements in complete context. It should identify whether a supplier is being introduced, a selector rotated, an obsolete sender removed or a policy changed. Do not let a formatting-only change conceal a meaningful alteration to authorization or alignment.
Choose a review mechanism suitable for the organization's tools, but do not assume a version-control commit is equivalent to approval. Record the decision owner and approval scope separately. Define what happens if the observed current configuration differs from the expected baseline before execution. The safe response is to investigate and reconcile the difference, not to overwrite newer state simply because a prepared change file exists.
Account for concurrent edits and rollback limits
Azure DNS documents Etags associated with zones and record sets, and explains how they can detect concurrent changes when supplied during updates. That is a provider-specific concurrency mechanism, not a general DNS property. A TTL controls caching behavior, not who may edit a record or whether one change overwrites another. Confirm the actual interface's concurrency behavior and retain the version evidence used for the authorized change.
Rollback criteria should identify both the technical trigger and the authorized decision maker. Restore material needs the previous complete configuration, relevant provider state and known dependencies. Restoring a DNS record may not restore a deleted supplier resource, undo delivered mail or instantly replace cached answers. Plan recovery as a coordinated workflow rather than promising that copying an old value reverses every consequence. No rollback was attempted in preparing this draft.
A baseline review worksheet
Create a worksheet with baseline version, domain and workflow scope, business purpose, configuration owner, execution owner, exact record inventory and expected authentication path. Add evidence references with dates, known gaps, source-document versions and review triggers. For a proposed revision, include the intended diff, business approval, preconditions, concurrency checks, verification criteria, rollback criteria and final disposition. Mark unobserved outcomes explicitly rather than leaving them implied by a completed design review.
Review triggers can include a new sender, supplier retirement, domain migration, key rotation, changed business ownership or a material authentication incident. A calendar review may also help, but its frequency should reflect organizational risk and change volume rather than an invented universal interval. Review whether the baseline still covers all legitimate workflows and whether retired dependencies remain. Do not treat an unchanged file as evidence that the production environment has not drifted.
Fictional diagnosis: an undocumented supplier addition
A fictional organization has an approved baseline covering its billing service and employee mail. A marketing team later introduces another sender through a separate supplier. The baseline remains unchanged, while a prepared DNS cleanup would remove a dependency the new service uses. In the proposed exercise, the reviewer compares current ownership and workflow records with the baseline before approving the cleanup and discovers the documentation gap.
The team would reconcile the new workflow, obtain business sign-off, update the intended diff and collect verification evidence after an authorized change. It would not blindly restore the old baseline merely because it was previously approved. This scenario is fictional: no supplier was discovered, no configuration diff was applied and no delivery test occurred. It illustrates why version history must be paired with current ownership and operational observations.
Release the baseline with its limitations visible
A useful review conclusion states which workflows are covered, which observations support them and what remains unverified. It does not promise universal delivery or permanent safety. Authentication controls can be correct while content, reputation, account compromise or receiver policy affects mail outcomes. The baseline should make those boundaries visible so future operators do not mistake a configuration record for a complete security assessment.
The catalogue requires a change record with baseline, intended diff, business sign-off, verification and rollback criteria. That original operational record remains open. This draft supplies a proposed structure, not executed change evidence. Human specialist review, source applicability, production routes, visual accessibility and owner release also remain open. A publishable version requires an authorized example with real observations and approvals, appropriately redacted and retained without exposing secrets.