Configure an SPF record for your sending domain

SPF, the Sender Policy Framework, lets a domain publish which servers may use it as an SMTP sending identity. Receivers compare the connecting IP address with a policy published in DNS as a TXT record.

SPF evaluates the SMTP MAIL FROM domain and can also check the HELO/EHLO identity. It does not directly authenticate the From header a reader sees. For a null reverse-path, the HELO identity is used for the relevant SPF check. The receiver decides how to handle the result.

Read the policy

This is an illustrative policy, not a record to copy into production:

v=spf1 ip4:203.0.113.10 include:_spf.example.net ~all

include is a conditional evaluation, not a literal paste of another record. The included policy's errors can propagate. Use only a provider's documented include value for a service you actually use.

Inventory senders before editing DNS

List your mail servers, workplace email service, marketing platforms, ticket systems, and application notifications. For each one, determine the actual envelope sender domain. A service using its own bounce domain may require a custom return-path setup before your domain's SPF policy is relevant to that path.

Inspect existing records:

dig TXT example.com

There must be only one selected v=spf1 policy at a given owner name. Multiple unrelated TXT records are fine; two SPF policies cause a permanent evaluation error. One TXT record can contain several quoted character strings that are concatenated when interpreted.

Update or merge the existing policy rather than adding a second one. Publish it at the domain used by the SMTP identity, using the DNS provider's required apex or subdomain notation.

Stay within SPF's DNS limits

SPF limits the evaluation of DNS-querying terms such as include, a, mx, ptr, exists, and redirect to ten in total, including nested evaluations. This is not a count of UDP packets or a count of TXT records. Exceeding the limit produces PermError. Additional limits apply to some mechanisms and empty DNS answers.

Use explicit IP mechanisms for stable addresses you control, remove redundant includes, and check the complete evaluation path. Manually flattening a provider's changing IP ranges can silently become stale; use a supported, maintained approach if flattening is necessary.

Verify every sending path

After checking the authoritative and recursive TXT answers, send controlled messages through each authorized service. Inspect the receiver-generated Authentication-Results or Received-SPF information. One Pass proves only that particular source and identity worked.

Choose ~all or -all according to an inventoried policy and the expected treatment of legitimate traffic. Softfail does not itself guarantee acceptance, and Fail does not force every receiver to reject. SPF can fail after ordinary forwarding because the forwarding server connects from a different IP.

DKIM signs selected message content and headers with a signing domain. DMARC evaluates alignment between the visible From domain and a passing SPF or DKIM identity and publishes handling/reporting policy. These mechanisms complement SPF; none guarantees inbox placement.

SPF is not inherited from the parent domain. Publish a policy for each SMTP identity you use. A non-sending domain can publish v=spf1 -all, after confirming it is not used by any legitimate sending path.

Reference

• RFC 7208: SPF version 1

Related reading

• Handle an SSH host-identification warning (Chinese)
• Maildir and Mbox differences (Chinese)