SPF Record Checker: Fix Duplicate and Missing SPF Records

Quick answer: what should an SPF checker look for?

A useful SPF checker should check whether your domain has:

The most common SPF issue is simple: the domain has more than one SPF record. SPF records must be merged, not stacked.

What is an SPF record?

SPF stands for Sender Policy Framework.

It is a DNS TXT record that says: these servers and services are allowed to send email for this domain.

For example, if your domain uses Google Workspace, your SPF record may authorize Google to send mail. If you use Microsoft 365, your SPF record may authorize Microsoft. If you also use Mailchimp, HubSpot, Klaviyo, Stripe, Shopify, or another system to send emails from your domain, those services may also need to be included.

SPF does not receive email. It helps authenticate outgoing email.

Receiving email is mainly controlled by MX records. Sending authorization is where SPF comes in.

What does an SPF record look like?

A typical SPF record is published as a TXT record at the root domain.

Example for a Google Workspace-only domain:

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

Example for a Microsoft 365-only domain:

v=spf1 include:spf.protection.outlook.com -all

These examples are common, but do not copy them blindly. Your correct SPF record depends on which services actually send email for your domain.

SPF record parts explained

Here is a basic SPF record:

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

Another example:

v=spf1 include:spf.protection.outlook.com -all

The ending mechanism matters, but it should not be changed aggressively unless you understand your full sending setup.

Common SPF ending mechanisms

SPF records usually end with one of these:

For many small businesses, ~all is a safer starting point while auditing senders. Once you know every legitimate sending source is included, -all may be appropriate.

Avoid +all. It tells receivers that everyone is allowed to send for the domain, which defeats the point of SPF.

Why duplicate SPF records are a problem

A domain should have one SPF record, not several.

This is wrong:

v=spf1 include:_spf.google.com ~all
v=spf1 include:spf.protection.outlook.com ~all

This does not mean Google and Microsoft are both allowed. It means the domain has duplicate SPF records, which can cause SPF evaluation errors.

If both Google and Microsoft genuinely send email for the same domain, the record must be merged into one SPF record:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

But only include both if both really send email for your domain.

Why duplicate SPF happens so often

Duplicate SPF records usually happen because every platform gives you its own setup instructions.

You might see instructions like:

• Google Workspace says to add Google SPF
• Microsoft 365 says to add Microsoft SPF
• Mailchimp says to add its SPF or authentication record
• HubSpot gives DNS authentication records
• Shopify or another ecommerce platform gives records
• A developer adds something for a contact form
• A previous IT vendor left old DNS records behind

Each instruction may be correct by itself. The mistake is adding each one as a separate SPF record.

The correct approach is to maintain one combined SPF record for the domain.

How to check your SPF record

To check SPF manually, inspect the TXT records for your root domain.

For example, check:

example.com

Look for any TXT record that starts with:

v=spf1

Possible outcomes:

Remember: SPF for example.com and SPF for mail.example.com are different records. Check the domain you actually send from.

Missing SPF record: what it means

If your domain has no SPF record, receiving servers do not have a public SPF policy to check.

This does not always mean every email will bounce. But it does mean your domain is missing an important email authentication layer.

Common symptoms of missing SPF

• Emails land in spam more often
• Some recipients mark mail as suspicious
• DMARC alignment may rely entirely on DKIM
• Email provider setup checklists show incomplete DNS
• Your domain looks less mature to receiving systems

How to fix missing SPF

1. Identify your email provider.
2. Identify all other services that send from your domain.
3. Get the official SPF include value from each sending provider.
4. Create one SPF TXT record at the root domain.
5. Save it at the active DNS host.
6. Recheck the domain after DNS propagation.

Duplicate SPF record: how to fix it

If your domain has two or more SPF records, do not simply delete one at random.

Use this process:

Step 1: Copy all existing SPF records

Example:

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

v=spf1 include:spf.protection.outlook.com ~all

v=spf1 include:servers.mcsv.net ~all

Step 2: Identify which services are still used

Ask:

• Do we still use Google Workspace?
• Do we still use Microsoft 365?
• Do we still use this email marketing platform?
• Do we still use this CRM?
• Do website contact forms send through this service?
• Is this old provider still needed?

Remove services that no longer send email for your domain.

Step 3: Merge valid mechanisms into one record

Merged example:

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

This example keeps Google and Mailchimp-like sending, but removes Microsoft if Microsoft is not actually used.

Step 4: Publish only the merged SPF record

Delete the old duplicate SPF records after creating the merged one.

Final result should be:

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

Only one TXT record should start with v=spf1.

SPF for Google Workspace

If your domain sends email only through Google Workspace, Google's SPF include is commonly:

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

Use this when Google Workspace is your actual outgoing email provider.

If you also send from other platforms, do not create a second SPF record. Add those services into the same SPF record.

Example:

v=spf1 include:_spf.google.com include:example-sender.com ~all

Replace example-sender.com with the real include value from your provider.

SPF for Microsoft 365

If your domain sends email only through Microsoft 365, Microsoft's common SPF include is:

v=spf1 include:spf.protection.outlook.com -all

If you also send from another service, merge the sender into one SPF record.

Example:

v=spf1 include:spf.protection.outlook.com include:example-sender.com -all

Only use the exact include values provided by your actual platforms.

SPF for email marketing tools, CRMs, and website forms

Many businesses send email from more than one place.

Common sending sources include:

• Google Workspace or Microsoft 365
• Email marketing tools
• CRM platforms
• Ecommerce platforms
• Helpdesk systems
• Invoicing tools
• Booking platforms
• Website contact forms
• SMTP plugins
• Transactional email providers

Each tool may send email using your domain. If it does, it may need SPF, DKIM, or both.

Important: some modern platforms rely more on DKIM and custom return-path setup than SPF. Do not assume every tool must be added to SPF unless the provider's documentation says so.

SPF and website contact forms

A common issue happens with website contact forms.

Your website may send notification emails from an address like:

hello@example.com

But the server actually sending the email may be:

• Your web host
• A WordPress SMTP plugin
• Mailgun
• SendGrid
• Amazon SES
• Postmark
• Brevo
• Another SMTP service

If your contact form sends as your domain, that sending service should be authenticated properly.

For best reliability, use a proper SMTP or transactional email provider instead of unauthenticated hosting mail.

SPF and subdomains

SPF is checked against the domain used in the message's return-path/envelope sender, not simply the visible From address.

Still, from a practical DNS-management perspective, remember this:

example.com

and:

mail.example.com

and:

news.example.com

can each have different SPF records.

If your marketing platform sends from a subdomain such as:

news.example.com

then the SPF record may need to be added to that subdomain, not the root domain.

Always follow the exact host/name provided by the sending platform.

Common SPF mistakes

SPF and the 10 DNS lookup limit

SPF has a DNS lookup limit. Mechanisms such as include, a, mx, ptr, and redirect can trigger additional DNS lookups.

If your SPF record includes too many third-party services, SPF can exceed the lookup limit and fail.

Example of a risky SPF record:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:service1.com include:service2.com include:service3.com include:service4.com include:service5.com include:service6.com ~all

This may look valid, but it can break if the includes expand into too many DNS lookups.

How to reduce SPF lookup risk

• Remove providers you no longer use
• Use subdomains for different sending platforms
• Avoid unnecessary mx and a mechanisms
• Do not include both old and new providers during migration longer than needed
• Prefer provider-recommended records rather than manually copying internal SPF chains
• Use DKIM and DMARC properly, not SPF alone

If your SPF record is already long, do not keep adding includes without reviewing it.

SPF during email migration

SPF mistakes often happen during migrations.

For example, you move from Google Workspace to Microsoft 365. During the migration, you may temporarily need both providers authorized. After the migration, you may only need Microsoft.

Temporary migration SPF:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

After migration is complete, if Google no longer sends for the domain:

v=spf1 include:spf.protection.outlook.com -all

Do not leave old providers in SPF forever unless they still send legitimate email.

SPF vs DKIM vs DMARC

SPF is only one part of email authentication.

SPF answers: is this sending server allowed?

DKIM answers: was this message signed by an authorized domain key?

DMARC answers: did SPF or DKIM align with the visible From domain, and what policy should apply if they fail?

A good email DNS setup usually needs all three.

Does SPF guarantee email deliverability?

No.

SPF helps with authentication, but it does not guarantee inbox placement.

Deliverability can also depend on:

• DKIM
• DMARC
• Domain reputation
• IP reputation
• Email content
• Sending volume
• Complaint rate
• Bounce rate
• Recipient engagement
• Whether your domain is new
• Whether you send cold email

SPF is necessary, but it is not a magic inboxing tool.

Safe SPF fixing workflow

Use this workflow before changing DNS:

1. Check active nameservers.
2. Confirm where DNS is actually managed.
3. Find all TXT records that start with v=spf1.
4. If none exist, create one based on your real sending services.
5. If multiple exist, merge valid mechanisms into one record.
6. Remove old senders you no longer use.
7. Avoid +all.
8. Check DNS lookup count if the record is long.
9. Save the record.
10. Recheck after DNS propagation.
11. Send a test email and review authentication results.

Example SPF fixes

Example 1: Missing SPF

Current result:

No SPF record found

If the domain only sends through Google Workspace:

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

If the domain only sends through Microsoft 365:

v=spf1 include:spf.protection.outlook.com -all

Example 2: Duplicate SPF

Current result:

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

v=spf1 include:servers.mcsv.net ~all

Correct merged record:

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

Then delete the two old separate SPF records.

Example 3: Old provider still included

Current result:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:oldservice.com ~all

If the domain now only sends through Google Workspace and the old service is no longer used:

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

Do not remove senders unless you are sure they no longer send legitimate email.

Example 4: Unsafe SPF

Current result:

v=spf1 +all

This is unsafe because it authorizes everyone.

A safer Google Workspace-only record would be:

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

A safer Microsoft 365-only record would be:

v=spf1 include:spf.protection.outlook.com -all

What to check before deleting an SPF include

Before removing a sender from SPF, ask:

• Do we still use this provider?
• Does it send email using our domain?
• Is it used for invoices, receipts, password resets, or booking confirmations?
• Is it used by the website contact form?
• Is it used by marketing or sales automation?
• Is it used by a CRM or helpdesk?
• Is it part of an old migration?
• Does DKIM cover this sender instead?

Deleting the wrong include can break legitimate outgoing email.

SPF checklist for small businesses

Use this checklist:

• One SPF record only
• SPF exists at the correct domain
• SPF is edited at the active DNS host
• Main email provider is included
• Third-party senders are included only if needed
• Old providers are removed
• SPF does not use +all
• SPF syntax starts with v=spf1
• SPF ends with a clear all mechanism
• DNS lookup count is not excessive
• DKIM and DMARC are also configured

Final recommendation

If your SPF record is missing, add one based on your real email provider.

If your domain has duplicate SPF records, do not stack them. Merge the legitimate sending mechanisms into one SPF record and delete the duplicates.

If your SPF record is long, audit it carefully before adding more includes.

A clean SPF record is simple, intentional, and current.