SPF, DKIM & DMARC Record Generator

Build the three DNS TXT records that stop your mail from landing in spam — and, done wrong, stop it from being delivered at all.

All three of these records live in the same place — a TXT record in DNS — but they check different things, and understanding what each one actually verifies is the difference between a working setup and a broken one. SPF says which mail servers are allowed to send for your domain, checked against the SMTP envelope sender. DKIM cryptographically signs the message so a receiver can confirm it was not altered in transit and really came from a holder of your private key. DMARC does not check anything new by itself — it tells receivers what to do when SPF and DKIM disagree with the visible From address, and where to send reports about it.

SPF’s most consequential rule is the one people find out about the hard way: a maximum of 10 DNS lookups. Every include, mx, a, exists, ptr and redirect mechanism costs one lookup, and include mechanisms are recursive — if include:_spf.google.com itself includes three more domains, that is four lookups from one line in your record. Exceed 10 and receivers are required by the RFC to treat the entire record as a permerror, which most mail filters treat as equivalent to no SPF record at all. ip4 and ip6 mechanisms are free regardless of how many you list, since they need no lookup.

The choice between ~all and -all is a real risk decision, not a formality. ~all (softfail) tells receivers to accept the message but mark it as suspicious, typically routing it to spam. -all (hardfail) tells them to reject it outright. Ship ~all while you are still discovering every legitimate sending source — a forgotten transactional-email provider under -all means its mail bounces, not just gets flagged. Move to -all once you are confident the list is complete.

DKIM signs with a private key that only lives on your mail server, and publishes the matching public key at a very specific DNS location: <selector>._domainkey.<domain>. The selector exists because you can run more than one DKIM key at once — useful for key rotation, or when two different providers both sign mail for the same domain. Whatever you paste into the public key field should be just the base64 body; this tool strips the -----BEGIN/END PUBLIC KEY----- wrapper and any line breaks automatically, since the DNS record needs it as one continuous string.

DMARC alignment (adkim/aspf) controls how strictly the domain in the DKIM signature or the SPF check has to match the visible From address. Relaxed (the default) accepts an exact match or a subdomain of the From domain — mail.example.com aligns with a From of example.com. Strict requires an identical match. Relaxed is the right default for most domains, since it tolerates the common pattern of sending infrastructure living on a subdomain; strict is for organizations that need to guarantee no subdomain can pass as the primary domain in mail.

The rollout path that actually avoids breaking mail: publish DMARC at p=none first. This changes nothing about delivery, but the rua address starts receiving daily aggregate reports naming every source sending mail as your domain, legitimate or not. Read those for a couple of weeks, fix any legitimate source that is failing SPF or DKIM, and only then move to quarantine and eventually reject. Jumping straight to reject without that visibility step is the single most common way DMARC rollouts silently drop real customer mail.