How to Set Up Custom Domain Email and MX Records

An address such as [email protected] puts your business domain in every conversation. To make it work, you need a registered domain, a receiving email service and the DNS records that connect them. Your website can remain with a different provider.

An MX record controls where other mail systems deliver incoming messages. It does not create a mailbox, migrate existing messages or configure outgoing mail. Treat the following sequence as a complete setup project rather than a single DNS edit.

Gather the information before changing anything

Identify your authoritative DNS provider, not just the company that sold the domain. Confirm that you can sign in, use its recovery process and export the current records. Record existing MX, SPF, DKIM and DMARC settings before replacing values.

From the new email provider, obtain its exact domain-verification instructions, MX hostnames and priorities, authentication requirements and mailbox connection details. Values vary by service and sometimes by account or region. Do not copy a mail-server hostname from an unrelated example, including the examples in an old tutorial.

Decide which addresses need separate inboxes. An alias such as sales@ might deliver to an existing mailbox, while a shared inbox needs agreed access and ownership. Avoid shared passwords when the platform supports delegated access.

Step 1: add and verify your domain

Open the email platform's domain setup workflow and add the exact domain you own. It will normally ask you to prove control using a DNS record, often a TXT token. Publish the token at the specified name in the active zone.

Verification is different from routing. A verification record can normally be added while the old mail service continues receiving messages. Check the provider's verification result before proceeding and retain the token when its instructions require it for continuing ownership checks.

A business domain does not itself guarantee trust or inbox placement. What it gives you is control over your identity and authentication, provided you configure and maintain those services properly.

Step 2: create the receiving mailboxes

Create users, shared mailboxes, aliases and any required distribution groups before moving incoming delivery. Match important addresses already published on invoices, contact pages and customer accounts.

Check storage limits, attachment limits, retention, backup arrangements, access controls and the difference between an included alias and a licensed mailbox. Five addresses with tiny shared storage are not automatically equivalent to five large independent mailboxes.

If you are migrating, agree which messages, calendars and contacts will move and how. Keep an independent recovery copy appropriate to your business. An IMAP synchronisation job does not necessarily migrate calendars, contacts, rules or permissions.

Step 3: prepare the DNS change

Record your old MX values and lower their TTL in advance if your provider allows it. Allow the old TTL to pass before the cutover. Schedule the move when someone can watch mail flow and respond, rather than immediately before a holiday or campaign launch.

Do not add the new provider as a casual “backup MX” alongside the old provider. MX preference is a routing mechanism, not a mailbox-migration system. Mixed destinations without a supported coexistence design can split delivery between systems and create confusing missing-message reports.

For Microsoft 365, Google Workspace, Zoho or another platform, use that platform's current domain wizard. Historical tutorials may show a different MX set from the one required for your account today.

Step 4: publish the MX entries

An MX entry needs the owner name, preference and receiving hostname. The owner is commonly the domain apex, represented as @. A lower preference number has higher priority, but the correct numbers come from your provider.

Remove obsolete entries according to the migration plan once the new service is ready. If a web proxy is in use, ensure mail-related records and their targets follow the DNS provider's email guidance. A normal web proxy does not transport standard SMTP traffic simply because a hostname is proxied.

Step 5: authenticate outgoing mail

Inventory every sender using your domain: staff mail, the website contact form, e-commerce receipts, invoicing software and newsletters. Receiving email and authorising these senders are separate jobs.

Publish one applicable SPF policy containing the authorised infrastructure. Enable DKIM signing at each sending service and publish the exact public key or selector CNAME it supplies. Never publish the private signing key.

Set up DMARC reporting and check alignment with the visible From domain. Start with observation while you identify legitimate senders, then move towards enforcement after testing. Authentication helps receiving systems evaluate messages; it does not override reputation, content quality, recipient preferences or a compromised authorised account.

Step 6: connect desktop and mobile applications

Use the provider's supported setup method for Outlook, Apple Mail, Thunderbird or another client. An account using modern sign-in may redirect you to an authorisation screen rather than ask you to enter a server password directly.

For manual configurations, obtain the incoming IMAP and outgoing SMTP hostnames, ports and encryption settings from the provider. Do not guess that mail.yourdomain is valid. The hostname must match the certificate and the service's supported connection method.

IMAP normally synchronises mailbox folders across devices; POP behaviour differs and can remove messages depending on settings. Confirm that sent items and deleted messages synchronise as expected. Enable multi-factor authentication where supported and use the provider's documented application-password process only when required.

Step 7: test mail in both directions

Send from an unrelated external mailbox to each important address. Reply from the new service and inspect delivery, spam placement and authentication results. Test aliases, shared mailboxes, website forms and transactional receipts separately.

Check public MX answers and compare authoritative results with a recursive resolver. A correct new answer does not prove every cache has expired. Watch both the old and new services during the overlap, and run a final message synchronisation before retiring the old account.

Save the result of each test, including timestamp, sender, recipient and any bounce message. A delivery-status code or message header is far more useful for diagnosis than “email is broken”. Remove personal message content before sharing evidence with support.

Document the operating routine

Assign an owner for new starters, leavers, shared inboxes and storage alerts. A mailbox migration is a good moment to remove dormant access and check whether former staff still receive forwarding copies. Keep business records according to an appropriate retention policy rather than retaining every message indefinitely by default.

Train staff to verify unexpected payment-detail changes through a known independent contact method. SPF, DKIM and DMARC cannot stop a criminal sending a convincing invoice from a different lookalike domain or from a genuinely compromised supplier account. Good email administration includes these human checks alongside the technical configuration.

Troubleshoot the right layer

If no external mail arrives, check MX, domain activation and receiving mailboxes first. If sending fails from only one application, investigate its sign-in or SMTP configuration. If mail arrives in junk, inspect authentication, reputation and message practices instead of repeatedly changing MX.

When the provider is telaHosting email hosting, ask for the exact settings for your ordered service. Review capacity and recovery requirements as the team grows. A successful setup is one you can test, document and hand over, not merely one showing a green DNS verification tick.