multiple spf records found permerror for subdomain sender

Not specified by the original author.

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

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

Thread query: "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.

Not specified by the original author.

TL;DR

SPF allows at most 10 DNS lookups while evaluating a record; nested includes blow past it and receivers treat the result as a permanent error. Flatten the record to direct IPs, drop stale includes, and stay under the limit.

spf permerror too many dns lookups 10 lookup limit exceeded

Use this when

• Receivers report SPF permerror or 'too many DNS lookups'.
• SPF shows none or permerror even though the TXT record exists.
• You added a new mail vendor and SPF broke the same day.

Not for this skill when

• SPF fail, meaning the IP is not in the record.
• DKIM signature failures.
• DMARC alignment problems on forwarded mail.

Steps

1. Pull the current TXT record and count lookups: every include, a, mx, ptr, and redirect counts. Verify: you have a written count above 10.
2. Identify which vendors still send for you; remove includes for dead tools. Verify: the remaining include list matches active vendors only.
3. Ask big vendors for their dedicated IP ranges and replace the include with ip4 entries. Verify: the lookup count drops under 10 with margin.
4. Flatten anything still nested, keeping the record under 255 characters per string. Verify: a DNS query returns the full record intact.
5. Test with a mail-tester service or an actual send to Gmail and check headers. Verify: Authentication-Results shows spf=pass.

Variant phrasings

spf too many dns lookups permerror

Common phrasing of the error.

spf 10 lookup limit exceeded fix

The limit-angle search.

spf permerror flatten includes

The fix-angle search.

Compatibility: Any DNS provider and any sender; the 10-lookup limit is in the SPF spec (RFC 7208).

Why it happens

SPF was designed with a lookup cap to stop DNS amplification attacks. Every include pulls in another record, and vendor records include their own vendors, so three includes can silently become fourteen.

Edge cases / pitfalls

• The count includes lookups from nested includes; audit recursively, not just your own line.
• Flattened records go stale when a vendor changes IPs; re-check quarterly.
• Multiple TXT records starting with v=spf1 at the same name break everything; keep exactly one.
• Macros in SPF count against the limit too; keep the record simple.

Provenance

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

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

Thread query: spf permerror too many dns lookups 10 lookup limit exceeded

TL;DR: SPF allows at most 10 DNS lookups while evaluating a record; nested includes blow past it and receivers treat the result as a permanent error. Flatten the record to direct IPs, drop stale includes, and stay under the limit.

Not specified by the original author.

mailgun domain verification failed multiple spf records

TL;DR

SPF allows exactly one TXT record starting with v=spf1, and Mailgun's verifier fails the domain while two exist. List all TXT records, merge every SPF mechanism into one record including Mailgun's include, delete the extras, wait for propagation, and re-run verification.

mailgun domain verification failed multiple spf records

Use this when

• Mailgun domain verification fails and the domain has two or more SPF records
• SPF worked before another service's record was added
• Receivers report permerror on SPF checks

Not for this skill when

• DKIM record verification failing (separate record, separate fix)
• A single SPF record with a syntax error (fix the syntax)
• Mailgun tracking or webhook issues (unrelated to DNS)

Steps

Step 1: List all TXT records

Query the domain's TXT records and identify every one starting with v=spf1. Expected: you see the full set of competing SPF records.

Step 2: Merge into one record

Combine all mechanisms and includes, including Mailgun's, into a single v=spf1 record. Expected: one record covers every legitimate sender.

Step 3: Delete the extras

Remove the duplicate SPF TXT records so exactly one remains. Expected: the domain publishes a single SPF record.

Step 4: Wait for propagation

Wait out the TTL and confirm with public resolvers. Expected: one SPF record visible everywhere.

Step 5: Re-run Mailgun verification

Verify the domain in Mailgun again. Expected: SPF verification passes.

Tool compatibility

Mailgun domain verification; DNS TXT records; SPF (RFC 7208).

Variant phrasings

Variant 1

mailgun multiple spf records verification failed

Variant 2

more than one spf record mailgun

Variant 3

merge spf records mailgun include

Why it happens

The SPF specification is unambiguous: a domain must publish exactly one SPF record, and evaluators return permerror when they find more. The duplicates accumulate innocently, each SaaS vendor's onboarding docs say to add their SPF record, and nobody mentions the single-record rule until verification fails. Mailgun's verifier enforces the rule strictly, so the domain fails even though each individual record is valid. Merging is mechanical but needs care: every legitimate sender's mechanism must survive the merge, and the 10-DNS-lookup limit means includes must be counted, not just concatenated.

Edge cases / pitfalls

• Count DNS lookups after merging; more than 10 mechanisms that trigger lookups breaks evaluation.
• The all mechanism should appear once at the end; duplicated or conflicting endings cause failures.
• SPF flattening services exist for complex cases, but audit what they include before trusting them.

Provenance

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

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

Thread query: mailgun domain verification failed multiple spf records

TL;DR: SPF allows exactly one TXT record starting with v=spf1, and Mailgun's verifier fails the domain while two exist. List all TXT records, merge every SPF mechanism into one record including Mailgun's include, delete the extras, wait for propagation, and re-run verification.