How SPF works
SPF (Sender Policy Framework) is a TXT record on your domain that lists the servers allowed to send email for it. When a message arrives, the receiving server looks up the SPF record of the domain in the envelope sender, also called the Return-Path or MAIL FROM, and checks whether the sending IP address is on the list.
The record starts with v=spf1, followed by mechanisms that are checked from left to right: ip4 and ip6 for specific addresses, a and mx for your own servers, and include to pull in a provider's list. It ends with an all mechanism for everything else. ~all means soft fail, so unlisted mail is usually accepted but marked as suspicious, while -all means fail. A domain must have exactly one SPF record: if you add a new service, edit the existing record rather than creating another.
The 10 DNS lookup limit
SPF has a hard limit: evaluating a record may trigger at most 10 DNS lookups. Every include, a, mx, ptr, exists and redirect counts, and so does every lookup inside the records you include. Google Workspace costs one lookup, but some providers nest several includes, so a few services can use up the budget quickly. ip4 and ip6 entries cost nothing.
If a record goes over 10, receivers return a permanent error and treat SPF as failed for all of your mail, which can push it to spam or get it rejected under DMARC. To stay under the limit, remove services you no longer use, avoid the slow and discouraged ptr mechanism, and send bulk or marketing mail from a subdomain such as news.example.com, which has its own SPF record and its own budget of 10.
How DMARC builds on SPF and DKIM
SPF on its own does not stop spoofing, because it checks the hidden envelope sender rather than the From address people see. DMARC closes that gap. A message passes DMARC when it passes SPF or DKIM and the domain that passed is aligned with the visible From domain. Relaxed alignment, the default, accepts any subdomain of the same organizational domain; strict alignment requires an exact match.
The DMARC record lives at _dmarc.yourdomain.com. Its policy, p=none, quarantine or reject, tells receivers what to do with mail that fails. The rua tag asks receivers to send daily aggregate reports, XML summaries of who sent mail as your domain and whether it passed. Those reports are how you discover forgotten senders before you enforce a strict policy.
Rolling out DMARC safely
Start with p=none and an rua address. Nothing is blocked at this stage; you simply collect reports. Review them for a few weeks, ideally with a DMARC report viewer, and make sure every legitimate service, including CRMs, help desks and invoicing tools, passes SPF or DKIM with alignment. Most providers support DKIM signing with your own domain, which is the more robust of the two.
When the reports look clean, move to p=quarantine, optionally with a lower pct value to phase it in, and then to p=reject. Large mailbox providers now expect this setup: Google and Yahoo require SPF, DKIM and a DMARC record from bulk senders, and a published DMARC policy improves deliverability for everyone else too.
