SPF & DMARC Record Generator

What the SPF & DMARC Record Generator does

SPF and DMARC are DNS TXT records that protect your domain from forged email. SPF (Sender Policy Framework) lists the servers and services allowed to send mail for the domain. DMARC builds on SPF and DKIM: it tells receiving servers what to do with mail that fails those checks (none, quarantine or reject) and where to send reports about it.

This generator builds both records. For SPF, you pick the services that send as you from a list of common providers, which adds their include: mechanisms, and see how the record stands against the limit of 10 DNS lookups. For DMARC, you choose the policy and the address that should receive aggregate reports, and get the record to publish at _dmarc on your domain.

Why it matters

Without SPF and DMARC, anyone can send mail that appears to come from your domain, which is how much phishing and invoice fraud reaches customers and colleagues. Gmail and Yahoo require bulk senders to authenticate their mail, including a DMARC record, and unauthenticated mail is more likely to be filtered or rejected by any provider.

SPF is easy to get subtly wrong. Each include, a, mx, exists and redirect costs a DNS lookup, includes can contain further includes, and past 10 lookups the record fails with a permanent error. Publishing a second SPF record instead of merging into one has the same effect. See our guide to email authentication.

How to fix common problems

Add the SPF value as a TXT record on the domain itself (the @ or root name in most DNS panels). Keep exactly one record that starts with v=spf1; if one already exists, merge the new includes into it instead of adding another. Add the DMARC value as a TXT record on the name _dmarc, for example _dmarc.example.com.

Set up DKIM signing in each sending service as well. DMARC passes when SPF or DKIM passes and aligns with the From domain, and DKIM survives forwarding where SPF often does not. Start DMARC with p=none and read the aggregate reports for a few weeks; when every legitimate sender passes, move to p=quarantine and then p=reject. A domain that sends no mail at all can publish v=spf1 -all and p=reject straight away.

DNS changes can take up to the TTL of the old record to be seen everywhere. Then run the Email Security Checker (SPF, DKIM, DMARC) to confirm both records parse, count the SPF lookups and see your DKIM and MTA-STS status. Our MTA-STS and TLS-RPT guide covers the next step.

Questions

Should SPF end with -all or ~all?

-all marks mail from unlisted servers as a hard fail; ~all marks it as a soft fail that receivers usually accept but treat as suspicious. Start with ~all while you confirm every sender is listed, then consider -all. Once DMARC enforces a policy, receivers act mainly on the DMARC result.

What if my SPF record needs more than 10 lookups?

Remove services you no longer use, replace an include with the provider's published ip4: or ip6: ranges if you can keep them current, or move a sender such as a newsletter tool to a subdomain with its own SPF record.

Where do DMARC reports go?

Aggregate reports arrive as XML files, usually once a day per receiver, at the rua address. They are hard to read raw, so many teams use a DMARC reporting service. If the address is on another domain, that domain must publish a record authorizing it to receive your reports.

Does this create DKIM records?

No. DKIM keys are generated by each sending service, which gives you the record to publish under its own selector.