{"id":17237,"date":"2024-10-09T18:39:00","date_gmt":"2024-10-09T18:39:00","guid":{"rendered":"https:\/\/easydmarc.com\/blog\/?p=17237"},"modified":"2025-05-08T18:40:08","modified_gmt":"2025-05-08T18:40:08","slug":"spf-authentication-spf-all-vs-all","status":"publish","type":"post","link":"https:\/\/easydmarc.com\/blog\/spf-authentication-spf-all-vs-all\/","title":{"rendered":"SPF Authentication: SPF-all vs ~all"},"content":{"rendered":"

What is SPF? <\/span>Sender Policy Framework (SPF) lets the admin specify what IP addresses are allowed to send emails on a domain\u2019s behalf. This authorization is published as a TXT record in the DNS Provider (Cloudflare, GoDaddy, etc.). Note that SPF checks against the <\/span>5321.MailFrom<\/b> address (also known as <\/span>Return-Path<\/i><\/b>, <\/span><\/i>Envelope From,<\/i><\/b> or <\/span>Bounce<\/i><\/b> address) to authorize sending IP addresses. <\/span>The recipient’s mail server, if it adheres to the sender’s domain SPF policy, should act in accordance with the published SPF policy.<\/span><\/p>\n

There’s been a historical dispute related to using SPF\u00a0hard fail or soft fail since the inception of Sender Policy Framework in 2004.<\/span><\/p>\n

In this article, we’ll discuss <\/span>why you should use SPF\u00a0softfail vs hardfail (-all vs ~all)?<\/span><\/p>\n

\"\"<\/a><\/p>\n

SPF Record: what does it look like?<\/span><\/h2>\n

SPF TXT record starts with the SPF version indicator followed by all the \u2018whitelisted\u2019 IP addresses that are authorized to send emails on a domain\u2019s behalf, ending with an <\/span>all<\/b> tag. Here are the possible ones:<\/span><\/p>\n

    \n
  1. -all (Fail): email from servers \/ IP addresses, not listed in the SPF record, should be <\/span>rejected<\/span><\/i>.<\/span><\/li>\n
  2. ~all (SoftFail): emails from servers \/ IP addresses, not listed in the SPF record, should be <\/span>accepted but marked\u00a0<\/span><\/i><\/li>\n
  3. +all (Pass): any servers can send emails on your domain\u2019s behalf. <\/span>We highly recommend not to use this option<\/b>.\u00a0<\/span><\/li>\n
  4. ?all (Neutral): Interpreted as None \/ No policy. <\/span>We highly recommend not to use this option.<\/b><\/li>\n<\/ol>\n

    The tags above indicate what policy should be applied to email when MBPs (Mailbox Providers like Google, Microsoft, Yahoo!, etc.) detect that mail was sent from servers \/ IP addresses not listed in the SPF record. Using SPF hard fail or soft fail are the two more accepted methods. Still, the preference falls on the ~all.<\/span><\/p>\n

    Now that you know you shouldn’t be using +all and ?all, let’s review an example before we touch upon the SPF SoftFail vs HardFail issue. (Use our free SPF testing tool<\/a> to test your SPF records.)<\/span><\/p>\n

    SPF Record Example:<\/strong>
    \n<\/span><\/h3>\n

    v=spf1 ip4:172.16.254.1 ip4:213.22.138.0\/24 ip6:2001:db8:0:1234:0:567:8:1 include:_spf.google.com -all<\/span><\/p>\n

      \n
    1. v=spf1: SPF record should always start with <\/span>v=spf1<\/span><\/i> version number.<\/span><\/li>\n
    2. ip4 and ip6 mechanisms: Lists the single IP address (e.g 172.16.254.1 and 2001:db8:0:1234:0:567:8:1) or IP subnets (e.g. ip4:213.22.138.0\/24) that are authorized to send emails on a domain\u2019s behalf. Note that IPv4 addresses should be prefixed as \u201cip4\u201d, and IPv6 as \u201cip6\u201d tags.<\/span><\/li>\n
    3. \u201cinclude\u201d mechanism: Used to authorize third-party services that are used to send emails on your domain\u2019s behalf. In this example, the \u201c<\/span>_spf.google.com<\/b>\u201d authorizes Google Workspace (formerly G Suite) to send emails on behalf of your domain.<\/span><\/li>\n
    4. \u201call\u201d mechanism: In this example, the \u201c-all\u201d (Fail) tag is used.<\/span><\/li>\n<\/ol>\n

      Now, the example uses SPF record hardfail vs\u00a0<\/span>softfail, which will discard all the emails that fail the test, including the legitimate ones.<\/p>\n

      \"SPF-Record-Generator\"<\/p>\n

      SPF -all vs ~all: what should I use?\u00a0<\/span><\/h2>\n

      Before DMARC adoption (in 2012), SPF alone played a major role, despite its limitations, in fighting against Return-Path or MailFrom email spoofing attempts. MBPs applied rules based on the admins\u2019 expressed SPF record policies (~all or -all). Thus, this caused major issues with blocking legitimate emails due to SPF configuration errors, which led the majority and well-known MBPs to use both SoftFail (~all) and Fail (-all) as <\/span>accept but mark <\/span><\/i>method.<\/span><\/p>\n

      \n