Salesforce is one of the most widely deployed email-sending platforms in the world. It is not just a CRM. It is the engine behind millions of transactional notifications, marketing campaigns, automated workflows, and customer service replies every single day. When that email volume is tied to your domain and those messages arrive without proper authentication, the consequences go well beyond the spam folder. You are exposing your domain to spoofing, phishing attacks, and the kind of sender reputation damage that takes months to recover from.
The challenge with Salesforce email authentication is not that it is technically difficult. The challenge is that Salesforce’s default configuration is specifically designed to break SPF alignment, and most documentation stops at telling you to add an SPF record without explaining why that alone is insufficient to pass DMARC. Understanding the mechanics behind why Salesforce behaves this way, and what you need to do about it, is the difference between having authentication records that look correct and having authentication that actually works.
This guide covers the complete setup: SPF, DKIM, and DMARC across Salesforce Sales Cloud, Marketing Cloud, and Pardot (now Marketing Cloud Account Engagement). It explains how each protocol works in the context of Salesforce specifically, walks through step-by-step configuration, and covers the troubleshooting scenarios that trip up even experienced administrators.
Before touching any DNS records, understand this:
By default, Salesforce routes bounces through its own infrastructure by setting the email’s Return-Path to a Salesforce-controlled address – something like sampleemail=salesforce.com__abc123@abc123.bnc.salesforce.com. This is intentional, for bounce management.
The problem: DMARC checks SPF alignment against the Return-Path domain, not the From address. Since that Return-Path belongs to Salesforce – not your domain – SPF will never be DMARC-aligned, even after you add include:_spf.salesforce.com to your record.
Adding Salesforce to your SPF record does not fix this.
The solution: DKIM is your primary DMARC alignment mechanism for Salesforce. DMARC only requires one of SPF or DKIM to align, so properly configured DKIM is all you need for compliance. You should still add Salesforce to your SPF record as a baseline, but DKIM does the heavy lifting.
Even though SPF alignment won’t pass with default Salesforce settings, include it in your record for baseline authentication.
Check your existing SPF record first. Your domain can only have one SPF TXT record – a second record causes an immediate PermError. Look up your domain’s TXT records and find any record starting with v=spf1.
If one exists, add the Salesforce mechanism to it. If none exists, create a new TXT record on your root domain.
Salesforce SPF include:
include:_spf.salesforce.com
Example – Salesforce only:
v=spf1 include:_spf.salesforce.com ~all
Example – Salesforce + Google Workspace:
v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all
Key rules:
Want SPF alignment too? You can disable Bounce Management in Salesforce ( Setup → Email Administration → Deliverability → uncheck “Activate Bounce Management” ). This forces Salesforce to use your domain in the Return-Path, enabling SPF alignment. Trade-off: Salesforce stops auto-processing bounce notifications. Most organizations skip this and rely on DKIM alone, which is fully sufficient.
DKIM is the protocol that actually gets you DMARC-compliant. Configure this before publishing your DMARC record.
Salesforce will generate two CNAME records . Copy them exactly – one character error breaks verification.
In your DNS provider, create two new records:
| Field | Value |
| — | — |
| Type | CNAME |
| Name | [selector]._domainkey.yourdomain.com |
| Value | The long CNAME target Salesforce provides |
Repeat for the second CNAME record.
Cloudflare users: Set both records to DNS Only (grey cloud). Proxied CNAME records will break DKIM lookups.
Wait for DNS propagation – typically 15 minutes to a few hours, up to 48 hours.
Return to Setup → DKIM Keys , open your key, and click Activate . If it fails, DNS hasn’t propagated yet – wait and retry.
Send a test email to Gmail, open the original headers, and look for:
DKIM-Signature: v=1; a=rsa-sha256; d=yourcompany.com; s=sf-2025; …
The d= should be your domain. If it is, DKIM is active and aligned.
Marketing Cloud handles DKIM differently depending on whether you have the Sender Authentication Package (SAP) .
Without SAP: Marketing Cloud uses Salesforce’s shared infrastructure. You cannot configure domain-level DKIM for your custom domain in this state. Emails sent via Marketing Cloud without SAP cannot be DMARC-aligned on your From domain.
With SAP: SAP provisions a custom subdomain (e.g., em.yourcompany.com) and handles DKIM signing under that subdomain automatically. DNS changes are made during SAP onboarding in coordination with Salesforce’s deliverability team. Since em.yourcompany.com shares the same organizational domain as yourcompany.com, DMARC relaxed alignment passes.
SAP is available for organizations sending 250,000+ emails/month. Contact your Salesforce account team to initiate onboarding.
Marketing Cloud DMARC alignment note: DMARC’s default relaxed alignment accepts subdomain matches – so DKIM signing for em.yourcompany.com aligns with a DMARC policy on yourcompany.com. No separate DMARC record needed for the subdomain.
Once verified, Pardot signs outgoing messages with DKIM automatically.
With DKIM active, you’re ready for DMARC. Start with monitoring (p=none) before enforcing any policy.
Publish a TXT record at _dmarc.yourdomain.com (note the underscore – it’s a subdomain, not the root):
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1;
Core DMARC tags:
| Tag | What it does |
| — | — |
| p=none | Monitor only – no messages are blocked or filtered |
| p=quarantine | Failed messages go to spam |
| p=reject | Failed messages are rejected outright |
| rua= | Where to send aggregate reports (daily XML summaries) |
| ruf= | Where to send forensic reports (per-failure notifications) |
| pct= | Percentage of messages the policy applies to (default: 100) |
Only one DMARC record per domain is allowed.
Don’t rush this. The phased approach prevents blocking legitimate email from sources you forgot to authenticate.
Phase 1 – p=none (2–4 weeks minimum) Monitor your DMARC reports. Confirm all Salesforce traffic shows dkim=pass. Identify any other sending sources that are failing.
Phase 2 – p=quarantine at 25%
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com;
Increase pct to 50, then 100 over the following weeks as you confirm no false positives.
Phase 3 – p=reject
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; fo=1;
Full protection. Unauthenticated emails claiming to be from your domain are rejected.
DMARC aggregate reports arrive daily from each major mail provider (Gmail, Yahoo, Microsoft). For each sending source, you’ll see whether SPF and DKIM passed, and whether they aligned with your From domain.
For Salesforce traffic with Bounce Management enabled, this is the expected result – and it is compliant:
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
spf=fail is expected – Salesforce’s Return-Path doesn’t align. dkim=pass is what carries DMARC compliance. If you see dkim=fail for Salesforce traffic, DKIM is not properly configured or hasn’t been activated. Do not move to enforcement until Salesforce shows consistent dkim=pass.
A DMARC reporting tool – dmarcian, Valimail, or the reporting tools at dmarcs.com – is strongly recommended over reading raw XML directly. These tools surface new unauthorized senders immediately, which is the real security value of DMARC.
DMARC fails even though SPF passes for Salesforce Expected behavior with Bounce Management enabled. SPF passes at the mechanism level but doesn’t align with your From domain. Configure DKIM – that’s the fix.
DKIM key stuck in “Pending” in Salesforce DNS hasn’t propagated yet, or Cloudflare proxy is enabled on the CNAME records. Disable the proxy, wait, and retry activation.
SPF PermError – too many DNS lookups You’ve exceeded the 10-lookup limit. Audit your SPF record, remove unused include: entries, or replace nested includes with direct IP addresses using ip4:.
Multiple SPF records on the domain Delete all but one and merge all include: entries into a single record.
DMARC record not found Published at the wrong location. The record must be at _dmarc.yourdomain.com – missing the underscore (dmarc.yourdomain.com) or publishing on the root domain both cause lookup failures.
SPF
DKIM
DMARC
Rotate DKIM keys annually. Salesforce supports multiple active keys simultaneously, so rotation has zero downtime: create the new key, publish its DNS records, activate it, confirm it’s signing, then deactivate and remove the old key.
Audit SPF when adding new tools. Any new service that sends email from your domain – a support desk, a billing tool, a new marketing platform – needs to be added to SPF and have DKIM configured before it goes live.
Keep DMARC reports monitored. New unauthorized senders appear in reports the day they start. Catching spoofing campaigns early requires monitoring, not monthly check-ins.
*Ready to get started? Use our DMARC record generator, SPF checker, and report analyzer to set up, validate, and monitor your Salesforce authentication.*
Your emails are landing in spam. Or worse, they’re being rejected outright. You pull up the delivery logs and there it is: SPF PermError: too many DNS lookups . It looks like a minor technical hiccup. It is not. That single error means every email your domain sends is failing authentication, regardless of whether the message is legitimate or not. If your DMARC policy is set to quarantine or reject, the consequences compound fast.
This article walks through exactly what causes the SPF PermError, why the 10-lookup limit exists, how it interacts with your DMARC posture, and what you can actually do to fix it without breaking your email environment in the process.
SPF (Sender Policy Framework) works by publishing a DNS TXT record that lists every server authorised to send email on behalf of your domain. When a receiving mail server checks an inbound message, it queries your DNS to verify the sending IP against that record. Simple enough, until you start chaining services together.
RFC 7208, the specification that governs SPF, sets a hard ceiling of 10 DNS mechanism lookups per SPF check. That limit covers the include , a , mx , ptr , and exists mechanisms, plus the redirect modifier. Critically, this is a cumulative count across the entire chain. If your SPF record includes _spf.google.com , that counts as one lookup. If Google’s own record includes further mechanisms, those count too. Nested includes add up faster than most administrators realise, and the validator on the receiving side stops counting at 10 and returns a PermError, full stop.
The mechanisms that do not count against this limit are all , ip4 , and ip6 , since they resolve directly to addresses without requiring additional DNS queries. That distinction matters a great deal when you start optimising.
The 10-lookup ceiling is not arbitrary. It exists to protect receiving mail servers from denial-of-service scenarios. A malicious actor could theoretically craft an SPF record that triggers hundreds of chained DNS lookups, consuming bandwidth and CPU on every validator that checks it. The limit prevents that amplification attack by design.
There is also a practical performance angle. Every DNS lookup during SPF evaluation adds latency. More lookups mean more round trips, more opportunities for timeout failures, and a higher chance that the evaluation never completes cleanly. Receiving servers have finite patience for authentication checks, and a record bloated with nested includes creates real delay in the delivery pipeline.
The second threshold in RFC 7208 is a maximum of 2 void lookups (meaning lookups that return no result or an error), and it is less discussed but equally dangerous. Hit that limit and you also get a PermError. Many organisations only discover this when a third-party service they included has quietly let their SPF record lapse.
This is how it happens in practice. A company starts with a straightforward SPF record: Microsoft 365 gets an include, a CRM adds one, the transactional email service adds another. At that point the organisation is probably sitting around 5 or 6 lookups, comfortably within the limit.
Then growth happens. Marketing adds a new automation platform. Support adopts a helpdesk tool that also sends email. The outbound sales team integrates a sequencing tool. Each of these services requires an include statement. Each include triggers lookups of its own, and some of those services use providers that themselves chain to sub-records. Before anyone has audited the SPF record, the organisation has breezed past 10 lookups, and the first sign of trouble is a bounce report.
The uncomfortable truth is that most organisations hit this problem not through negligence but through exactly the kind of growth their business wants. The modern SaaS stack, where every tool sends email on behalf of your domain, is structurally in tension with SPF’s architecture. That tension needs to be managed deliberately.
An SPF fail means a sending server was not authorised. A PermError means something more fundamental: the SPF record itself could not be evaluated. DMARC treats these very differently.
When DMARC receives an SPF PermError, it interprets that as an SPF fail. If your DMARC policy is p=none , that may not affect immediate deliverability, but it will show up in your aggregate reports as a systematic authentication failure. If your policy is p=quarantine or p=reject , DMARC will act on that failure according to policy, and your legitimate emails will be quarantined or dropped.
That creates a painful situation: the more security-forward your DMARC posture, the more damage an SPF PermError causes. Organisations that have worked to move from p=none through to p=reject can find that a misconfigured SPF record effectively defeats their own enforcement. The receiving server has no basis on which to trust the message, and the DMARC record tells it exactly what to do with messages it cannot trust.
Given that Google and Yahoo mandated SPF and DKIM authentication for bulk senders starting February 2024, and Microsoft followed suit for its consumer platforms in May 2025, the stakes for getting this right have increased considerably. An SPF PermError is no longer a background noise problem that only affects a percentage of deliveries. It is a compliance failure that can trigger systematic rejection.
Before you can fix an SPF PermError, you need an accurate count of where your lookups are being spent. The starting point is straightforward.
Run a DNS query against your domain’s TXT records:
dig TXT yourdomain.com +short
Locate the record starting with v=spf1 and look at every mechanism it contains. Count each include , a , mx , ptr , exists , and redirect . Then follow each include recursively and count the mechanisms in those records too. If you are not comfortable doing this manually, any reputable SPF checker tool will flatten the chain and give you a total lookup count alongside a breakdown of where each lookup originates.
Pay attention to a few common patterns that inflate counts unnecessarily. Duplicate includes are frequent, especially when multiple administrators have added records over time without auditing existing entries. Services that have been decommissioned but whose SPF records were never removed are another source of bloat, and they carry the added risk of becoming void lookups if the provider eventually removes the record. The ptr mechanism is a particular problem: RFC 7208 actively discourages its use due to performance concerns, and it costs a lookup while delivering limited benefit.
Audit and remove stale includes. Go through every include in your chain and verify that the service is still in active use and still requires email-sending authorisation from your domain. Services you no longer use have no place in your SPF record. This step alone frequently recovers two or three lookups.
Replace include statements with direct IP mechanisms. For services that send from a predictable, static IP range, there is no reason to use an include that triggers a DNS lookup. Replace them with ip4: or ip6: mechanisms pointing directly to the address or CIDR block. This is particularly effective for internal mail servers and hosting infrastructure where the IPs are under your control and unlikely to change frequently.
Consolidate redundant mechanisms. Multiple ip4: entries covering adjacent address ranges can often be combined into a single CIDR block. Similarly, if a vendor provides multiple SPF includes across different subdomains, check their documentation: many providers now offer a single consolidated include that replaces all the separate entries.
Remove the ptr mechanism entirely. If your record contains ptr or ptr:domain , remove it. RFC 7208 discourages its use, it costs a lookup, and modern SPF implementations provide no meaningful benefit from it.
Consider SPF flattening for complex environments. SPF flattening is the process of resolving all the DNS lookups in your chain to their underlying IP addresses and publishing those directly, replacing the nested include structure with a single flat record containing explicit ip4: and ip6: entries. This brings the lookup count to one (the primary record query itself). The drawback is maintenance: when a provider changes their sending IPs, your flattened record becomes stale immediately. Automated flattening tools monitor for these changes and update records dynamically, which is the more sustainable approach for organisations with complex sending environments.
Use SPF macros if your infrastructure supports it. For advanced deployments, SPF macros allow dynamic per-recipient evaluation without consuming lookup quota in the traditional sense. This requires more careful configuration but can be the right long-term architecture for organisations managing email at scale.
Fixing your SPF record is not a one-time exercise. As soon as you add a new SaaS tool, a new marketing platform, or a new transactional email provider, the lookup count goes up again. The organisations that avoid repeat occurrences are the ones that build a review step into their vendor onboarding process and maintain documentation of which services hold a slot in the SPF record.
After making changes, validate the updated record with an SPF checker that performs full recursive resolution. Confirm the total lookup count is at or below 10. Then send test emails through the services you modified and check the authentication headers ( Authentication-Results ) in the received messages to confirm SPF is passing.
Your DMARC aggregate reports are a secondary verification mechanism. Within a day or two of the fix, you should see the PermError rate drop to zero across the sources that were previously failing. If it does not, there is likely a secondary record or a subdomain sending configuration that has not been addressed.
A clean SPF record is not complicated infrastructure. It is a controlled list of authorised senders kept deliberately within a hard technical boundary. The organisations that run into repeated SPF PermErrors are usually those that treat the DNS record as an append-only log rather than a maintained policy document.
The good news is that the fix is always available. Unlike some authentication problems that require co-ordination with upstream providers, an SPF PermError is entirely within the domain owner’s control. Audit the record, remove what does not belong, replace dynamic lookups with static IPs where possible, and monitor the count every time the sending environment changes.
If you are working through SPF PermError issues and need help auditing your full authentication posture, including how SPF failures are interacting with your DMARC policy and DKIM alignment, the team at DMARCS can walk through your configuration and identify exactly where the chain is breaking down. Getting this right protects your deliverability, your domain reputation, and the trust your recipients place in every email your organisation sends.
To truly understand the Sender Policy Framework (SPF) , you must first understand the environment it was built to protect. When the Simple Mail Transfer Protocol (SMTP) was developed in the early 1980s, the internet was a small, academic, and highly trusted network. SMTP was designed simply to route messages efficiently from point A to point B. It was not designed to verify the identity of the person or machine sending the message.
Because of this architectural oversight, SMTP allows anyone to claim they are anyone else. Just as you can write a fake return address on a physical envelope and drop it in a public mailbox, a malicious actor can connect to a mail server and send an email claiming to be ceo@yourcompany.com.
This practice, known as email spoofing , became the foundation for global spam operations, targeted phishing campaigns, and devastating Business Email Compromise (BEC) attacks. As the internet exploded in commercial popularity, the lack of authentication became a critical vulnerability. The industry desperately needed a mechanism to verify that an email claiming to come from a specific domain was actually authorized by the true owner of that domain.
Enter SPF, standardized by the Internet Engineering Task Force (IETF) in RFC 7208. SPF provides a public, verifiable list of authorized sending servers for any given domain, turning the “honor system” of early email into a strict, cryptographic security checkpoint.
SPF (Sender Policy Framework) is an open-standard email authentication protocol. It allows a domain owner to specify exactly which mail servers, IP addresses, or third-party hostnames are authorized to send email on behalf of their domain.
It operates entirely using the Domain Name System (DNS) . The domain owner publishes an SPF record , which is a specifically formatted line of text added to their DNS settings as a TXT record. When an email is sent across the internet, the receiving mail server looks up this DNS record and checks if the server attempting to deliver the email is on the approved list.
In the modern email landscape, implementing SPF is no longer an optional “best practice”—it is a mandatory baseline requirement for any business that relies on digital communication.
To understand how SPF validates an email, we have to look “under the hood” at how servers communicate during an SMTP transaction. This technical process is crucial for troubleshooting deliverability issues later.
When you send an email, there are actually two different “From” addresses involved in the transaction:
An SPF record is a single, unbroken string of text. It consists of three primary components: the Version Tag, the Mechanisms, and the Qualifiers.
Every SPF record must begin with v=spf1. This explicitly identifies the TXT record to the parsing server as an SPF protocol record. If a record starts with v=spf2 (which was associated with the deprecated Sender ID framework) or lacks the prefix entirely, receiving servers will ignore it completely.
Mechanisms are the building blocks that define exactly who is authorized. The server reads these from left to right until it finds a match.
Modifiers provide additional instructions but do not directly authorize IP addresses themselves.
The qualifier is the symbol placed at the very end of the record, directly attached to the all mechanism. It dictates the strictness of your policy for senders who fail the check.
| Qualifier | Name | Action | Security Posture |
| — | — | — | — |
| -all | Hard Fail | Reject the email. Only explicitly listed senders are authorized. | Maximum Security |
| ~all | Soft Fail | Accept the message but mark it as suspicious (sends to spam). | Moderate / Testing |
| ?all | Neutral | No policy regarding unlisted senders. Treats mail as if there is no SPF record. | Zero Security |
| +all | Pass | Authorizes every IP address on earth to send on your behalf. | Dangerously Insecure |
Let’s dissect a typical corporate SPF record:
v=spf1 ip4:203.0.113.5 include:spf.protection.outlook.com include:servers.mcsv.net -all
When an MTA evaluates an SPF record, the result is more granular than a simple “yes” or “no.” The server generates a specific status code that dictates the email’s fate.
SPF is an incredibly powerful protocol, but it was purposefully designed with strict limitations to prevent abuse and protect the global DNS infrastructure from being overwhelmed by infinite loops. Violating these limits is the number one cause of broken email authentication.
This is the most infamous and frequently violated rule in email administration. RFC 7208 dictates that evaluating an SPF record cannot require more than 10 DNS lookups .
The “Nested Include” Trap:
The 10-lookup limit includes *recursive* lookups. If you add include:_spf.google.com to your record, that counts as one lookup. However, if Google’s SPF record contains three include statements of its own, evaluating Google’s record takes three more lookups. You have now consumed 4 of your 10 available lookups just by adding Google Workspace.
In a modern enterprise utilizing Google Workspace, Salesforce, Zendesk, Mailchimp, and a payroll tool, you will easily exceed 10 lookups without realizing it, instantly breaking your email authentication and generating a PermError.
A single string within a DNS TXT record cannot technically exceed 255 characters. If your SPF record is very long due to multiple IP ranges, you cannot simply paste it as one giant block in some older DNS managers.
To prevent malicious actors from tying up DNS servers by pointing to domains that don’t exist, SPF limits “void” lookups (DNS queries that return an empty response or a timeout error) to a maximum of two. If your include statements point to defunct companies, legacy vendors, or dead domains, your entire record will fail.
When large organizations hit the constraints of SPF, they cannot simply delete vendors. They must employ advanced architectural strategies.
The cleanest, most secure way to avoid the 10-lookup limit is to stop sending all mail from your root domain (@company.com). Instead, delegate specific software functions to dedicated subdomains.
Because DNS evaluates SPF strictly based on the exact domain found in the Return-Path, each subdomain gets its own independent 10-lookup limit , entirely solving the congestion problem.
If subdomain partitioning is impossible due to branding guidelines, IT administrators turn to SPF Flattening. This is the process of resolving all include domains down to their base ip4 and ip6 addresses, and listing those raw IPs directly in the SPF record.
For massive enterprises or ISPs hosting thousands of domains, static SPF records are insufficient. SPF Macros allow the creation of dynamic records using variables.
When an IP connects, the receiving server reconstructs the query using the macro to ask a specific question to the enterprise DNS server, allowing for real-time, dynamic IP authorization based on internal threat intelligence.
If you use major cloud providers, setting up SPF requires specific syntax. Here are the exact include statements for the most popular platforms.
Google Workspace (G Suite)
If you use Gmail for your business, you only need one mechanism.
Microsoft 365 (Office 365)
Microsoft routes all outbound mail through a specific protection domain.
Mailchimp
Mailchimp recommends utilizing subdomains, but if you must use your root domain:
Shopify
To ensure order confirmations and receipts land in the inbox:
*(Note: Always merge these into a single record. If you use both Google and Shopify, your record is:* *v=spf1 include:_spf.google.com include:shops.shopify.com ~all* *)*
While SPF is an excellent foundational security measure, it has a fatal flaw: it breaks when emails are auto-forwarded.
Imagine Alice (alice@example.com) sends an email to Bob (bob@university.edu). Bob has set up his university account to automatically forward everything to his personal Gmail account (bob@gmail.com).
To fix this, intermediate forwarding servers must implement SRS (Sender Rewriting Scheme) . SRS actively alters the Envelope “From” address during the forward. Instead of passing along alice@example.com, the University server rewrites the Envelope “From” to something like SRS0=abc=example.com=alice@university.edu.
When Gmail receives this, it checks the SPF record for university.edu. Because the University server is obviously authorized to send for its own domain, SPF passes.
*While SRS fixes the technical SPF failure, you cannot control whether a forwarding server uses SRS. This highlights exactly why SPF alone is not enough, bringing us to DKIM and DMARC.*
SPF is powerful, but because it relies on the hidden Return-Path and routinely breaks during forwarding, it must be paired with DKIM and DMARC to achieve true security and deliverability.
Where SPF validates the *server* using IP lists, DKIM validates the *content* using cryptography. The sending server attaches a digital “wax seal” (a cryptographic signature) to the email headers. The receiving server uses a public key found in the sender’s DNS to verify the signature.
DMARC is the master policy layer that unites SPF and DKIM. It does two critical things:
Can I have multiple SPF records on one domain?
No. You can only have one TXT record that begins with v=spf1. If you have multiple services, you must combine their mechanisms into a single, unified string. Having multiple records will result in a PermError and authentication failure.
Does SPF check the “From” address I see in my email app?
No. SPF only checks the Envelope “From” (Return-Path) address, which is hidden in the email headers and used for routing bounces. This is why DMARC is necessary—to force the visible “From” address to align with the authenticated Envelope “From”.
How long does it take for a new SPF record to work?
Because SPF relies on DNS, changes are subject to DNS propagation. Depending on the TTL (Time to Live) set on your previous TXT record, it can take anywhere from 15 minutes to 48 hours for the global internet to recognize your new SPF policy.
What is the difference between ~all and -all ?
~all is a Soft Fail. It tells receiving servers that unlisted IPs are suspicious but should still be accepted (usually routed to spam). It is used during setup to prevent accidentally blocking legitimate mail. -all is a Hard Fail, instructing servers to strictly reject any unlisted IP. -all is the ultimate goal for maximum security.
You should never transition your SPF record from a SoftFail (~all) to a HardFail (-all) blindly. You must implement DMARC in “report-only” mode (p=none) first.
Major mail providers (Google, Yahoo, Microsoft) will send you daily XML reports showing every single IP address that sent an email claiming to be from your domain. By analyzing these reports, you can discover forgotten internal servers, rogue marketing tools purchased by other departments, and active phishing campaigns. Once your reports prove that 100% of your legitimate mail is correctly passing SPF, you can safely lock down your domain with -all.
Scenario 1: “My new marketing tool’s emails are going straight to spam.”
Scenario 2: “MxToolbox says I have a PermError: Too many lookups.”
Scenario 3: “My SPF record is perfectly valid, but emails forwarded to Gmail are failing.”
The Sender Policy Framework is the absolute bedrock of modern email security. While the internet has evolved drastically since the inception of SMTP, the core need to verify digital identity remains paramount.
Mastering SPF requires far more than just pasting a line of text into your DNS panel. It requires a holistic understanding of your organization’s digital footprint, a deliberate strategy for managing DNS lookup limits, and a commitment to pairing SPF with DKIM and DMARC. By adhering to the technical specifications and architectural best practices outlined in this guide, you can eliminate domain spoofing, fiercely protect your brand’s reputation, and ensure that your legitimate business communications always find their way to the inbox.
Tell us where your domains stand today and we will take it from there.
