Definition
SPF is defined in RFC 7208. A domain publishes one TXT record beginning with v=spf1, followed by mechanisms that match sending sources (ip4, ip6, a, mx, include) and a final qualifier that says what to do with everything else (-all fail, ~all softfail, ?all neutral).
Why it matters
Without SPF, any server on the internet can send mail with your domain in the return path and nothing in DNS says otherwise. With SPF, receivers can identify mail from unauthorised sources. SPF alone does not stop spoofing of the visible From header; that requires DMARC alignment, which needs SPF or DKIM to pass on the right domain.
How it works
- A message arrives from IP 203.0.113.5 with an envelope sender of bounce@yourdomain.co.zm.
- The receiver fetches the TXT record on yourdomain.co.zm and finds
v=spf1 include:_spf.provider.example -all. - It expands the include, gathers the provider's IP ranges, and checks whether 203.0.113.5 is among them.
- If yes, SPF passes. If no, the
-allqualifier produces a fail, and the receiver's policy (and the domain's DMARC record) decides what happens.
Example
yourdomain.co.zm. IN TXT "v=spf1 include:_spf.provider.example -all"If you also send from a second service, add its include to the same record: "v=spf1 include:_spf.provider.example include:spf.other.example -all". Never create a second SPF record; two records cause a permanent error.
Common problems
- More than one SPF record. Invalid. Merge them into one.
- The ten-lookup limit. Includes, a, mx and redirect each cost a DNS lookup; more than ten makes the record fail permanently. Trim unused services.
- Forwarded mail fails SPF. A forwarder resends from its own IP, which is not in your record. This is expected; DKIM survives forwarding and DMARC accepts a DKIM pass.
- Using
+allor?all. Authorises everyone. Use-allonce all senders are listed,~allwhile testing. - SPF on a subdomain. Each sending subdomain needs its own record.
- Record too long. TXT strings over 255 characters must be split into quoted segments; most panels do it automatically.
How ontechmail handles it
When a domain is added, the dashboard shows the SPF record that authorises ontechmail's sending infrastructure. If DNS is hosted on ontechmail it is seeded automatically. Because ontechmail also signs every message with your domain's DKIM key, mail sent through webmail, the OMail app, the API or SMTP submission passes DMARC even when it is forwarded and SPF alone would fail. If you send from other services as well, add their includes to the same record. Sending from a domain that is not hosted on ontechmail will not be signed and should not be listed as ontechmail's responsibility in SPF.
Frequently asked questions
What is SPF?
SPF (Sender Policy Framework) is a DNS TXT record on your domain listing the mail servers permitted to send email using that domain in the envelope sender. Receiving servers check the connecting server against the list.
What does an SPF record look like?
A typical record is v=spf1 include:provider.example -all. The include names the provider's servers, and -all tells receivers to fail anything else. Only one SPF record is allowed per domain.
Why does SPF fail for forwarded mail?
Forwarding servers resend the message from their own address, which is not in the original domain's SPF list. DKIM, which survives forwarding, and DMARC alignment exist partly to cover this gap.
Does ontechmail publish SPF for me?
When you add a domain, the dashboard shows the SPF record to publish; if your DNS is hosted on ontechmail it is seeded automatically.