How to Set Up MX Records for Custom Domain Email

Setting up email on your own domain so messages come from [email protected] instead of a generic free address is one of the quickest credibility upgrades a business can make. The piece of plumbing that makes it work is the MX record, the DNS entry that tells the rest of the world which servers are allowed to receive mail for your domain. Get it right and mail flows in cleanly; get it wrong and messages bounce, vanish, or land in spam. This guide walks through what MX records do, how to set them up for a real provider, the records you must add alongside them for deliverability, the mistakes that trip people up, and how to confirm everything is correct. You can inspect any domain's current configuration as you go with the MX Lookup lookup tool.

MX stands for Mail Exchanger. An MX record points your domain at the hostname of a mail server that accepts incoming email on your behalf. When someone sends a message to [email protected], the sending server looks up the MX records for yourcompany.com, finds the destination servers, and delivers the mail there. Without a valid MX record, the internet has no idea where to route your mail, and senders receive a delivery failure.

Every MX record carries a priority number, and this is where people get confused: a lower number means higher priority. A server listed with priority 1 is tried before one listed with priority 10. Priorities give you failover. If you publish two records, say a primary at priority 1 and a backup at priority 5, senders attempt the priority 1 server first and only fall back to the priority 5 server if the first is unreachable. When two records share the same priority number, senders distribute mail between them roughly evenly, which providers use for load balancing. The actual numbers are arbitrary; only their relative order matters.

You do not run your own mail server for a custom domain in most cases; you sign up with a hosted email provider and point your domain at them. The popular choices are Google Workspace and Microsoft 365 for full office suites, and Zoho Mail and Fastmail for leaner, often cheaper email-focused plans. All four let you use your own domain, and all four give you a specific set of DNS records to publish.

Pick one provider and commit to it. A domain should have exactly one set of MX records pointing at one mail system. You cannot split incoming mail for the same address across two providers by listing both their MX records, that only causes unpredictable routing. Once you have an account, the provider's admin console will display the exact MX hostnames and priorities you need, which is always the authoritative source, since values change over time.

Each provider gives you their own hostnames. The shapes look roughly like this. Microsoft 365 typically uses a single MX record at priority 0 in the form yourdomain-com.mail.protection.outlook.com. Zoho commonly publishes three records: mx.zoho.com at priority 10, mx2.zoho.com at priority 20, and mx3.zoho.com at priority 50. Fastmail uses in1-smtp.messagingengine.com and in2-smtp.messagingengine.com at priorities 10 and 20.

Google Workspace historically handed out five records (ASPMX.L.GOOGLE.COM plus four ALT servers at increasing priorities) but now issues a single simplified record, SMTP.GOOGLE.COM at priority 1, for new setups. Whatever your provider shows in their console is what you publish, exactly, including the trailing structure of the hostname. Do not copy values from an old blog post; copy them from your own admin panel.

Log in to wherever your DNS is hosted, this is your domain registrar or DNS provider (Cloudflare, Namecheap, GoDaddy, Route 53, and so on), not necessarily your email provider. Find the DNS or zone management section. Before adding anything, delete every existing MX record on the domain. Leftover records from a previous host or a registrar's default parking setup are the single most common cause of mail going to the wrong place.

Now add the new MX records. Set the host or name field to the apex of your domain, which most panels represent as @ (some show it as blank or as your full domain name). For each record, enter the provider's hostname as the value and its priority number in the priority field. Add one row per MX hostname your provider listed. Leave the TTL at the default, often 3600 seconds, unless you have a reason to change it. Save the zone.

Here is what a finished Google Workspace setup looks like in zone-file form, which mirrors what your DNS panel stores under the hood:

yourcompany.com. 3600 IN MX 1 SMTP.GOOGLE.COM.

A Zoho setup with failover would instead read:

yourcompany.com. 3600 IN MX 10 mx.zoho.com. yourcompany.com. 3600 IN MX 20 mx2.zoho.com. yourcompany.com. 3600 IN MX 50 mx3.zoho.com.

Notice the trailing dot after each hostname in zone-file notation, it marks the name as fully qualified. Most web-based DNS panels add this for you automatically, so you usually type the hostname without it. The number immediately before the hostname is the priority.

MX records get mail to you, but they do nothing to prove that mail leaving your domain is legitimate. Three TXT-based records handle that, and skipping them is why so much custom-domain email lands in spam or gets rejected outright. They are not optional extras in 2026; major receivers expect them.

SPF (Sender Policy Framework) is a TXT record at your apex listing which servers are allowed to send mail as your domain, for example v=spf1 include:_spf.google.com ~all. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing messages; your provider gives you a public key to publish as a TXT or CNAME record on a selector hostname like google._domainkey.yourcompany.com. DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the two together and tells receivers what to do with mail that fails, published as a TXT record at _dmarc.yourcompany.com, such as v=DMARC1; p=none; rua=mailto:[email protected]. Start DMARC with p=none to monitor, then tighten to quarantine or reject once you confirm legitimate mail passes. Check each one with the SPF Check, DKIM Check, and DMARC Check tools after you publish it.

Leftover MX records top the list. If you migrate providers but forget to delete the old MX entries, senders may keep routing mail to a mailbox you no longer read. Always clear the slate before adding new records, and verify afterward that only your new provider's records remain.

Trailing-dot and formatting errors are next. In zone-file syntax a hostname needs a trailing dot to be absolute, but most web panels expect you to omit it; pasting a hostname with an extra dot, or with a stray space, produces a record that silently fails. Equally common is putting an IP address or a URL in the MX value, an MX must point to a hostname, never an IP.

A CNAME-at-apex conflict can break things subtly. The DNS standard forbids a CNAME from coexisting with any other record on the same name, so if your apex domain is set up as a CNAME (or an ALIAS that your provider mishandles), your MX records there may be ignored. Keep the apex as A or ALIAS records, not a plain CNAME. Finally, do not point at multiple email providers at once; choose one mail system and list only its records.

Once you save the zone, the change does not take effect everywhere instantly. Resolvers cache the old answer until its TTL expires, so allow anywhere from a few minutes to a few hours for the new records to propagate globally, occasionally up to 24 to 48 hours for stubborn caches. Send a test message from an outside account to an address on your domain, and send one out from the new mailbox to confirm both directions work.

To confirm the records themselves, run a lookup with the MX Lookup tool, which lists every MX hostname and its priority so you can check they match your provider's instructions exactly and that no old records linger. For a fuller picture of the zone, including the SPF, DKIM, and DMARC TXT records you added, the DNS Lookup lookup tool shows everything in one place. On the command line, dig yourcompany.com MX or nslookup -type=mx yourcompany.com does the same job. If a lookup shows the old values, you are simply waiting out the TTL rather than facing a real misconfiguration.