SPF (Sender Policy Framework) mistakes can ruin your email deliverability and expose your domain to security risks. Here's a quick rundown of the most common SPF record errors and how to fix them:
v=spf1, or it won’t work.include or ip4.~all (soft fail) or -all (hard fail); avoid using +all.PTR and keep your SPF updated.all qualifier.Key takeaway: Regularly review and update your SPF record to maintain email security and deliverability. Tools like Mailforge can simplify this process by automating DNS updates and reducing manual errors.
One of the most basic yet critical SPF errors is leaving out the "v=spf1" version tag. Every SPF record must begin with this tag, as it tells mail servers that the record is an SPF entry. Without it, mail servers will ignore your SPF record entirely, making it non-compliant.
If the "v=spf1" tag is missing, email providers like Gmail and Outlook treat your emails as though no SPF protection exists. This increases the chances of your messages being flagged as spam or outright rejected. Since major email providers rely heavily on SPF checks, this error can significantly lower your delivery rates.
This issue often arises when users copy and paste SPF configurations without fully understanding the format. It’s also common when merging multiple SPF records or when automated tools fail to enforce proper formatting.
According to Mailhardener, missing the "v=spf1" tag is one of the top five most frequent SPF mistakes seen in email security analyses.
Without the correct tag, your domain’s email authentication is weakened, leaving it open to spoofing attacks. Fixing this is simple: go to your domain's DNS settings and ensure your SPF TXT record starts with "v=spf1". Here’s an example of a properly formatted record:
v=spf1 include:_spf.google.com ~all
After updating your DNS TXT record, allow some time for DNS propagation (anywhere from a few minutes to 24 hours in the U.S.). Once that’s done, use an SPF lookup tool to confirm the changes. Tools like Mailforge can streamline this process by automating DNS setup and bulk updates, reducing the chance of errors.
Next, we’ll dive into syntax misconfigurations that can further impact your SPF setup.
SPF mechanisms are the backbone of your email authentication policy, but even a small syntax error can make your entire SPF record ineffective. These errors occur when mechanisms like "include", "ip4", or "a" aren't formatted correctly according to SPF standards. Something as simple as a missing space or an incorrect qualifier can disrupt email authentication.
Syntax errors in SPF records are surprisingly frequent and rank among the most common mistakes administrators make. The complexity of SPF syntax, combined with the manual effort required to configure DNS records, creates plenty of room for typos and formatting missteps. Many users copy examples without double-checking the syntax, leading to widespread issues.
If your SPF record has syntax errors, recipient mail servers may treat it as invalid or ignore it altogether. This can result in your legitimate emails being flagged as suspicious or rejected. Major email providers like Gmail, Outlook, and Yahoo depend on accurate SPF authentication, so errors in your record can harm your sender reputation and reduce delivery rates.
Here are some common syntax mistakes and how to fix them:
Missing spaces between mechanisms:
Incorrect: v=spf1include:_spf.example.com~all
Correct: v=spf1 include:_spf.example.com ~all
Incorrect mechanism names:
Incorrect: v=spf1 include:_spf.example.com ip:192.138.1.1 -all
Correct: v=spf1 include:_spf.example.com ip4:192.138.1.1 -all
Improper IPv6 formatting:
Incorrect: v=spf1 ip6:2001:0db8:85a3:0000:0000:8a2e:0370:7334 -all
Correct: v=spf1 ip6:[2001:0db8:85a3:0000:0000:8a2e:0370:7334] -all
To ensure your SPF records function correctly, you must follow the exact syntax requirements. This includes separating each mechanism with spaces, enclosing IPv6 addresses in square brackets, and using proper mechanism names. Failing to meet these standards can break your email authentication process.
The good news is that fixing syntax errors is relatively simple once you spot them. Always separate mechanisms and modifiers with spaces, verify that you're using the correct mechanism names (e.g., "ip4" instead of "ip"), and make sure IPv6 addresses are enclosed in square brackets. Keep in mind that DNS changes can take up to 48 hours to propagate.
For organizations managing multiple domains, tools like Mailforge simplify the process by automating DNS setup and bulk updates, reducing the risk of manual errors and improving efficiency.
SPF records are limited to 10 DNS lookups. Exceeding this cap - often due to mechanisms like include, a, mx, ptr, or exists - leads to SPF validation failure. This issue becomes especially problematic when include statements reference SPF records that themselves contain multiple mechanisms, creating a domino effect that quickly breaches the limit.
This problem is more widespread than you might think. With businesses increasingly relying on multiple cloud-based email services, over 20% of SPF records for business domains are misconfigured, according to 2023 industry reports. Excessive DNS lookups rank among the top three errors. Companies using marketing tools, CRMs, helpdesks, and other third-party platforms often add each service as an include statement, unaware of how quickly the lookups stack up.
Here’s an example. Imagine a business with five email services. Their SPF record might look something like this:
v=spf1 include:service1.com include:service2.com include:service3.com include:service4.com include:service5.com -all
At first glance, it seems fine. But if service1.com and service2.com each reference three additional include statements in their SPF records, the total DNS lookups can easily hit or exceed the 10-lookup limit. This seemingly small oversight can have major consequences for email deliverability.
When your SPF record exceeds the DNS lookup limit, it triggers a "PermError" (permanent error) during SPF validation, causing your email to fail authentication. To receiving mail servers, this is as bad as having no SPF record at all. The result? Legitimate emails may get rejected or flagged as spam. Worse, it leaves your domain more vulnerable to spoofing because the SPF mechanism isn’t functioning properly.
The 10-lookup rule isn’t arbitrary - it’s part of the SPF specification (RFC 7208). This restriction ensures email authentication remains efficient and secure by preventing excessive DNS queries, which could otherwise be exploited for denial-of-service attacks. The rule is non-negotiable - there are no exceptions or workarounds.
Here’s a quick breakdown of how different SPF mechanisms contribute to DNS lookups:
| SPF Mechanism | DNS Lookups | Notes |
|---|---|---|
| include | 1 per use | The most common reason for exceeding the limit |
| a | 1 per use | Triggers a DNS A record lookup |
| mx | 1 per use | Triggers a DNS MX record lookup |
| ptr | 1 per use | Generally discouraged due to inefficiency |
| exists | 1 per use | Each use triggers a DNS query |
| ip4/ip6 | 0 | No DNS lookup required |
The good news? This issue is fixable. Start by checking your SPF record with validation tools to count the DNS lookups. Then, take these steps to reduce the count:
For organizations managing multiple domains or complex email setups, platforms like Mailforge can simplify the process. These tools automate DNS configurations and bulk updates, keeping your SPF records compliant and optimized without the need for constant manual adjustments.
Having multiple SPF records for a single domain can create conflicting instructions, leading to SPF validation failures. When email servers encounter this issue, they can't determine which record to follow, causing authentication problems that can severely impact your email deliverability.
According to DNS standards, a domain should only have one SPF record. The SPF specification leaves no room for ambiguity - when multiple records exist, the authentication process fails altogether.
A 2025 study by Cornell University revealed that 2.9% of domains have duplicate SPF records. This often happens due to decentralized management, where different teams or departments add separate SPF entries without coordination. Other common scenarios include:
These missteps lead to validation failures that disrupt email communication.
When SPF validation fails due to conflicting records, legitimate emails can end up flagged as spam. This affects every type of communication from your domain - whether it's marketing emails, transactional messages, customer support replies, or even internal emails.
Fortunately, resolving this issue is straightforward. The solution lies in consolidating all SPF records into a single, unified entry. For example, you can merge multiple entries like this:
v=spf1 include:_spf.google.com include:mailgun.org ~all
Once consolidated, email deliverability improves, and SPF authentication failures are eliminated.
To avoid future issues, consider these preventive measures:
For organizations managing multiple domains, tools like Mailforge can simplify the process. Its automated DNS setup and bulk update features help consolidate SPF records and prevent duplicates. Up next, explore how to prevent similar misconfigurations during updates.
The 'all' mechanism is the final directive in an SPF record, telling email servers how to handle messages from sources not explicitly listed. When it's missing or duplicated, it can lead to security vulnerabilities and delivery problems.
Every SPF record needs to end with a single 'all' mechanism. If it's missing, the record is incomplete. On the other hand, having multiple 'all' mechanisms causes issues because SPF processing stops at the first one it encounters.
Missing or extra 'all' mechanisms are among the top 10 SPF errors found in DNS records. These mistakes often happen when configurations are edited manually or when settings from different email services are combined. Without clear instructions from the 'all' mechanism, mail servers don't know how to handle unlisted senders. This can lead to inconsistent outcomes, such as messages being flagged as spam or outright rejected.
Luckily, addressing this issue is straightforward. Make sure your SPF record ends with one correctly formatted 'all' mechanism. Here are examples:
v=spf1 ip4:192.0.2.0/24 include:mailforge.ai -allv=spf1 ip4:192.0.2.0/24 include:mailforge.aiv=spf1 ip4:192.0.2.0/24 -all include:mailforge.ai -allChoose -all for strict enforcement or ~all for a more lenient approach. Avoid using +all - it permits all senders, undermining SPF's purpose.
For organizations managing numerous domains, tools like Mailforge can simplify DNS setup. These platforms help ensure the correct use of the 'all' mechanism, minimizing manual errors and keeping your SPF records in line with best practices.
Outdated or invalid mechanisms, like deprecated features or incorrect entries, can undermine SPF records. Let’s take a closer look at how these issues impact email deliverability.
Outdated mechanisms often crop up when businesses update their email services. For example, when switching to a new email provider or adding third-party tools, organizations typically update their SPF records with new mechanisms. However, they often forget to remove old, unused entries. Over time, this oversight can clutter SPF records, making them harder to manage and increasing the likelihood of errors.
Just like other SPF misconfigurations, invalid mechanisms can wreak havoc on email deliverability. They can lead to SPF validation failures, causing legitimate emails to end up in spam folders or be outright rejected. If an SPF check encounters deprecated or unresolvable mechanisms, it might fail entirely. This not only disrupts email delivery but also leaves your domain more vulnerable to spoofing attacks, damaging your sender reputation in the process. The ripple effect? Critical communications might never reach their destination.
To comply with SPF standards, your DNS records should only include mechanisms that are supported and correctly formatted. A common offender is the PTR mechanism, which is no longer recommended due to its poor reliability and slow performance. Using outdated mechanisms like PTR can lead to intermittent SPF failures, putting your domain out of step with current email authentication practices.
Another issue is exceeding the 10 DNS lookup limit. Even if your mechanisms are valid, going over this limit will cause automatic SPF failures, further complicating deliverability.
The good news? Fixing outdated mechanisms is usually simple once you identify them. Start by reviewing your SPF record in your DNS settings. Remove mechanisms that are no longer needed or have become invalid. Be cautious, though - ensure you don’t accidentally delete entries that are still active.
Here’s a quick tip: Replace outdated entries like PTR with supported mechanisms such as a, mx, ip4, ip6, or include for services you’re actively using.
For businesses managing multiple domains, tools like Mailforge can streamline the process. These platforms can automate DNS updates and help prevent outdated mechanisms from piling up. After making changes, allow up to 48 hours for DNS updates to propagate, then recheck your SPF validation to ensure everything is working as intended. This proactive approach will keep your SPF records clean and effective.
Mistakes like typos and incorrect capitalization can disrupt your SPF record, leading to failed email authentication and causing your messages to land in spam folders. SPF records play a crucial role in verifying the legitimacy of your email sender and safeguarding your domain.
Spelling and case errors are surprisingly frequent, especially in organizations that rely on manual DNS record management. These errors often show up in support forums and are consistently flagged by email security providers as one of the main reasons for SPF failures. Companies juggling multiple domains without automated tools are particularly susceptible.
Some common mistakes include typing "incldue" instead of "include", misusing qualifiers like "+all" instead of "-all" or "~all", and incorrectly formatting the version tag as "v=spf" instead of "v=spf1". These errors usually occur during manual input, copy-paste actions, or when someone unfamiliar with SPF syntax edits DNS records. Such errors highlight the importance of careful DNS management.
When DNS servers encounter typos or incorrect capitalization in SPF records, they treat the record as invalid and ignore it entirely. This results in SPF authentication failures, which can cause legitimate emails to be flagged as spam or outright rejected by recipient mail servers. The damage to your domain's reputation can be significant and long-lasting.
For example, at workcanvas.com, a missing space in v=spf1include:spf.mandrillapp.com?all caused complete SPF failure until the error was fixed.
SPF mechanisms and modifiers must be spelled exactly as outlined in the RFC standards. Although SPF records are technically case-insensitive - meaning "include" and "INCLUDE" should work the same - some DNS management tools handle case inconsistently. This inconsistency can lead to unexpected and hard-to-diagnose issues.
To avoid such problems, it’s best to use lowercase for all SPF mechanisms and qualifiers. DNS servers enforce strict parsing of SPF records, so even a minor typo can invalidate the entire record and cause all emails from your domain to fail SPF checks.
The good news? Fixing spelling and case errors in SPF records is usually straightforward once you identify them. Most SPF validation tools and DNS management platforms will flag invalid syntax or mechanisms, giving you the chance to correct them quickly. Always double-check the spelling and formatting of your SPF record before publishing any updates.
When copying SPF records, ensure there are no extra spaces, dashes, or commas. For organizations managing complex email infrastructures across multiple domains, tools like Mailforge can help minimize manual errors. These platforms offer automated DNS setup and bulk updates with built-in validation, making it easier to maintain accurate SPF records. Careful SPF configuration is essential for dependable email delivery and complements the troubleshooting strategies discussed earlier. Up next, we’ll explore additional configuration challenges that can undermine SPF integrity.
Extra spaces, misplaced dashes, or unnecessary commas can quietly wreak havoc on your SPF record. These small errors often slip by unnoticed during manual DNS edits but can lead to serious authentication failures that disrupt email delivery. This problem is especially common when records are updated manually.
Formatting mistakes are among the most frequent SPF issues, especially for users who manually edit DNS records or aren’t fully familiar with SPF syntax. Even seasoned administrators can introduce errors when updating or merging records.
The problem often escalates when administrators copy SPF records from multiple sources and paste them into DNS management tools. Combining mechanisms without paying attention to proper formatting can also lead to these errors.
When DNS servers encounter an SPF record with incorrect formatting, they treat it as invalid and ignore it. This happens because errors like extra spaces, misplaced dashes, or commas cause the record to fail validation. As a result, legitimate emails might be flagged as spam or outright rejected by recipient servers. This not only lowers deliverability rates but can also harm your sender reputation.
In some cases, these formatting issues can even cause DNS servers to split the SPF record, breaking the validation process entirely. When this happens, your domain is left without the protection SPF is supposed to provide.
To avoid these deliverability issues, it’s essential to stick to SPF syntax guidelines as outlined in RFC 7208. The rules are clear: separate mechanisms and modifiers with a single space, and avoid using commas or unnecessary dashes. Dashes should only appear as part of mechanisms, like -all for a hard fail, and never as separators.
If your SPF record doesn’t follow these rules, it will be considered non-compliant and ignored by receiving mail servers. This not only weakens SPF’s effectiveness as an email authentication tool but can also disrupt compliance with DMARC and other security protocols.
Here’s a simple example to illustrate how to resolve these issues:
Incorrect formatting:
v=spf1 ip4:192.0.2.1, include:example.com -all
Correct formatting:
v=spf1 ip4:192.0.2.1 include:example.com -all
These errors are easy to fix once identified. Use SPF validation tools to detect and correct extra spaces, dashes, or commas. When adding SPF records to DNS, always enclose them in double quotes to prevent the server from splitting the record into multiple strings. Using validated SPF records ensures there are no hidden formatting problems.
For organizations managing multiple domains or large-scale email systems, automating the process can significantly reduce the risk of manual formatting errors. Proper formatting is a critical step in ensuring SPF integrity and maintaining consistent email authentication across all your domains.
A surprising number of domains operate without an SPF record, leaving them exposed to email spoofing and delivery problems. Unlike other SPF-related issues that stem from misconfigurations, this problem arises from a complete lack of setup. For many domain owners, especially those managing new businesses, personal domains, or using third-party email services, SPF setup isn’t even on their radar until email delivery issues start piling up.
The absence of an SPF record often comes to light only after recipients complain about emails landing in spam folders or email providers flag messages as suspicious. By then, the damage to the sender's reputation may already be done.
Without an SPF record, your domain lacks a critical layer of email authentication, making it vulnerable to spoofing. This creates a twofold issue: spammers can exploit your domain to send fraudulent emails, and legitimate messages from your domain are more likely to be treated as untrustworthy by receiving servers.
Major providers like Gmail, Outlook, and Yahoo now prioritize emails that meet authentication standards. If your domain doesn’t have an SPF record, these providers can’t confirm your emails are legitimate, leading to higher spam rates or outright delivery failures. This can harm business communications, disrupt marketing efforts, and strain customer relationships.
Setting up an SPF record is a simple but essential step to align with modern email authentication practices. An SPF record is a TXT entry in your domain’s DNS settings that specifies which servers or IP addresses are authorized to send emails on your behalf. Even if your domain doesn’t actively send emails, publishing an SPF record is crucial to prevent abuse.
For domains that don’t send email at all, the recommended SPF record is:
v=spf1 -all
This tells receiving servers that no emails should be sent from your domain, effectively blocking spoofing attempts.
Fixing this issue is straightforward. Here’s how to get started:
v=spf1, then add authorized IP addresses (e.g., ip4:1.2.3.4) and third-party senders using include:thirdpartydomain.net. End with ~all for a soft fail or -all for a hard fail.For organizations managing multiple domains, tools like Mailforge can simplify the process by automating DNS setup and ensuring proper SPF configuration. This minimizes manual errors and helps avoid the common misconfigurations mentioned earlier in this guide.
Let’s dive into a common issue with SPF records: incorrect or missing endings. The way you end your SPF record (using the 'all' qualifier) is crucial - it determines how servers handle emails from unauthorized sources. Unfortunately, many administrators either leave this part out entirely or choose the wrong qualifier, leading to delivery problems and potential security gaps.
One of the biggest mistakes is using permissive endings like "+all" or just "all" without a qualifier. These settings essentially allow any IP address to send emails on behalf of your domain. This not only undermines the purpose of an SPF record but also opens the door for malicious actors to exploit your domain.
These errors often happen when administrators copy generic SPF examples without customizing them or misunderstand the SPF syntax. For instance, the minus sign ("-") signals a strict policy, while the plus sign ("+") creates a permissive one. This can lead to setups that either block legitimate emails or fail to protect your domain from abuse.
Using the wrong ending can seriously hurt your email deliverability and damage your domain's reputation. For example, a "+all" or "all" configuration allows any server to send emails as your domain, making it easier for spammers and scammers to misuse your name. While this might seem like it improves deliverability at first, it usually leads to long-term harm as your domain becomes associated with spam.
On the flip side, switching abruptly to "-all" (a hard fail policy) without proper testing can block legitimate emails. The choice between "~all" (soft fail) and "-all" (hard fail) matters: some email providers may aggressively reject messages when they encounter a hard fail, even if your DMARC policy suggests otherwise.
SPF standards recommend ending your record with "~all" (soft fail) or "-all" (hard fail), depending on your risk tolerance and deployment phase. The "~all" qualifier flags suspicious emails as potential spam, often sending them to the recipient’s spam folder. Meanwhile, "-all" instructs servers to outright reject unauthorized emails.
"Use '~all' (softfail) or '-all' (fail). While most receivers treat these directives similarly, some are more likely to reject email when '-all' is used, regardless of your DMARC policy." - dmarcian
Start by reviewing your SPF record’s ending. If it currently uses "+all", "all", or "?all", replace it with a more secure option. For organizations just getting started with SPF or making major changes, it’s a good idea to begin with "~all." This approach gives you a grace period to identify legitimate senders without causing immediate delivery failures.
Once you’ve confirmed that all authorized sources are included and your DMARC policies are in place, you can gradually move to a "-all" policy for stronger protection. During this transition, monitor your email delivery metrics and feedback carefully to ensure no legitimate emails are being blocked.
To make this process easier, tools like Mailforge can automate DNS updates and ensure your SPF records are correctly formatted. This reduces the risk of syntax errors and helps maintain proper record endings as your email setup evolves.
The table below outlines the top 10 SPF errors and their fixes to help you troubleshoot quickly and effectively.
| Error | Description | Impact | Solution |
|---|---|---|---|
| Missing v=spf1 Version Tag | SPF record doesn’t begin with the required version identifier | The record won’t be recognized as an SPF record, leading to authentication failures | Begin your record with "v=spf1" followed by a space |
| Wrong Syntax in Mechanisms | Incorrect formatting of mechanisms like "include:" or "ip4:" | Results in permanent errors, causing emails to be rejected or marked as spam | Use correct syntax: for example, "include:domain.com" (not "include domain.com") |
| Too Many DNS Lookups | Exceeds the 10 DNS lookup limit due to multiple "include" mechanisms | SPF checks may fail entirely, causing legitimate emails to be rejected or flagged | Remove unused services, flatten the record, or consolidate "include" mechanisms |
| Multiple SPF Records | Two or more SPF records exist for the same domain | Email servers may not know which record to use, leading to authentication failures | Combine all SPF details into a single TXT record |
| Missing or Extra 'all' Mechanism | SPF record lacks a proper ending or uses an incorrect "all" qualifier | Weakens security or blocks legitimate emails | End with "~all" (soft fail) or "-all" (hard fail); avoid using "+all" |
| Outdated or Invalid Mechanisms | Deprecated mechanisms or non-existent domains are referenced | Causes permanent errors, reducing email deliverability | Update mechanisms to meet current standards and verify all referenced domains |
| Spelling Errors and Case Issues | Typos in domain names or mechanism keywords | Leads to lookup failures and authentication errors | Double-check domain names and use lowercase for all mechanisms |
| Extra Spaces, Dashes, or Commas | Unintended whitespace or punctuation in the record | Makes the record invalid and generates permanent errors | Eliminate extra spaces and avoid using commas as separators |
| No SPF Record Set Up | Domain completely lacks an SPF record | Emails are more likely to be marked as spam, and the domain is vulnerable to spoofing | Create a basic SPF record that includes all authorized sending sources |
| Wrong or Missing Record Ending | Incorrect or absent "all" qualifier at the end | May be overly permissive (security risk) or overly restrictive (delivery issues) | Use "~all" for testing and "-all" for strict enforcement |
Studies show that thousands of well-known domains encounter SPF record errors. Use this table to pinpoint and resolve common issues efficiently.
For a hassle-free approach, tools like Mailforge can automate DNS setup and manage bulk updates, ensuring SPF records remain consistent across multiple domains. Since SPF validation errors can hurt email deliverability, regular monitoring and proactive fixes are essential to maintain inbox placement.
Getting your SPF records right is crucial for ensuring both email deliverability and security. Missteps in configuration can not only hurt your ability to reach your audience but also expose your domain to spoofing attacks, eroding the trust your customers have in your communications.
The ten common mistakes highlighted earlier can significantly impact your email campaigns, making it clear that regular audits and proactive upkeep are essential for any organization that depends on email as a communication tool.
One way to handle these challenges is through automation. Manual processes can quickly become overwhelming, especially as your operations grow. Tools like Mailforge simplify DNS setup and bulk updates, keeping your SPF records consistent and freeing up your time to focus on more strategic tasks.
As noted, manual processes don’t scale well over time. Whether you're managing multiple client domains as an agency or expanding your enterprise's email outreach, adopting automated systems to prevent common SPF errors is a smart move for maintaining reliable deliverability.
Make it a habit to conduct quarterly SPF audits, and always review your records when adding new email services. Pairing this routine with automated tools ensures your email infrastructure stays secure and efficient, while complementing your DKIM and DMARC strategies. Together, these efforts build a strong foundation for trustworthy and effective email communication.
Starting an SPF record with the 'v=spf1' tag is crucial because it tells email servers that the record is part of the Sender Policy Framework (SPF). This step ensures the record can be properly understood and used during email authentication.
Leaving out the 'v=spf1' tag renders the record invalid. As a result, your emails could fail authentication checks, increasing the chances of them being marked as spam or rejected entirely by recipient servers. To avoid these problems and keep your email delivery reliable, always start your SPF record with 'v=spf1'.
To ensure your SPF record stays within the 10-lookup DNS limit, focus on streamlining its configuration. Start by removing redundant include statements and, when possible, directly listing IP addresses. Avoid chaining multiple include mechanisms, as they can quickly push you past the limit.
It's also important to regularly review your SPF record to keep it aligned with the email sources you actively use. For those managing several domains or mailboxes, tools like Mailforge can simplify your DNS setup, helping you stay within SPF limits while maintaining dependable email deliverability.
The final part of an SPF record is vital for striking the right balance between email security and deliverability. The -all directive takes a strict approach, outright rejecting any emails that come from unauthorized sources. This method strengthens security by blocking spoofed emails but can also result in legitimate emails being rejected if your SPF record isn’t perfectly configured.
In contrast, the ~all directive is more forgiving. Instead of rejecting emails from unauthorized sources, it marks them as suspicious. While this approach can enhance deliverability, it does slightly compromise security. For most scenarios, ~all tends to be the safer bet unless you're absolutely sure that every valid email source is accurately listed in your SPF record. Take the time to assess your specific requirements before choosing between these options.