custom domain email verification failing: a step-by-step fix

You added the TXT record. You waited. You clicked verify. It failed.

This is one of the most frustrating states to be in when setting up agent email infrastructure. The DNS change looks right, the record is there when you dig for it, but the verification endpoint keeps returning an error. The good news: it's almost always one of a handful of specific issues. The bad news is that most setup guides don't mention any of them.

This post is for developers using LobsterMail with a custom domain who are stuck at the verification gate. If you're setting up a custom domain for the first time, the custom domains setup guide covers the full walkthrough — this post is for when that guide got you 90% of the way there and verification still won't complete.

If you're building an agent that needs email as part of a broader automation, this piece on agent email without pub/sub is worth reading once you're unblocked.

Start here: check actual propagation#

This sounds obvious but skipping it wastes an hour. DNS changes don't apply instantly. The industry standard is "up to 48 hours," but in practice most changes propagate within 15–30 minutes for providers like Cloudflare, Route 53, and Porkbun. Registrar-managed DNS — GoDaddy, Namecheap, that kind of thing — runs slow. Expect 4–6 hours minimum.

Before debugging anything, run this from your terminal:

dig TXT yourdomain.com

Or use dnschecker.org and check from at least 10 different regions. If your record appears in most locations globally, propagation is done and you have a real misconfiguration. If it only appears in 2–3 locations, wait.

One thing that catches people: if you had a different TXT record at the same name before and recently swapped it out, some resolvers cache the old value for the full TTL window even after the change. You're stuck waiting until those caches expire. Lowering TTL before making changes (to 300 seconds or less) is good practice for next time. This time, you're waiting it out.

The TXT record value itself#

If propagation isn't the issue, the record value is likely malformed in one of a few ways.

Quoted strings first. Some DNS providers require TXT record values to be wrapped in double quotes. Others strip them automatically. Others want them wrapped in the API but not in the web UI. Enter the LobsterMail verification value exactly as it appears in the dashboard — don't add quotes if the input field is plaintext, and don't strip them if the field explicitly expects quoted values. When the instructions don't specify, enter without quotes and let the provider handle escaping.

Subdomain placement is where I see the most mistakes. If you're verifying mail.yourdomain.com, the TXT record should be placed at mail, not at mail.yourdomain.com. DNS control panels automatically append the root domain. When you enter mail.yourdomain.com as the record name, the actual record ends up at mail.yourdomain.com.yourdomain.com, which is not a real host and will never verify. Enter just the subdomain label.

Multiple TXT records at the same DNS name are technically valid — you can stack them and DNS handles it correctly. The problem is that some providers silently overwrite existing TXT records instead of adding a new entry. If you added the LobsterMail verification record and your SPF record disappeared, that's what happened. Go add both records back and confirm they both appear when you run dig. If only one shows up, your provider is overwriting. Some providers let you combine multiple values into a single TXT record entry; that's a valid workaround.

SPF conflicts#

SPF is where setups start fighting with each other in non-obvious ways.

The SPF spec allows a maximum of 10 DNS lookups per validation check. Once you include sendgrid.net, mailgun.org, _spf.google.com, Workspace, and a few others, you can burn through 10 fast. Adding LobsterMail's SPF mechanism might tip you over — and when you exceed the limit, validating servers return a PermError, which looks identical to a misconfiguration.

Check your current SPF with:

dig TXT yourdomain.com | grep "v=spf1"

Count the include: directives. Each one typically costs 1–3 lookups depending on what's nested inside it. dmarcian's SPF surveyor counts the full tree for you and shows exactly where the excess is. If you're over 10, you need to flatten your SPF chain by replacing some include: references with their constituent IP ranges.

Also: you should have exactly one v=spf1 record. Multiple SPF records at the same name are technically invalid. Email providers handle this inconsistently — some reject everything, some use the first record, some use the last. If dig returns two v=spf1 lines, merge them into one.

DKIM record issues#

DKIM records are longer and more fragile than standard TXT records, and a few things break them specifically.

The record name for DKIM looks like lobstermail._domainkey.yourdomain.com — the exact selector will be shown in your LobsterMail dashboard. That underscore in _domainkey is required by the spec. A small number of DNS providers don't allow underscores in record names. If your provider rejects it, contact their support team. This is a documented limitation and most providers have a workaround or a dedicated DKIM record field that handles the underscore correctly.

DKIM values are long. The full public key can run 300+ characters. Some DNS control panels silently truncate long TXT values, particularly older cPanel-based shared hosting environments. After saving the record, read it back with dig and compare the character count against what's in your dashboard:

dig TXT lobstermail._domainkey.yourdomain.com

If the value returned by dig is shorter than the value in the dashboard, it got truncated on save. The fix depends on your provider — some let you split the value into multiple quoted chunks in a single record entry, which is valid per RFC 4408 and most DKIM validators handle it fine.

Platform-specific quirks#

A few specific platforms bite people consistently.

Cloudflare's orange cloud proxy mode rewrites headers and intercepts traffic in ways that break SPF alignment and DKIM signatures. Every DNS record associated with your sending domain — the MX record, the verification TXT, the DKIM record — should be set to "DNS only" (gray cloud). This doesn't affect how your site is proxied, only the DNS resolution for those specific records.

Route 53 handles TXT records correctly but expects values to be double-quoted when entered through the web console. If you paste a value without quotes in the Route 53 interface, it gets saved incorrectly and dig returns it wrong. Always wrap TXT values in double quotes when using the Route 53 console. The CLI and Terraform handle this differently and generally don't need the quotes.

GoDaddy's DNS propagation is slow. Four to six hours is realistic, sometimes longer. Beyond that, GoDaddy's editing interface has a habit of appearing to save a change while actually reverting to the old value. After saving any DNS record in GoDaddy, reload the DNS management page and read the record back before declaring it done.

If your domain's DNS is managed through Vercel or Netlify's nameservers: both platforms have limited support for the full range of DNS record types and formats you need for email authentication. If you're running into problems, moving DNS management to Cloudflare (while keeping hosting wherever it is) gives you significantly better control. Hosting and DNS don't need to be with the same provider.

After making a fix: re-trigger verification#

After correcting a DNS record, you need to explicitly re-trigger the verification check. Most systems cache the last result — just waiting won't do anything.

In the LobsterMail dashboard, there's a "Verify again" button on the custom domain setup screen. Use it after you've confirmed the corrected record is visible in dig. If you prefer the API:

curl -X POST https://api.lobstermail.ai/v1/domains/{domain_id}/verify \
  -H "Authorization: Bearer lm_sk_live_..."

The verification check runs against live DNS, so propagation still needs to be complete before this will work. Clicking verify immediately after making a change will just return the same failure.

If you've checked everything and it's still failing#

A few less common causes worth ruling out before giving up.

Run the check from a different network. Corporate DNS resolvers and some ISPs cache aggressively. Your work laptop might be returning cached results while the change has already propagated globally. Check from a mobile hotspot or use a tool like dnschecker.org that queries from multiple geographic locations simultaneously.

Check for a broken DNSSEC signature. DNSSEC validation failures cause the entire domain's DNS to return errors for any resolver that validates signatures. When DNSSEC breaks, it breaks everything — not just email. It's rare but catastrophic. Verisign's DNSSEC debugger will tell you immediately whether your domain has a DNSSEC issue.

Confirm you're verifying the right hostname. If your sending address is agent@mail.yourdomain.com, you're verifying mail.yourdomain.com, not yourdomain.com. The verification TXT record, SPF record, and DKIM record all need to be placed at the exact hostname you're setting up as the sending domain.

When you're unblocked#

Once the domain is verified, your agent gets a persistent inbox under a domain it controls. Emails sent from a verified custom domain go out with proper SPF alignment and DKIM signatures, which matters for deliverability — especially as your agent's send volume grows. The shared @lobstermail.ai domain is fine for verification codes and internal automation, but outbound emails representing your company or a customer-facing agent persona land differently when they come from a domain you own.

Getting through this verification gate is the last piece of infrastructure setup. After this, provisioning inboxes is one function call:

const inbox = await lm.createSmartInbox({ name: 'My Agent', domain: 'yourdomain.com' });
console.log(inbox.address); // my-agent@yourdomain.com

Give your agent its own email address on your domain. Get started with LobsterMail — it's free.