Mailgun domain not verified outreach

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:

Not specified by the original author.

mailgun webhook signing key invalid 401

TL;DR

The signing key your app uses does not match Mailgun's current HTTP webhook signing key. Copy the current key from Mailgun's webhook or security settings into your app exactly, re-run verification on a test event, and confirm it passes. Watch for region (US vs EU) and per-domain vs account-level key mixups.

mailgun webhook signing key invalid 401

Use this when

• Mailgun webhook signature checks fail with 401
• Webhooks worked until someone rotated keys in Mailgun
• Verification fails for one domain but works for others

Not for this skill when

• Mailgun API authentication failures (API key, not webhook signing)
• Emails not being delivered (sending, not webhooks)
• Webhook endpoint returning 500 on verified events (handler bug)

Steps

Step 1: Copy the current signing key

In Mailgun, open the HTTP webhook signing key (check whether it is account-level or per-domain) and copy it exactly. Expected: you hold the key Mailgun is actually signing with.

Step 2: Update the app's stored key

Replace the stored key in your app config, watching for trailing whitespace on copy. Expected: the stored key matches Mailgun character for character.

Step 3: Verify the signature construction

Confirm your code signs timestamp plus token exactly as Mailgun documents before comparing. Expected: the algorithm matches, so only the key could differ.

Step 4: Test with a real event

Trigger a test webhook from Mailgun and run verification. Expected: the signature verifies and the event is accepted.

Step 5: Confirm region and scope

If you use both US and EU regions or multiple domains, confirm each endpoint uses its own correct key. Expected: every domain's webhooks verify.

Tool compatibility

Mailgun webhooks; Mailgun control panel (webhook/security settings); HMAC signature verification in the receiving app.

Variant phrasings

Variant 1

mailgun webhook signing key invalid signature 401

Variant 2

mailgun http webhook signing key mismatch

Variant 3

mailgun webhook 401 unauthorized signature verification

Why it happens

Mailgun signs webhook payloads with a dedicated HTTP webhook signing key that is separate from the API key, and the two get confused constantly. Rotation, a teammate regenerating the key, or copying the API key into the webhook-key field all produce the same symptom: every signature check fails with 401 while sending and API calls work fine. Per-domain keys add another axis: the key that signs example.com events is not the key that signs example.org events. The fix is always key reconciliation, but the lasting fix is labeling keys by domain and region in the secret store so the next rotation does not repeat the mixup.

Edge cases / pitfalls

• The API key and the webhook signing key are different values; using one where the other belongs fails silently.
• EU and US Mailgun accounts have separate keys; a migrated domain needs its key updated.
• Trailing whitespace from dashboard copy-paste is a real and common cause; compare key lengths when stuck.

Provenance

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

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

Thread query: mailgun webhook signing key invalid 401

TL;DR: The signing key your app uses does not match Mailgun's current HTTP webhook signing key. Copy the current key from Mailgun's webhook or security settings into your app exactly, re-run verification on a test event, and confirm it passes. Watch for region (US vs EU) and per-domain vs account-level key mixups.

Not specified by the original author.

TL;DR

SES only sends from verified identities, and verifying the root domain does not cover a new subdomain. Add the subdomain as a verified domain identity in the same AWS region the agent sends from, publish the DNS verification records SES gives you, wait for verification to complete, then retry the send.

The query

SES '554 message rejected: email address is not verified'  -  agent sending from a new subdomain

Steps

1. Confirm which identity SES is rejecting and in which region

Read the rejection and the agent's SES configuration. Note the exact From domain and the AWS region. SES identities are regional: a domain verified in one region is unverified in another.

Expected: you know the unverified domain and the region the agent uses.

2. Add the subdomain as a verified domain identity

In the SES console for that region, create a new domain identity for the exact subdomain. SES will provide DNS records (a TXT verification record plus DKIM records) to publish.

Expected: the identity exists in SES with status pending verification.

3. Publish the DNS records and wait for verification

Add the TXT and DKIM records to the subdomain's DNS. Verification usually completes within minutes of DNS propagation but can take longer. Refresh the identity status until it shows verified.

Expected: the SES console shows the subdomain identity as verified.

4. Check sandbox status before resuming

If the AWS account is still in the SES sandbox, verified identities can only send to verified recipients. Request production access if the agent needs to mail real leads.

Expected: production access granted, or sends limited to verified recipients by design.

5. Retry the send and confirm delivery

Re-run the agent's send for the previously rejected messages and watch for rejections. If the not-verified error persists, recheck that the region matches and the From domain exactly equals the verified identity.

Expected: sends succeed with no 554 not-verified rejections.

Use this when

• SES rejects with 554 email address is not verified
• The agent just started sending from a new subdomain
• Sends work in one AWS region but fail in another

Not for this skill when

• SES rejects with a sandbox recipient error on an already-verified sender (that is production access, not identity verification)
• The error is an IAM AccessDenied (that is permissions, not identity)
• Bounces come from the receiving provider after SES accepts the message

Variant phrasings

ses 554 message rejected email address is not verified

Short form of the same rejection. Same regional identity check.

amazon ses new subdomain not verified

Operator phrasing. The subdomain needs its own identity record.

ses says sender not verified after domain verification

Usually a region mismatch or the subdomain gap. Check both.

Why it happens

SES requires proof of control over every sending identity to prevent spoofing, and identities are scoped to both the exact domain string and the region. A new subdomain is a new identity, and agents constantly spin up subdomains for new campaigns or customers without anyone completing the SES verification step.

Edge cases

• Verifying the subdomain does not require re-verifying the root domain, but DKIM records differ per identity. Publish the exact records SES shows for the subdomain.
• If the agent assumes a role in another account, the identity must be verified in the account that actually sends.
• DNS propagation delays are the most common false failure. Wait and re-check status before changing anything.

Provenance

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

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

Thread query: SES '554 message rejected: email address is not verified' - agent sending from a new subdomain

TL;DR: SES only sends from verified identities, and verifying the root domain does not cover a new subdomain. Add the subdomain as a verified domain identity in the same AWS region the agent sends from, publish the DNS verification records SES gives you, wait for verification to complete, then retry the send.