Build from approved senders, not a guessed provider list
An SPF builder should preserve the organization's explicit decisions about which systems may use a particular SMTP identity. A convenient list of popular providers cannot establish that those services are authorized for the domain, that their recommended mechanism is current or that the resulting record fits the lookup limits. The output should be an annotated proposal tied to sender ownership, not a broad authorization assembled from brand recognition.
RFC 7208 defines SPF publication and evaluation. This article proposes requirements for a builder and its review process. It does not claim that EmailAuth offers any particular builder feature, generate a production record or modify DNS. No supplier account, private credential or user-domain record was inspected. Original output and test evidence remain open.
Inventory the actual SMTP identity and owner
For each workflow, record the business purpose, approved service owner, sending service, relevant MAIL FROM or HELO identity and the source of the proposed authorization. SPF does not directly authenticate the visible From display name. A provider used by one team should not automatically be added to every organizational domain. The intended identity and service relationship need explicit confirmation from the responsible owner.
RFC 9989 defines the alignment relationship needed for SPF to contribute to DMARC. A builder should explain that SPF authorization and DMARC alignment are related but separate decisions. Adding a provider to an SPF record does not guarantee that the provider uses that identity in actual mail. The integration owner must supply current configuration and authorized message evidence when verifying the workflow.
Use current provider instructions without expanding scope
The exact include target or address range should come from current official documentation or authorized configuration for the actual service. Do not infer it from another customer's record, an old tutorial or a similarly named product. Record the evidence date and the owner responsible for tracking provider changes. This manuscript does not invent provider include values because no specific sender configuration has been approved for construction.
Direct IP mechanisms and delegated dependencies carry different maintenance obligations. Static addresses can avoid the same lookup-term budget as DNS-query-causing mechanisms, but copying a provider's current addresses into a record can become stale when the provider changes infrastructure. A builder should not silently flatten dependencies as an optimization without an approved maintenance model. Preserve the trade-off and owner decision in the annotation.
Produce one coherent SPF policy
RFC 7208 requires a single SPF record for the evaluated identity; publishing multiple SPF records is not a valid way to combine several services. The proposed change should therefore describe how existing authorized senders are preserved in one coherent policy. It should not simply instruct the operator to add another v=spf1 record beside an existing one. Unrelated TXT records must not be removed as a side effect.
RFC 1035 defines TXT record structure. Multiple character strings within one TXT record are distinct from multiple TXT records, so the builder's display and test fixtures should retain that difference. An editor may format a long value differently from its wire representation. The approved exact diff should specify the intended record set rather than relying on a screenshot of a single field.
Explain mechanisms, qualifiers and modifiers
Each generated term should have an owner and rationale. Include delegates an evaluation according to the standard's result mapping; redirect is a modifier with different semantics and is ignored if any all mechanism is present. A builder should not interchange them just because both reference another domain. Qualifiers affect the result associated with a matching mechanism and should be selected through an explicit policy decision.
Do not imply that adding all makes every configuration safe. The placement and qualifier matter, and an overly broad authorization can defeat the intended boundary. Conversely, a restrictive ending can affect legitimate senders that were omitted from the inventory. The builder should surface unresolved workflows and require approval before publication rather than choosing a business-risk posture automatically from a template.
Check evaluation limits without confusing the count
RFC 7208 section 4.6.4 limits evaluated DNS-query-causing terms such as include, a, mx, ptr, exists and redirect to ten. This is not a limit of ten visible provider names or ten raw packets. Nested dependencies and the actual matching path matter. The builder should provide a dependency review and identify what it has not evaluated, rather than certify every possible input from a shallow count.
The standard also recommends a void-lookup limit of two with configurable behavior, and defines additional limits for specific mechanisms. A generator's static output does not establish how all receivers will evaluate every path under future DNS state. Keep path tests separate from formatting tests. A builder can explain likely dependencies without claiming that a successful syntax check proves universal SPF success.
An ownership-preserving output worksheet
Create a worksheet with identity domain, workflow, business owner, technical owner, approved sender evidence, proposed term, rationale and maintenance responsibility. Add the existing record reference, exact intended diff, unresolved senders, lookup-path review, verification plan and rollback criteria. The output should explain why each authorization exists and who may approve its removal or expansion.
The test set should include a positive valid proposal, invalid syntax, duplicate SPF records and unsupported-term cases. Distinguish unknown mechanisms from unknown modifiers because RFC 7208 treats them differently. The catalogue wording calls for unsupported-tag cases; for SPF, map that requirement explicitly to the protocol's mechanism and modifier vocabulary rather than inventing a generic tag parser. No such tests were executed for this draft.
Fictional diagnosis: an old supplier remains authorized
A fictional organization asks a builder to add a new mailing service. Its current record also references a retired supplier, but nobody has documented whether another workflow still uses that dependency. A simplistic builder merges the new term and preserves everything else without explanation. The proposed ownership-aware review instead marks the old authorization unresolved and asks the responsible business and technical owners to determine its status.
The team would not delete the old term merely to reduce the count, nor add the new supplier to unrelated identities. It would prepare an exact approved change after resolving the dependency and plan representative verification. This is a fictional lifecycle exercise, not an observed record, supplier retirement or completed DNS change. It illustrates why sender ownership is part of record construction rather than administrative paperwork afterward.
Verify the intended workflow before declaring completion
After an authorized publication, the operational team would retain exact DNS observations and representative trusted received-message evidence for each relevant workflow. Those observations must show the actual identity and alignment, not merely that the generated string appears in an editor. A successful sample remains scoped to its sender, time and receiver; it does not establish every future message's outcome.
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 generated production policy, executed test suite or verified EmailAuth feature claim.