Will switching to -all block my newsletter or CRM mail?

Only if that system is not in your SPF record or does not sign with DKIM for your domain. Do the test sends in Step 2 first; anything that shows spf=pass keeps working after the change.

My provider's instructions say to use ~all. Are they wrong?

They are being cautious: ~all can never block your mail, so it can never generate a support ticket. It is the right starting point and the wrong place to stay. Once you have confirmed every sender, move to -all.

Does -all replace DMARC?

No. SPF says which servers may send; DMARC says what to do when neither SPF nor DKIM passes and aligns, and gives you the reports. Use both; the AstraVerify report shows the exact records.

What about a domain that never sends mail?

Publish v=spf1 -all with no includes, a DMARC record with p=reject, and a null MX (an MX record with priority 0 and the name "."). The check recognises this pattern and scores it as fully protected.

How many lookups is too many?

SPF allows ten DNS lookups per evaluation, counting every include, a, mx, redirect and exists mechanism and the lookups inside included records. Past ten, receivers return permerror and treat SPF as failed. The check shows your count.

SPF ~all vs -all: what the difference is and how to move safely

The last mechanism in an SPF record says what receivers should do with mail from a server the record does not list. ~all (softfail) says "probably not us, but accept it and mark it". -all (fail) says "not us, reject it". Almost every provider's setup guide ends the record with ~all because it can never block legitimate mail, and almost every domain keeps it that way for years. Across the domains checked on AstraVerify, ~all instead of -all is the single most common email finding, tied with DKIM not being turned on.

This guide explains what each ending does in practice, when ~all is the right choice, and how to get to -all in three steps without a single lost message.

What each ending means to a receiver

Ending	Name	What the sender is saying	What Gmail, Outlook and most receivers do	Effect on DMARC
-all	Fail	Only the listed servers send for this domain	Treat an unlisted server as a failure; with DMARC enforced, reject or quarantine	SPF fails cleanly, DMARC policy applies
~all	Softfail	The listed servers send for this domain; others probably do not	Accept, mark as softfail, weigh it in spam scoring	SPF still counts as a fail for DMARC; DMARC policy applies
?all	Neutral	No claim about unlisted servers	Ignore SPF	No SPF pass; DMARC relies on DKIM alone
+all	Pass	Any server may send for this domain	Ignore SPF or treat the domain as suspicious	Every spoofed message passes SPF; DMARC is useless

Why -all still matters when you have DMARC

A common objection: DMARC treats ~all and -all the same, so why bother. Two reasons. First, not every receiver enforces DMARC, and many smaller mail systems and older gateways still make their decision on SPF alone; for them ~all is a shrug and -all is a block. Second, -all is the statement of intent that DMARC alignment is built on: a record that ends in softfail tells a reader, human or machine, that the owner is not sure who sends for the domain. Scoring systems, including AstraVerify's, treat ~all as an open item for that reason.

The reverse objection is also fair: -all with an incomplete record blocks your own mail. That is why the move is done in three steps, not by editing one character.

Step 1: find every system that sends as your domain

Your mail provider is the obvious one. The rest hide in other departments: the CRM, the helpdesk, the invoicing tool, the newsletter platform, the website contact form, the scan-to-email function on the office printer, a developer's script that sends alerts. Each one either needs to be in your SPF record or needs to be sending through a server that is.

If you have a DMARC record with a reporting address (rua), the aggregate reports list every source IP that sent as your domain and whether it passed. Two weeks of reports is usually enough. Without DMARC reports, ask each team, and check the SPF include lines your providers document.

Example record

Name: yourdomain.com
Type: TXT
Value: v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net ~all

A typical finished list: mail provider, transactional mail service, newsletter platform. Keep it under ten DNS lookups; each include counts, and nested includes count too.

Step 2: check the record before you tighten it

Run the AstraVerify check. The SPF row shows the record, every include resolved, the lookup count against the limit of ten, and whether the record ends in -all.
Send a message from each system you listed to a mailbox you control (a Gmail address works). Open it, choose Show original, and read the SPF line: it should say pass, with the sending IP. A softfail here means that system is not in your record yet.
Fix anything that shows softfail or too many lookups. Consolidate includes where a provider offers one, or move low-volume systems to send through your mail provider's SMTP relay.

Step 3: switch to -all and verify

Change the final mechanism and nothing else. Wait for the TTL to pass (an hour at most for most zones), then repeat the test sends from every system and confirm they all still pass. Press Verify on the SPF row in your AstraVerify report; it re-reads the record and updates the score. From now on, a new sending system has to be added to SPF before it goes live, which is a good habit to make part of vendor onboarding.

Example record

Name: yourdomain.com
Type: TXT
Value: v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net -all

When ~all is the right answer for now

You have just published SPF and have no DMARC reports yet: keep ~all for two to four weeks while the reports show you every sender, then switch.
A system sends as your domain and cannot be authenticated (some legacy scanners and appliances): either route it through your provider's relay or give it its own subdomain with its own SPF, then tighten the main domain.
You forward mail through the domain: forwarding breaks SPF regardless of the ending; DKIM and ARC are the fix, not softfail.

Frequently asked questions

Will switching to -all block my newsletter or CRM mail?: Only if that system is not in your SPF record or does not sign with DKIM for your domain. Do the test sends in Step 2 first; anything that shows spf=pass keeps working after the change.
My provider's instructions say to use ~all. Are they wrong?: They are being cautious: ~all can never block your mail, so it can never generate a support ticket. It is the right starting point and the wrong place to stay. Once you have confirmed every sender, move to -all.
Does -all replace DMARC?: No. SPF says which servers may send; DMARC says what to do when neither SPF nor DKIM passes and aligns, and gives you the reports. Use both; the AstraVerify report shows the exact records.
What about a domain that never sends mail?: Publish v=spf1 -all with no includes, a DMARC record with p=reject, and a null MX (an MX record with priority 0 and the name "."). The check recognises this pattern and scores it as fully protected.
How many lookups is too many?: SPF allows ten DNS lookups per evaluation, counting every include, a, mx, redirect and exists mechanism and the lookups inside included records. Past ten, receivers return permerror and treat SPF as failed. The check shows your count.

Check your own domain. The scan shows your live records, a score out of 100 and the exact record to publish for each fix.