A generated record is a decision artifact
A DMARC record generator can format a proposed policy, but it cannot decide which legitimate senders the organization has, what business risk it accepts or whether a reporting destination is authorized. The output should explain each policy choice and the assumptions behind it. A copyable string without those decisions can encourage publication of a syntactically plausible policy that does not fit the organization's actual mail flows.
RFC 9989 defines the current policy format and mechanism. This article proposes requirements for a generator and an annotated-output review. It does not claim that EmailAuth implements a generator, produce a production-ready record or change DNS. The required original test cases and operational evidence remain separate from the explanatory framework.
Establish the policy domain and ownership
Record the domain for which the policy is being prepared, the business owner, the DNS publication owner and the legitimate sending workflows in scope. Distinguish the exact owner name where a policy would be published from the domain identities used by senders. A generator should not silently choose a parent or child domain based on a display label or an assumed organizational boundary.
Current policy discovery includes the DNS Tree Walk described by RFC 9989. The generator's annotation should explain the intended scope and any inheritance-related assumptions that need review, rather than promising that a record affects only the address the user typed. The actual applicable behavior depends on the standard and receiver implementation. No domain hierarchy or existing policy was queried during this work.
Explain the requested policy and readiness
The requested policy expresses the domain owner's assessment preference under the protocol; it is not a guarantee of a receiver's final disposition or a statement that every legitimate sender is ready. Before recommending enforcement, require a sender-by-sender readiness review and an authorized decision about remaining failures. A generator can present choices and consequences, but it should not invent the business approval behind them.
Explain alignment choices separately from policy severity. The visible From domain, authenticated SPF identity and DKIM signing domain have defined relationships under DMARC. Strict and relaxed alignment are not merely labels for stronger and weaker overall security; their operational implications depend on the organization's domain structure and sending services. Preserve the selected rationale and unresolved dependencies in the annotated output.
Retain the current version and tag semantics
RFC 9989 still specifies the case-sensitive version value DMARC1. A generator should not advertise a new standards document as a switch to DMARC2. The version tag's required position and value should be validated according to the current format. Unknown tags must be ignored by protocol processing under the formal definition, so the tool should distinguish an unsupported-tag warning from an invented rule that every unfamiliar tag invalidates the whole policy.
Appendix A.6 explains removal of pct and introduction of t with y and n values. A current generator should not carry forward an obsolete percentage slider as though it were a current normative control, nor assume that replacing every historical percentage with t is a safe universal migration. It should document the standard it targets, the exact testing semantics and compatibility questions that remain for the intended environment.
Treat reporting destinations as approved recipients
RFC 9990 defines aggregate reporting and verification of external destinations. A generator should explain that publishing a report request and receiving reports are different steps. It should identify the proposed recipient, the data purpose and whether the applicable external-destination authorization is in place. Do not infer authorization merely because a user pasted an address into a form.
This article does not supply a reporting address, publish an authorization record or send data to a third party. A proposed output should use clearly nonoperational placeholders until a destination is approved. The annotation should also state that report availability depends on receivers and delivery, so including a URI is not a guarantee of complete observations. Failure-reporting choices, if offered, require their own supported specification and privacy review rather than being bundled casually into an aggregate-report setting.
Explain existing-record and duplicate handling
A generator should ask how the proposed policy relates to the existing published state. Producing a second policy candidate at the same owner can create a different result from replacing an approved existing record. The output should therefore describe the intended exact diff and preserve restore material, not simply say add this TXT record. Existing unrelated TXT data should not be deleted as a side effect of policy generation.
RFC 1035 defines TXT record structure. Multiple strings within one TXT record are not the same as multiple policy records. The annotation and tests should preserve that distinction so an editor's display does not mislead the operator. No existing DNS state was inspected here; duplicate handling remains a proposed test requirement rather than a verified result.
An annotated-output worksheet
Create a worksheet with policy domain, publication owner, proposed record, each tag's meaning, selected rationale, prerequisite evidence and approval owner. Add existing-state reference, exact intended diff, reporting-recipient authorization, compatibility limitations, verification plan and rollback criteria. Keep generated syntax separate from approval and publication status. A completed form should not automatically imply permission to make a live change.
The required fixture set should include a positive valid case, invalid version or required-format cases, duplicate policy candidates and unsupported-tag behavior. State expected outcomes from the current standard and the product's presentation rules separately. Retain the generator version, test input and observed output when authorized tests are later run. This draft has not generated or evaluated those fixtures and makes no implementation-conformance claim.
Fictional diagnosis: a percentage slider hides the decision
A fictional team uses an old policy form with a percentage slider and assumes selecting a smaller number makes any enforcement change safe. The reviewer asks which standard the form implements, what the organization's legitimate sender readiness is and how the proposed output will behave at relevant receivers. The control's appearance does not answer those questions.
The proposed response is to obtain current standards-linked behavior, document the policy decision and verify an exact change plan rather than mechanically translate the slider into another tag. No real generator or provider is accused of this behavior. The exercise is fictional, with no record generated, DNS modification or receiver test performed. It illustrates why policy rationale must remain visible alongside syntax.
Require evidence before calling the output ready
A useful generator result states which inputs were supplied, which assumptions remain and what must happen before publication. It can help a qualified owner make a consistent decision without claiming that formatted text establishes safe enforcement. The final authority remains with the approved business and technical change process.
The catalogue requires an annotated record and positive, invalid, duplicate and unsupported-tag test cases. Those original artifacts remain open. Human specialist review, source applicability, production routes, accessibility and owner release also remain open. This draft supplies a proposed worksheet and fictional diagnosis, not a ready-to-publish policy, completed tests or verified EmailAuth tool features.