Guide: authentication
How to set up SPF
SPF lets a receiving server check whether the server that handed over a message is allowed to send for the domain in its envelope. One DNS record does it, and it is easy to get subtly wrong.
Last reviewed November 4, 2026
What SPF checks
Sender Policy Framework (SPF, RFC 7208) is a TXT record on your domain that lists the servers allowed to send mail for it. When a message arrives, the receiving server looks up the record for the domain in the envelope sender (the SMTP MAIL FROM, also called the Return-Path) and compares it with the IP address that connected.
SPF does not look at the From address your recipients see. That is why SPF alone does not stop someone from showing your domain in From: DMARC closes that gap by requiring the checked domain to align with the From domain.
Write one record for every sender
A domain may publish only one SPF record. Two records that both start with v=spf1 make the check fail with a permanent error, so when you add a new service, add its include to the record you already have instead of creating a second one.
A record starts with v=spf1, lists mechanisms and usually ends with an all mechanism that says what to do with everything else. The example below is illustrative: it keeps an existing provider (replace _spf.example.com with your provider's include) and adds Mail.Land.
- include:domain adds the servers another domain authorises, the usual way to add an email service.
- ip4: and ip6: list your own addresses or ranges directly.
- a and mx authorise the hosts in your domain's A or MX records.
- ~all (soft fail) marks other senders as suspicious; -all (fail) says they are not allowed. Never end with +all, which allows anyone.
v=spf1 include:_spf.example.com include:spf.mlnd.net ~allStay within the lookup limit
The include, a, mx, ptr and exists mechanisms and the redirect modifier each count toward a limit of 10 DNS-querying terms per evaluation, and the terms inside an included record count too. Beyond that limit the result is a permanent error, and receivers treat the record as broken.
Remove services you no longer use, prefer ip4 or ip6 ranges for servers you run yourself, and avoid the ptr mechanism, which the standard asks senders not to use.
Check the result
After publishing, send a message to a mailbox you control and read the Authentication-Results header: it shows spf=pass, fail, softfail, neutral, none, permerror or temperror, and the domain that was checked.
Forwarding often breaks SPF, because the forwarding server is not in your record. This is expected; DKIM usually survives forwarding that leaves the signed content unchanged, which is one reason to publish both.
What mailbox providers ask for
Google asks every sender to set up SPF or DKIM, and senders of close to 5,000 or more messages a day to personal Gmail accounts to set up SPF, DKIM and DMARC. Yahoo asks bulk senders to implement both SPF and DKIM. Publishing both is the safe default for any domain that sends.
How Mail.Land handles SPF
Add include:spf.mlnd.net to the single SPF record on your sending domain, before the all mechanism. SPF, DKIM and DMARC must all verify before the domain can send.
New domains also get a custom Return-Path: a CNAME from bounce.yourdomain to bounce.mlnd.net. Once that record verifies, the envelope domain is your own subdomain and SPF aligns with your From domain under relaxed alignment, the DMARC default; until then Mail.Land uses its default Return-Path. Keep the record DNS only (not proxied), or mail servers cannot see it.
Sources
- RFC 7208, Sender Policy Framework (SPF) (checked November 4, 2026)
- Google, Email sender guidelines (checked November 4, 2026)
- Yahoo, Sender best practices (checked November 4, 2026)
Put it into practice
Add your domain to Mail.Land and the dashboard shows the exact SPF, DKIM and DMARC records to publish.