# Introduction to SPF Records > If you're involved in managing email deliverability for your tech company, you may have come across the term 'SPF record.' An SPF record, which stands for… ## What is an SPF record? An [SPF record](/tools/spf) (Sender Policy Framework) is a DNS entry that lists which mail servers are allowed to send email for your domain. It's a core piece of [email authentication](/resources-post/what-are-dmarc-dkim-and-spf) that helps prevent [email spoofing](/resources-post/protect-your-business-how-to-stop-email-spoofing-and-secure-your-brand-reputation) and unauthorized use of your domain name. When a receiving server gets a message that claims to come from you, it looks up your SPF record and checks whether the sending server is on your approved list. SPF is defined in [RFC 7208](https://datatracker.ietf.org/doc/html/rfc7208). One important detail: SPF checks the domain in the envelope's `MAIL FROM` (also called the Return-Path), not the visible `From:` address a recipient sees. That gap is exactly why SPF alone isn't enough, and why [DMARC](/learning/what-is-dmarc) adds alignment on top of it. ![Introduction to SPF Records](/images/generated/introduction-to-spf-records-what-is-an-spf-record-and-why-does-it-matter.webp) ### Why are SPF records important? Email is central to how businesses communicate, and attackers know it. Spam and phishing campaigns routinely forge sender addresses to trick recipients. An SPF record gives receiving servers a reliable way to tell your legitimate mail from a forgery, which protects your domain's reputation and improves the deliverability of the messages you actually send. ## How SPF works SPF lets a domain owner publish a list of authorized sending sources as a single [TXT record](/learning/what-is-a-txt-record) in DNS. The record uses a small syntax of **mechanisms** (which sources to authorize) and **qualifiers** (what to do when a source matches). A receiving server reads the record, evaluates it against the connecting IP address, and returns a result such as `pass`, `fail`, or `permerror`. A domain must have **exactly one** SPF TXT record. If two SPF records exist, compliant receivers return a `permerror` and the check fails, so multiple sources always have to be merged into one record. ### SPF record structure and syntax A typical SPF record looks like this: `v=spf1 include:_spf.google.com ip4:203.0.113.0/24 ~all` It always starts with `v=spf1`, followed by one or more mechanisms, and ends with an `all` mechanism that sets the default policy. For a full walkthrough of the syntax, see [what is SPF](/learning/what-is-spf). ## Creating an SPF record Publishing an SPF record for your domain is a straightforward process. Follow these steps to get started. ![Six-step flow for creating an SPF record, from identifying authorized servers to saving the DNS change.](/images/figures/introduction-to-spf-records-what-is-an-spf-record-and-wh-fig1.webp) *The six steps to publish an SPF record for your domain.* - Identify the authorized email servers and services that send mail for your domain. - Choose the SPF mechanisms and qualifiers that match your sending practices. - Open the DNS management interface for your domain. - Create a new TXT record with your domain name in the "Host" or "Name" field. - In the "Value" or "Text" field, enter your SPF record following the correct syntax. - Save the change and allow time for DNS to propagate. If you'd rather not hand-build the record, the [SPF generator](/tools/spf-generator) assembles a valid record from your sending sources. ### Choosing the right SPF mechanisms Pick the mechanisms that map to your actual email infrastructure. The commonly used ones are: - **ip4**: authorizes specific IPv4 addresses or ranges. - **ip6**: authorizes specific IPv6 addresses or ranges. - **a**: authorizes the IP address(es) in the domain's A record. - **mx**: authorizes the IP address(es) of the domain's [MX record](/tools/mx). - **include**: pulls in the SPF record of another domain, such as a mail provider. - **all**: sets the default action for any source that didn't match. Each mechanism carries a **qualifier** that decides the outcome when it matches: `+` (pass, the default), `~` (softfail), `-` (fail), or `?` (neutral). The qualifier on `all` is the one that matters most — see the FAQ below on `~all` vs `-all`. ### Common mistakes to avoid - **Overly restrictive records**: leaving out a legitimate sender means valid mail gets rejected. - **Incorrect syntax**: a typo anywhere in the record can cause a `permerror`. - **Omitting the `all` mechanism**: always end the record with an `all` qualifier so unmatched sources have a defined policy. - **Too many DNS lookups**: SPF allows a maximum of **10** DNS-querying mechanisms during evaluation (see the FAQ on `permerror`). ## SPF best practices To keep your SPF record effective, apply these deployment practices. ![Checklist of four best practices for deploying an SPF record.](/images/figures/introduction-to-spf-records-what-is-an-spf-record-and-wh-fig2.webp) *Deployment practices that keep your SPF record effective.* - **Keep it current**: as your email infrastructure changes, update the record to add new senders and drop decommissioned ones. Monitor your delivery logs and run periodic audits to catch drift. - **Watch the lookup count**: the `include`, `a`, `mx`, `ptr`, `exists`, and `redirect` terms each count toward the 10-lookup limit; `ip4`, `ip6`, and `all` do not. If you're near the limit, consider SPF flattening to collapse nested includes into direct IP ranges. - **Use CIDR notation**: specify IP ranges (for example `ip4:203.0.113.0/24`) instead of listing addresses one by one. - **Choose the right `all` policy**: end with `-all` for a strict "hard fail" that rejects unauthorized sources, or `~all` (soft fail) while you're still confirming every legitimate sender. ### SPF, DKIM, and DMARC together SPF is one leg of a three-part authentication stack. [DKIM](/learning/what-is-dkim) adds a cryptographic signature that proves the message wasn't altered in transit, and DMARC ties SPF and DKIM results to the visible `From:` domain and tells receivers what to do on failure. Aligning all three is what actually stops domain spoofing — see [what are DMARC, DKIM, and SPF](/resources-post/what-are-dmarc-dkim-and-spf) for how they fit together. ## Troubleshooting SPF issues When SPF fails, the cause is usually one of a handful of issues: - **No SPF record**: without one, receivers have no way to confirm your authorized senders. - **Syntax errors**: a malformed record produces a `permerror`. Validate it with the [SPF checker](/tools/spf). - **Overly restrictive policy**: a record that omits a legitimate sender rejects real mail. - **Too many DNS lookups**: exceeding 10 lookups returns a `permerror` and, under DMARC, is treated as a fail. - **Propagation delay**: DNS changes take time to spread; allow a few hours before assuming an edit didn't work. To diagnose a problem, inspect the `Authentication-Results` and `Received-SPF` headers of a failing message to see whether SPF passed, softfailed, or errored, then confirm the sending IP is actually covered by your record. A [DNS lookup tool](/tools/dns-lookup) helps you see exactly what receivers are resolving. ## SPF and email deliverability A correctly published SPF record improves deliverability in three ways: it reduces spoofing by blocking unauthorized senders, it builds a trustworthy sending reputation with receivers, and it helps mailbox providers separate your legitimate mail from spam. Combined with DKIM and DMARC, it forms the authentication baseline that Gmail, Yahoo, and Microsoft now expect from bulk senders. ## SPF and related standards Several RFCs govern this stack: - **RFC 7208**: defines the SPF protocol, its syntax, and its evaluation rules. - **RFC 6376**: defines DKIM, the cryptographic-signature partner to SPF. - **RFC 7489**: introduced DMARC, which builds on SPF and DKIM (later revised by the DMARCbis standards). Note that Sender ID, an older SPF-like protocol, is effectively deprecated and no longer worth deploying. ## Conclusion SPF records are a foundational part of email authentication. A single, well-maintained SPF TXT record tells receivers exactly which servers may send for your domain, which improves deliverability and cuts off the easiest forms of spoofing. Pair it with DKIM and DMARC, keep the lookup count under 10, and review the record whenever your sending infrastructure changes. Want to see where your domain stands? Check your record with the [SPF lookup tool](/tools/spf), or get a full picture across SPF, DKIM, and DMARC with the [Email Security Score](/tools/email-security-score). ## Frequently asked questions ### Can I have two SPF records? No. A domain must publish exactly one SPF TXT record. If a receiver finds more than one `v=spf1` record for the same domain, RFC 7208 requires it to return a `permerror`, which fails the check for all of your mail. When you add a new sending service, merge its `include` into your existing record rather than creating a second one. ### Why does my SPF fail after 10 lookups? SPF caps the number of DNS-querying terms at 10 per evaluation. The `include`, `a`, `mx`, `ptr`, `exists`, and `redirect` terms each count against that limit; `ip4`, `ip6`, and `all` do not. Exceed 10 and the receiver returns a `permerror`, which DMARC treats as a failure. Flattening nested includes into direct IP ranges is the usual fix — see [fixing SPF alignment for DMARC](/resources-post/fixing-spf-alignment-dmarc----full-guide). ### Does SPF survive email forwarding? Often not. When a message is forwarded, the forwarding server usually becomes the new sender, so the original SPF check breaks even though the mail is legitimate. This is a key reason SPF isn't sufficient on its own: a DKIM signature travels with the message and typically survives forwarding, and DMARC only needs one of SPF or DKIM to pass and align. ### What's the difference between `~all` and `-all`? Both set the default policy for sources not otherwise authorized. `-all` is a "hard fail" that tells receivers to reject unauthorized mail outright. `~all` is a "soft fail" that flags the mail as suspicious but usually still delivers it. Use `~all` while you're confirming every legitimate sender, then move to `-all` once you're confident your record is complete. ### Does SPF check the visible "From" address? No. SPF validates the domain in the envelope `MAIL FROM` (the Return-Path), not the `From:` header a recipient actually sees. An attacker can pass SPF for a domain they control while still forging your visible `From:`. Closing that gap is the job of [DMARC alignment](/learning/what-is-dmarc). ## Related reading - [What are DMARC, DKIM, and SPF?](/resources-post/what-are-dmarc-dkim-and-spf) - [How to create an SPF record: a step-by-step guide](/resources-post/how-to-create-an-spf-record-a-step-by-step-guide-for-better-email-authentication) - [Fixing SPF alignment for DMARC](/resources-post/fixing-spf-alignment-dmarc----full-guide)