SPF allows a domain owner to declare which infrastructure may send using a particular envelope-sender domain. Adding a second provider by publishing another SPF TXT record makes the result invalid rather than additive.
Inventory every legitimate source and update one policy deliberately.
Identify the domain SPF evaluates
Inspect a received message or provider log to find the envelope sender, sometimes shown as Return-Path. SPF evaluates that domain, which may differ from the visible From address.
Record whether WordPress uses the website domain, a subdomain or a provider-managed bounce domain. Do not edit the visible domain’s SPF if the actual envelope sender is elsewhere.
DMARC alignment is a separate question addressed after SPF passes.
Find the authoritative record
Query DNS through more than one resolver and confirm the domain’s active nameservers. Hosting-panel DNS has no effect when Cloudflare or another provider is authoritative.
Collect every TXT record beginning with v=spf1. There must be only one SPF policy per exact hostname.
Keep a copy of the current value and TTL before making a change.
Check the published value for accidental quotation marks, duplicated spaces or text split into separate records by the DNS interface. Multiple quoted strings inside one TXT answer can be valid, but multiple independent SPF answers are not.
Inventory legitimate sending services
List company mailboxes, WordPress transactional mail, helpdesk, CRM, newsletters, invoices and any hosting relay that uses the same envelope domain. Verify each against current service ownership and provider documentation.
Do not retain obsolete includes "just in case." Every include expands trust and consumes DNS lookups.
Separate marketing and transactional mail onto purposeful subdomains where operationally appropriate.
Merge mechanisms into one policy
Add the second provider’s documented include, IP or other mechanism to the existing record before the final all qualifier. Preserve syntax and avoid smart quotes or line breaks introduced by a document editor.
A simplified structure may look like this:
v=spf1 include:provider-one.example include:provider-two.example -allThe example domains are placeholders. Never publish them; use values supplied by the actual providers.
Control the DNS lookup limit
SPF evaluation permits a limited number of DNS-causing mechanisms. Nested includes, redirects, a and mx can exhaust that allowance even when the record looks short.
Use an SPF analysis tool or direct inspection to count the expanded path. Remove unused services before considering provider-supported flattening, because flattened IP lists can become stale.
Do not add broad a or mx mechanisms unless those hosts truly send.
Choose the final qualifier deliberately
An existing -all, ~all or ?all expresses different policies. Do not weaken it merely to hide a configuration error. Add the known sender correctly and keep the intended enforcement.
Coordinate changes with the mail administrator, especially when the domain also supports employee mail. A WordPress-only repair must not disrupt corporate sending.
Allow for the old TTL before interpreting external results.
Query at least two public resolvers after that period and compare their complete answers before sending the verification messages.
Verify both sources and DMARC
Send one labelled message through each provider after propagation. Inspect SPF result and the authenticated envelope domain. Then check DKIM and DMARC alignment with the visible From.
An SPF pass alone may not satisfy DMARC if the provider uses a non-aligned return path. Configure a custom bounce domain or aligned DKIM where supported.
Test the real form rather than only a provider dashboard.
Maintain the record over time
Document each mechanism’s service owner and removal condition. Review the policy when a provider, hosting account or marketing platform is retired.
Monitor authentication reports and provider bounces without collecting unnecessary recipient data. Keep DNS change history and rollback evidence.
Request specialist help when lookup limits are exceeded, ownership is unknown or several business systems share the domain. Share the public record and redacted headers—never DNS account credentials or private DKIM keys.