How to Check an SPF Record

An SPF record helps receiving email systems decide whether a server is allowed to send email using your domain. Checking it is a good first step when business email starts going to spam, bounces unexpectedly, or fails an authentication check. But simply finding "an SPF record" is not enough. A record can exist and still be incomplete, duplicated, outdated, or too complex for receiving servers to evaluate. Here's how to check it properly.

What an SPF record does

SPF stands for Sender Policy Framework. It is a DNS TXT record that lists the services allowed to send email for your domain. For example, your business may send email through:

• Google Workspace or Microsoft 365
• A newsletter platform
• A CRM
• A support desk
• An ecommerce platform
• A transactional-email provider

Your SPF record should authorize every service that legitimately sends as your domain. A basic SPF record might look like this:

v=spf1 include:provider.example -all

v=spf1 identifies the record as SPF. The include: portion authorizes a provider's published sending infrastructure. The ending, -all, says that senders not listed in the record should fail SPF. Do not copy this example into your DNS settings. Your record must match the services your own business uses.

Step 1: Make a list of every system that sends email

Before editing DNS, make an inventory of every system that may send email using your domain. This often includes more than the company mailbox. For example, a business might use Google Workspace for employee email, Mailchimp for newsletters, Stripe for receipts, Zendesk for support, and a website form tool for notifications. If you forget one legitimate sender, you may remove its authorization while trying to fix another problem. Ask these questions:

• Where do employees send email from?
• What tool sends newsletters or marketing campaigns?
• What tool sends invoices, receipts, or password resets?
• Does the website send form notifications?
• Has the business changed email platforms recently?
• Are any old tools still sending from the domain?

Write the answers down. This list is the foundation for a safe SPF setup.

Step 2: Find the SPF TXT record

An SPF record is stored in DNS as a TXT record. A free domain check can show the published record and flag common issues. There should usually be one SPF record for a domain. A frequent problem is publishing separate SPF records for separate services, such as one for Microsoft 365 and another for a newsletter provider. That does not combine the two permissions. Receiving servers may treat multiple SPF records as an error. Instead, the authorized services need to be combined into one record.

Step 3: Read the important parts

You do not need to memorize SPF syntax, but you should recognize the parts that matter. Common mechanisms include:

• include: — authorizes another domain's published SPF policy.
• ip4: or ip6: — authorizes a specific sending IP address.
• a — authorizes the IP address behind a domain's A record.
• mx — authorizes the servers listed in the domain's MX records.
• redirect= — points SPF evaluation to another domain's policy.

Most businesses use provider-supplied include: mechanisms. Use the provider's current setup instructions rather than copying an include from an old article, another company, or a forum post. Also look at the ending:

• -all means unlisted senders should fail.
• ~all means unlisted senders should soft-fail.
• ?all means neutral.

The right ending depends on whether you have fully identified and authorized every legitimate sender. Do not switch to a strict ending just because it looks more secure if you still have unknown senders.

Step 4: Check for the 10-DNS-lookup limit

SPF has a hard limit of ten DNS lookups during evaluation. This matters because an SPF record can look short while the providers it includes perform additional lookups behind the scenes. Includes inside includes still count. For example, adding several marketing, support, and transactional platforms can eventually create an SPF record that exceeds the limit. When that happens, SPF can return a permanent error instead of a pass or fail result. Do not solve this by deleting includes at random. First determine whether the related service is still sending email. If it is, removing it may cause legitimate mail to fail authentication. If you are near or above the limit:

1. Remove services that are genuinely retired.
2. Confirm the remaining providers' official SPF instructions.
3. Avoid duplicate or unnecessary includes.
4. Consider an SPF-management or flattening approach only after understanding the maintenance tradeoff.

Read more about SPF lookup limits and SPF flattening.

Step 5: Make one change at a time

DNS changes can take time to appear everywhere because DNS systems cache records. Before changing anything:

1. Copy the existing SPF record somewhere safe.
2. Record why you are making the change.
3. Add or remove only the verified provider entry.
4. Wait for DNS propagation.
5. Recheck the record.
6. Send a test email from every active platform.

Making several edits at once makes it difficult to tell what fixed the problem—or what caused a new one.

Step 6: Test real messages, not just DNS

A correct-looking SPF record is useful, but a real email test provides stronger evidence. Send a message from each active platform to a mailbox you control. View the message headers and look for the authentication results. You want to know:

• Did SPF pass?
• Which domain was evaluated for SPF?
• Did DKIM pass too?
• Did DMARC pass?
• Does the authenticated domain align with the visible From address?

SPF can pass while DMARC still fails. That can happen when the envelope sender or Return-Path domain does not align with the From address your recipient sees. That is why SPF should be checked alongside DKIM and DMARC.

Common SPF mistakes

Publishing more than one SPF record

A domain should normally have one SPF TXT record. Multiple records can create an SPF error.

Leaving old services authorized

A retired provider does not need to remain in the record. Removing it after confirming it is inactive reduces complexity and attack surface.

Forgetting a legitimate sender

A new CRM, support desk, or ecommerce platform may start sending email without being included in the SPF record.

Exceeding the lookup limit

Nested provider includes can quietly push SPF over ten DNS lookups.

Treating SPF as the whole solution

SPF is important, but it does not replace DKIM, DMARC, sender reputation, list hygiene, or responsible sending practices.

Frequently asked questions

Can I create a separate SPF record for each email provider? No. Combine authorized providers into one SPF record. Will fixing SPF immediately move all of my email to the inbox? Not necessarily. SPF is one authentication signal. Inbox placement also depends on DKIM, DMARC alignment, reputation, recipient engagement, list quality, and sending behavior. How often should I check SPF? Check it whenever you add, remove, or migrate an email service. It is also worth monitoring because DNS records can change after a provider update, site migration, or accidental edit. What should I do if I do not know who added an SPF include? Do not remove it immediately. Identify the service, check whether it is still used, and test before making a change.

The practical next step

Run a free check on your domain to see the SPF record currently visible to the public. Then compare it with your list of real sending services. Once the record is correct, keep an eye on it. A working email setup can break later when a vendor changes, an old tool is reactivated, or someone edits DNS during unrelated work. Run a free Beacon domain check →