📡 Sender Policy Framework (SPF)

Sender Policy Framework (SPF) is an email authentication standard designed to prevent domain spoofing by verifying which mail servers are authorised to send emails for your domain.

It was introduced to fix a core flaw in SMTP — the protocol never verified the identity of the sender. SPF allows domain owners to publish a DNS record that specifies approved sending hosts, helping receiving mail servers identify forged messages.

🎯 Purpose of SPF

SPF allows receiving mail servers to check if an incoming email from @yourdomain.com originates from a server authorised by your domain’s DNS.

If the sending host isn’t listed, the recipient’s server can reject, quarantine, or flag the message.

✅ Key Benefits

• Reduces email spoofing and phishing
• Provides policy enforcement at the DNS level
• Supports DMARC alignment for stronger authentication
• Helps maintain domain reputation and deliverability

🧬 Anatomy of an SPF Record

SPF records are published in DNS as TXT records at the domain root (or relevant subdomain).

📘 Example Record

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

🔍 Breakdown

🧩 Understanding the mx Mechanism

The mx mechanism tells SPF to authorise any server defined as a Mail Exchanger in your DNS MX record.

Example DNS Setup

When using mx in SPF, this automatically includes 203.0.113.12 (from the A record of your MX host) as an authorised sender.

⚠️ Caution

Only use mx if your MX hosts also handle outbound mail.
If your MX records point to third-party spam filters (e.g. Barracuda, Proofpoint), including mx may unintentionally authorise them to send as your domain.

🔧 Safe Implementation Steps

1. Identify all legitimate outbound mail sources

   • On-prem servers, Microsoft 365, Google Workspace, third-party senders (Mailchimp, SendGrid, etc.)

2. Build the SPF Record

   • Use a combination of mechanisms:
     • mx for your MX hosts
     • include: for cloud mail providers
     • ip4: / ip6: for static outbound relays

3. Publish the Record in DNS

   • Add as a TXT record at the root (@) of your domain.
   • Example:

     Name: @  
     Type: TXT  
     Value: v=spf1 mx include:spf.protection.outlook.com ip4:203.0.113.12 -all
     

4. Start with a Soft Fail

   • Use ~all while testing, then move to -all when confident.

5. Monitor SPF Alignment via DMARC Reports

   • Ensure all legitimate mail sources align with SPF and pass validation.

⚙️ Common Qualifiers

🚫 Pitfalls to Avoid

• +all (e.g. v=spf1 +all) — allows anyone to send as your domain
• Exceeding 10 DNS lookups (SPF hard fail)
• Omitting key providers — leads to legitimate mail rejection
• Leaving stale includes after migrating services
• Relying on SPF alone — it only authenticates the envelope sender, not the visible “From” header

🧪 Real-World Example — Hybrid Microsoft 365 + On-Prem Exchange

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

• mx → On-prem Exchange mail relays
• include:spf.protection.outlook.com → Microsoft 365 outbound servers
• ip4:203.0.113.12 → Specific relay or mail gateway
• -all → Reject all unauthorised senders

Run checks with:

dig txt yourdomain.com +short
dig mx yourdomain.com +short

📈 Summary

SPF provides the first line of defence against domain spoofing by authenticating the sending server at the DNS level.

However, SPF alone does not validate the visible “From” address — only the envelope sender (Return-Path). This means attackers can still spoof what users see in their inbox.

To be effective, SPF must be deployed as part of a multi-layered email authentication strategy, alongside:

• DKIM – to cryptographically verify message content integrity (similar to the concept of code signing)
• DMARC – to enforce alignment between SPF/DKIM and the visible “From” domain, and to define actions for failed checks

When configured properly, SPF helps:

• Prevent unauthorised mail delivery
• Improve email deliverability for legitimate messages
• Strengthen your domain’s overall trust and reputation

✅ A correctly implemented SPF policy, combined with DMARC monitoring, is essential for defending against phishing, spoofing, and Business Email Compromise (BEC). We will discuss how we can combine SPF with another two technologies (DKIM and DMARC) to ensure the validity of mails from your domain.