The domain troubleshooting guide can help with most custom domain configuration issues. You might be able to use that guide to solve it before a human is available to help you. Then you can come back here and share the answer for bonus points.

https://vercel.com/docs/projects/domains/troubleshooting

You can also use v0 to narrow down the possibilities.

Hi Rafin,

Your diagnosis sounds reasonable: the records in the Vercel DNS panel will only matter if the domain is actually delegated to Vercel’s nameservers at the registry level.

I’d verify the delegation from outside both dashboards with:

1
dig NS asifhossain.dev +short
2
dig SOA asifhossain.dev +short
3
dig MX asifhossain.dev +short
4
dig +trace asifhossain.dev
5

If dig NS or the trace still points to Netlify / p01.nsone.net, then the MX records you added in Vercel cannot be served yet, even if they look correct in the Vercel DNS UI. In that case, this is not really an ImprovMX issue — the authoritative nameservers are still wrong.

Since you said the domain was registered through Vercel and the “Restore Original Nameservers” option is disabled, I’d include the dig NS and dig +trace output in the support case and ask specifically for the registry delegation to be checked against the nameservers shown in the Vercel dashboard.

Until the public NS records show Vercel’s nameservers, changing MX/TXT records in the Vercel DNS panel probably will not change the external result.

Hi Ryux,

Thanks for the detailed diagnosis steps. Update: the issue with asifhossain.dev has been resolved. Netlify confirmed they released the domain from their NS1 zone (it was previously orphaned there with "responsible mail addr = domains+netlify.netlify.com" under p01.nsone.net, despite the Vercel DNS panel showing p05 nameservers).

After Netlify released it, the delegation correctly resolved to Vercel's nameservers (ns1/ns2.vercel-dns.com), and MX records for ImprovMX (mx1/mx2.improvmx.com) are now resolving correctly. Email forwarding is working.

However, I've found the same issue on another domain I own, quickfinance.tools, which was also previously connected to the deleted Netlify team. Running the same checks:

1
nslookup -type=SOA quickfinance.tools
2

3
primary name server = md-link-5
4
responsible mail addr = domains+md-link-6

This shows the same orphaned Netlify NS1 zone (p01), even though the NS records returned are p02.nsone.net.

Could you check the registry-level delegation for quickfinance.tools as well, and confirm whether this domain also needs Netlify to release their orphaned zone, similar to asifhossain.dev?

Thanks, Asif

Hi Asif,

Glad the first domain is resolved.

For quickfinance.tools, I can’t check or change the registry delegation from here, but the SOA result you shared is a strong sign it is still being answered by a Netlify-managed NS1 zone. The fact that you see p02.nsone.net in one place and dns1.p01.nsone.net in the SOA does not necessarily change the diagnosis — the important part is that the SOA responsible email is still domains+netlify.netlify.com.

I’d run these for the second domain and compare the parent delegation with the authoritative answer:

1
dig NS quickfinance.tools +short
2
dig SOA quickfinance.tools +short
3
dig MX quickfinance.tools +short
4
dig +trace quickfinance.tools
5

If dig +trace still delegates to Netlify/NS1 rather than Vercel DNS, then the MX records in Vercel still will not be authoritative for that domain. In that case I’d ask Netlify to release quickfinance.tools from their NS1 zone too, just like they did for asifhossain.dev.

If the trace shows Vercel nameservers but the SOA still shows Netlify, then it may be resolver caching or propagation, and I’d retest from a couple of public resolvers after the TTL expires.

When contacting support, I’d include the successful asifhossain.dev resolution as precedent plus the dig +trace and SOA output for quickfinance.tools, since that shows the same orphaned-zone pattern without needing to share any private account details.