How to Add an IP Address to Your SPF Record (Step-by-Step Guide)

To add an IP to your SPF record, edit your domain’s existing SPF TXT record in DNS and insert an ip4: (or ip6:) mechanism before the all mechanism. For example:

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

Important: Do NOT create a second SPF record. You must edit your existing one and before adding a raw IP, check whether your sending service provides an include: value instead, which is usually the better long-term choice.

This guide walks you through the full process, including finding your current record, choosing between ip4 and include, editing your DNS across popular providers, validating the result, and avoiding the mistakes that silently break email for thousands of domains every year.

What Is an SPF Record and Why Does It Matter in 2026?

SPF (Sender Policy Framework) is a DNS TXT record that lists the IP addresses and services authorized to send email from your domain. If a server’s IP is not on the list, receiving mail servers can reject or flag the message.

Google began enforcing bulk sender authentication requirements in February 2024, requiring SPF or DKIM plus DMARC for anyone sending more than 5,000 messages per day. 

As of November 2025, non-compliant emails face permanent rejections, not soft deferrals, but hard bounces. Yahoo enacted identical requirements on the same timeline. Microsoft followed in May 2025, rejecting unauthenticated bulk email outright with 550 errors.

Without a correct SPF record, your domain is exposed to spoofing and even your legitimate email may be rejected by Gmail, Yahoo, and Outlook. If your SPF record is broken, your email just stops arriving without any alerts. It silently fails on the receiving end, and you find out when a customer or colleague tells you they never got your message.

SPF Record Syntax Explained (With Examples)

Before adding anything to your record, you need to understand what each part does. Here is the anatomy of a typical SPF record:

v=spf1 ip4:192.0.2.1 ip4:203.0.113.0/24 include:_spf.google.com -all

Here are three real-world examples covering different levels of complexity:

Simple (single mail server):

v=spf1 ip4:198.51.100.25 -all

Typical SMB (Microsoft 365 + one marketing tool):

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

Complex enterprise (multiple services):

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:spf.brevo.com -all

Need to build a record from scratch? 

Use PowerDmarc’s free SPF record generator to create a syntactically correct record instantly.

How to Add an IP Address to Your SPF Record (Step-by-Step)

Adding an IP address to your SPF record is one of the most direct ways to authorize a sending source. It’s typically required when you’re using a dedicated server, a transactional email system, or any infrastructure you control.

While the change itself is simple, accuracy matters because incorrect entries or formatting issues can affect authentication and deliverability. The steps below walk through the process of adding an IP address to your SPF record correctly, without disrupting your existing configuration.

Step 1:Find Your Current SPF Record

Many domains already have an SPF record from a previous setup. If you create a new one without checking, you will end up with two and that breaks everything.

You can look up your current record in two ways. 

Use PowerDMARC’s free SPF checker tool for an instant visual result or run a command-line query:

nslookup -type=TXT yourdomain.com

dig TXT yourdomain.com

See how to instantly check your SPF record and identify configuration issues that could impact email deliverability

Look for a TXT record that starts with v=spf1. If you see one, that is your SPF record, and you will be editing it in Step 3. If you see two records both starting with v=spf1, you already have a problem, merge them into one before doing anything else.

Step 2: Identify the IP Address or Include: Value You Need to Add

There are two scenarios here, and the right choice depends on what you are authorizing:

Scenario A: You are adding a specific IP address. This applies when you run your own mail server on a static IP, or you have a dedicated sending IP you control. You need the exact IPv4 or IPv6 address of the server.

Scenario B: You are authorizing a third-party service. This applies to services like Mailchimp, SendGrid, HubSpot, Google Workspace, or Microsoft 365. In this case, you need the include: value from that service’s documentation, not their IP addresses.

Before you add a raw IP, read the section below on ip4 vs. include. For most third-party services, include: is the better long-term choice.

Step 3: Edit Your SPF Record in DNS

Log in to your DNS provider (your domain registrar or hosting provider), find the TXT records for your domain, and edit the existing SPF record. Add the new ip4: or include: mechanism BEFORE the all mechanism.

Here is how to do it on the most common providers:

• Cloudflare: Navigate to DNS → Records. Find the existing TXT record for your domain (@ or root) that starts with v=spf1. Click Edit. Add the new mechanism before the all tag. Click Save.
• GoDaddy: Go to My Products → DNS → DNS Records. Find the TXT record containing v=spf1. Click Edit. Modify the Value field to include the new mechanism before all. Save.
• Namecheap: Go to Domain List → Manage → Advanced DNS. Under TXT Records, find the SPF entry. Edit it to add the new mechanism. Save.
• AWS Route 53: Open Hosted Zones → select your domain → find the TXT record with v=spf1. Click Edit. Update the value (keep the surrounding quotes). Save.
• cPanel: Go to Email Deliverability → click Manage next to your domain → scroll to Suggested SPF Record → click Customize. Add the new IP in the IP Address section. Click Install.

Step 4: Validate Your Updated SPF Record

A single misplaced space, missing colon, or duplicate record can silently break email for your entire domain. Validation takes 30 seconds and prevents hours of troubleshooting.

Run through this checklist after every SPF change:

1. Run your domain through an SPF checker tool and confirm the record parses without errors.
2. Confirm you see only ONE SPF record (not two TXT records starting with v=spf1).
3. Check your total DNS lookup count. It must be 10 or fewer.
4. Verify the all mechanism is at the very end of the record.
5. Send a test email to a Gmail or Yahoo account, open the message, view the original headers, and look for spf=pass.

For a full security audit beyond SPF, run your domain through the PowerDMARC domain analyzer. It checks SPF, DKIM, DMARC, MTA-STS, and BIMI in one pass.

Step 5: Monitor SPF Authentication Results Over Time

Adding the IP is step one. Knowing whether it actually works and catching when it breaks later is step two.

DMARC aggregate reports are the primary way to get ongoing visibility into SPF pass/fail rates per sending source. Without monitoring, you are flying blind. Many administrators only discover a broken SPF record after customers start marking legitimate email as spam or an invoicing tool sends from an unauthorized IP for weeks without anyone noticing.

ip4 vs. include: Which Should You Use? (Decision Guide)

When to use ip4: (raw IP addresses):

• You run your own mail server on a static IP you control.
• You have a dedicated sending IP from an ESP that you own (not shared).
• You are authorizing an on-premises SMTP relay with a fixed address.

The rule: use ip4: only when YOU control the IP and it will not change.

When to use include: (delegated SPF):

• You are authorizing any third-party SaaS service, like Google Workspace, Microsoft 365, Mailchimp, SendGrid, HubSpot, Salesforce, Zendesk, or any cloud-based email tool.
• The service uses shared or rotating IPs.
• The service publishes its own SPF record that it maintains.

Why include: is almost always better for third-party services:

Cloud services rotate IP addresses regularly. If you hardcode their current IPs with ip4:, your SPF record goes stale when they migrate infrastructure and your email breaks with no warning. 

The include: mechanism delegates to the service’s own dynamically maintained SPF record. When they update their IPs, your SPF automatically reflects the changes with zero maintenance on your end.

[Image: Decision tree flowchart — “Is this a server/IP you own and control?” → YES → Use ip4 / NO → “Does the service provide an include: value?” → YES → Use include (preferred) / NO → Use ip4 + set a quarterly review reminder]

[Alt text: Decision flowchart showing when to use ip4 vs include mechanism in SPF records]

For a deeper dive on include syntax and best practices, see the full SPF include guide.

Common Third-Party SPF Include Values (Quick Reference Table)

This table eliminates the need to search for each service’s SPF documentation separately. Bookmark it for the next time marketing signs up for a new tool.

Table: Quick reference of SPF include values for popular email services. Always verify the current value in each service’s official documentation, providers occasionally update these.

Important: Each include: counts as at least one DNS lookup, and many third-party SPF records contain nested includes that add more. If you are using five or more services, you are likely approaching the 10-lookup limit. See the next section for how to handle this.

The 10 DNS Lookup Limit And What to Do When You Hit It

RFC 7208 caps SPF evaluation at 10 DNS-querying mechanisms. The mechanisms that count are: include, a, mx, redirect, and exists. The mechanisms that do NOT count are: ip4, ip6, and all. These are evaluated locally without a DNS query.

When your record exceeds 10 lookups, SPF returns a PermError. Many receiving servers treat a PermError as an SPF failure. Your email deliverability drops, and you get no notification that it happened.

There is also a lesser-known constraint: the 2-void-lookup limit. If more than two DNS queries return NXDOMAIN (domain not found) during SPF evaluation, SPF also fails.

Here are three ways to fix it, ranked by practicality:

Option 1: Remove Unused Mechanisms

Start with an audit. Remove include: statements for services you no longer use. Remove a and mx mechanisms if you do not send email from your domain’s a or mx record IPs. This is the fastest fix and often frees up 2–3 lookups immediately.

Option 2: Manual SPF Flattening

Resolve your include: mechanisms down to their underlying IP addresses and hardcode them as ip4: entries. This eliminates the DNS lookups those includes would have consumed.

This creates an ongoing maintenance burden. Email service providers change or add to their IP ranges without notifying you. When they do, your flattened record goes stale, and legitimate email starts failing. Manual SPF flattening is like mowing the lawn. It works, but you have to do it again every few weeks.

Option 3: SPF Macros or Automated Flattening

The modern approach uses SPF Macros (defined in RFC 7208 §7), which dynamically expand at evaluation time to keep your record under the lookup ceiling without manual IP maintenance. 

Automated flattening tools handle this continuously, re-resolving provider IPs on a schedule and updating your published record.

SPF Alone Isn’t Enough: Why DKIM and DMARC Complete the Picture

SPF checks the envelope sender (MAIL FROM) IP address against your authorized list. It works when email travels directly from sender to receiver but when email is forwarded, through mailing lists, auto-forwarding rules, shared mailboxes, or any relay, the sending IP changes. SPF breaks, because the forwarding server’s IP is not in your SPF record, and it should not be.

DKIM (DomainKeys Identified Mail) works differently. It attaches a cryptographic signature to the email body. That signature travels with the message regardless of which server relays it. DKIM survives forwarding but SPF does not.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties them together. It requires only ONE of SPF or DKIM to pass and align with your From domain for the message to pass DMARC. 

In practice, DKIM is the more reliable alignment mechanism because it is not affected by forwarding.

This is why having both matters:

• Google requires SPF or DKIM for all senders, plus DMARC for bulk senders (5,000+ messages/day). As of November 2025, non-compliant messages receive permanent rejections.
• Microsoft began rejecting unauthenticated bulk email in May 2025.
• Yahoo enforces the same requirements on the same timeline as Google.

If SPF is your only authentication mechanism, your domain is still vulnerable to impersonation on any forwarded email path and you are not fully compliant with 2026 inbox provider requirements.

What to do next:

1. Set up DKIM for every service that sends email from your domain.
2. Publish a DMARC record (start with p=none for monitoring, then progress to p=reject).
3. Monitor DMARC aggregate reports to see which sources pass or fail SPF and DKIM.

SPF Records for Domains That Don’t Send Email

If you own domains that are parked, inactive, or used only for websites. They still need SPF protection. Attackers actively spoof unused domains precisely because they are often left unprotected.

The fix is simple. Publish this SPF record:

v=spf1 -all

This tells receiving servers that no one is authorized to send email from this domain. Any message claiming to come from it should be rejected.

For maximum protection, also publish a DMARC record with a reject policy:

v=DMARC1; p=reject; rua=mailto:[email protected]

This combination closes the door on spoofing for every domain you own, whether it sends email or not.

Common SPF Mistakes and How to Fix Them

SPF syntax errors are rampant, and the worst part is they fail silently. Here are the eight most common mistakes, what happens when you make them, and how to fix each one:

Table: The most common SPF record mistakes, their impact, and how to fix each one.

For a deeper look at troubleshooting SPF validation errors, see our guide on SPF validation errors and how to resolve them.

Conclusion

Adding an IP to your SPF record is a straightforward DNS edit but getting it right requires understanding the syntax, choosing between ip4: and include:, staying under the 10 DNS lookup limit, and validating the result after every change.

SPF is one layer of a complete email authentication stack. In 2026, with Google, Yahoo, and Microsoft all actively enforcing sender authentication mandates, SPF alone is not enough. DKIM and DMARC are equally essential for full protection and compliance.

As your organization adds more sending services, your SPF record will grow. Manual management does not scale and a single mistake can silently kill email delivery across your entire domain. Automated SPF management is not a luxury anymore. It is operational hygiene.

Stop managing SPF records manually. PowerDMARC gives you automated SPF flattening (PowerSPF), DMARC monitoring, DKIM management, and clear reporting across all your domains, in one platform. Start your free 15-day trial 

Frequently Asked Questions

1) Can I have two SPF records on the same domain?

No. RFC 7208 requires exactly one SPF TXT record per domain. If a domain has two records starting with v=spf1, receiving servers return a PermError and treat SPF as failed for every message. If you need to authorize additional sources, edit your existing record to add them, do not create a new one.

2) What is the difference between -all and ~all?

-all is a hard fail, it tells receiving servers to reject email from unauthorized IPs. ~all is a soft fail, it flags unauthorized email but does not mandate rejection. In practice, when DMARC is enforced with p=quarantine or p=reject, the difference is minimal because DMARC policy overrides the SPF qualifier. If you have DMARC at enforcement, either works. If you do not have DMARC yet, -all provides stronger protection.

3) How many IP addresses can I add to an SPF record?

There is no hard limit on the number of ip4: or ip6: mechanisms. These do not count toward the 10 DNS lookup limit. However, the total SPF record must fit within DNS TXT record size constraints (255 characters per string, with multiple strings concatenated up to approximately 4,096 characters). For large IP lists, use CIDR notation (e.g., ip4:192.0.2.0/24) to cover ranges efficiently.

4) How long does it take for SPF changes to take effect?

It depends on your DNS record’s TTL (Time to Live). If your TTL is 3600 (1 hour), most resolvers will pick up the change within 1 hour. To speed things up: lower your TTL to 300 (5 minutes) before making changes, wait for the old TTL period to expire, then make your edit. This dramatically reduces propagation time.

5) How do I find out which IPs are currently sending email from my domain?

The most reliable method is DMARC reporting. When you publish a DMARC record with an rua tag, receiving servers send daily aggregate reports listing every IP that attempted to send email from your domain, along with SPF and DKIM pass/fail results. Without DMARC, you are guessing. PowerDMARC processes these reports into clear, human-readable dashboards so you can see exactly who is sending from your domain.

6) Do ip4 and ip6 mechanisms count toward the 10 DNS lookup limit?

No. Only mechanisms that require a DNS query count toward the limit: include, a, mx, redirect, and exists. The ip4, ip6, and all mechanisms are evaluated locally and do not consume any DNS lookups.

• About
• Latest Posts

Ahona Rudra

Domain & Email Security Expert at PowerDMARC

Ahona is the Marketing Manager at PowerDMARC, with 5+ years of experience in writing about cybersecurity topics, specializing in domain and email security. Ahona holds a post-graduation degree in Journalism and Communications, solidifying her career in the security sector since 2019.

Latest posts by Ahona Rudra (see all)

• How to Add an IP Address to Your SPF Record (Step-by-Step Guide) - May 11, 2026
• Avanan SPF Record: How to Set Up, Fix, and Optimize Your SPF for Check Point Harmony Email - May 7, 2026
• DNS SPF Record: How It Works, and How to Set It Up - May 6, 2026