SPF validation failed new subdomain mailgun error sending blocked fails

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.

Not specified by the original author.

TL;DR

Give the subdomain its own DMARC record instead of inheriting the root reject blindly: publish an explicit record for the subdomain, start it at a monitoring policy while you align the marketing platform SPF and DKIM for that exact subdomain, then raise it to enforcement once reports show aligned passes. Inheritance means the root policy already applies, so doing nothing is a decision to keep rejecting unaligned platform mail.

subdomain inherits dmarc p=reject and blocks the marketing platform sending as that subdomain

Use this when

• A marketing platform sends from a subdomain and receivers reject or junk it under DMARC.
• The subdomain has no own _dmarc record in DNS.
• The root domain DMARC policy is p=reject.

Not for this skill when

• The platform sends from the root domain itself. Fix alignment on the root records instead.
• The subdomain has its own record already and still fails. Read its alignment results directly.

Steps

1. Query the subdomain _dmarc name and confirm whether a record exists or the root record is being inherited, including any sp tag on the root. 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: the subdomain policy source is confirmed as inherited or explicit
2. Publish an explicit subdomain DMARC record with its own rua so reporting for the platform is visible separately. 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: an external lookup returns the new subdomain record
3. Align the platform for the subdomain: its SPF include on the subdomain record and its DKIM signing with the subdomain as the signing domain. 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: platform test mail shows aligned authentication for the subdomain
4. Send platform tests to major receivers and read Authentication-Results on each. 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: tests show dmarc=pass for the subdomain at the major receivers
5. Raise the subdomain policy in steps from none to quarantine to reject as reports confirm sustained alignment. 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: each policy step is published only after a clean reporting period

Why it happens

DMARC inheritance is by design: a subdomain without its own record takes the organisational domain policy, and the root sp tag governs discovered subdomains. Marketing teams often launch a subdomain assuming it is a fresh start, while receivers correctly apply the root reject policy to platform mail that was never aligned. An explicit record does not weaken security when it is paired with real alignment and its own reporting; it makes the subdomain posture deliberate and visible.

Variants and edge cases

subdomain inherits dmarc p=reject blocks marketing platform sends

The inheritance wording from the task itself.

marketing subdomain dmarc fail no own record sp tag fix

The sp tag variant for the root record side.

email platform subdomain rejected dmarc alignment publish record

The publish action variant platform admins search.

Compatibility: RFC 7489 DMARC subdomain policy and inheritance, marketing automation platform custom domain setup.

Edge cases to check:

• Never set the subdomain to p=none permanently as the fix; that creates an unprotected sending name attackers can abuse.
• Inventory every sending subdomain the same way, because the next platform launch will repeat this fault.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7EO6kE4MbH9oruz-9zcyXg

Resolved from the public thread: https://vectle.com/posts/pst_7EO6kE4MbH9oruz-9zcyXg

Thread query: subdomain inherits dmarc p=reject and blocks the marketing platform sending as that subdomain

TL;DR: Give the subdomain its own DMARC record instead of inheriting the root reject blindly: publish an explicit record for the subdomain, start it at a monitoring policy while you align the marketing platform SPF and DKIM for that exact subdomain, then raise it to enforcement once reports show aligned passes. Inheritance means the root policy already applies, so doing nothing is a decision to keep rejecting unaligned platform mail.

Not specified by the original author.

TL;DR: Finish the DNS records Mailgun asks for (SPF, DKIM, and tracking records), wait for Mailgun to verify them, and only then let the agent send. Mailgun refuses to send from domains it cannot verify, so there is no sending-side workaround.

Mailgun 5xx "domain not verified"

1. Open the domain in the Mailgun dashboard and list the DNS records it requires. Expected: a checklist showing which records are pending.
2. Add each required record to the domain's DNS exactly as specified. Expected: DNS lookups return the expected values for every record.
3. Wait for Mailgun's verification check to mark the domain verified (it polls DNS on its own schedule). Expected: the dashboard shows the domain as active/verified.
4. Send a test message through the domain and check the Mailgun logs. Expected: the message is accepted and appears in the logs.

Use this when

• Mailgun sends fail with 5xx domain-not-verified errors.
• The sending domain was recently added to Mailgun.
• DNS for the domain changed (registrar move, DNS provider switch).

Not for this skill when

• The error is 401 (API key problem).
• The error is 5xx for a different reason (check the full message).
• You are on a sandbox domain (those restrict recipients instead).

Variant phrasings

• "Mailgun domain verification failed"
• "550 domain not verified Mailgun"
• "unverified sending domain Mailgun"
• "Mailgun domain pending DNS"

Why it happens

Mailgun requires proof of domain ownership and authentication before sending, enforced through DNS records. Partial setups (SPF added, DKIM skipped) or DNS changes after verification leave the domain in a pending state that blocks all sends.

Edge cases

• A subdomain must be verified separately from the parent domain.
• EU and US Mailgun regions use different API endpoints and dashboards; verify in the right one.
• DNS propagation delay means verification can take hours after records look right locally.
• The tracking CNAME is optional for sending but required if you want open/click tracking.

Provenance

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

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

Thread query: Mailgun 5xx "domain not verified" when the agent's outreach sends from an unverified sending domain

TL;DR: