SPF (Sender Policy Framework)

Complete Guide to Email Authentication - Preventing Email Spoofing and Ensuring Deliverability

What is SPF?

SPF (Sender Policy Framework) is a DNS record that specifies which mail servers are authorized to send email on behalf of your domain. It works by publishing a list of authorized sending servers in DNS, allowing receiving mail servers to verify that incoming emails actually came from authorized servers.

Think of SPF as a "whitelist" of authorized mail servers. When someone receives an email claiming to be from your domain, their mail server checks the SPF record to see if the sending server is on the list. If the server isn't authorized, the email can be rejected or marked as spam.

How SPF Works

Here's how SPF verification works when an email is received:

1. Email Received: A mail server receives an email claiming to be from your domain
2. SPF Record Lookup: The receiving server looks up your domain's SPF record in DNS
3. IP Address Check: The receiving server checks if the sending server's IP address is in the SPF record
4. Verification Result: The receiving server determines if the email is authorized:
   • Pass: Sending server is authorized (email accepted)
   • Fail: Sending server is not authorized (email rejected or marked as spam)
   • Soft Fail: Sending server is likely not authorized (email accepted but marked suspicious)
   • Neutral: SPF record doesn't specify (email accepted)

This process happens automatically for every email received, providing protection against spoofing without requiring any action from end users.

SPF Record Format

SPF records are TXT records in DNS that start with "v=spf1". Here's the basic format:

v=spf1 [mechanisms] [qualifiers]

The record contains mechanisms that specify authorized servers and qualifiers that specify what to do with emails that don't match.

SPF Mechanisms

SPF mechanisms specify which servers are authorized to send email:

• all: Always matches (used at the end with a qualifier)
• ip4: Specifies an IPv4 address or range (e.g., ip4:192.0.2.1 or ip4:192.0.2.0/24)
• ip6: Specifies an IPv6 address or range (e.g., ip6:2001:db8::1)
• a: Authorizes servers specified in the domain's A record
• mx: Authorizes servers specified in the domain's MX records
• include: Authorizes servers specified in another domain's SPF record (e.g., include:_spf.google.com)
• exists: Authorizes if a DNS record exists (advanced use)
• redirect: Redirects to another domain's SPF record (replaces current record)

SPF Qualifiers

SPF qualifiers specify what to do with emails that match (or don't match) mechanisms:

• + (plus): Pass (default) - email is authorized
• - (minus): Fail - email is NOT authorized, reject it
• ~ (tilde): Soft Fail - email is likely NOT authorized, accept but mark as suspicious
• ? (question): Neutral - SPF doesn't specify, accept email

Critical: The "-all" mechanism at the end of your SPF record means "reject all emails from servers not explicitly listed." This provides strict protection. Without "-all" (or with "~all" or "?all"), attackers can still send spoofed emails.

Example SPF Records

Here are examples of SPF records:

Basic SPF Record (Single Server)

v=spf1 ip4:192.0.2.1 -all

This authorizes only one IP address (192.0.2.1) and rejects all others.

SPF Record with Multiple Servers

v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 mx -all

This authorizes two specific IP addresses and all servers in MX records.

SPF Record with Third-Party Email Service

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

This authorizes servers specified in Google's and another service's SPF records.

Weak SPF Record (NOT Recommended)

v=spf1 ip4:192.0.2.1 ~all

WARNING: This uses "~all" (soft fail) instead of "-all" (fail). This provides weak protection—emails from unauthorized servers are accepted but marked as suspicious.

No Protection (NOT Recommended)

v=spf1 ip4:192.0.2.1 ?all

WARNING: This uses "?all" (neutral). This provides NO protection—emails from unauthorized servers are accepted without any indication they're suspicious.

Why SPF is Critical for Government Agencies

For government agencies, SPF is not just recommended—it's critical for email security. Here's why:

1. Prevents Email Spoofing

Without SPF, anyone can send emails claiming to be from your domain. Attackers can:

• Send phishing emails that appear to come from your agency
• Impersonate government officials
• Steal credentials or sensitive information
• Intercept payment instructions or invoices
• Damage your agency's reputation

Real-world impact: In December 2025, Smithville, Tennessee lost $425,000 when attackers spoofed a vendor's email address and tricked city officials into wiring payment to a fraudulent account. Proper SPF configuration with "-all" would have prevented this attack.

2. Ensures Email Deliverability

Mail servers increasingly require SPF records for email deliverability. Emails from domains without SPF records are more likely to be:

• Rejected as spam
• Marked as suspicious
• Filtered into spam folders
• Blocked entirely

3. Required for Complete Email Security

SPF is the first layer of email authentication. It works with DKIM and DMARC to provide complete email security. Without SPF, you cannot achieve complete email authentication and protection.

4. Required for CISA Compliance

The Cybersecurity and Infrastructure Security Agency (CISA) mandates SPF, DKIM, and DMARC for all government email domains. Failure to implement SPF results in non-compliance, which can lead to:

• Criminal charges for negligence
• Civil liability from email attacks
• Federal grant restrictions
• Insurance claim denials

Why "-all" is Critical

The "-all" mechanism at the end of your SPF record is critical because it means "reject all emails from servers not explicitly listed." This provides strict protection against spoofing.

Without "-all" (or with "~all" or "?all"), your SPF record provides weak or no protection:

• "~all" (soft fail): Emails from unauthorized servers are accepted but marked as suspicious. This is weak protection—attackers can still send spoofed emails.
• "?all" (neutral): Emails from unauthorized servers are accepted without any indication they're suspicious. This provides NO protection—anyone can send spoofed emails.
• "-all" (fail): Emails from unauthorized servers are rejected or marked as spam. This provides STRICT protection—only authorized servers can send email.

For government agencies, "-all" is mandatory. Soft fail or neutral provides insufficient protection for sensitive government communications.

What Can Go Wrong Without SPF?

The consequences of operating without SPF or with improper SPF configuration are severe:

Email Spoofing

Attackers can send emails claiming to be from your domain, leading to:

• Phishing attacks targeting citizens or employees
• Credential theft through fake login pages
• Payment interception through fake invoices
• Impersonation of government officials
• Reputation damage and loss of public trust

Email Delivery Failures

Emails from domains without SPF records are increasingly rejected or marked as spam by mail servers. This can cause:

• Important emails not reaching recipients
• Delayed or lost communications
• Reduced email deliverability rates
• Loss of citizen trust

Liability and Legal Consequences

Without SPF, you cannot prove that spoofed emails weren't authorized. This exposes your agency to:

• Civil lawsuits from affected citizens
• Criminal charges for failure to implement required security measures
• Insurance claim denials
• Loss of federal funding

How to Implement SPF

Implementing SPF requires identifying all authorized mail servers and creating an SPF record:

Step 1: Identify Authorized Mail Servers

You need to identify all servers that send email on behalf of your domain:

• Your organization's mail servers (IP addresses)
• Third-party email services (Google Workspace, Microsoft 365, etc.)
• Email marketing services
• Any other services that send email from your domain

Step 2: Create SPF Record

Create an SPF record that authorizes all identified servers. Use "include:" for third-party services and "ip4:" or "ip6:" for your own servers. Always end with "-all" for strict protection.

Step 3: Publish SPF Record in DNS

Publish the SPF record as a TXT record in your domain's DNS. The record must:

• Start with "v=spf1"
• Be a single TXT record (if the record is too long, it may need to be split, but this is not recommended)
• End with "-all" for strict protection
• Not exceed DNS record size limits (typically 255 characters per string, but modern DNS supports longer records)

Step 4: Test SPF Configuration

Test your SPF configuration using:

• SPF validation tools (online SPF checkers)
• Email authentication testing services
• Your domain checker (YesGov's domain checker verifies SPF status)

Step 5: Monitor and Update

SPF records must be updated when:

• Adding new mail servers
• Changing email service providers
• Adding new services that send email

Regular monitoring ensures your SPF record remains accurate and up-to-date.

Common SPF Implementation Issues

Several common issues can cause SPF problems:

1. Missing "-all" Mechanism

SPF records without "-all" (or with "~all" or "?all") provide weak or no protection.

Solution: Always end SPF records with "-all" for strict protection.

2. Incomplete List of Authorized Servers

Missing authorized servers in SPF records causes legitimate emails to be rejected.

Solution: Ensure all mail servers and services are included in your SPF record.

3. Including Unauthorized Servers

Including servers that shouldn't send email (or using overly broad mechanisms like "a" or "mx" when not appropriate) weakens protection.

Solution: Only authorize servers that actually send email from your domain.

4. Record Too Long

SPF records that exceed DNS size limits may not work correctly.

Solution: Use "include:" mechanisms for third-party services instead of listing all their IPs.

5. Not Updated When Servers Change

Outdated SPF records can cause legitimate emails to be rejected or allow unauthorized servers to send email.

Solution: Keep SPF records updated whenever mail servers or services change.

SPF and DMARC Integration

SPF works with DMARC (Domain-based Message Authentication, Reporting & Conformance) to provide complete email authentication. DMARC uses SPF (and DKIM) results to determine email handling policy.

Important: SPF alone is not enough. You need both SPF and DKIM, plus DMARC to enforce policies and provide reporting. SPF without DMARC provides some protection but doesn't allow you to control what happens to spoofed emails or provide visibility into authentication failures.

How YesGov Ensures SPF is Properly Configured

YesGov handles all aspects of SPF implementation and management for government agencies:

• Complete Setup: We identify all authorized mail servers and create comprehensive SPF records
• Strict Protection: We always use "-all" for strict protection against spoofing
• Third-Party Integration: We properly integrate third-party email services using "include:" mechanisms
• DNS Configuration: We publish SPF records in DNS with proper formatting
• Testing and Validation: We test SPF configuration to ensure it works correctly
• Ongoing Management: We update SPF records when mail servers or services change
• Documentation: All SPF configuration and status is documented for compliance and insurance purposes
• Integration: We ensure SPF works with DKIM and DMARC for complete email security

How YesGov Ensures Complete SPF Protection

At YesGov, we don't just check if SPF is configured—we perform comprehensive validation of your entire SPF setup:

• Record Validation: We verify SPF record syntax and ensure it's properly formatted
• Strict Policy Enforcement: We ensure "-all" mechanism is used for maximum protection
• Server Authorization: We verify all authorized mail servers are correctly listed
• Third-Party Integration: We properly configure "include:" mechanisms for third-party services
• DNS Propagation: We verify SPF records are properly published and accessible
• Testing and Validation: We test SPF from multiple mail servers to ensure proper enforcement
• Ongoing Monitoring: We continuously monitor SPF status and alert on any issues

When you host with YesGov, SPF is properly configured with strict "-all" enforcement, continuously monitored, and automatically maintained. We handle record updates, third-party integrations, and validation testing so you don't have to worry about email spoofing. This is one of our comprehensive security checks that ensures your agency meets and exceeds federal, state, and industry standards.