SPF for Developers

Your App Sends Email but You Never Set Up SPF

You built the authentication flow, integrated SendGrid, and your app sends beautiful password reset emails. In development, everything works. In staging, everything works. In production, users say they never got the verification email. You check the SendGrid dashboard — delivered. But "delivered" means the receiving server accepted the connection, not that the message reached the inbox. Without SPF, your app's emails are unauthenticated, and unauthenticated email gets filtered.

The Developer SPF Problem

As a developer, email authentication is probably not the first thing on your mind. You chose an email API, wrote the integration code, and tested that messages get sent. But SPF lives in the DNS layer, outside your application code, and it's easy to overlook.

Here's what developers commonly run into:

• You set up SendGrid or SES in your app but nobody added the SPF record to DNS
• Your staging and production environments send from different domains or subdomains, each needing separate SPF records
• You deploy a new service that sends email (monitoring alerts, cron job notifications) and forget to update SPF
• Multiple microservices send email through different providers, and the SPF record needs to cover all of them
• Infrastructure-as-code deploys everything except DNS records, creating a gap in your automation

How SPF Creator Helps

Setting Up SPF for Application Email

Using Subdomains for Different Environments

One SPF record per domain means you can't easily separate concerns on a single domain. Subdomains solve this.

# Production: yourdomain.com
v=spf1 include:_spf.google.com include:sendgrid.net ~all

# Staging: staging.yourdomain.com
v=spf1 include:sendgrid.net ~all

# Transactional: mail.yourdomain.com
v=spf1 include:amazonses.com ~all

# Marketing: marketing.yourdomain.com
v=spf1 include:servers.mcsv.net ~all

Benefits of the subdomain approach:

• Each subdomain gets a fresh 10-lookup budget
• A deliverability problem on your marketing subdomain doesn't affect transactional email
• You can use ~all in staging and -all in production
• Infrastructure-as-code can manage subdomain records independently

Automating SPF with Infrastructure as Code

If you manage DNS through Terraform, here's what the resource looks like:

resource "aws_route53_record" "spf" {
  zone_id = aws_route53_zone.main.zone_id
  name    = ""
  type    = "TXT"
  ttl     = 300
  records = ["v=spf1 include:_spf.google.com include:sendgrid.net ~all"]
}

For CloudFormation:

SPFRecord:
  Type: AWS::Route53::RecordSet
  Properties:
    HostedZoneId: !Ref HostedZone
    Name: !Ref DomainName
    Type: TXT
    TTL: 300
    ResourceRecords:
      - '"v=spf1 include:_spf.google.com include:sendgrid.net ~all"'

While you're automating DNS, consider adding DKIM keys and a DMARC policy to your IaC templates as well. All three records (SPF, DKIM, DMARC) should be part of your infrastructure baseline for any domain that sends email.

Testing SPF Records

Command-line testing

# Check the SPF record for a domain
dig TXT yourdomain.com +short | grep spf

# On Windows
nslookup -type=TXT yourdomain.com

# Check what a specific include resolves to
dig TXT _spf.google.com +short

Programmatic testing

Most email APIs include headers in webhook payloads. Check the Authentication-Results header:

Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of user@yourdomain.com designates 167.89.123.45 as permitted sender)

If you see spf=fail or spf=softfail, your SPF record doesn't cover the sending IP.

Common Developer Pitfalls

Pricing

Monitor Your New SPF Record

You've created your SPF record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.