Stage email authentication changes
Generate records offline, inventory your senders, and measure alignment before enforcing DMARC.
SPF authorizes infrastructure
An SPF TXT record identifies sending sources authorized for a domain. It is published at that domain’s DNS host. The generator supports a bounded mechanism set: ip4, ip6, a, mx, include and exists, followed by a final qualifier. Documentation-only 192.0.2.1 is an example, not an actual mail provider.
Do not publish several independent SPF records at one host. Inventory all legitimate senders and merge their authorization into one record. Changing -all or removing a provider without understanding your mail flow can affect delivery.
The lookup budget is recursive
SPF evaluation limits lookup-causing terms to ten across evaluation. A direct include is not necessarily one final DNS operation: it may lead to further nested mechanisms. MX and A behavior and void-lookup limits also matter.
The offline builder can count visible lookup mechanisms but cannot conclusively validate the final lookup budget. It does not query DNS. Inspect your existing record and each provider’s include chain separately before publishing.
Host: example.com TXT: v=spf1 ip4:192.0.2.1 ~all Host: _dmarc.example.com TXT: v=DMARC1; p=none; adkim=r; aspf=r
DMARC depends on alignment
DMARC evaluates alignment of an authenticated SPF or DKIM identity with the visible From domain. Begin with a monitoring policy and a reporting plan. Reports need a real destination, and an external reporting domain may need to authorize receipt through DNS.
RFC 9989 replaced RFC 7489 in May 2026 and removed percentage-based pct handling. The builder omits pct by default; its legacy compatibility option is not a safe partial-enforcement guarantee. Move toward quarantine or reject only after reviewing legitimate sources and alignment. Forensic report requests can involve personal information and provider-specific behavior. Long TXT values may need quoted chunks inside one record; follow your DNS provider’s input format rather than creating multiple SPF records.
Prepare demonstration DNS TXT records
Stage monitoring for example.com after inventorying the domain’s real mail senders. The documentation-only IP is deliberately not a real provider.
Input
Domain: example.com SPF mechanism: ip4:192.0.2.1 Final qualifier: ~all DMARC: none; relaxed alignment Reports: [email protected]
Expected output
{
"spf": {
"host": "example.com",
"value": "v=spf1 ip4:192.0.2.1 ~all"
},
"dmarc": {
"host": "_dmarc.example.com",
"value": "v=DMARC1; p=none; adkim=r; aspf=r; rua=mailto:[email protected]"
},
"lookupEstimate": 0,
"warnings": [
"Publish only one SPF record at this host. Merge existing senders before changing it.",
"Offline estimate only: nested includes, MX/A expansion, void lookups and existing DNS are not resolved.",
"External report destinations may require DNS authorization. Forensic reports may contain personal data."
]
}Publish the suggested name/value pairs through your DNS provider after merging any existing SPF senders. The current DMARC format omits historic pct. These offline strings do not resolve DNS, expand recursive SPF lookups, prove ownership, or establish that messages will authenticate.
Keep the references close
Primary documentation supports the technical details above. Check it alongside the behavior of your own runtime and deployment.
Open SPF & DMARC →