Skip to main content
Free tool

SPF and DMARC record generator

Pick the services that send as your domain and a DMARC policy. Get records ready to paste into your DNS, plus where each provider keeps its DKIM key.

Services that send as this domain
Mail from servers not listed
DMARC policy

SPF record

Type TXTHost example.com (@)
v=spf1 include:_spf.google.com ~all

1 top-level DNS lookup. Replace any existing SPF record; never publish two.

DMARC record

Type TXTHost _dmarc.example.com
v=DMARC1; p=none; rua=mailto:dmarc@example.com
  • Note: p=none only monitors. Read the reports for a few weeks, then move to quarantine and reject once all your legitimate mail passes.

DKIM: where to get each key

  • Google Workspace. Admin console → Apps → Google Workspace → Gmail → Authenticate email. Generates a TXT record at google._domainkey; publish it, then click Start authentication.

How to publish the records

  1. Open the DNS settings wherever your domain is managed (your registrar, Cloudflare, or similar).
  2. SPF: edit the existing TXT record that starts with v=spf1, or add one if there is none. The host is the domain itself, often written @.
  3. DMARC: add a TXT record with host _dmarc. Some DNS panels append your domain automatically, so enter _dmarc, not _dmarc.example.com.
  4. DKIM: follow your provider's steps shown with the result, then turn signing on in the provider.
  5. Wait for the records' TTL to pass, then check them.

Why some providers need no SPF include

SPF is checked against the return-path (bounce) address, not the From address people see. Services such as SendGrid, Amazon SES, Resend and Postmark set the return-path to a subdomain of yours and publish SPF there through the records they hand you. A root include for them spends one of your ten lookups and adds nothing. The generator leaves those out and says what to publish instead.

Common mistakes

  • Publishing a second SPF record for a new service instead of editing the first.
  • Keeping includes for services you stopped using. Each one spends a lookup and authorizes servers you no longer control.
  • Wrapping the record in extra quotes, or pasting it with a line break, which some DNS panels then store literally.
  • Jumping straight to p=reject before reading any reports, and losing mail from a service you forgot about.

Moving DMARC from none to reject

Start at p=none with a report address. The reports list every server sending as your domain. When every service you use passes, move to p=quarantine, optionally with pct below 100 to apply it to part of the failing mail first, and then to p=reject. That last step is what stops other people sending as your domain.

Sending cold email from new domains

Every domain you send from needs its own records. The cold email calculator shows how many domains a campaign needs, and the blacklist checker tells you if one has been listed.

FAQ

Questions

No. A domain must have exactly one SPF record; with two, SPF fails for all your mail. Add the new include to the existing record instead. Use "Load my current SPF" to start from what is published and add to it.

~all (soft fail) asks receivers to treat mail from unlisted servers as suspicious; -all (fail) asks them to reject it. With DMARC in place, receivers mostly act on the DMARC policy instead, so ~all is the safer default while you confirm every sender is listed.

The private half of a DKIM key has to live with the service that signs your mail, so the provider generates the pair and gives you the public record to publish. The generator tells you where each provider keeps that record.

Receivers email daily XML summaries to the rua address. They are hard to read raw; a free DMARC report viewer turns them into a list of who sends as your domain and whether each passes.

More free tools

These tools are free and need no sign-up. They are made by AngelSend, an agentic CRM that sends outreach from your own mailbox and runs these kinds of checks before each send.