SPF
SPF is a DNS TXT record on your domain listing the hosts permitted to send mail using it as the envelope sender. A receiving server checks the connecting address against that list and gets a pass, a fail or a softer verdict. It authorises a route, not a person, and it says nothing about the From: line a reader sees.
The record, mechanism by mechanism#
example.net. TXT "v=spf1 include:_spf.provider.example a:mail.example.net ip4:203.0.113.10 -all"v=spf1- Version marker. Must be first. A domain must publish at most one SPF record; two is a permanent error, not a merge.
include:- Import another domain's policy. The usual way a provider is authorised, and the usual cause of the lookup-limit problem below.
a/mx- Authorise the addresses of the domain's own A or MX records. Convenient and each costs a lookup.
ip4:/ip6:- Literal addresses or ranges. Cost no lookups, which makes them the fix when you are close to the limit.
-all- Hard fail: nothing else is authorised. The intended end state.
~all- Soft fail: not authorised, treat as suspicious. Reasonable while rolling out; not a destination.
?all/+all- Neutral and pass-everything.
+allauthorises the entire internet and should never be published.
Mechanisms are evaluated left to right and the first match wins, so ordering matters: an include that matches early stops evaluation before anything after it is considered.
The ten-lookup limit, and how domains exceed it#
Evaluating a record may perform at most ten DNS-querying mechanisms. include, a, mx, ptr, exists and redirect each count, and they count recursively — an include that itself contains three includes has spent four. Exceeding the limit is a permerror, and a permerror is not a fail-open: many receivers treat it as no valid policy at all.
| Mechanism | Lookups | Note |
|---|---|---|
ip4: / ip6: | 0 | Free. The lever when you are over budget |
a / mx | 1 each | Plus one more per MX host resolved |
include: | 1 plus whatever that record spends | The recursive cost is invisible in your own record |
exists: | 1 | Rare outside macro-based setups |
ptr | 1, and deprecated | Slow and unreliable; remove it |
redirect= | 1, and replaces the rest | Only takes effect if no mechanism matched |
What SPF cannot prove#
- It does not authenticate the visible sender. SPF checks the envelope sender. A message can pass SPF for
bounces.attacker.examplewhile displayingFrom: Acme Traders— which is why DMARC requires alignment between the authenticated domain and the header. - It breaks on forwarding. A forwarder relays the message from its own address without changing the envelope sender, so the check fails at the final destination through no fault of anyone. SRS rewriting exists to address this and is not universal.
- It says nothing about content. An authorised host sending unpleasant mail passes.
- It does not survive a mailing list. Lists commonly rewrite the envelope, and some rewrite the header too, precisely because of the two points above.
- A pass is not a reputation. Authentication and trust are different questions; SPF answers the first only.
This is the reason the three-record set exists. SPF authorises the route, DKIM signs the message so it survives being relayed, and DMARC requires that one of them aligns with the domain the reader actually sees.
Does Connect use SPF, and who configures it?#
Educational, and a customer responsibility. SPF, DKIM and DMARC are records published in DNS for the domain that mail is sent from. That domain belongs to the business, not to Connect, so Connect does not set them and cannot set them for you. Anyone telling you a mail tool has configured your SPF has described something that is not possible without control of your DNS.
What Connect does is send through the mailbox you connected — Gmail, Microsoft Graph, or your own SMTP server. The sending infrastructure is therefore your existing provider's, and the SPF record you already publish for that provider is the one that applies. Connecting a mailbox to Connect does not introduce a new sending host and does not require a new include.
The practical consequence is a short checklist for the business rather than for Connect: confirm the domain publishes exactly one SPF record, confirm it authorises the provider your mailbox actually uses, confirm the lookup count is under ten, and confirm it ends in -all once you are confident the list is complete.
Questions#
Can a domain publish two SPF records?
No. More than one v=spf1 TXT record on the same name is a permanent error, and receivers do not merge them — the policy is treated as broken. When two tools each want to be authorised, the mechanisms go into one record.
Why does mail fail SPF only after being forwarded?
Because the forwarder relays from its own address while leaving the envelope sender as yours, so the final receiver checks an address your record does not authorise. Nothing is misconfigured; the protocol simply does not survive a relay. DKIM does, which is why the pair is stronger than either.
Does Connect need to be added to our SPF record?
Not for mail sent through a mailbox you connected, because that mail leaves through your existing provider's infrastructure and your record already covers it. If your provider's own documentation asks for a particular include, that is the record to follow — it is a fact about your mail provider, not about Connect.