SPF / DMARC / DKIM Record Builder — Generate DNS Email Records
Build SPF, DMARC, and DKIM DNS records visually with live preview, validation, and one-click copy. Generate DKIM RSA key pairs in your browser. Includes presets, plain-English explanations, and DNS lookup commands. Runs in your browser — nothing is sent to a server.
What are SPF, DKIM and DMARC? They are three DNS TXT records that together let a receiving mail server decide whether a message really came from your domain. SPF lists the servers allowed to send for the domain, DKIM publishes a public key so receivers can verify a signature carried in each message, and DMARC — published at _dmarc.yourdomain — states what to do when those checks fail and where to send reports.
How to Use the Email Record Builder
-
Enter your domain — Type the domain you send mail from into the field at the top. Every record name, preview and lookup command on the page rewrites itself to match, so the DKIM host becomes
selector1._domainkey.yourdomainrather than the example. - Build the SPF record — Start from a provider preset, then add or remove mechanisms. The validator counts the mechanisms that cost a DNS lookup as you type, warns once you pass seven and reports an error above ten — the limit in RFC 7208, beyond which receivers return a PermError.
-
Choose the all qualifier —
-alltells receivers to treat anything not listed as a hard fail,~allmarks it as suspicious but deliverable, and?alltakes no position. Publish~allwhile you are still discovering senders, then tighten to-all. - Generate a DKIM key pair — Pick a selector and key size and press Generate Keys. The RSA pair is created in the page by the browser's Web Crypto API — publish the TXT value in DNS and load the PEM private key into your mail server. The private key is never transmitted.
-
Set the DMARC policy — Start at
p=nonewith anruaaddress so aggregate reports arrive without any mail being affected. Tags left at their defaults — 100%, relaxed alignment, a daily interval — are left out of the record rather than written explicitly. -
Copy from the Combined View — The last tab shows all three records against the exact hostname each belongs on, plus
digandnslookupcommands prefilled with your domain so you can confirm publication once DNS has propagated.
How Email Authentication Works
SMTP was designed without any way to prove who sent a message, so anyone can put your domain in the From: header. SPF, DKIM and DMARC are three DNS-published records that close that gap from different directions, and they only add up to real protection when all three are in place. Each answers a different question, and DMARC is the one that turns the answers into a decision.
SPF — which servers may send
SPF (Sender Policy Framework, RFC 7208) is a TXT record on the domain itself listing the sources allowed to send mail for it. When a message arrives, the receiver takes the domain from the SMTP envelope sender — the MAIL FROM address, also called the return path — looks up that domain's SPF record and checks whether the connecting IP matches any mechanism in it. The record is evaluated left to right and the first match wins, which is why the catch-all all mechanism has to be the last token. Every include, mx, a, exists and redirect costs a DNS lookup, and the total is capped at ten across all nested records; go over it and conforming receivers return a PermError, which usually means the record is ignored entirely. That cap is the single most common way a working SPF setup quietly breaks after a fourth or fifth vendor is added.
DKIM — proving the message was not altered
DKIM (DomainKeys Identified Mail, RFC 6376) works with a key pair instead of an address list. Your mail server hashes the body and a chosen set of headers, signs the result with a private key and adds a DKIM-Signature header carrying the signing domain in the d= tag and the selector in s=. The receiver fetches the public key from <selector>._domainkey.<domain> and verifies the signature. Because the proof travels inside the message, DKIM survives forwarding that would break SPF — a mailing list that relays your mail keeps the signature intact as long as it does not rewrite the signed headers or the body.
The key generator on this page calls the browser's Web Crypto API — crypto.subtle.generateKey with RSASSA-PKCS1-v1_5 and SHA-256 — and exports the public half in SPKI form, base64-encoded into the p= tag of a v=DKIM1; k=rsa; p=… record. The private half is exported as a PKCS#8 PEM block for your mail server. Both halves are produced inside the tab and neither is transmitted anywhere, which also means the private key exists only in that page until you copy it — if you close the tab, generate a fresh pair.
DMARC — the policy and the alignment rule
DMARC (RFC 7489) sits on top of both and adds the piece neither has: it looks at the domain a human actually sees, the one in the From: header. A message passes DMARC if either SPF or DKIM passes and the domain that passed lines up with the From: domain. That second condition is alignment, and it is what stops a spammer from passing SPF for a throwaway domain while displaying yours. Relaxed alignment accepts a subdomain — mail.example.com aligns with example.com — while strict alignment demands an exact match. The p= tag then tells receivers what to do with messages that fail: nothing, quarantine, or reject.
The SPF builder writes the qualifier in front of every mechanism, so you will see v=spf1 +mx -all rather than v=spf1 mx -all. The two are identical to a receiver — + is the default qualifier — so the record can be published exactly as shown.
Where Each Record Goes
All three are ordinary TXT records; what differs is the hostname they sit on. Getting the host wrong is the usual reason a correctly written record never takes effect. Note that many DNS control panels want the host relative to the zone, so enter _dmarc rather than _dmarc.example.com — if you paste the full name into a relative field you end up with _dmarc.example.com.example.com.
| Record | Hostname | Starts with |
|---|---|---|
| SPF | example.com (the root) | v=spf1 |
| DKIM | selector1._domainkey.example.com | v=DKIM1 |
| DMARC | _dmarc.example.com | v=DMARC1 |
SPF Mechanisms and Qualifiers
A mechanism describes a set of permitted senders; a qualifier in front of it says what a match means. The builder offers the mechanisms below, and marks the ones that consume part of the ten-lookup budget.
| Mechanism | Matches | Costs a lookup |
|---|---|---|
include:domain | Anything that domain's own SPF record authorises — how you add a provider such as a marketing platform | Yes |
mx | The servers listed in your MX records | Yes |
a | The addresses your domain's A or AAAA records point at | Yes |
ip4:1.2.3.0/24 | A literal IPv4 address or CIDR block | No |
ip6:2001:db8::/32 | A literal IPv6 address or prefix | No |
exists:… | Passes when a macro-expanded name resolves; used for per-IP checks | Yes |
redirect=… | Hands evaluation to another domain's record entirely | Yes |
| Qualifier | Result on match | Typical use |
|---|---|---|
+ | Pass | The default; may be omitted |
- | Fail | -all once you are confident every sender is listed |
~ | SoftFail | ~all during rollout — receivers usually accept but mark |
? | Neutral | Explicitly no opinion; treated like no record at all |
DMARC Tag Reference
A DMARC record is a semicolon-separated list of tags. Only v and p are required, and the builder omits any tag left at its default value so the published record stays short and readable.
| Tag | Meaning | Default |
|---|---|---|
v | Version — always DMARC1, and it must come first | required |
p | Policy for the domain: none, quarantine or reject | required |
sp | A different policy for subdomains | same as p |
pct | Percentage of failing messages the policy is applied to | 100 |
rua | Where to send aggregate XML reports, as a mailto: URI | none sent |
ruf | Where to send per-message failure reports; many receivers never send these | none sent |
aspf | SPF alignment: r relaxed or s strict | r |
adkim | DKIM alignment: r relaxed or s strict | r |
ri | Requested seconds between aggregate reports | 86400 |
rf | Failure report format | afrf |
Rolling Out DMARC Without Breaking Mail
- Start with monitoring: Set DMARC policy to
nonefor 2–4 weeks. Review aggregate reports to identify all legitimate sending sources before enforcing. - Use 2048-bit DKIM keys for stronger security. Rotate keys periodically and use unique selectors for each email provider.
- Keep your SPF record under 10 DNS lookups. Use
ip4/ip6mechanisms where possible to avoid nested includes that consume lookups. - Enable both SPF and DKIM before enforcing DMARC. Dual authentication provides a safety net if one mechanism fails.
- Use relaxed alignment (
adkim=r; aspf=r) unless you have strict subdomain requirements. Relaxed mode is more forgiving and compatible with most setups. - Monitor DMARC reports regularly. Check for unauthorized senders, misconfigured mail servers, and legitimate sources that need SPF or DKIM updates.
- Gradually tighten your policy: Move from
none→quarantine→rejectover several weeks, ensuring no legitimate mail is blocked at each stage.
Frequently Asked Questions
SPF checks whether the connecting server is allowed to send for the envelope sender's domain. DKIM checks a cryptographic signature carried in the message, proving it was not altered after signing. DMARC looks at the domain in the visible From: header and passes only if SPF or DKIM passed and the passing domain aligns with it — then applies the policy you published and sends you reports.
Yes, if you are not certain you can name every system that sends mail as your domain. p=none changes nothing about delivery but, with an rua address set, starts aggregate reports flowing from the large receivers. Two to four weeks of reports usually surfaces the forgotten senders — the CRM, the billing system, the ticketing tool — before a policy that could reject them is switched on.
2048-bit RSA is the current recommendation and is what this generator selects by default. The catch is DNS: a single character-string in a TXT record is limited to 255 bytes, and a 2048-bit key encodes to roughly 400 characters, so the value has to be split into several quoted strings joined by the DNS server. Most providers handle that automatically when you paste the whole value; a few require you to split it by hand.
RFC 7208 caps SPF evaluation at ten DNS-querying mechanisms in total — include, mx, a, exists and redirect — and that budget is shared with everything your includes pull in. One provider's include can consume three or four lookups on its own. Exceeding ten yields a PermError, which most receivers treat as though you had no SPF record. Replace what you can with ip4 and ip6 literals, which cost nothing.
Alignment compares the domain in the visible From: header with the domain that passed SPF or signed with DKIM. Relaxed (r) accepts an organisational match, so a message from example.com aligns with a signature from mail.example.com. Strict (s) requires the two to be identical. Relaxed is the default and the right choice for almost everyone, because outsourced senders very often sign or bounce from a subdomain.
Yes, and you generally should. Each key lives under its own selector at selector._domainkey.yourdomain, so a mail platform and a marketing platform can each hold a private key without sharing one. Selectors are also how rotation works without downtime: publish the new key under a new selector, switch the signer over, then wait until no mail signed with the old selector is still in flight before removing it.
No. The records are assembled as you type and the DKIM key pair is generated by the browser's Web Crypto API, so the private key never leaves the tab. One caveat: your domain and the DMARC settings — including any rua and ruf addresses you type — are written into the page URL so a draft can be bookmarked or shared. Clear those fields before you paste the link somewhere public.
Web Crypto is only available in a secure context, so the generator needs the page served over HTTPS (or from localhost) and will fail silently on an insecure origin. Generating a 2048-bit key also takes a moment on slower hardware; the button disables itself while it works. If it reports a failure, try the 1024-bit option to confirm the API is reachable, then investigate the browser rather than the key size.
Use Cases
Onboarding a New Sending Platform
A marketing or invoicing service tells you to add its include and a DKIM selector. Add the mechanism here first and watch the lookup counter, so you find out before you publish whether the new vendor tips the record past the ten-lookup limit.
Rotating a DKIM Key
Generate a fresh 2048-bit pair under a new selector, publish it alongside the old one, switch the mail server to sign with the new private key, and remove the retired selector only once no signed mail is still in transit.
Moving DMARC From Monitor to Enforce
Build the quarantine record with a reduced pct so only part of the failing mail is affected, compare the next batch of aggregate reports against the previous one, then rebuild at reject when the reports come back clean.
Locking Down a Domain That Sends No Mail
Parked and brand-protection domains are favourite targets for spoofing. Publish v=spf1 -all with a DMARC record at p=reject and sp=reject, and nothing can convincingly claim to be them.
Diagnosing Mail Landing in Spam
Build what the records ought to say, then run the prefilled dig commands from the Combined View against what is actually published. A missing selector, a stray second SPF record or a typo in the DMARC host shows up in seconds.
Explaining the Change Request
The plain-English breakdown under each preview names what every mechanism and tag does, which is what you paste into the ticket when someone else owns the DNS zone and needs to know why the change is safe.