Sender Policy Framework (SPF) is one of the three records that prove mail claiming to be from your domain really is. Here is what an SPF record does, how to read one, and the part that surprises people: sending through Bird does not need an apex SPF record at all.
What is SPF?
SPF is a form of email authentication that lets a domain owner declare which mail servers may send on that domain's behalf. It was introduced as a supplement to SMTP, which by itself offers no authentication, and it exists to make spoofing and forgery harder. Configuring authentication properly also helps your deliverability, since receivers treat authenticated mail more favourably.
What is an SPF record?
An SPF record is a specially formatted DNS TXT record published on the sending domain. It looks something like this:
example.com TXT "v=spf1 include:mailprovider.example ~all"Reading it left to right: v=spf1 says that mail claiming to be from example.com should be validated with SPF. Each include: names another domain whose own SPF record should be consulted, which is how you authorize a provider to send on your behalf. And ~all says that any other server claiming to send for the domain should be treated as questionable, a soft fail.
One limit is worth knowing before you add anything. RFC 7208, the SPF standard, caps the DNS-querying terms at ten:
The following terms cause DNS queries: the "include", "a", "mx", "ptr", and "exists" mechanisms, and the "redirect" modifier. SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return "permerror".
So the eleventh term does not simply get ignored: it makes SPF evaluation fail for every sender on that record. all, ip4 and ip6 cost nothing against the limit, because they query nothing.
How does SPF work with Bird?
This is where the usual advice does not apply, so it is worth being precise.
You do not need to publish an SPF record at your apex to send through us, and the dashboard does not ask for one. SPF is evaluated against the envelope-from domain rather than the visible From address. Your envelope-from is the return-path hostname, and the return-path CNAME you publish when you verify a sending domain points it at our bounce infrastructure, which already carries SPF authorization. SPF passes, and it aligns with your domain because the return-path is a subdomain of it.
The corollary matters more than the rule: adding an include: entry at your apex does not authorize mail sent through us. It spends one of your ten lookups and authorizes nothing, and on a record that already carries several senders it is the kind of addition that tips the total past ten and breaks SPF for all of them. If you already have an apex SPF record for other senders, leave it exactly as it is.
DKIM, SPF & DMARC has the full record set with the exact shapes, and Where's SPF? is the section on this specifically. If an existing record has grown long enough to need splitting across strings, the DNS record splitter does that part.
What should I publish instead?
For sending through Bird, publish the records that gate sending: DKIM, the return-path CNAME, and DMARC. Sending domains walks through adding and verifying a domain.
SPF alone was never enough anyway. A complete approach is SPF, DKIM and DMARC together, and SPF vs DKIM vs DMARC covers what each one proves and why all three exist.