--- title: "SPF Authentication: Understanding SPF -all vs ~all | DMARC Report" description: "Learn the key differences between SPF -all and ~all, how each affects email authentication, and when to use them for stronger domain security." image: "https://dmarcreport.com/og/blog/spf-authentication-understanding-spf-all-vs-all.png" canonical: "https://dmarcreport.com/blog/spf-authentication-understanding-spf-all-vs-all/" --- Quick Answer SPF -all produces a hard fail for unauthorized senders, while \~all produces a soft fail. Use \~all while identifying legitimate sources and consider -all after your SPF record is complete and verified. Share [ ](https://www.linkedin.com/sharing/share-offsite/?url=undefined%2Fblog%2Fspf-authentication-understanding-spf-all-vs-all%2F "Share on LinkedIn") [ ](https://twitter.com/intent/tweet?text=SPF%20Authentication%3A%20Understanding%20SPF%20-all%20vs%20~all&url=undefined%2Fblog%2Fspf-authentication-understanding-spf-all-vs-all%2F "Share on X/Twitter") [ ](https://www.facebook.com/sharer/sharer.php?u=undefined%2Fblog%2Fspf-authentication-understanding-spf-all-vs-all%2F "Share on Facebook") [ ](https://reddit.com/submit?url=undefined%2Fblog%2Fspf-authentication-understanding-spf-all-vs-all%2F&title=SPF%20Authentication%3A%20Understanding%20SPF%20-all%20vs%20~all "Share on Reddit") [ ](mailto:?subject=SPF%20Authentication%3A%20Understanding%20SPF%20-all%20vs%20~all&body=Check out this article: undefined%2Fblog%2Fspf-authentication-understanding-spf-all-vs-all%2F "Share via Email") ![SPF authentication qualifiers comparison](https://media.mailhop.org/dmarcreport/dmarc-check-5211-1787229992086.jpg) Sender Policy Framework (SPF) is one of the fundamental technologies used to **protect email domains** from unauthorized sending. It allows domain owners to publish a list of legitimate email sources in DNS so receiving [mail servers](https://www.activecampaign.com/glossary/mail-server) can determine whether a message was sent from an approved server. One of the most important decisions when creating an SPF record is choosing the appropriate qualifier for the `all` mechanism. The two options most commonly considered are `-all` and `~all`. Although both indicate that a sending source was not authorized by the SPF record, they communicate different levels of policy. Understanding the distinction can help you **maintain email security** without unnecessarily interfering with legitimate messages. This guide explains how SPF works, what each `all` qualifier means, and how to decide between SPF hardfail and softfail. ## What Is SPF Authentication? _Sender Policy Framework, commonly called SPF, is an email authentication method that helps prevent unauthorized servers from sending messages using your domain._ A domain owner publishes an SPF policy as a [TXT record in DNS](https://www.cloudflare.com/learning/dns/dns-records/dns-txt-record/). The record identifies the servers, IP addresses, and authorized third-party email services that are permitted to send mail for the domain. When an email is received, the receiving server evaluates the sending IP against the **SPF policy** associated with the domain used in the SMTP envelope. The domain evaluated by SPF is generally the domain associated with the SMTP MAIL FROM address, also known as the Return-Path or envelope sender. This is different from the visible `From:` address that recipients see in their email clients.![Dmarc Lookup 9677](https://media.mailhop.org/dmarcreport/dmarc-lookup-9677-1787230417181.jpg)A simplified SPF record might look like this: ``` v=spf1 ip4:192.0.2.10 include:_spf.examplemail.com ~all ``` The receiving server evaluates the mechanisms in the record and determines whether the sending server is authorized. ## What Does the SPF all Mechanism Do? The `all` mechanism acts as the final catch-all in an [SPF record](https://dmarcreport.com/blog/spf-record-syntax-explained-understanding-structure-components-best-practices-guide/). The receiving server evaluates the mechanisms in sequence. It may first encounter authorized IP addresses, `include` mechanisms, or other **SPF mechanisms**. If none of those mechanisms match the sending server, evaluation eventually reaches `all`. The qualifier placed before `all` determines the SPF result for that unmatched sender. There are four possible qualifiers: | SPF qualifier | Result | General meaning | | ------------- | -------- | ---------------------------------------------------- | | +all | Pass | Every sending server is considered authorized | | \-all | Fail | Unlisted sending servers are explicitly unauthorized | | \~all | SoftFail | Unlisted sending servers are probably unauthorized | | ?all | Neutral | The domain makes no assertion about unlisted senders | For most domains, the practical choice is between `~all` and `-all`. _The other two options generally provide little or no useful protection and should not normally be used in a properly configured SPF policy._ ## SPF +all: Why It Should Be Avoided Consider the following record: ``` v=spf1 +all ``` This effectively tells receiving servers that any **IP address** is allowed to send email for the domain. That eliminates the authorization benefit SPF is designed to provide. _Even if legitimate sending sources are listed elsewhere in the record, adding `+all` ultimately authorizes every sender because the `all` mechanism matches all remaining IP addresses._ For this reason, `+all` is generally unsuitable for a security-focused SPF configuration.![Dmarc Record Generator 5766](https://media.mailhop.org/dmarcreport/dmarc-record-generator-5766-1787230454680.jpg) ## SPF ?all: What Does Neutral Mean? The `?all` qualifier produces a neutral SPF result. A neutral result does not make a positive or negative statement about whether the sending server is authorized. For example: ``` v=spf1 include:_spf.examplemail.com ?all ``` If the sender is not covered by the **preceding mechanisms**, SPF returns Neutral. This provides very little enforcement value. If your objective is to communicate that unidentified senders are suspicious, `~all` provides a stronger signal. If your SPF policy is fully established and you want a strict [authorization statement](https://www.ibm.com/docs/en/iis/11.3.0?topic=functions-authorization-statement), `-all` is stronger still. ## What Does SPF \~all Mean? `~all` represents an SPF SoftFail. For example: ``` v=spf1 include:_spf.examplemail.com ~all ``` _This tells the receiving system that sources not matched by the preceding SPF mechanisms are not authorized, but the domain is not making the strongest possible rejection-oriented statement._ A SoftFail does not necessarily mean that the message will be rejected. The receiving provider can combine the SPF result with other information, including DMARC, DKIM, [sender reputation](https://marketing.help.dotdigital.com/en/articles/8199429-understand-your-sender-reputation), message characteristics, and its own filtering policies. This makes `~all` useful when an organization is still identifying all of its legitimate email-sending services. ### Advantages of \~all Using SoftFail can be helpful when: - You are deploying SPF for the first time. - Your organization uses several third-party email platforms. - You are still discovering legitimate sending sources. - You want to reduce the possibility of disrupting legitimate mail during **SPF deployment**. - You are monitoring DMARC reports before applying a stricter SPF policy. - Your email infrastructure changes frequently. For example: ``` v=spf1 ip4:192.0.2.10 include:_spf.examplemail.com ~all ``` _If a legitimate service was accidentally omitted, its messages are not automatically subjected to the strongest SPF failure instruction._ ## What Does SPF -all Mean? `-all` represents an SPF Fail result. A record such as: ``` v=spf1 include:_spf.examplemail.com -all ``` states that only the sources authorized by the preceding mechanisms should be permitted to send mail using the domain. Any sender that does not match the listed mechanisms receives an SPF Fail result. This is the strictest of the commonly used SPF endings. _However, an SPF Fail result does not mean that every receiving mail server is required to reject the message_. The receiving server ultimately determines how to handle the result according to its own policies and the other authentication signals available to it. ### When Can -all Be Appropriate? A hardfail can be appropriate when: - Every legitimate sending service has been identified. - Your SPF record has been thoroughly tested. - Your **third-party email providers** are correctly included. - Your [DNS configuration](https://phoenixnap.com/kb/dns-configuration) is stable. - DMARC monitoring shows that legitimate messages are authenticating correctly. - You are comfortable explicitly declaring unlisted sources unauthorized. For domains that do not send email at all, a policy such as `v=spf1 -all` can also be used to state that no sending hosts are authorized. ## SPF -all vs \~all: Key Difference ![Dmarc Report 8955](https://media.mailhop.org/dmarcreport/dmarc-report-8955-1787230493563.jpg)The main difference is the strength of the SPF result generated for a sender that does not match the authorized mechanisms. ### **`~all` — SoftFail** The domain indicates that the sender is probably unauthorized. The receiving provider can use this information as part of its filtering decision without necessarily rejecting the message solely because of the SPF result. ### **`-all` — Fail** The domain makes a definitive statement that the unmatched sender is not authorized. A receiving server may apply stricter treatment based on this result, depending on its own **mail-handling policies**. _Therefore, the difference is not simply that one “blocks” and the other “allows” email. SPF produces an authentication result, while the receiving system determines the ultimate disposition of the message._ ## Example: Comparing the Two Policies Suppose a company legitimately sends email through [Google Workspace](https://en.wikipedia.org/wiki/Google%5FWorkspace) and a marketing platform. Its SPF record could be: `v=spf1 include:_spf.google.com include:marketing.example.com ~all` With `~all`, a previously unknown sending IP produces a SoftFail. The same policy could eventually be changed to: ``` v=spf1 include:_spf.google.com include:marketing.example.com -all ``` Now an unmatched sending source produces an SPF Fail. The important point is that changing the qualifier does not add a missing sender to the SPF record. Before moving to `-all`, the organization must first make sure that every [legitimate sending platform](https://www.suped.com/learn/blocklists/what-is-xmr3com-and-is-it-a-legitimate-email-sending-platform) has been properly authorized. ## Why SPF Configuration Errors Matter One of the biggest risks associated with changing from `~all` to `-all` is an incomplete SPF record. Modern organizations often send email through many different systems, including:![Dmarc Record 8322](https://media.mailhop.org/dmarcreport/dmarc-record-8322-1787230563279.jpg) - [Corporate email](https://mailrelay.com/en/glossary/corporate-email/) platforms - [Marketing automation services](https://numerous.ai/blog/marketing-automation-as-a-service) - [Customer support software](https://www.zoho.com/desk/customer-support-software.html) - CRM systems - Transactional email providers - Website contact forms - Cloud applications - Billing platforms - Notification systems - Human resources platforms If one legitimate service is missing from the SPF record, its messages can fail **SPF authentication**. _This is why SPF should be reviewed as part of the organization’s complete email-sending infrastructure rather than configured using only the primary mail server._ ## How DMARC Changes the SPF Conversation SPF does not operate in isolation. DMARC adds another layer of email authentication by evaluating SPF and [DKIM](https://dmarcreport.com/what-is-dkim/) results in relation to the visible From domain. A DMARC policy can specify how receiving providers should handle messages that fail the required authentication and alignment checks. The three commonly used DMARC policies are: - `p=none` — Monitor authentication results without requesting **quarantine or rejection**. - `p=quarantine` — Ask receiving systems to treat failing [messages as suspicious](https://www.cybersecuritydive.com/news/fbi-us-officials-impersonated-text-ai-voice/748334/). - `p=reject` — Request rejection of messages that fail DMARC. This means the `all` mechanism in an SPF record is not the only factor determining what happens to an email. ## SPF Authentication and SPF Alignment Are Different It is also important to distinguish **SPF authentication** from SPF alignment. SPF authentication checks whether the sending IP is authorized by the SPF record associated with the envelope [sender domain](https://docs.acquia.com/campaign-studio/add-ons/campaign-factory/sender-domains). DMARC alignment goes one step further by checking whether the authenticated SPF domain aligns with the domain presented in the visible `From:` address. _For example, a message may successfully authenticate through SPF using one domain while displaying another domain in the visible From field._ SPF can therefore pass while DMARC still fails if the required alignment condition is not satisfied. This distinction is particularly important when troubleshooting [email authentication](https://dmarcreport.com/blog/ensure-email-authentication-with-domain-health-report-and-dmarc-insights/) problems. ## Why Monitoring Is Important Before Using -all Before implementing a strict SPF policy, organizations should identify all legitimate sending sources. DMARC aggregate reporting can help with this process by providing information about sending IP addresses and **authentication outcomes**. A practical deployment process can look like this:![Dmarc Report 8133](https://media.mailhop.org/dmarcreport/dmarc-report-8133-1787230802507.jpg) **Step 1: Identify Your Email Sources** Create a list of every service that sends email using your domain. **Step 2: Build the SPF Record** Add the necessary IP addresses and authorized third-party services. **Step 3: Validate the Record** Check the syntax and make sure the SPF policy can be evaluated correctly. **Step 4: Monitor Authentication** Review SPF, DKIM, and [DMARC](https://dmarcreport.com/) results to identify legitimate services that may have been overlooked. **Step 5: Fix Missing Sources** Update your SPF record when a legitimate sender is discovered. **Step 6: Consider a Stricter Policy** Once the **sending infrastructure** is well understood and the record is complete, evaluate whether `-all` is appropriate for your domain. ## Common SPF all Mistakes ### 1\. Publishing +all This effectively authorizes every IP address and defeats SPF’s purpose. ### 2\. Using ?all as a permanent policy **Neutral provides** little protection because it does not make a meaningful statement about unauthorized senders. ### 3\. Placing all Before Other Mechanisms The `all` mechanism matches every sender that reaches it. Therefore, it should normally appear at the end of the SPF record. For example, this is problematic: ``` v=spf1 ~all include:_spf.google.com ``` The `include` mechanism will never be reached because `~all` has already matched. ### 4\. Switching to -all Without Identifying Every Sender A strict SPF policy can expose configuration mistakes if legitimate services were left out. ### 5\. Forgetting Third-Party Platforms A company may authorize its primary email provider while overlooking marketing, CRM, ticketing, or transactional email services. ### 6\. Ignoring SPF Record Complexity Large organizations can accumulate many SPF mechanisms and [DNS lookups](https://www.digicert.com/faq/dns/how-does-dns-lookup-work). SPF has a DNS lookup evaluation limit, so records should be carefully optimized as the number of email providers grows. ### 7\. Treating SPF as the Entire Email Security Strategy SPF is only one component of a broader email authentication system. DKIM and DMARC should also be considered when building a comprehensive anti-spoofing strategy.![Dmarc Check 5439](https://media.mailhop.org/dmarcreport/dmarc-check-5439-1787230843028.jpg) ## Should You Choose \~all or -all? There is no universal answer for every domain. If you are still discovering legitimate email sources, `~all` provides a more cautious starting point. It allows you to monitor authentication behavior while reducing the risk associated with an incomplete **SPF configuration**. Once your SPF record accurately represents your email infrastructure and your authentication reports show that legitimate sources are properly authorized, `-all` can be considered when you want to make a stronger statement that unidentified senders are unauthorized. _The important principle is to avoid choosing a qualifier based solely on the idea that “stricter is always better.” A strict SPF policy is useful only when the underlying record is accurate._ ## A Practical SPF Example Consider a business that uses: - Google Workspace for employee email - A marketing platform for newsletters - A [transactional email provider](https://www.tatacommunications.com/knowledge-base/cpaas/choosing-transactional-email-api-providers) for **application notifications** Its SPF record could look similar to: ``` v=spf1 include:_spf.google.com include:marketing.example.com include:transactional.example.com ~all ``` After monitoring authentication results and confirming that these are the organization’s complete legitimate sending sources, the organization may decide to use: ``` v=spf1 include:_spf.google.com include:marketing.example.com include:transactional.example.com -all ``` The exact SPF mechanisms required depend on the providers being used. Never copy an SPF record from another organization simply because its setup looks similar.![Dmarc Check 5249](https://media.mailhop.org/dmarcreport/dmarc-check-5249-1787230124130.jpg) ## Final Thoughts The `all` mechanism is a small but important part of an SPF record. _Its qualifier determines how an SPF evaluation concludes when the sending source does not match any of the authorized mechanisms that came before it._ `~all` produces a SoftFail and is useful when you want a more cautious policy while validating your [email infrastructure](https://www.zoho.com/workplace/articles/email-infrastructure.html). `-all` produces a Fail and provides a stronger statement that unlisted sending sources are unauthorized. Meanwhile, `+all` effectively removes SPF’s authorization protection, and `?all` provides little useful **policy information**. The best approach is to build an accurate SPF record first, verify every legitimate sending service, monitor authentication results, and then choose the appropriate ending for your organization’s email environment. SPF works most effectively when combined with DKIM and DMARC. Together, these technologies provide a stronger framework for authenticating legitimate email, reducing [domain spoofing](https://www.infosecurity-magazine.com/news/infosec2025-email-domains-spoofing/), and improving overall email security. ![Brad Slavin](https://media.mailhop.org/dmarcreport/images/team/brad-slavin.jpg) [ Brad Slavin ](/authors/brad-slavin/) General Manager Founder and General Manager of DuoCircle. Product strategy and commercial lead for DMARC Report's 2,000+ customer base. [LinkedIn Profile →](https://www.linkedin.com/in/bradslavin) ## Take control of your DMARC reports Turn raw XML into actionable dashboards. Start free - no credit card required. [Start Free Trial](https://app.dmarcreport.com/signup?plan=free) [Check Your DMARC Record](/tools/dmarc-checker/) Scan Your Domain Now Instantly scan your domain for DKIM, SPF, and DMARC issues Check My Domain Share this article [ ](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fdmarcreport.com%2Fblog%2Fspf-authentication-understanding-spf-all-vs-all%2F) [ ](https://twitter.com/intent/tweet?text=SPF%20Authentication%3A%20Understanding%20SPF%20-all%20vs%20~all&url=https%3A%2F%2Fdmarcreport.com%2Fblog%2Fspf-authentication-understanding-spf-all-vs-all%2F) [ ](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fdmarcreport.com%2Fblog%2Fspf-authentication-understanding-spf-all-vs-all%2F) Copy Related Articles - [ ![10 Reasons Why DKIM Fails](https://media.mailhop.org/dmarcreport/images/2022/04/dmarc-alignment-6379.jpg) 10 Reasons Why DKIM Fails Intermediate ](/blog/10-reasons-why-dkim-fails/) - [ ![cybersecurity news](https://media.mailhop.org/dmarcreport/dmarc-check-9711-1784029121308.jpg) Accenture Sourcecode Breached, JADEPUFFER AI Ransomware, GodDamn Disables Windows Intermediate ](/blog/accenture-sourcecode-breached-jadepuffer-ai-ransomware-goddamn-disables-windows/) - [ ![AppRiver SPF Record](https://media.mailhop.org/dmarcreport/dmarc-check-7224-1785846270575.jpg) AppRiver SPF Record: How To Set It Up (Owned By Zix) Intermediate ](/blog/appriver-spf-record-setup-guide-for-zix-email-security-platform/) - [ ![Best DMARC Reporting Tools in 2026: Honest Comparison](https://media.mailhop.org/dmarcreport/images/2022/04/dmarc-report-4236.jpg) Best DMARC Reporting Tools in 2026: Honest Comparison Intermediate ](/blog/best-dmarc-reporting-tools-2026/) ## Related Articles [ Intermediate 4m 10 Reasons Why DKIM Fails Apr 19, 2022 ](/blog/10-reasons-why-dkim-fails/)[ Intermediate Accenture Sourcecode Breached, JADEPUFFER AI Ransomware, GodDamn Disables Windows Jul 14, 2026 ](/blog/accenture-sourcecode-breached-jadepuffer-ai-ransomware-goddamn-disables-windows/)[ Intermediate AppRiver SPF Record: How To Set It Up (Owned By Zix) Aug 4, 2026 ](/blog/appriver-spf-record-setup-guide-for-zix-email-security-platform/)[ Intermediate 8m Best DMARC Reporting Tools in 2026: Honest Comparison Mar 25, 2026 ](/blog/best-dmarc-reporting-tools-2026/) ```json {"@context":"https://schema.org","@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com","logo":{"@type":"ImageObject","url":"https://dmarcreport.com/images/dmarcreport-logo.png"},"description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]},"sameAs":["https://www.wikidata.org/wiki/Q138898167","https://www.linkedin.com/company/duocircle","https://x.com/duocirclellc","https://www.g2.com/products/dmarc-report/reviews","https://github.com/duocircle","https://www.crunchbase.com/organization/duocircle-llc","https://www.trustradius.com/products/duocircle/reviews"],"aggregateRating":{"@type":"AggregateRating","ratingValue":"4.8","reviewCount":"471","bestRating":"5","worstRating":"1","url":"https://www.g2.com/products/dmarc-report/reviews"},"contactPoint":{"@type":"ContactPoint","contactType":"customer support","url":"https://dmarcreport.com/support/"},"knowsAbout":["DMARC","DMARC Reporting","DMARC Aggregate Reports","DMARC Forensic Reports","Sender Policy Framework","DKIM","Email Authentication","Email Security","DNS Management","Email Deliverability"]} ``` ```json {"@context":"https://schema.org","@type":"WebSite","name":"DMARC Report","url":"https://dmarcreport.com","description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","publisher":{"@type":"Organization","name":"DMARC Report","url":"https://dmarcreport.com","logo":{"@type":"ImageObject","url":"https://dmarcreport.com/images/dmarcreport-logo.png"},"description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]}}} ``` ```json [{"@context":"https://schema.org","@type":"BlogPosting","headline":"SPF Authentication: Understanding SPF -all vs ~all","description":"Learn the key differences between SPF -all and ~all, how each affects email authentication, and when to use them for stronger domain security.","url":"https://dmarcreport.com/blog/spf-authentication-understanding-spf-all-vs-all/","datePublished":"2026-08-20T00:00:00.000Z","dateModified":"2026-08-20T00:00:00.000Z","dateCreated":"2026-08-20T00:00:00.000Z","author":{"@type":"Person","@id":"https://dmarcreport.com/authors/brad-slavin/#person","name":"Brad Slavin","url":"https://dmarcreport.com/authors/brad-slavin/","jobTitle":"General Manager","description":"Brad Slavin is the founder and General Manager of DuoCircle, the company behind DMARC Report, AutoSPF, Phish Protection, and Mailhop. He founded DuoCircle in 2014 and has led the company's growth to 2,000+ customers across its email security product family. Brad's focus is product strategy, customer relationships, and the commercial and compliance side of email authentication (DPAs, SLAs, enterprise procurement).","image":"https://media.mailhop.org/dmarcreport/images/team/brad-slavin.jpg","knowsAbout":["Email Security Strategy","SaaS Product Management","Enterprise Compliance","Customer Success","Email Deliverability Business"],"worksFor":{"@type":"Organization","name":"DMARC Report","url":"https://dmarcreport.com"},"sameAs":["https://www.linkedin.com/in/bradslavin"]},"publisher":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com","logo":{"@type":"ImageObject","url":"https://dmarcreport.com/images/dmarcreport-logo.png"},"description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]},"sameAs":["https://www.wikidata.org/wiki/Q138898167","https://www.linkedin.com/company/duocircle","https://x.com/duocirclellc","https://www.g2.com/products/dmarc-report/reviews","https://github.com/duocircle","https://www.crunchbase.com/organization/duocircle-llc","https://www.trustradius.com/products/duocircle/reviews"],"aggregateRating":{"@type":"AggregateRating","ratingValue":"4.8","reviewCount":"471","bestRating":"5","worstRating":"1","url":"https://www.g2.com/products/dmarc-report/reviews"},"contactPoint":{"@type":"ContactPoint","contactType":"customer support","url":"https://dmarcreport.com/support/"},"knowsAbout":["DMARC","DMARC Reporting","DMARC Aggregate Reports","DMARC Forensic Reports","Sender Policy Framework","DKIM","Email Authentication","Email Security","DNS Management","Email Deliverability"]},"mainEntityOfPage":{"@type":"WebPage","@id":"https://dmarcreport.com/blog/spf-authentication-understanding-spf-all-vs-all/"},"articleSection":"intermediate","keywords":"","image":{"@type":"ImageObject","url":"https://media.mailhop.org/dmarcreport/dmarc-check-5211-1787229992086.jpg","caption":"SPF authentication qualifiers comparison"},"speakable":{"@type":"SpeakableSpecification","cssSelector":[".answer-block","h1"]}}] ``` ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://dmarcreport.com/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://dmarcreport.com/blog/"},{"@type":"ListItem","position":3,"name":"Intermediate","item":"https://dmarcreport.com/intermediate/"},{"@type":"ListItem","position":4,"name":"SPF Authentication: Understanding SPF -all vs ~all","item":"https://dmarcreport.com/blog/spf-authentication-understanding-spf-all-vs-all/"}]} ```