Stop Broadcasting Your Network! Why It’s Time to Fix Your SPF Record

One of y biggest bugbears - working through technical onboarding and coming across hardcoded fixed IP addresses in the email's Sender Policy Framework (SPF) record that NO ONE seems to know why they are there!

For some in the IT industry this will be seen as a personal crusade - another "old man shouts at cloud" situation. It is not. Configuring bulk IP address in a “set and forget” manner exposes your organisation to significant security and operational risks.

Below, I'm going to run through my explanation as to why this is bad and provide the better options if you want stable, scalable, and secure email delivery.

The Risks of Fixed IP Addresses in SPF Records

When your SPF record lists IP addresses (or worse, whole subnets) that are specific to your organisation, you are publicly handing over valuable information on your network environment straight to potential attackers. Every IP in your SPF record gives outsiders a map of your network. In plain terms:

1. You Reveal Your Network boundary to Attackers
   Fixed IPs in SPF records tell the world the IP address that you authorise mail to be sent from - if these addresses belong firewalls (or worse, Internet routers),these addresses are like giving over the street address of a house -it's now just a matter of knocking long enough before someone answers!
   Attackers will use this info to plan attacks, scan for weak points, and target your infrastructure.
2. More Admin, More Mistakes
   Changing a server’s IP, or even changing ISP's? You must update your SPF and any IP address records—miss one and you'll have email fails!
   The more manual changes, the higher the risk of human error and delays.
   Outdated records can break email delivery fast.
3. Greater Chance for Impersonation
   If a malicious actor gains access to one of your SPF-listed IPs—by hacking, lease expiry, cloud reassignment, or even just joining a guest WiFi network—they can send authorised emails on behalf of your Organisation.
   This leads to dangerous spoofing, phishing, and reputation damage.
4. Poor Scalability
   Growing your email infra means adding more IPs. Each one needs another edit in your SPF record.
   Manual updates don’t scale. It’s too easy to make mistakes.

Safer Alternatives - the Three SPF records that we use

1. The ‘A’ Record
   Example:
   v=spf1 a:mail.yourdomain.com -all
   
   SPF queries now match the email sending server to the DNS A record for mail.yourdomain.com.
   No hardcoded IPs, slightly less exposure and no ability to defined entire subnets! When the server IP changes, update your A record only and if the "A" record does not exist, the entry is not trusted.
   
   
2. The ‘MX’ Record
   Example:
   v=spf1 mx -all
   
   Automatically authorises all servers specified in the MX record (ie: all mail servers that accept inbound email, are now authorised to send email)
   Email platform changes? Update the MX record—SPF follows instantly.
   
   
3. Use ‘include’ for Third-Party Email Providers (My Favourite)
   
   Example:
   v=spf1 include:_spf.google.com include:sendgrid.net -all
   
   Authorises known, reputable senders (like Google or SendGrid) to deliver email for you.
   These providers keep their SPF records current so you don’t have to manage external IP lists.

For Internal Email: Why Smart Relays Beat Blanket IPs

Above I made mention of NOT adding the external IP address of a firewall or Internet router as an authorised sender in an SPF record and I absolutely stand by this position.  One of the primary reasons that this has historically been done is to provide authorisation for devices such as Multifunction Printers (MFP's) with scanning functionality access to use "scan-to-email" with minimal device configuration.

This is simply bad practice and leads to both poor email security and a complete lack of visibility in how devices are being used.

Much, much better to take the time and either establish an internal mail relay server (if you have many MFP's), or subscribe to a service such as SMTP2GO or Sendgrid.  These services provide each device with a unique set of credentials, support encryption, logging and message auditing. These services supply "include" statements for your SPF record - eliminating the need for publicly displaying the IP addresses of your Internet connection points!

Using this approach has an added benefit - it allows for the blocking of all outbound SMTP connection attempts - unless the connection is to the approved relay service!

Actionable Steps to Secure Your SPF Records

1. Audit and Plan
   • Review your existing SPF records for any fixed IP addresses.
   • List all systems authorised to send email today.
2. Clean Up Outdated Practices
   • Remove any router, firewall, or shared network IPs from SPF records immediately.
   • Migrate servers to use DNS-based ‘a’ or ‘mx’ mechanisms.
3. Implement Secure Smart Email Relays
   • For internal systems, route all mail through a single, dedicated gateway with strict authentication.
4. Use Soft Fail While Testing
   • Test changes with ~all (soft fail). Monitor for deliveries and missing mail.
     
     v=spf1 a:mail.yourdomain.com include:_spf.google.com ~all
5. Document and Monitor
   • Log all SPF changes with dates and reasons.
   • Regularly check SPF records for drift—especially after infra changes.
   • Keep DNS lookups below SPF’s 10-lookup limit to ensure reliability.

Microsolve Recommendations for Your Organisation

As boring as DNS and SPF records may appear, the information they provide to potential attackers can be significant if optimal settings are not deployed.

Take five minutes now: check your SPF record. If you see hardcoded IPs or broad network ranges, it’s time to act.