DNS Records Generator — One Email Setup, Five Provider Syntaxes, Zero Typos

Every email deliverability thread on the internet eventually arrives at the same place: a tangled mix of SPF, DKIM, DMARC, MX, and a half-dozen other TXT records, each with fiddly syntax that differs by DNS provider. Gmail rejects your mail because SPF includes are wrong. Microsoft 365 marks you as spam because DKIM is missing. Your DMARC aggregate reports never arrive because you typed rua= instead of rua=mailto:. The problem is rarely conceptual. The problem is that you're hand-typing 14 TXT records into a web UI and one character is off somewhere.

The DNS Records Generator exists to take the hand-typing out. Pick your email provider, enter your domain, and get the complete record set in the syntax your DNS host expects. Five outputs, one canonical input.

What it generates

Eleven records for a typical small-business email setup:

• SPF at the apex, the TXT record listing authorized senders. Preset per email provider with include:_spf.google.com, include:spf.protection.outlook.com, include:amazonses.com, etc.
• MX at the apex, inbound mail routing. Priority + host per provider.
• DKIM, the selector record that signs outgoing mail. Value pulled from your provider's admin dashboard; the tool emits the record name (like google._domainkey or fm1._domainkey) and a placeholder for the public key.
• DMARC at _dmarc, ties SPF + DKIM together with policy. Defaults to p=none (monitor only) with rua=mailto: pointing at your reporting email.
• CAA at the apex, restricts which CAs can issue TLS certs for your domain. Pre-filled with Let's Encrypt + Sectigo (ZeroSSL's underlying CA).
• BIMI (optional), brand logo in supporting mail clients. Requires DMARC enforcement + a paid VMC.
• MTA-STS + TLS-RPT (optional), tells senders to require TLS when delivering mail to your domain. Near-zero downside.
• DNSSEC (optional), enablement instructions + DS-record template per DNS provider.

Everything is data-driven from one canonical RECORDS array. The five emitters, BIND, Cloudflare, DigitalOcean, AWS Route53, Google Cloud DNS, take that array and render it in each provider's native syntax.

Why five syntaxes matter

Every DNS provider has a different way of expressing the same record. The values are the same — v=spf1 include:_spf.google.com -all is v=spf1 include:_spf.google.com -all everywhere. But the API / CLI / Terraform syntax, the quoting rules, the special handling for @ vs the bare domain, the CAA record format, all different.

Cloudflare takes Terraform resources (cloudflare_record) or dashboard entries. Proxied=false for TXT/MX/CAA is a trap that catches everyone once.

DigitalOcean uses doctl with flag-per-field (--record-type, --record-name, --record-data) or the Terraform digitalocean_record resource. CAA records get split flags/tags/data separately.

AWS Route53 wants a JSON change-batch that you feed to aws route53 change-resource-record-sets. Fully-qualified domain names with trailing dots. TXT values wrapped in escaped quotes.

Google Cloud DNS uses gcloud dns record-sets transaction with start/add/execute semantics or a Terraform google_dns_record_set. String escaping for TXT is the weirdest of the five.

BIND is the lowest-common-denominator, the zone-file format that everything else is modeled after. If your setup is something exotic (on-prem bind, or a DNS provider that lets you paste zone-file syntax), this tab is the fallback.

The tool renders all five, you copy the one that matches, and nobody ever re-types a TXT record.

The step-up dance for DMARC

DMARC is where most small-business email setups go wrong. The record is easy to add; the policy transition is where people either skip ahead and break their own mail or never finish and leave spoofing wide open.

The tool's default is p=none, the "monitor only" policy. It doesn't block anything. It just asks receiving mail servers to send you aggregate reports (at the rua=mailto: address you provide) every 24 hours showing which IPs are sending mail claiming to be from your domain.

For the first 2-4 weeks you watch those reports. Every legitimate sending source, your email provider, your transactional mail service (Mailgun, Postmark, SES), any marketing platform, any CRM that sends on your behalf, should show up with both SPF and DKIM aligned. If one of them isn't aligned, you configure it before proceeding.

When the reports are clean, you step up to p=quarantine (send non-aligned mail to spam). Two more weeks of monitoring. Then p=reject (block non-aligned mail entirely).

The tool emits p=none by default with a checkbox to flip to p=reject when you're ready. The ship-order card in the output walks through the transition timing explicitly.

The DNSSEC caveat

DNSSEC protects against DNS spoofing by signing your zone with cryptographic keys. It's widely supported on the resolver side (most ISP resolvers validate), variably supported on the authoritative side (every provider has different steps to enable), and has one footgun that catches everyone: the DS record goes at your registrar, not your DNS host.

Every DNS provider that supports DNSSEC will generate a DS record for you (it contains the key tag + algorithm + digest of your KSK). You copy that DS record to wherever you bought the domain, Namecheap, GoDaddy, Google Domains, whoever, and they publish it in the parent TLD zone. After 24-48 hours of propagation, your zone is DNSSEC-validated end-to-end.

The tool emits DNSSEC enablement instructions per provider. Cloudflare: one dashboard toggle. AWS Route53: one CLI command. DigitalOcean: they don't support native DNSSEC, your options are to host DNS elsewhere or forward NS to a provider that does. Google Cloud DNS: gcloud dns managed-zones update --dnssec-state on. BIND: hand-generate KSK + ZSK with dnssec-keygen and sign your zone.

The companion workflow

1. Run DNS / Email Audit on your domain to see what's currently published.
2. Run the Generator with your current email provider to see what the correct record set looks like.
3. Diff the two. Add missing records, fix misconfigured ones.
4. Wait 30-60 min for propagation. Send a test email to a Gmail inbox, view original, confirm SPF=PASS + DKIM=PASS.
5. Leave DMARC at p=none for 2-4 weeks. Read the rua reports. Fix any unaligned sources.
6. Step up to p=quarantine, then p=reject.
7. Re-audit. All green.

Related reading

• Email Infrastructure for Small Business, the concept-level overview
• ZeroSSL, the CA Alternative Mentioned in Your CAA Record
• Security Headers as a Trust Signal
• Caddy, Automatic TLS That Works With Your CAA Config

If your business runs on cold email (mine does, 29 mailboxes, ~2,600 sends per week), getting email auth right is table stakes, not a nice-to-have. The $20 Dollar Agency walks through the full deliverability + follow-up SOP: The $20 Dollar Agency.

Fact-check notes and sources

• SPF (RFC 7208): datatracker.ietf.org/doc/html/rfc7208
• DKIM (RFC 6376): datatracker.ietf.org/doc/html/rfc6376
• DMARC (RFC 7489): datatracker.ietf.org/doc/html/rfc7489
• MTA-STS (RFC 8461): datatracker.ietf.org/doc/html/rfc8461
• TLS-RPT (RFC 8460): datatracker.ietf.org/doc/html/rfc8460
• BIMI working group draft: bimigroup.org
• CAA record (RFC 8659): datatracker.ietf.org/doc/html/rfc8659
• DNSSEC overview: cloudflare.com/learning/dns/dns-security/