SPF

A DNS record naming the IPs allowed to send with your domain in the SMTP envelope, checked by the receiver against the connecting server.

the DNS thing that says who can send email as meproving my server is allowed to sendsender policy frameworkspf recordspf reccordtxt record for email sendingauthorizing my mail server in dnsthe include:_spf thing my email provider gave me

See it

Live demo coming soon

What it is

SPF is a TXT record that authorizes which IPs may send mail using a given domain in the SMTP envelope, written as a list of 'include:' tokens and IP ranges ending in a verdict like '~all' (softfail) or '-all' (hard fail). The receiver takes the domain from the SMTP MAIL FROM command (or from the HELO name when MAIL FROM is empty, as it is on bounces), looks up that domain's record, compares it to the IP that just connected, and stamps pass or fail.

You need it the moment mail leaves anything other than your own mailbox: a transactional provider, a newsletter tool, a helpdesk, a billing system. Each vendor hands you an include token, and every token for one sending domain goes into one record on that domain. Two SPF records on the same name is not twice the protection, it is a permerror that fails the whole check. There is no global record either: a separate sending subdomain is a separate evaluation, so it publishes its own record naming only the vendors that send from it.

Two traps. SPF says nothing about the From line your recipients read. It only authorizes IPs for the envelope identity, so on its own it stops nobody from spoofing your brand; DMARC alignment is the piece that ties an SPF pass back to the visible From domain. And SPF allows only 10 DNS lookups per evaluation, so five chatty vendors can quietly blow the budget and turn every send into a permerror.

Ask AI for it

Below I am pasting the exact MAIL FROM domains we send with and the SPF mechanisms each provider documents. For each domain separately, merge only the mechanisms that belong on that domain into a single 'v=spf1' record, and say which host name each record is published on. Then calculate the worst-case DNS lookup count per record. If a record goes over 10, identify the provider responsible for the overage and lay out the options (moving that stream to its own sending subdomain, a narrower mechanism the provider offers, or flattening with a stated refresh plan). Do not drop a legitimate sender, and do not flatten includes into raw IPs unless I have agreed to an explicit maintenance plan for the churn. Finish with the DNS entry to paste for each record (host, type, TTL, value) and a one-command 'dig' check per record.

You might have meant

dkimdmarcdmarc identifier alignmentcustom mail from domainenvelope vs header from

Go deeper