An MX record tells sending mail servers where to deliver email addressed to your domain. It does not point visitors to your website and does not authorize your outgoing messages.
What an MX record looks like
This is a fictional example, not a configuration to paste into your DNS:
example.com. MX 10 mail1.example.com. example.com. MX 20 mail2.example.com.
The number is the priority: lower values are preferred. A sender normally tries the priority-10 server first and can try another server if delivery fails. The destination is a mail server hostname, not an email address, IP address or web URL. Your provider supplies the actual hostnames and priorities.
MX, website records and authentication are separate
- A/AAAA and CNAME: connect names to your website or another host.
- MX: routes incoming email.
- SPF: identifies servers authorized to send for a domain.
- DKIM: lets receivers verify a signature added to an outgoing message.
- DMARC: checks alignment with the visible From domain and publishes a handling policy.
You can host the website and email with different companies. Do not delete website records to install email. An MX check also cannot tell you whether a particular mailbox exists, whether a password works, or whether a message will reach the inbox.
How to check your own MX records
- Find the authoritative DNS provider from your domain's nameservers. That may be different from the registrar.
- Run the domain email DNS check and compare the returned MX values with your email provider's instructions.
- Check the root domain, not a full address: enter example.com rather than hello@example.com.
- Look for old provider records mixed with the new ones. Keep only records required by the intended receiving service, after checking migration requirements.
- After a change, allow existing DNS caches to expire. Test delivery to an existing mailbox from a different provider and read any bounce message.
What if there is no MX record?
SMTP specifies an address-record fallback when a domain has no MX records, but modern hosted email should use the provider's explicit MX configuration. A special null MX record, with priority 0 and destination '.', declares that a domain accepts no incoming mail. These rules come from SMTP routing, RFC 5321 section 5.1 and null MX, RFC 7505.
Receiving works, but sending fails?
Check the email app's SMTP hostname, port, encryption and login. Then inspect a delivered message's authentication results. Changing MX is generally not the fix for an outgoing authentication problem. Modusdom email uses OpenSRS hosted email; its published SPF include is _spf.hostedemail.com. Preserve other legitimate senders when updating the existing SPF record. OpenSRS SPF instructions.
Need help interpreting the result? Contact support with the domain, the time of the failed delivery and the bounce text. For a scoped DNS review, see email setup help.
