No MX Record Found: Why Your Domain Has No Mail Server and the Fix
A checker says no MX records found, or mail bounces with no mail server for the domain. The six reasons the record is invisible and how to fix each.
MX records tell every mail server in the world where to deliver mail for your domain. When a lookup returns none, senders fall back to the domain's web address and usually bounce with something like "no mail server for domain" or "unable to find MX record". If you added the record and it still does not show, the record is not where the world is looking. That is nearly always one of six mistakes, and each has a quick way to confirm it.
Quick answer
Run the domain through the free MX lookup. If it shows nothing, check in this order: the nameservers point at the DNS host where you added the record; the record is on the root of the domain and not on a subdomain; the type is MX, not TXT or A; and the value is mail.oqumail.com with priority 10. If all four are right, wait for the TTL to expire and check again.
The six causes
- Wrong DNS host. You added the record at the registrar, but the domain uses different nameservers (Cloudflare, a web host, a previous provider). Only the nameservers that are live count. A lookup of the NS records shows which ones those are.
- Full domain typed in the host field. Most panels take only the part before the domain. Typing yourdomain.com creates the record at yourdomain.com.yourdomain.com, which no one queries. The host should be blank or @.
- Wrong record type. An MX value pasted into a TXT or A record is not an MX records (the settings that tell the internet where to deliver email for your domain). Delete it and add the right type.
- Priority in the wrong box. Some panels want "10 mail.oqumail.com" in one field, others want 10 and the host separately. The lookup shows a malformed record as missing.
- registrar (the company where you bought your domain, e.g. Namecheap or GoDaddy) DNS not switched on. Namecheap, GoDaddy and others park new domains on a default DNS profile; records you add under "Advanced DNS" or "Custom" take effect only when that profile is selected.
- Not published yet. The record is correct but a resolver still holds the old answer for the TTL, often an hour. The MX lookup queries public resolvers directly, so it reflects the change sooner than your mail app does.
Find out which one
- Look up the NS records for the domain (the MX lookup result box shows the nameservers). If they belong to a different company than the panel you edited, that is the cause.
- In that panel, open the record list and read the host column. If it shows yourdomain.com.yourdomain.com or a doubled name, delete the record and add it with the host blank.
- Check the type column says MX, and the value is exactly mail.oqumail.com with priority 10. No http://, no trailing spaces.
- Query a public resolver directly to bypass your own cache: dig @8.8.8.8 MX yourdomain.com or nslookup -type=MX yourdomain.com 8.8.8.8.
- If the direct query shows the record but your checker does not, wait for the TTL and retry. If the direct query shows nothing, the record is not in the live zone.
After the record appears
Click Verify in your OquMail dashboard so the domain is marked ready, then send a test from an outside address. If mail arrives at the new provider but the sender still gets a bounce from the old one, see mail looping back to the old host. If the lookup shows two providers, read multiple MX records explained.
Common questions
Does Cloudflare's proxy hide the MX record?
No. MX records are always DNS-only. What does cause trouble is a proxied A record named mail.yourdomain.com used as an MX target, but with OquMail the target is mail.oqumail.com, so this does not apply.
The domain is new. Could that be it?
Yes, if the registrar has not yet published the nameservers to the registry, which can take an hour on a fresh registration. Everything else looks right and simply needs time.
Does a missing MX affect sending?
Indirectly. Many receivers reject or spam-file mail from a domain that cannot receive replies, and SPF records that use the MX (Mail Exchanger — where incoming email is delivered) mechanism (v=spf1 mx a:mail.oqumail.com ~all does) evaluate to nothing without one.
Want to see how your own domain is set up? Use the free MX lookup: it runs in your browser and stores nothing.