RunLocalTools

SPF, DKIM & DMARC Generator — Free, Runs in Your Browser

Free SPF, DKIM and DMARC generator with a linter, DKIM key creation, DMARC rollout plan, MTA-STS, TLS-RPT and BIMI. Runs in your browser.

What it does

Type your domain, pick who sends email for it, and this tool writes the DNS records that prove your mail is genuine: an SPF record, a DKIM public key (with a freshly generated key pair if you want one), and a DMARC policy. It also builds MTA-STS, TLS-RPT and BIMI records, checks any record you paste in, explains each part in plain English, and exports everything as a zone file, JSON or CSV.

Every record is linted as you type. You get warnings for the mistakes that quietly break email: too many DNS lookups, a record over the length limit, +all, a missing report address, a weak key, and more.

How it works

SPF. Pick providers from the preset list (Google Workspace, Microsoft 365, Amazon SES, SendGrid and others), add your own includes and IP ranges, and choose the ending (~all, -all, ?all). IPv4 and IPv6 addresses and CIDR ranges are validated, duplicates are removed, and records over 255 characters are split into the quoted strings DNS requires. The linter counts the DNS-lookup terms against the limit of 10, flags deprecated ptr, catches terms placed after all, and warns before the record gets close to the 512-byte DNS limit.

DKIM. The key pair is generated in your browser with the Web Crypto API: RSA 2048 by default, RSA 4096 or 1024 if you need them, and Ed25519 where your browser supports it. The public key is formatted as the exact TXT record you publish at selector._domainkey.yourdomain. The private key can be downloaded as a standard PEM file (or the older PKCS#1 format some mail servers expect). A checker also reads any existing DKIM record or public key and reports its type, size and problems.

DMARC. Choose the policy for the domain, for subdomains (sp) and for subdomains that don’t exist (np), plus alignment, testing mode (t) and report addresses. A rollout planner produces a ready-to-publish record for each stage, from monitoring to full reject. If a report address is on a different domain, the tool also generates the authorization record that domain must publish before reports will arrive. DMARC was updated in 2026 (RFC 9989): np, psd and t were added and pct, ri and rf became historic. The tool supports the new tags and keeps the old ones in a legacy section, because many receivers still honor them.

Optional live checks. If you choose, the tool can look up a domain’s published records over DNS, resolve every SPF include to count the true number of lookups, flatten includes into plain IP ranges (split into sub-records when the result is too long), probe common DKIM selectors, and check a whole list of domains. These are off until you tick one box (see Privacy).

How to use it

  1. Enter your domain at the top.
  2. SPF tab: tick the services that send mail for you, add any extra IP addresses, and pick the ending. Copy the record.
  3. DKIM tab: if you run your own mail server, enter a selector, generate a key pair, download the private key, and publish the public record. If a provider like Google or Microsoft gave you a record instead, paste it into the checker.
  4. DMARC tab: start with p=none and an address for reports. Use the rollout plan to tighten the policy over several weeks.
  5. In your DNS panel, add each record as type TXT using the name shown. Switch between relative names (@, _dmarc) and full names to match your registrar.
  6. Optionally tick Allow DNS lookups in the sidebar and use Check live to confirm the records are published and valid.
  7. Managing many domains? Use the Bulk tab: paste or import a list and download one CSV, zone file or zip.

If your domain list is buried in a document or spreadsheet, pull the names out first with the Domain Extractor. When an SPF record needs a network range worked out, the IP subnet / CIDR calculator shows the exact start, end and size. To see how a real message actually authenticated, open the original in the EML File Viewer and read its headers. After authentication is solid, the Email Spam-Trigger Keyword Checker helps with the content side of deliverability.

FAQ

Do I need SPF, DKIM and DMARC all together?

Yes, in practice. SPF lists the servers allowed to send for your domain, DKIM signs each message so it can’t be altered unnoticed, and DMARC tells receivers what to do when both fail and sends you reports. Gmail and Yahoo require all three from bulk senders, and DMARC only works if SPF or DKIM passes and aligns with your visible From domain.

Should I end SPF with ~all or -all?

Start with ~all (softfail) while you confirm every legitimate sender is listed, then move to -all (hard fail). Avoid ?all, which gives no protection, and never use +all, which lets anyone send as you. With DMARC enforcing, the practical difference between ~all and -all is small, so don’t rush it.

What is the SPF limit of 10 DNS lookups, and how do I fix going over?

Each include, a, mx, ptr, exists and redirect counts as one lookup, including those inside the records you include. Past 10, SPF fails entirely. The fix is to remove providers you no longer use, replace a/mx with fixed IP ranges, or flatten includes into IP ranges. The optional live check counts the real total, and the flatten option can produce the records. Flattened records go stale when a provider changes its addresses, so re-check them periodically.

What if I lose my DKIM private key?

Nothing is permanently lost. Generate a new key with a new selector (the tool suggests the next dated one), publish the new public record, point your mail server at the new private key, and delete the old record once mail is signing with the new one. This tool deliberately never stores the private key, so download it before you leave the page.

What changed in DMARC in 2026?

The updated standard (RFC 9989) adds np (policy for subdomains that don’t exist), psd (for public-suffix operators) and t (a testing flag), and marks pct, ri and rf as historic. Many receivers still honor pct, and receivers that don’t yet understand t ignore it, so each rollout method has a trade-off. The planner explains both.

Is it safe to generate a DKIM key in a web page?

The key is created by your browser’s cryptography and never leaves the page, but any private key should be treated carefully. If you’d rather not trust a web page with it, the tool shows the equivalent OpenSSL commands so you can generate the pair offline and just paste the public part.

Privacy

Almost everything runs locally in your browser: building and linting SPF, DKIM, DMARC, MTA-STS, TLS-RPT and BIMI records, generating DKIM keys, the rollout planner, the bulk generator, and all exports. Nothing you type or paste is sent to a server.

  • Saved in your browser: your last-used choices (domain, providers, DMARC settings) and any bulk domain list you add, so they survive a refresh. Each has a clear control. The bulk list can be removed with Clear saved list, and settings with Reset saved settings.
  • Never saved: the DKIM private key lives in memory only and is gone when you leave the page.
  • Optional, uses the internet: the live checks (checking a domain, resolving or flattening SPF includes, probing DKIM selectors, bulk live check) need to ask a public DNS resolver, either Cloudflare or Google, which you choose. The domain names you check are sent to that resolver. These features are off every time the tool loads, and nothing is requested until you tick Allow DNS lookups over the internet.
  • Zip downloads load a small open-source library (JSZip) from a CDN the first time; this sends none of your data.

Limitations

  • The SPF lookup count is exact only when you use the optional live resolver. Offline, it counts the terms written in the record and can’t see inside includes.
  • The “does this report address need an authorization record” check uses a built-in list of common two-part domain suffixes, not the full public-suffix list. If the check misjudges an unusual domain, follow what your report provider tells you.
  • Provider include hostnames in the presets are the commonly documented ones. Confirm them against your provider’s current setup guide.
  • Ed25519 DKIM keys depend on browser support, and not all receivers verify them yet.
  • The live-check score is a rough guide, not a security audit.
  • This tool generates records; it can’t publish them to your DNS for you.