Build correct SPF, DKIM and DMARC records step by step. Live DNS lookup, the 10-lookup SPF limit, safe qualifiers and a monitoring-first DMARC rollout.
This wizard walks you through configuring the three DNS records that decide whether your email reaches the inbox or the spam folder: SPF, DKIM and DMARC. It checks your domain's existing records with a live DNS lookup, detects your mail provider, generates each record with the correct syntax, and warns you about the mistakes that silently break delivery for an entire domain. It is a guided, step-by-step flow rather than a single text box, because these three records interact and the order you enable them in matters.
Getting email authentication wrong is uniquely dangerous: a bad SPF or DMARC record does not fail loudly at setup time, it quietly causes legitimate mail from your whole domain to be rejected or junked days later, and the damage is invisible until customers stop receiving your messages. This tool exists to keep you out of the specific traps that cause that.
The wizard configures them in that order — SPF, then DKIM, then DMARC — because DMARC only makes sense once the mechanisms it references are in place.
include mechanisms for the services that send your mail (Google Workspace, Microsoft 365, SendGrid, Mailchimp and others are recognised) and choose the ending qualifier. The tool counts your DNS lookups as you go.SPF has a hard rule that catches almost everyone eventually: an SPF record may trigger no more than 10 DNS lookups during evaluation. Every include, a, mx and redirect mechanism costs at least one lookup, and each included record can pull in more recursively. Exceed ten and the result is a permerror — and many receivers treat a permerror as an SPF failure, so your legitimate mail starts failing authentication. This is easy to hit because each SaaS sender you add (your CRM, your invoicing tool, your newsletter platform) contributes its own includes. The wizard counts lookups as you build the record and warns you as you approach and cross the limit, so you can consolidate senders or use SPF flattening before you publish something that will break.
An SPF record ends with an “all” mechanism that says what to do with servers not on your list. The qualifier in front of it is critical:
-all (hard fail) — reject anything not listed. The strongest and the goal for a locked-down domain.~all (soft fail) — accept but mark as suspicious. A reasonable rollout setting while you confirm you have listed every sender.?all (neutral) — no opinion. Weak, but at least not harmful.+all (pass everything) — never use this. It tells the world that any server on the internet is authorised to send mail as your domain, which completely defeats SPF and hands spammers your domain. A permissive +all is not a fix for delivery problems; it is an open door. If mail is failing SPF, the answer is to add the legitimate sender to the list, not to authorise everyone.A DMARC record's policy (p=) tells receivers what to do with mail that fails both SPF and DKIM alignment. There are three levels, and it is vital to understand that only two of them actually protect you:
p=none — take no action; just send me reports. This is monitoring mode. It changes nothing about how failing mail is handled — spoofed messages still get delivered. Its only job is to give you visibility so you can find every legitimate sender before you turn on enforcement.p=quarantine — send failing mail to spam. The first level that actually blunts spoofing.p=reject — refuse failing mail outright. Full protection, and the destination you should aim for.The correct rollout is to start at p=none, read the aggregate reports until you are confident SPF and DKIM pass for all your real mail, then move to quarantine and finally reject. Stopping at p=none and believing you are protected is the single most common DMARC mistake: it monitors, it does not defend. The wizard recommends monitoring mode until SPF and DKIM are both in place, then guides you toward enforcement.
SPF first, then DKIM, then DMARC. DMARC references the other two, so it should be enabled — and initially set to monitoring — only after SPF and DKIM are working.
An SPF record may cause at most 10 DNS lookups when evaluated. Going over produces a permerror that many receivers treat as a failure, breaking delivery. Consolidate includes or flatten your record to stay under it.
No. +all authorises every server on the internet to send as your domain and destroys the purpose of SPF. Use ~all while rolling out and -all once you are confident every sender is listed.
No. p=none is monitoring only — failing mail is still delivered. It exists to collect reports so you can safely move to p=quarantine and then p=reject, which are the policies that actually stop spoofing.
A selector is a label that identifies which public key to use, published at selector._domainkey.yourdomain. Your provider tells you the selector and the key to publish.
Yes. It performs a live DNS-over-HTTPS lookup to show your current SPF, DKIM and DMARC records and detect your mail provider, so recommendations are based on your actual configuration.
All three are DNS TXT records that you add at your DNS host. After publishing, re-check to confirm they resolve before moving to a stricter policy.
For focused edits, the SPF record generator and DMARC record generator build individual records, and the DNS lookup tool confirms that a published record is resolving as expected.
Email authentication is your first line of defense against email spoofing and phishing attacks. Without it, anyone can send emails that appear to come from your domain.
SPF (Sender Policy Framework) SPF is a TXT record in your DNS that lists all servers authorized to send email for your domain.
DKIM (DomainKeys Identified Mail) DKIM adds a cryptographic signature to your outgoing emails. The receiving server uses a public key in your DNS to verify this signature.
DMARC (Domain-based Message Authentication, Reporting & Conformance) DMARC tells receiving servers what to do when emails fail SPF or DKIM. It also provides reporting.
Email authentication consists of SPF, DKIM, and DMARC - three DNS-based protocols that verify emails are legitimately from your domain. They help prevent email spoofing and phishing attacks.
Each protocol serves a different purpose: SPF specifies which servers can send email for your domain, DKIM adds a digital signature to verify message integrity, and DMARC tells receiving servers what to do with emails that fail authentication.
We recommend: 1) SPF first - simplest and most widely supported, 2) DKIM second - requires coordination with your email provider, 3) DMARC last - it relies on SPF and DKIM being configured.
DNS changes typically propagate within 1-4 hours, but can take up to 48 hours. If your records don't verify immediately, wait a few hours and check again.
Start with policy "none" (monitoring mode) to receive reports without affecting email delivery. Gradually move to "quarantine" then "reject" after verifying SPF and DKIM work correctly.
DKIM requires a private key that must be securely stored on your email server. This setup is provider-specific - Google Workspace, Microsoft 365, and other providers each have their own DKIM configuration process.
Include all your email services in your SPF record using "include:" mechanisms. Each service should have its own DKIM selector configured.
DMARC aggregate reports are XML files sent to the email address in your "rua" tag. Free services like DMARC Analyzer or Postmark's DMARC tool can parse these reports into readable dashboards.