2026 Custom Domain Email Alias Not Receiving Mail? Check the Domain and MX First

ICANN’s expired-domain guidance is dated August 30, 2013, and explains that an expired domain can leave associated services unavailable (ICANN’s guidance on expired domains). If a custom domain email alias is not receiving mail, check the domain’s status first, compare its MX records with the current mail provider’s instructions next, and inspect the alias and forwarding destination last. Do not assume that messages missed during an outage will arrive automatically after recovery.

Who this is for: People using a custom domain for personal or work email who need to separate a domain, DNS, and mailbox problem.
Freelancers who rely on project or client addresses can use the checks below to locate a broken delivery step.
Long-term alias users will also find a maintenance process for renewals, DNS changes, and recovery.

Custom domain email alias not receiving mail: start with the domain state

An alias is only one part of the delivery path. A message addressed to a custom domain must first reach a working domain and mail-routing setup. A forwarding rule cannot compensate for a domain that is suspended, and changing an alias does not fix MX records that point to an old provider.

Keep the fault path in this order:

Domain status → MX records → alias and forwarding rule → destination inbox.

That order prevents a common troubleshooting detour: repeatedly editing an alias while the domain itself is inactive or mail is being routed elsewhere. It also keeps separate services separate. A website can load while its email route is broken because web traffic and email delivery rely on different DNS record types and may use different providers. Microsoft’s documentation treats custom-domain setup as a set of service-specific DNS requirements, rather than one setting that makes every domain service work (Microsoft’s custom-domain setup guide).

Before changing anything, note which company manages the domain registration, which service hosts its DNS, and which provider handles email. They may be the same company, but they do not have to be. Make changes in the DNS zone that is authoritative for the domain; editing an unused DNS dashboard will not change the records that senders see.

Domain status and renewal problems

Sign in to the domain registrar and inspect the domain’s current status, expiry information, renewal settings, and any notices asking for account or contact verification. A domain may be expired, suspended, or affected by an administrative issue. The exact status labels and recovery process vary by registrar, so use that registrar’s own instructions rather than assuming a universal renewal procedure.

If the domain is not active, resolve that issue before editing mail records. ICANN’s renewal guidance notes that domain renewal and associated services are related, but restoration can depend on the registrar and service involved (ICANN’s domain-renewal guidance). The practical consequence is that a successful payment or a changed status in one dashboard is not enough evidence that mail is flowing again. Confirm the domain is active, then test the mail path separately.

Also check whether the domain account has a pending verification or management issue. A registration can be paid for and still require an action before the provider considers it fully operational. When the registrar shows a hold or unresolved notice, follow its remediation steps and avoid making unrelated alias changes until the domain status is clear.

MX records and mail routing

When the domain is active, inspect its MX records in the DNS provider’s control panel. Compare the records that are currently published with the configuration supplied by the email provider that is meant to receive mail today. Check the destination host and any priority values shown in that provider’s instructions. Cloudflare’s email troubleshooting documentation likewise directs domain owners to inspect MX records when diagnosing mail delivery problems (official MX troubleshooting guidance).

A frequent cause of interruption is a leftover MX record from an old mail provider. This can happen after a migration, a DNS template change, or a domain transfer. Do not use a record copied from a tutorial or another company’s help page as a shortcut. The correct values depend on the service currently configured for the domain. The official setup instructions for one provider are not a universal recipe for every mailbox service. For example, providers publish their own domain-specific MX requirements (Google Workspace MX setup instructions; Microsoft’s external DNS records reference).

Record what is already there before making a change. If a provider’s instructions call for replacing or removing existing entries, follow those instructions carefully; do not delete unrelated records simply because they are in the same DNS zone. If the provider’s documentation and DNS dashboard appear to disagree, confirm that you are editing the active DNS host and that you are reading the setup instructions for the correct mail service and domain.

A website that still loads only confirms that its web route is responding. It does not confirm that the domain’s MX records point to a working mail service.

Alias and forwarding checks

If the domain is active and the MX records match the current provider’s requirements, move down the delivery path. Confirm that the recipient address still exists, that the alias has not been disabled, and that its forwarding rule still targets the intended inbox. A valid alias can still fail to deliver if the destination address changed, was removed, or is no longer accessible.

It helps to separate the address layer from the delivery method. An alias is an address or recipient identity; forwarding is a rule that sends incoming mail elsewhere. Their exact relationship depends on the service. The guide to email address relationships can help clarify where an alias ends and forwarding begins, which matters when an address is present but its delivery route is not.

Use a low-risk test message and observe each point in the route:

• Send a message to the original domain address, if it is a mailbox you can access.
• Send a separate message to the alias address.
• Check whether the alias provider recorded or accepted the message.
• Look in the final destination inbox, including spam, quarantine, and filtered folders.
• If the service offers delivery logs or bounce details, check them before changing the rule.

A message reaching the original address but not the alias suggests a problem in the alias or forwarding layer. A message accepted for forwarding but missing from the destination points toward the target mailbox, its filters, or a delivery rejection there. If neither address receives a message, return to the domain and MX checks. The mail arrival troubleshooting guide can help distinguish a delayed or filtered message from a failure earlier in the route.

Recovery verification and messages sent during an outage

After correcting a domain status or DNS setting, send a fresh test message. Do not treat the change itself as proof of delivery. Confirm that the test arrives at the intended destination, then check the service’s logs, quarantine, and bounce reports for messages that failed before the fix.

If an important sender says a message was sent during the interruption, ask whether it bounced, remains queued, or was accepted by a mail server. Those outcomes are not equivalent. A sender may need to retry, and a message that received a rejection may not be retried automatically. Neither a domain renewal nor a corrected MX record guarantees that previous messages will be replayed. For anything time-sensitive, request a resend after confirming that a new test message reaches the inbox.

Use a separate contact method when contacting the sender or provider. If the affected domain is your only listed contact address, you may not receive replies about the outage. This is one reason to keep a recovery address that does not depend on the domain being diagnosed.

Frequently asked questions

Can an email alias keep receiving mail after its custom domain expires?

Usually, you should not expect mail to keep working when the domain is expired, suspended, or otherwise inactive. The alias depends on the domain being valid and on its DNS records remaining usable. Check the registrar’s status and renewal notices first. Restoring the domain may not restore every associated service immediately, so verify the mail route and ask important senders to retry.

What should you check when a website loads but its domain email does not?

A website and email can use separate DNS records, providers, or hosting arrangements. A working website therefore does not prove that the domain’s mail route is configured correctly. Check the domain status, then inspect the MX records against the current email provider’s official setup instructions. If those are correct, move on to the alias, forwarding rule, and destination inbox.

How do you check missing or conflicting MX records?

Open the DNS zone at the provider that currently hosts the domain’s DNS, not necessarily the registrar. Compare every MX entry with the current mail provider’s instructions, including the destination host and any priority values it specifies. Look for missing entries or records left from an older provider. Do not copy another service’s example values; use the configuration intended for your own account.

Will email that failed during a domain outage arrive after renewal?

Do not assume that it will. A domain renewal or DNS correction may restore future delivery, but it does not guarantee that a sender or intermediate mail system will retry messages that previously failed. Check for a bounce or quarantine notice, then contact the sender of any important message and ask them to confirm delivery or send it again.

A decision path for choosing the next action

Use the condition that matches the evidence rather than changing several settings at once:

• If the registrar shows an expired, suspended, or unresolved domain status, resolve that status first. Then check mail routing again. If the domain is active, continue to MX verification.
• If the domain is active but its MX records are missing or do not match the current provider’s instructions, correct only the relevant mail records using that provider’s documented configuration. Then send a fresh test message.
• If the MX records match and the mail service accepts the message, inspect the alias, forwarding rule, target address, and destination filters.
• If the provider reports a rejection or the sender received a bounce, keep the diagnostic details and ask the sender to retry only after the delivery path passes a fresh test.
• If you cannot identify the active DNS host or mail provider, pause before editing records. Confirm ownership and configuration with the registrar, DNS host, or mail provider. Guessing at MX values can create a second fault.

This is a troubleshooting sequence, not a promise that every service will recover in the same way. The registrar, DNS host, and mail provider can each have different dashboards, verification steps, and status information.

Maintenance choices for long-term aliases

Once mail works again, write down who controls each part of the setup and how the next check should be performed. Keep the registrar account’s recovery contact outside the custom domain, save the mail provider’s current setup instructions, and record the DNS host where MX changes must be made. Review those notes whenever a provider or DNS arrangement changes.

A migration deserves its own verification pass. When moving mail services, keep the old provider’s settings and the new provider’s documented settings separate. Confirm which one should receive new mail before changing MX records, and test the destination after the change. Avoid assuming that a successful website migration or domain transfer also migrated email routing.

For important services, use an inbox you can access long term, not an address that may disappear when a temporary session ends or a forwarding rule changes. Keep banking, payment, government, and other account-recovery messages tied to a durable address you control directly. An alias can make routine intake easier to sort, but it should not become a single point of failure for account access.

If the address is only needed for a short-lived signup or a one-time verification message, using a separate temporary inbox can keep your primary address out of that registration flow and help avoid adding unrelated messages to your regular inbox. Forwardtmp is an option to check for that limited use; review its current page for the available address and service rules rather than assuming it supports your custom domain or a particular forwarding setup. For a custom-domain outage, first use a long-term reachable mailbox for important notices, then work through the domain, MX, and alias checks above.

Frequently asked questions