Why You Should Avoid +all in Your SPF Record

Learn what +all means in SPF, why it weakens email authentication, and how to replace it with a safer SPF policy.

By CheckDomainHealth Editorial Team Reviewed by Dionis Ceban Updated Jun 28, 2026 6 min read Beginner

Introduction

The +all mechanism is one of the most dangerous SPF settings because it tells receiving mail servers that every sender is allowed to send email for your domain.

In most cases, +all should not be used. It weakens SPF protection, makes spoofing easier to pass SPF checks, and can make your domain look poorly configured. A safer SPF record should list only real sending services and end with a policy such as ~all or -all.

Quick answer

Quick answer

+all means “pass all senders.” It allows any server to pass SPF for your domain, which defeats the main purpose of SPF. Most domains should replace +all with ~all while testing or -all only after confirming all legitimate senders are included.

What +all means

In SPF, the all mechanism matches any sender that did not match earlier mechanisms. The + qualifier means pass.

So this SPF record:

Example 
v=spf1 +all

means: Any server is allowed to send email for this domain.

This is usually not what you want. SPF is meant to define authorized senders, not approve every possible sender.

Why +all is risky

It allows every sender

Any server can pass SPF because +all returns a pass result.

It weakens domain protection

SPF no longer helps distinguish real senders from unauthorized ones.

It can help spoofed messages pass SPF

Attackers may be able to send mail that passes SPF for the domain.

It can hurt trust

A domain with +all may look misconfigured to mail administrators and security tools.

It breaks the purpose of SPF

Instead of listing authorized senders, the record authorizes everyone.

+all vs ~all vs -all

+all

  • Meaning: Pass all senders.
  • Use: Usually avoid.
  • Risk: Makes SPF ineffective.

v=spf1 +all

~all

  • Meaning: Soft fail for unlisted senders.
  • Use: Good while testing or when not fully sure all senders are included.
  • Risk: Less strict, but safer during setup.

v=spf1 include:_spf.google.com ~all

-all

  • Meaning: Fail unlisted senders.
  • Use: Use after confirming all legitimate senders are included.
  • Risk: Can fail real mail if the SPF record is incomplete.

v=spf1 include:_spf.google.com -all

?all

  • Meaning: Neutral for unlisted senders.
  • Use: Rarely useful for strong authentication.
  • Risk: Weak guidance.

v=spf1 include:_spf.google.com ?all

For many domains, ~all is the safest replacement while reviewing SPF.

Why this matters

Why this matters

This matters because SPF is supposed to tell receivers which servers are allowed to send email for your domain. If your SPF record ends in +all, the record gives permission to every sender, including unauthorized ones.

+all does not guarantee inbox placement. It only makes SPF pass too broadly, which can reduce the value of your email authentication setup.

How to check for +all

Use the SPF Checker to inspect the domain’s SPF TXT record and review the final all policy.

When checking for +all, review

These five checks help identify risky SPF policies.

SPF record exists

Confirm the domain publishes an SPF TXT record.

Final policy

Check whether the record ends with +all, ~all, -all or ?all.

Authorized senders

Confirm the record lists only real sending providers and IPs.

Duplicate records

Make sure the domain does not publish multiple SPF records.

DKIM and DMARC

Check whether SPF is supported by DKIM and DMARC.

Check SPF policy now

Use SPF Checker to inspect your SPF record and final all policy.

Run SPF Check →

Common problems

SPF record is v=spf1 +all

High

The domain allows every sender to pass SPF.

Next step: Replace +all with a proper SPF record listing only real senders.

+all added during testing and never removed

High

Temporary permissive SPF settings were left in production.

Next step: Review real senders and replace +all with ~all or -all.

Provider told user to add +all incorrectly

Medium

Some old or incorrect instructions may suggest overly permissive SPF.

Next step: Use official current SPF values from your real email providers.

SPF includes real providers but still ends with +all

High

Even if real providers are listed, +all still allows everyone else.

Next step: Change the final policy to ~all or -all after reviewing senders.

Domain has no DKIM or DMARC

Medium

A weak SPF policy is even worse when DKIM and DMARC are also missing.

Next step: Configure DKIM and DMARC after fixing SPF.

Fear of breaking email prevents fixing +all

Medium

The record stays permissive because the sender list is unknown.

Next step: Start with ~all while auditing sending sources.

How to replace +all

  1. Step 1: List legitimate senders

    Identify all services that send mail for your domain, including mailbox provider, hosting server, CRM, billing system, marketing platform, website forms and transactional email tools.

  2. Step 2: Get official SPF values

    Use the official SPF include or IP values from each provider.

  3. Step 3: Build one SPF record

    Create a single SPF TXT record that includes only real senders.

  4. Step 4: Replace +all with ~all first

    If you are unsure whether all senders are included, use ~all while testing.

  5. Step 5: Validate with SPF Checker

    Check syntax, duplicate records, mechanisms and lookup count.

  6. Step 6: Review DKIM and DMARC

    After SPF is fixed, configure DKIM and DMARC for stronger authentication.

  7. Step 7: Consider -all later

    Move to -all only after confirming all legitimate senders are included and email authentication is stable.

SPF examples

Unsafe 
v=spf1 +all
Still unsafe 
v=spf1 include:_spf.google.com +all
Safer while testing 
v=spf1 include:_spf.google.com ~all
Stricter after validation 
v=spf1 include:_spf.google.com -all
Multiple real providers 
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

These are examples only. Use the SPF values from your real providers. Do not copy example records into production without checking your sending sources.

What to use instead

Use a real SPF record that lists authorized senders.

~all

Best while testing, migrating or auditing senders.

-all

Best when all legitimate senders are known and SPF is stable.

Do not jump directly from +all to -all if you do not know every service sending mail for the domain. Start with ~all, test, then decide whether stricter enforcement is safe.

In normal production email setups, +all should almost never be used. It may appear in testing, temporary troubleshooting or badly written examples, but it should not remain on a real business domain.

If you see +all on a live domain, treat it as a configuration problem that should be reviewed.

Frequently asked questions

What does +all mean in SPF?

+all means every sender passes SPF. It allows any server to send mail that passes SPF for the domain.

Is +all bad?

Yes, for normal production domains it is usually bad because it defeats the purpose of SPF.

What should I use instead of +all?

Use ~all while testing or -all after confirming all legitimate senders are included.

Can +all improve email delivery?

No. It may make SPF pass broadly, but it does not create real trust and can make the domain look misconfigured.

Can I change +all directly to -all?

Only if you are sure all legitimate senders are included. Otherwise, use ~all first while testing.

Does fixing +all mean I am fully protected?

No. You should also configure DKIM and DMARC and maintain good sending practices.

Use these free tools to verify your configuration after applying changes.

SPF Checker DKIM Checker DMARC Checker MX Lookup Domain Health Checker
SPF Basics: Defining Authorized Senders 7 min read Creating a Valid SPF Record: Common Syntax Mistakes 7 min read SPF Qualifiers and Mechanisms Explained 8 min read What Is DMARC 5 min read DMARC for Beginners: Policies, Alignment and Enforcement 8 min read
Browse all Email Authentication guides →

Need help applying this fix?

Send us your domain, report link or issue details. CheckDomainHealth will review the request and route it to the right technical team if hands-on support is needed.

Get Help Run Domain Health Check

Was this guide helpful?

Your feedback helps us improve our guides for everyone.