SPF & DMARC Generator

SPF (Sender Policy Framework) is a DNS TXT record on your domain that lists which servers are allowed to send email claiming to be from you. Receiving servers look it up during delivery: if mail arrives from an IP the record doesn't authorise, the receiver can mark it as spam or reject it. It's one of the three pillars of email authentication, together with DKIM and DMARC.

Evaluating an SPF record may trigger at most 10 DNS lookups — every include, a, mx, exists and redirect counts, including the ones nested inside your providers' includes (Google's alone costs 4). Go over the limit and receivers return permerror, which many treat as "no SPF at all". This is the most common way SPF silently breaks; the generator counts lookups as you add providers and warns you near the limit.

-all (fail) tells receivers to reject unauthorised mail outright; ~all (softfail) suggests marking it suspicious instead. Start with ~all while you're still discovering which services send on your behalf, then move to -all once DMARC reports confirm nothing legitimate is failing. ?all (neutral) is effectively no protection — avoid it.

No — a domain must publish exactly one TXT record starting with v=spf1. Two SPF records cause a permanent error and receivers ignore both. If you add a second sending service, merge its include into your existing record instead of creating a new one.

DMARC builds on SPF and DKIM: it tells receivers what to do with mail that fails authentication (none / quarantine / reject) and where to send aggregate reports about who is sending as your domain. p=none is monitoring mode — nothing is blocked, but you receive reports. The standard rollout is p=none → review reports for a few weeks → p=quarantine (often with pct=10 first) → p=reject.

rua=mailto:… receives daily aggregate XML reports from receivers (Google, Microsoft, Yahoo…) summarising which IPs sent mail for your domain and whether SPF/DKIM passed. Raw XML is unpleasant to read at scale — most teams point rua at a report-processing service, but even manually skimming a week of reports quickly reveals forgotten senders and spoofing attempts.

A forwarder resends your message from its own servers, which aren't in your SPF record — so SPF fails at the final destination. This is by design and is exactly why DKIM matters: the cryptographic signature survives forwarding. DMARC passes if either SPF or DKIM passes with alignment, so a correct setup keeps forwarded mail deliverable.

No — DKIM keys are generated by your sending provider (Google Workspace, SES, SendGrid…), because the private key lives on their servers. Each provider's dashboard gives you the exact CNAME or TXT records to publish. Once SPF, DKIM and DMARC are all in place, verify the whole setup with our email health checker.