How to Set Up SPF for Subdomains

Many administrators assume that publishing a Sender Policy Framework (SPF) record on their apex domain (example.com) automatically protects all subdomains (mail.example.com, marketing.example.com). Under internet email standards, however, SPF records do not inherit downward. If a subdomain transmits email or appears in a message envelope without its own dedicated SPF record, receiving mail servers treat that subdomain as completely unauthenticated. This leads to SPF softfails, DMARC failures, and routing directly to the spam folder.

Quick Answer

Subdomains do not inherit SPF from their parent domain. To configure SPF for an active sending subdomain, create a separate DNS TXT record using the subdomain prefix as the host (e.g., marketing) and define only the sending servers authorized for that specific subdomain. For non-sending subdomains, publish a defensive null record (v=spf1 -all).

---

Why SPF Does Not Inherit (RFC 7208 Rules)

RFC 7208, the specification governing SPF, requires receiving mail transfer agents (MTAs) to query the exact domain found in the SMTP envelope sender (Return-Path or Mail From):

1. If an email uses newsletter@marketing.example.com in its envelope, the receiving server queries DNS specifically for: marketing.example.com TXT
2. The resolving server does not fall back to check example.com if no record is found at marketing.example.com.
3. Finding no TXT record starting with v=spf1 on the subdomain, the receiver assigns an SPF evaluation result of None.
4. While DMARC policies do inherit downward from the apex domain to subdomains by default, DMARC will fail if the subdomain lacks its own passing SPF or DKIM records.

Incoming Message: Envelope From = bounces@marketing.example.com
                               │
               Receiving Server Queries DNS:
                 marketing.example.com TXT
                               │
       ┌───────────────────────┴───────────────────────┐
       ▼                                               ▼
[Record Found on Subdomain]               [No Record on Subdomain]
v=spf1 include:sendgrid.net ~all          Receiver DOES NOT check example.com
       │                                               │
       ▼                                               ▼
SPF Evaluates Sender IP                   SPF Result = None
(Pass or Softfail)                        DMARC Fails Alignment

---

Active vs. Inactive Subdomain Configurations

Before editing your DNS zone, determine whether the subdomain is active (intended to send email) or inactive/defensive (web-only, API endpoints, or parked subdomains).

1. Active Sending Subdomains

Used for departmental routing, marketing platforms (e.g., SendGrid, HubSpot), customer support desks (e.g., Zendesk), or transactional notifications.

• Rule: Authorize only the specific systems sending mail for that subdomain. Do not blindly copy your corporate Google Workspace or Microsoft 365 includes into a subdomain record if those corporate servers never transmit subdomain mail.

2. Inactive / Defensive Subdomains

Used for websites (www), portals, staging servers, or development environments that should never transmit email.

• Rule: Publish a “Null SPF Record.” This explicitly tells global mail receivers that any email claiming to come from this subdomain is counterfeit and must be dropped.

---

Step-by-Step Configuration

Step 1: Set Up SPF on an Active Subdomain

Suppose you send marketing newsletters from news.example.com via Mailgun:

1. Log in to your DNS provider (e.g., Cloudflare, Route 53, GoDaddy).
2. Create a new TXT record.
3. In the Name / Host field, enter only the subdomain prefix:
   • news (or news.example.com, depending on whether your DNS provider automatically appends your root domain).
4. In the Value / Content field, enter your authorized SPF string: v=spf1 include:mailgun.org ~all
5. For information on selecting your ending qualifier, review Resolving SPF “Softfail” vs. “Hardfail”.

Step 2: Set Up a Defensive Null SPF Record

To prevent attackers from spoofing a non-sending host (such as www.example.com or dev.example.com):

1. Create a new TXT record in your DNS zone.
2. In the Name / Host field, enter the target subdomain (e.g., www).
3. In the Value / Content field, enter: v=spf1 -all
4. This instructs all receiving gateways to immediately reject any message claiming to originate from user@www.example.com.

---

Verifying Subdomain DNS Records

Test the live record using dig or nslookup from your command line:

# Query the subdomain specifically
dig news.example.com TXT +short

Confirm that the output returns the exact string you configured:

"v=spf1 include:mailgun.org ~all"

If the query returns empty, verify that you did not accidentally append the root domain twice (such as news.example.com.example.com), which is a common DNS editor mistake.

---

Common Pitfalls with Subdomain SPF

• Publishing Multiple SPF Records on a Subdomain: Just like the apex domain, a subdomain cannot have more than one SPF TXT record. If you need multiple services, combine them into one string; see Multiple SPF Records Detected (One Record Rule).
• Using SPF Wildcards (): While DNS supports wildcard TXT records (.example.com), SPF wildcards are dangerous. A wildcard record authorizes or denies all subdomains equally, which can unintentionally override custom configurations on child subdomains.
• Neglecting DMARC Alignment: If you send subdomain email, ensure your third-party provider also uses the subdomain in its cryptographic signatures. For setup procedures, consult How to Align SPF/DKIM for Third-Party Apps. If an unaligned subdomain triggers policy bounces, see “Message rejected due to DMARC policy”.