multiple spf records found" permerror for subdomain sender

TL;DR

Publish exactly one SPF record for the subdomain: gather every sender currently split across the duplicate TXT records, merge them into a single v=spf1 record, delete the extras, and verify with a lookup that returns one record. DNS allows only one SPF record per name, so two well meant records from two different vendors or teams produce a permerror and receivers treat the domain as having no usable SPF at all.

"multiple spf records found" permerror for subdomain sender

Use this when

• An SPF checker or receiver reports multiple SPF records found for the subdomain.
• The subdomain sends through two services, each of which asked for its own record.
• SPF returns permerror even though each individual record looks correct.

Not for this skill when

• The single record exceeds ten DNS lookups. That is the lookup limit permerror, fixed by flattening instead.
• The root domain has the duplicate problem and the subdomain inherits nothing. Fix the name that actually sends.

Steps

1. Query TXT records for the exact subdomain and list every record that starts with v=spf1. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: all duplicate SPF records for the name are listed
2. Collect the mechanisms from each duplicate and confirm every sender in them is still in use, asking the owning team before dropping any entry. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: the merged sender list is agreed and stale senders are marked for removal
3. Write one merged record, count its DNS lookups, and publish it in place of the duplicates in a single DNS change. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: the DNS zone now holds exactly one v=spf1 record for the name
4. Wait for propagation and query from an external resolver. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: an external lookup returns one SPF record and no checker reports a permerror
5. Send a test from the subdomain through each service that was merged and read the received headers. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: tests from every merged service show spf=pass

Why it happens

SPF was defined as a single policy record per name. When provisioning guides from two vendors are followed independently, or a team adds a second record instead of editing the first, resolvers return both and verifiers must declare permerror rather than guess which record the domain owner meant. The failure looks harsh because a merged record is trivial, but the ambiguity is real and receivers cannot safely pick one.

Variants and edge cases

multiple spf records found permerror subdomain fix merge

The merge-action phrasing for the DNS edit.

two v=spf1 txt records subdomain spf permerror

The record-count phrasing copied from checker output.

spf permerror vendor added second record subdomain sender

The vendor-onboarding variant explaining how the duplicate appeared.

Compatibility: RFC 7208 SPF section on multiple records, Google Workspace and Microsoft 365 subdomain sending, common DNS providers.

Edge cases to check:

• CNAME and TXT confusion at the same name can hide the second record from a quick zone review; query the exact name externally.
• Deleting one duplicate without merging first will break the senders that only existed in that record.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_o30KsR3ubAY4Lb7P2kehcQ