BrowserTools
Home / Generators / SPF & DMARC Generator

SPF & DMARC Generator

Create the DNS records that stop others from sending email in your name, or check one you already have.

Maintained by BrowserTools · Last updated 2026-09-29

Loading SPF & DMARC Generator… If nothing happens, please enable JavaScript.

Anyone can put your address in the From line of an email. SPF and DMARC are the two DNS records that let receiving mail servers tell real mail from forgeries. SPF (Sender Policy Framework) is a TXT record on your domain that lists the servers allowed to send for it: your mail provider, your newsletter service, your own server. DMARC sits on top of it at _dmarc.yourdomain and says what receivers should do with mail that fails the checks (deliver it, send it to spam or reject it) and where to send reports about it. Gmail, Yahoo and Microsoft now expect bulk senders to have both, and without them your genuine mail is more likely to land in spam while spoofed mail gets through.

Frequently asked questions

Where do I add these records?
In the DNS settings of the company that hosts your domain's DNS, which is usually your registrar or a service like Cloudflare. Create a TXT record. For SPF the host is the domain itself, often written as @. For DMARC the host is _dmarc, which some panels want as _dmarc.example.com and others as just _dmarc because they add the domain for you. Changes normally take effect within minutes to a few hours, depending on the TTL.
What is the difference between ~all and -all?
Both close the list of allowed senders. With ~all (soft fail), mail from unlisted servers is accepted but treated as suspicious, which usually means the spam folder. With -all (hard fail), receivers may reject it outright. ~all is the safer start while you are still discovering every service that sends for you. Once DKIM and DMARC are in place, -all is a good choice, and Microsoft recommends it for Microsoft 365 domains. ?all gives no protection and +all authorises the whole internet, so avoid both.
Why does SPF have a limit of 10 DNS lookups?
Checking an SPF record can make the receiver query DNS again and again, so RFC 7208 caps the number of mechanisms that need a lookup (include, a, mx, ptr, exists and redirect) at 10 per check, counting everything inside nested includes too. Going over the limit is a permanent error and SPF fails for all your mail. This tool counts the lookups written directly in your record. It cannot see inside the included records without live DNS queries, and some of them use several lookups on their own, so leave headroom. If you run out, move a service to a subdomain or replace an include with its published IP ranges.
Can I have two SPF records?
No. A domain or subdomain must publish exactly one TXT record that starts with v=spf1. If there are two, receivers return a permanent error and SPF fails for everything, which is a common mistake after adding a new service. Merge them instead: keep one v=spf1 at the start, put all the ip4, ip6 and include terms in the middle and end with a single all.
What about DKIM?
DKIM adds a cryptographic signature to each outgoing message, and the matching public key is published in DNS under a selector, such as selector1._domainkey.example.com. The key pair is created by whoever signs your mail, so you cannot generate a useful DKIM record on your own: turn DKIM on in your provider's admin console (Google Workspace, Microsoft 365, SendGrid and others) and publish the TXT or CNAME records it gives you. DKIM matters because it survives forwarding, where SPF usually breaks, and DMARC passes if either one aligns with your From domain.
Which DMARC policy should I start with?
Start with p=none and a rua address. Nothing changes for your mail, but receivers start sending daily aggregate reports that list every server sending as your domain and whether it passed. After two to four weeks, fix SPF or DKIM for any legitimate sender that fails, then move to p=quarantine, and later to p=reject. Staying on p=none forever gives no protection: it only watches.
What changed with RFC 9989?
In May 2026 the IETF published RFC 9989, which replaces RFC 7489 as the DMARC standard, together with RFC 9990 and 9991 for reports. It removes the pct, ri and rf tags, adds t=y as a simple testing mode and np for subdomains that do not exist, and folds in the psd tag used by public suffix operators. Existing records keep working, and many receivers still honour pct, so this tool keeps pct and ri as optional legacy settings.
Why do reports sent to another domain need an extra record?
To stop anyone from pointing DMARC reports at a mailbox they do not own, receivers check that the destination agrees to receive them. If your record for example.com sends reports to reports@dmarc-service.net, that service must publish a TXT record at example.com._report._dmarc.dmarc-service.net containing v=DMARC1. Reporting services set this up for you when you add your domain, but a mailbox at a different domain you own needs it too.
Does this tool look up my domain?
No. Records are built and checked entirely in your browser, and nothing you type is sent anywhere. That also means it cannot see what is currently published or resolve nested includes. Use the DNS Lookup tool to fetch the live TXT records of your domain and of _dmarc.yourdomain, then paste them into the checker.

About SPF & DMARC Generator

The SPF builder lets you tick the services you use (Google Workspace, Microsoft 365, Zoho Mail, Amazon SES, SendGrid, Mailgun and Mailchimp Transactional, with the include values taken from each provider's own documentation), add your own IPv4 and IPv6 addresses, and choose how strict the closing all should be. It counts DNS lookups as you go, because SPF stops working above 10, and splits the value into 255-character strings when a long record needs it. The checker takes an existing record and explains every term in plain language. It flags syntax mistakes such as include= instead of include:, a space after the colon or ipv4: instead of ip4:, and it warns about a second SPF record on the same domain, the deprecated ptr mechanism, the dangerous +all, terms placed after all, and records long enough to break over UDP.

The DMARC builder follows the rollout that avoids losing mail: start with p=none and a report address, read the reports for a few weeks to find every service that sends as you, then move to quarantine and finally reject. It covers subdomain and non-existent subdomain policies, strict or relaxed alignment, failure reporting options and the testing flag from RFC 9989, the updated DMARC standard published in May 2026, with the older pct and ri tags available for receivers that still use them. Both tabs output the exact host name and TXT value with copy buttons. Everything is worked out in your browser and no DNS queries are made, so to compare with what a domain publishes today, fetch its TXT records with the DNS Lookup tool and paste them into the checker.

SPF started as a fix for bounced spam

In the early 2000s, spammers routinely forged the envelope sender of their messages, so the bounces from millions of undeliverable spams landed in the inboxes of innocent domain owners. Several proposals tried to fix this, including Reverse MX and Designated Mailers Protocol, and in 2003 Meng Weng Wong merged ideas from them into Sender Permitted From, soon renamed Sender Policy Framework. Microsoft pushed a rival called Sender ID, and the two were published side by side as experiments in 2006. SPF won: it became a proposed standard as RFC 7208 in 2014, while Sender ID and its spf2.0 records faded away.

SPF alone had a gap, because it checks the hidden envelope address rather than the From line people actually see. In 2012 a group including PayPal, Google, Microsoft and Yahoo published DMARC, which ties SPF and DKIM results to the visible From domain and adds reporting. PayPal had good reason to care: it was one of the most phished brands on the internet. DMARC spent years as an informational document, RFC 7489, before RFC 9989 finally made it a standards-track protocol in 2026.

Related tools

DNS Lookup

See the DNS records of any domain, like its IP address, mail servers and TXT records.

WHOIS Lookup

See who registered a domain, when it expires and which registrar it uses.

URL Parser

Split a web address into its parts: domain, path, query parameters and more.

UUID Generator

Create unique IDs (UUIDs), one at a time or in bulk.
Support