SPF Lookup & Generator
Look up existing SPF records for any domain or build a new v=spf1 TXT record with the interactive generator
include: entries for email services (ESP, CRM, etc.)Add this as a TXT record on your domain's DNS with the host/name set to @ (or leave blank):
Frequently Asked Questions
v=spf1. When a receiving mail server gets an email, it checks the SPF record to verify the sending server is authorized. This reduces email spoofing and improves deliverability.~all (SoftFail) means emails from unlisted servers are accepted but marked as suspicious. -all (HardFail) instructs receivers to reject emails from any server not listed in the SPF record. Start with ~all while setting up to avoid blocking legitimate email, then switch to -all once you're confident all senders are listed. Always pair SPF with DMARC for full protection.include:, a, mx, and ptr mechanism counts as one lookup (and included records may themselves contain additional lookups). Exceeding 10 lookups causes an SPF PermError, which many servers treat as a fail. Use ip4: and ip6: mechanisms directly (they don't count as lookups) to stay within the limit.p=none, p=quarantine, p=reject). This triple combination is required by Google and Yahoo for bulk senders since 2024.From address, making it appear to come from you. SPF prevents this by letting receiving mail servers verify that the email originated from a server listed in your domain's SPF record. If an email from @yourdomain.com arrives from an IP not listed in your SPF, the receiver can reject or flag it. However, SPF alone is not sufficient — it only checks the envelope sender (MAIL FROM), not the visible From header. DMARC is needed to enforce alignment between the SPF-authenticated domain and the visible From header, closing the spoofing gap.
~all) — the email is accepted but tagged as potentially suspicious; most servers deliver it to the spam folder. HardFail (-all) — the email should be rejected outright, though many servers still deliver it with a spam flag. DMARC adds a definitive enforcement layer: if SPF fails and DMARC policy is p=reject, the message is rejected by major providers regardless of SPF qualifier. Without DMARC, SPF failures are handled inconsistently across different mail servers.
SPF — Verifies the sending server's IP address is authorized to send on behalf of the domain. Checked against the envelope MAIL FROM address. Does not survive email forwarding (the forwarding server's IP won't be in your SPF).
DKIM — Adds a cryptographic signature to the email using a private key; verified via a public key in DNS. Proves message integrity and survives forwarding.
DMARC — Ties SPF and DKIM together, requires at least one to pass and align with the visible From header, then specifies what to do on failure (none/quarantine/reject) and provides aggregate reports.
include: mechanism to add third-party email services to your SPF record. Each service provides their own SPF include domain — add it to your TXT record. Common examples:include:_spf.google.com — Google Workspaceinclude:spf.protection.outlook.com — Microsoft 365include:sendgrid.net — SendGridinclude:servers.mcsv.net — Mailchimpinclude:amazonses.com — Amazon SESRemember that each
include: counts as one DNS lookup toward the 10-lookup limit. If you have many senders, consider flattening your SPF record (replacing includes with their resolved IPs) to stay within the limit.
-all) instructs receiving servers to reject email from any server not listed in the SPF record. In practice, many servers accept it anyway but treat it as suspicious. It signals strong confidence that only listed servers should send for your domain.Soft fail (
~all) instructs receivers to accept but mark email from unlisted servers. It is the recommended starting point — use it while you're still discovering all your legitimate sending sources. Once your SPF record is complete and tested, consider moving to -all. In both cases, pair with DMARC p=reject for actual enforcement, as DMARC provides more reliable rejection than SPF -all alone.
include:, a, mx, and ptr mechanism counts as one lookup, and included domains may themselves contain further lookups that also count toward your limit. Exceeding 10 results in a PermError, which many receivers treat as an SPF failure.To stay within the limit: (1) use
ip4: and ip6: directly for known IPs (they don't count as lookups); (2) audit nested includes — some ESPs chain several includes together; (3) use an SPF flattening service (e.g. AutoSPF, dmarcian) that periodically resolves all includes to IPs and writes them directly. Run our SPF Lookup tool on your domain to count your current lookups.
About This SPF Lookup & Generator
This free SPF tool has two modes. The Lookup tab queries DNS TXT records for any domain and extracts the SPF record, showing both the raw string and a human-readable breakdown of every mechanism and qualifier. The Generator tab builds a valid v=spf1 record interactively — and you can load any looked-up record into the generator by clicking Edit in Generator after a lookup.
When to use this tool
- Verify that SPF is published and correctly configured for a domain
- Check all authorized sending mechanisms at a glance
- Troubleshoot email delivery failures caused by SPF mismatches
- Build or update a new SPF record with the interactive generator
SPF Mechanism Reference
| Mechanism | Description |
|---|---|
a | Allow the domain's A/AAAA records |
mx | Allow the domain's MX mail servers |
include: | Inherit authorized senders from another domain |
ip4: | Allow a specific IPv4 address or CIDR range |
ip6: | Allow a specific IPv6 address or CIDR range |
redirect= | Delegate entirely to another domain's SPF policy |
SPF Qualifier Reference
+ Pass
The sender is authorized. This is the default qualifier — most mechanisms omit it. Email is delivered normally.
- Fail
The sender is not authorized. The receiving server should reject the email. Used at the end as -all.
~ SoftFail
The sender is probably not authorized. Email is accepted but marked as suspicious. Best practice during initial setup (~all).
? Neutral
No policy stated. The domain owner makes no assertion about whether the sender is authorized. Receivers treat this like no SPF record.
SPF in the Email Authentication Ecosystem
SPF
Verifies the sending server IP is authorized to send on behalf of the domain. Checked in the envelope From (MAIL FROM). Does not survive email forwarding.
DKIM
Adds a cryptographic signature to the email header, verified via a public key in DNS. Survives forwarding. Proves the message content hasn't been tampered with.
DMARC
Ties SPF and DKIM together. Defines what to do when checks fail (none, quarantine, reject). Provides aggregate reports on who is sending email for your domain.
All three are required by Google and Yahoo for bulk senders (2024+). Start with SPF → add DKIM → enforce with DMARC.
The Email Authentication Stack
SPF is the first layer of email authentication. Combined with DKIM, DMARC, and BIMI it forms a complete protection and branding chain for your domain.
| Protocol | What it authenticates | DNS Record | Our Tool |
|---|---|---|---|
| SPF | The sending server's IP address is authorized to send for the domain | TXT at root domain |
This tool |
| DKIM | The message was cryptographically signed by an authorized sender and not altered | TXT at {selector}._domainkey.{domain} |
DKIM Checker |
| DMARC | SPF/DKIM alignment with the visible From: header — sets enforcement policy and reporting |
TXT at _dmarc.{domain} |
DMARC Lookup & Generator |
| BIMI | Displays the domain's brand logo in supporting email clients once SPF, DKIM, and DMARC all pass | TXT at default._bimi.{domain} |
BIMI Lookup & Generator |
| MX | Where inbound email for the domain should be delivered | MX at root domain |
MX Lookup |
Related Articles
View all articles
SPF Validates the Envelope Sender, Not What You See in Your Inbox — Here's Why That Matters
SPF validates the envelope sender — the address used during SMTP delivery — not the "From" header address that recipients actually see. This means SPF can pass for an email that appears to be from ceo@bigcorp.com, because the attacker set a legitimate envelope sender from their own domain. Here's why DMARC's alignment requirement exists to close this gap, what -all vs ~all vs +all actually mean, and the SPF flattening trade-off.
SPF Mechanisms Deep Dive: How include:, mx, and Macros Each Consume Your 10-Lookup Budget
A single `include:` mechanism can secretly consume several of SPF's 10 allowed DNS lookups, depending on what the included record itself contains. Here's exactly how each SPF mechanism (ip4, a, mx, include, exists, ptr, redirect) consumes lookups, how macro expansion works for dynamic IP-based checks, and how mechanism ordering and qualifiers interact.
CAN-SPAM vs GDPR vs CASL: Email Marketing Compliance for International Senders
CAN-SPAM, GDPR, and CASL have different models (opt-out vs opt-in) and very different penalties. Here's what each requires, how they differ in a practical comparison matrix, and the compliance approach for organisations sending internationally to all three jurisdictions.
SPF PermError: Why the 10-Lookup Limit Breaks Email Authentication and How to Fix It
Adding third-party email services pushes SPF past the 10-lookup limit, causing PermError and DMARC failures. Here's how to count SPF lookups, why the limit is hit so easily, and the three solutions: IP replacement, flattening, and consolidation.
SPF Lookup — Check Any Domain's Email Authentication Record
Learn how SPF records work, what the include, ip4, and all mechanisms mean, why the 10-lookup limit matters, and how to use a free SPF lookup tool to diagnose email authentication failures.
