What Is an SPF Record? How to Create One

A SPF record is a DNS TXT record that lists which servers may send mail for your domain. It helps reduce spoofed messages and can improve inbox placement for legitimate mail.

A lot of people run into SPF only after something breaks. Maybe a customer forwards you a fake invoice that looks like it came from your business, or your own mail starts landing in spam after you add a new sending tool. That's when SPF becomes more than a technical acronym, it becomes part of your email setup.

What Is an SPF Record

A small business owner often notices SPF only after a problem is already visible. A fake billing email goes out under the company domain, customers ask whether the invoice is real, and the domain starts to carry the wrong kind of attention. SPF exists to lower that risk by giving receiving mail servers a published list of authorised senders.

An SPF record, short for Sender Policy Framework, is a DNS-based email authentication standard that tells receiving mail servers which hosts are allowed to send mail for a domain. It is usually published as a TXT record that begins with v=spf1. That line acts like a roster for outbound mail, so receiving systems can check whether a sender belongs on the list.

Why it matters for normal senders

SPF does not stop every kind of phishing, but it does help receiving servers decide whether the sending IP has permission to use your domain. That matters when you send through a website host, an office mail server, or a third-party email service. If the sender is not on the list, the receiver can treat the message as suspicious or send it to spam.

Many Canadian businesses run into confusion about the gap between what people see and what mail servers check. The visible From header may say one thing, while the SMTP envelope sender, often called MAIL FROM, tells the receiving server which domain is being used for the delivery check. SPF looks at that envelope identity, so a message can still look legitimate in the inbox while failing the server-side check behind the scenes. That is why SPF sometimes feels confusing in day-to-day operations, especially when different tools send on behalf of the same domain.

For Canadian email operators and businesses, that matters because SPF is one of the basic controls used to reduce spoofing and support deliverability when sending mail under a domain. Adoption is substantial but incomplete, too. SPF adoption remains uneven across the internet. Larger organizations and domains are more likely to implement SPF correctly than smaller ones, which reflects both the resources available for email security setup and the sophistication level of different organizations.

Practical rule: if your business sends email from more than one system, SPF should be treated as a living DNS record, not a one-time checkbox.

The rest of the guide stays focused on the everyday problem, not the jargon. It explains how SPF checks a sender, what the syntax means, and why many records look fine at a glance but still fail in real use.

How SPF Stops Spoofing

A fake sender can still look convincing in the inbox. SPF is the DNS check that asks a narrower question at delivery time, whether the server sending the message is allowed to send mail for the domain in the envelope sender, also called the SMTP MAIL FROM identity. The receiving server checks that identity before it fully accepts the message.

The part SPF checks

SPF validates the SMTP envelope sender, not the visible From header people read in their inbox. That distinction matters because the mail system can verify one identity while the user sees another. The visible sender line is the name on the letter, while the envelope sender is the return address the postal service checks before delivery.

The receiving server looks up the domain's SPF TXT record in DNS, compares the sending IP against that policy, and then returns a result. Common outcomes include pass, fail, and softfail. If the IP is listed, the message clears this check. If it is not listed, the receiver can mark it as suspicious or reject it, depending on the policy and the mail system's handling rules.

Why that gap causes confusion

The gap between MAIL FROM and the visible From header is why SPF can stop one kind of abuse and still leave other problems in place. A message can leave an authorised server and still show a misleading display name, so the mailbox looks familiar even though the identity behind it is not. SPF does not solve that by itself.

Google describes SPF as a record that helps receiving servers verify which hosts may send mail for a domain, and Cloudflare describes it as authorising sending servers rather than proving the message end to end (Google, Cloudflare).

SPF answers a narrow question, “Was this server allowed to send for this domain?”

That narrow check still helps. If your helpdesk platform, CRM, or newsletter service sends from your domain, SPF gives receivers a way to confirm that those systems were authorised. If a random server tries the same thing, the receiver has a reason to distrust it.

For Canadian small businesses, that often shows up as a practical headache. One team sends invoices from accounting software, another sends receipts from the shop platform, and a third sends marketing mail through a separate service. If those systems are not all covered in the SPF record, messages may fail even though the business meant to send them. The problem is not usually the idea of SPF. It is the mismatch between the actual tools sending mail and the DNS record that is supposed to list them.

Analysts at Korczyński et al. found that SPF adoption is widespread but still uneven, which fits the day-to-day experience of businesses that have to keep records aligned with many sending services (Korczyński et al.).

SPF Record Syntax Explained

SPF syntax looks cryptic until you break it into small pieces. The record starts with v=spf1, which tells receivers they are reading an SPF record, then it lists mechanisms that describe who may send. You finish with a qualifier that tells the receiver how strict to be about anything not covered.

The basic pieces

A record often uses mechanisms such as ip4, ip6, include, a, mx, exists, and all. In plain English, those are different ways of saying “this sender is allowed” or “this sender is not allowed.” A long SPF chain usually becomes a list of trusted services, then a closing rule.

Two useful examples

A simple single-sender record might look like this in concept, v=spf1 ip4:... -all. That says one specific mail server is allowed, and everything else should fail. A business that sends through one hosted mail provider and one newsletter service might use v=spf1 include:provider-one include:provider-two ~all while testing, then tighten the ending later.

Rule of thumb: the record should read like a permissions list, not a paragraph.

An SPF record is not free-form text. It has a fixed structure, and the receiver evaluates it exactly as written. That is why tiny syntax mistakes can break legitimate mail, even when the record looks reasonable to a human eye.

How to Create Your SPF Record

A good SPF record starts with one clear question, which systems are allowed to send mail for this domain? Answer that first, then write the DNS policy to match. If one platform sends all of your mail, publish a single SPF TXT record in the domain's authoritative DNS zone and keep it tight. If another service joins later, update that same record instead of creating a second one.

Start with one sender

For a basic setup, the shape is straightforward, v=spf1 plus the mechanism that authorises your mail server or provider, then an ending rule like ~all or -all. If you use a hosted email platform, the provider usually gives you the part to include. If you send from your own server, authorise the server IP directly.

A small business often runs into trouble here because the visible From address and the underlying MAIL FROM path are not the same thing. A customer sees one brand name in the inbox, while the receiving server checks a different envelope sender behind the scenes. SPF only speaks for that envelope path, so the record has to match the system that hands off the message.

Add one more service carefully

If you add a newsletter tool, the usual move is to include that provider's SPF policy inside the same record. That is a normal edit, not a new record. Keep the SPF TXT record in one place and revise it as your sending tools change.

A practical example for a Canadian small business is a domain that sends everyday mail through one provider and campaigns through another. In that case, list both authorised sources in the same TXT record, then finish with a strict or testing qualifier depending on whether you are still validating the setup. If you are still arranging your domain email setup, the steps in how to set up a custom email domain help show where SPF fits in the larger DNS picture.

The record belongs in the authoritative DNS zone for the domain, not in a subdomain that the receiver never checks. SPF only works when the published policy sits where receivers expect to find it. If the record is placed in the wrong zone, the receiving server may never see the permissions you meant to publish.

Verify before you trust it

After you publish the record, test it with a DNS lookup tool or an SPF checker. Confirm that the domain returns one valid SPF TXT record and that the policy matches the mail systems you use. If the lookup shows something unexpected, fix it before a campaign or invoice run goes out.

Double-checking matters because SPF failures often come from a record that looks right at a glance but does not match the sending path. A receiver does not guess what you meant, it follows the published DNS record exactly. If the setup still feels unclear, review the sender list again and trace each service back to the domain that sends its mail.

The safest SPF record is the one you can explain without guessing.

Common SPF Mistakes and the 10-Lookup Limit

A Canadian small business can get SPF right on paper and still break mail delivery in practice. The usual pattern is simple. A company starts with one mailbox provider, then adds a CRM, a helpdesk, payroll, and a newsletter tool. Each service sends mail from a different place, while recipients still see the same brand in the visible From line. SPF only checks the envelope sender, so the gap between MAIL FROM and the From header is where confusion starts, especially when the people managing DNS are not the same people running email campaigns.

The lookup limit is the main trap

SPF stops after 10 DNS-mechanism lookups and 2 void lookups, because each include, a, mx, exists, or redirect can trigger more DNS queries and add failure risk (AutoSPF). The limit is not there to annoy you. It keeps receivers from chasing an endless chain of DNS checks every time a message arrives. If your record depends on too many nested services, a legitimate sender can fail because the path is too long.

A record can look tidy and still be too expensive to evaluate. One vendor include may hide several more includes inside its own policy, and a few added services can push a small business over the edge without anyone noticing. That is why a setup that works for one sender often starts failing after a few new tools are added.

Common mistakes that break a record

A domain should publish only one SPF record. If you publish two, receivers can treat the result as invalid. RFC 7208 also says the policy belongs in a single TXT record, so splitting it across multiple records creates confusion instead of protection (RFC 7208).

Ending a record with +all is another mistake. It tells receivers to accept every sender, which removes the protection SPF was meant to provide. A softfail ending like ~all can help while you are testing, but it should not stay there forever if you already know which services are allowed to send. For a plain-language refresher on how SPF fits into the wider authentication stack, this DMARC overview helps connect the dots without turning the setup into a guessing game.

What to check before you publish

Start by listing every service that sends mail for the domain, then count how each one is added. If a provider uses nested includes, follow the chain instead of assuming one line equals one lookup. That small habit catches the records that look fine during a quick review but fail once a receiver starts resolving them in real time.

A simple checker can show whether you are close to the limit or whether a record is malformed. If the count is too high, remove unused senders, flatten nested includes where you can, or move stable infrastructure to direct IP authorization when that makes sense. The goal is not a clever record, it is a record you can explain and maintain without guessing.

SPF, DKIM, and DMARC Working Together

A domain can publish SPF correctly and still end up with mail that looks suspicious to a receiver. The reason is the gap between the envelope sender, often called MAIL FROM, and the visible From header that people see in their inbox. SPF checks whether the server sending the message is allowed to use that envelope domain, while the display name in the inbox can still point somewhere else. That gap is often what Canadian small businesses run into when one service sends receipts, another sends newsletters, and a third handles support replies.

DKIM closes part of that gap by signing the message itself with a cryptographic signature. DMARC then checks whether SPF or DKIM lines up with the visible From domain, so the brand the recipient sees matches the authenticated identity. That is why SPF by itself can look fine on paper but still leave a message exposed to filtering or rejection.

Why alignment matters

Alignment means the domain in the visible From header lines up with the domain used by SPF or DKIM. If those domains do not line up, a message can still fail DMARC even when SPF passes. That is the part many beginner explanations skip, and it is why a sender can feel like everything is configured correctly while inbox providers still treat the mail cautiously.

The practical point is simple. SPF answers whether a server was allowed to send for the envelope domain. DMARC asks whether that authenticated domain matches the brand name in the inbox. For a business that sends through a payment processor, a help desk, and a marketing platform, those can be three different domains unless they are configured with care.

A sane order for setup

Start with SPF and publish the sender list you use. Then make sure DKIM signs mail from the same domain family, so the message has a second layer of identity that does not depend only on the envelope path. After that, add DMARC so receivers can evaluate the result instead of guessing whether the message is legitimate.

If you want a practical companion guide, our real-world email authentication setup guide walks through DMARC in the context of a working mail stack. The big picture stays straightforward, SPF answers who may send, DKIM answers whether the message was signed, and DMARC tells receivers how to judge the combination.

Putting It All Together

Check whether your domain already has one SPF record, and make sure it matches the services you send through. Then count the DNS lookups in that record with a free checker, because that is where many valid-looking records break. If DKIM and DMARC are missing, add them after SPF so the visible From domain lines up with the authenticated sender.

If you want a simple reference path, our email authentication setup guide covers the next pieces in a practical order. That is the fastest way to move from “I think SPF is set up” to “I know my mail is authenticated.”

We built Typewire around that same practical idea, custom domains should work without guesswork, and deliverability should not depend on trial and error. If you want a private email service with custom-domain support and a setup flow that treats SPF as part of the job, visit Typewire and see how we handle it in practice.