Skip to main content
Before you move customer email to MailChannels, check which sending domains authorize MailChannels in SPF. Group the results by authoritative nameserver so you can update DNS you manage and contact customers who manage DNS elsewhere. For Outbound Filtering, the SPF authorization is include:relay.mailchannels.net. The audit below reads DNS and creates a CSV report. It does not change DNS records.

Decide which domains need changes

Prioritize domains with -all that do not already authorize MailChannels. The - qualifier means hard fail: a receiving server can reject messages from an unauthorized sending IP. A hyphen inside a domain name, such as include:spf-example.net, does not indicate strict enforcement. For a valid policy without a hard-fail mechanism, updating SPF is optional for this migration, but recommended to explicitly authorize MailChannels. This includes ~all (soft fail), ?all (neutral), and no SPF record. These results are distinct from SPF pass. See the SPF result definitions.
Optional does not guarantee delivery. If a domain relies on SPF for DMARC, it needs an SPF pass aligned with the visible From domain, or a passing, aligned DKIM signature. A soft-fail or neutral SPF result does not satisfy DMARC. Check DMARC authentication and alignment before deferring an update.
The report uses these statuses: The script is an inventory tool, not a full SPF evaluator. It does not expand includes, evaluate sending IP addresses, or count recursive DNS lookups. A strict policy with another provider’s include goes to review: that include might already authorize MailChannels. Policies with redirect=, macros, unusual qualifiers, or unrecognized syntax also go to review. An all or +all policy authorizes every sender and needs review.

Prepare your domain and nameserver lists

Use a macOS, Linux, or Windows WSL terminal with Python 3.10 or later, pip, and virtual environment support. The commands below use Bash-compatible syntax and dnspython. Your machine must be able to query DNS through its configured resolver. Create domains.txt with one sending domain per line. Replace these examples with your customer domains:
Include the domains used in the SMTP envelope sender, usually shown as the Return-Path on delivered messages. They can differ from the visible From address. Audit sending subdomains separately: SPF does not inherit from the parent domain. You can also include your SMTP HELO domain for messages with an empty envelope sender. If you forward customer mail, include the envelope domains your MTA uses for SRS rewriting. Those domains must authorize MailChannels for the forwarded hop. See Configure SRS for forwarded mail. Create provider-nameservers.txt with the exact names of all nameservers for zones you manage:
The script compares whole names, ignoring case and trailing dots. It labels a domain provider only when every nameserver is in your list. Partial matches become review; no matches become customer. Leave this file empty if you only want grouping without identifying your nameservers. Nameservers identify DNS hosting, not account ownership. Confirm that you can edit each zone before treating it as provider-managed. Shared services such as Cloudflare can host both your accounts and your customers’ accounts on the same nameservers.

Run the bulk audit

Create an isolated Python environment and install the DNS library:
Copy this entire block into your terminal to create spf-audit.py:
Run the audit:
Open spf-audit.csv in a spreadsheet. The report sorts by the full nameserver set, then SPF status, then domain. It deduplicates input domains, joins split TXT strings, and finds the containing DNS zone for sending subdomains. Each DNS operation has a 10-second timeout; large lists or repeated DNS failures can take several minutes. Re-running the audit replaces the report. Example rows, with the record and notes columns omitted:

Apply changes by DNS owner

Domains you manage

Filter for dns_owner=provider and prioritize spf_status=required. Resolve review items before cutover. In your authoritative DNS system, edit each domain’s existing SPF TXT record to add include:relay.mailchannels.net before all. Keep existing senders and the existing all qualifier.
Before
After
Publish only one SPF record at each name. Keep the full policy within SPF’s 10 DNS-querying-term limit, including nested includes. Follow SPF setup and configure Domain Lockdown™ for your MailChannels account. If customers already include an SPF record you control, inspect that shared record. Adding MailChannels there may cover those customers without individual DNS edits. Verify the include chain, mechanism order, and lookup budget before relying on this approach.

Domains managed by customers

Filter for dns_owner=customer. Confirm who controls DNS, then send required changes before moving that domain’s mail. Give customers the exact record name and their complete proposed SPF value, preserving existing senders. Adapt this message for each customer:
For optional domains, explain that the existing policy does not impose an SPF hard fail, but adding MailChannels improves explicit authorization. Confirm aligned DKIM works if the customer will rely on it for DMARC.

Verify before moving traffic

Allow the previous DNS TTL to expire, then run the audit again. Check review rows and confirm expected includes appear. For indirect authorization, validate the referenced policy separately because this audit will still flag it for review. Send real messages from a domain you control, using a workload with little impact if delivery fails, such as noncritical cron reports or internal notifications. Repeated messages such as “Testing 1 2 3” are likely to be classified as spam and blocked. Inspect the receiving server’s Authentication-Results header for SPF and DMARC results. Test domains in each DNS and SPF group before expanding the rollout. Continue with mail server configuration and use Log Search to investigate delivery issues. For a complete test plan, pilot stages, and rollback criteria, see Testing and phased rollout.