Record Builders
Build SPF, DMARC, BIMI, MTA-STS and TLS-RPT records, meta tags and robots.txt with live checks as you type.
1/10 DNS lookups at the top level
Ready to publish
v=spf1 include:_spf.google.com -allexample.com. IN TXT "v=spf1 include:_spf.google.com -all"After publishing, verify the published record with Email Security.
Related tools
About this tool
Record Builders writes the things that are easy to get wrong by hand: an SPF record, a DMARC record, a BIMI record, the MTA-STS TXT record and its policy file, a TLS-RPT record, the metadata tags for a page head, and a robots.txt file. Each form checks itself as you type - the SPF builder counts the DNS lookups your record will cost against the limit of 10 in RFC 7208 §4.6.4 and validates every include, IPv4 and IPv6 term; the DMARC builder validates the rua and ruf addresses and runs the finished record through the same analyser the Email Security checker uses, so builder and checker never disagree; the metadata and robots builders warn about lengths, relative URLs and rules that block more than you meant, and the robots builder writes one rule block per user-agent so a named crawler can be treated differently from the rest. The output is text to copy: a TXT record value, a zone file line, the tags, or the file. It does not publish anything and does not read the records your domain has today, so a record only takes effect once you paste it into your DNS provider or your site. Each builder links to the checker that verifies the published version afterwards.
All seven builders run in your browser: the domain, IP ranges, report addresses, logo and certificate URLs, title and description text and robots rules you type stay on the page, and the record, zone line, policy file, tags and file are assembled there. The single exception is the “Check nested lookups” button in the SPF builder - it sends each include domain, for example _spf.google.com, to the XGM DNS API, which resolves its TXT record from the XGM server; the record you are building stands in for your own domain's answer, so the domain you entered is never queried. Nothing is published anywhere: no DNS record is created or changed, no logo or policy file is fetched, no page or file on your site is touched, and the result is text you copy yourself. What you typed is not stored with the result.
How to use it
- Open the Record Builders tool.
- Paste or type the input you want to inspect.
- Read the result, which is computed in your browser; the input is not sent to XGM.
- Copy the output only after checking it looks correct.
- Use related XGM tools if you need a broader diagnostic view.
FAQ
The counter says 4 of 10 lookups, so why can my record still fail?
The counter next to the record counts only the terms you added: each include, plus a and mx if you ticked them. RFC 7208 §4.6.4 applies the limit of 10 to the whole evaluation, so lookups inside the providers' own records count as well, and one include can cost several. The “Check nested lookups” button resolves each include and reports the real total; above 10 receivers return permerror and SPF fails for every message.
My SPF record is longer than 255 characters. Is that a problem?
Not by itself. A single character-string inside a TXT record is capped at 255 octets (RFC 1035 §3.3.14), so a longer value has to be published as several quoted strings that resolvers concatenate back into one record. Most DNS providers split it for you; the builder warns at that length so you can check that yours did. The way to shorten it is to replace includes with the ip4 and ip6 ranges they resolve to.
Should the record end in -all or ~all?
-all (fail) tells receivers that mail from any other address is not yours; ~all (softfail) only marks it as suspicious, and most receivers still deliver it. ~all is the right setting while you are still finding forgotten senders, which is why the builder flags it as something to revisit rather than as an error. Move to -all once aggregate reports show every legitimate source passing.
Why does the DMARC builder warn when my rua address is on another domain?
A receiver will not send reports about your domain to a mailbox somewhere else unless that domain says it accepts them. The authorisation is a TXT record at yourdomain._report._dmarc.reportdomain (RFC 7489 §7.1), published by the owner of the report domain. Commercial DMARC report services publish it for you; if you point rua at a colleague's mailbox by hand, nobody publishes it and the reports never arrive.
Does blocking the AI crawlers in robots.txt actually stop them?
robots.txt is a request, not a control. The file format (RFC 9309) is honoured voluntarily, so the Disallow blocks the builder adds work for crawlers that read and respect it and do nothing against one that ignores it or renames its user agent. Pages that must stay private need authentication, not a robots rule - and a Disallow also stops well-behaved crawlers from seeing a noindex tag on the page.