Email Forwarding Not Working: DNS, MX, Alias, and Mailbox Checks

Quick answer: why email forwarding is not working

If email forwarding is not working, check these first:

Email forwarding still needs correct receiving setup. Check nameservers, MX records, forwarding rules, and the destination mailbox before changing SPF, DKIM, or DMARC.

For the wider setup sequence, use the business email setup checklist.

What email forwarding actually means

Email forwarding means mail sent to one address is delivered to another address.

hi@example.com -> yourname@gmail.com

The sender sends to hi@example.com, but the message ends up in yourname@gmail.com.

This is different from a real mailbox. A real mailbox has its own inbox, login, storage, sending identity, and settings. A forwarding address is usually just a routing rule.

Forwarding can be useful, but it is not always enough for serious business email. A real mailbox, shared mailbox, group, or distribution list can be cleaner when the address matters to customers.

Forwarding vs mailbox vs alias vs group

These terms are often confused.

A forwarding problem may actually be an alias problem, group problem, mailbox problem, or MX problem. Identify the setup type before changing DNS.

Step 1: identify the forwarding path

Write down the exact path before troubleshooting.

hi@example.com -> hello@maincompany.com
support@example.com -> support-team Google Group
info@example.com -> personal Gmail

Do not troubleshoot blindly until the forwarding path is clear.

Step 2: confirm active nameservers

Before editing DNS, confirm where live DNS is managed. Nameservers decide which DNS provider is authoritative for your domain.

In that setup, the live MX records must be in Cloudflare. Adding MX records at Namecheap will not fix forwarding if Cloudflare is the active DNS host.

• Forwarding provider says MX records are missing.
• DNS checker still shows old MX records.
• Your DNS dashboard looks correct but public DNS does not change.
• Website works, but forwarding does not.
• You recently changed nameservers.
• Records exist in multiple DNS dashboards.

Find the active nameservers. Then edit MX, TXT, CNAME, and forwarding-related DNS only at the active DNS host. The email DNS checker guide explains this first step in more detail.

Step 3: check MX records

MX records control where incoming email is delivered. Forwarding can only happen if the forwarding provider receives the email.

For hi@example.com to forward, the MX records for example.com must point to the provider that handles the forwarding.

Do not mix MX records casually. If MX still points to Google Workspace, Cloudflare Email Routing will not receive the mail. If MX still points to Cloudflare Email Routing, Microsoft 365 will not receive the mail directly.

Use the MX Record Checker guide when incoming mail is not reaching the expected provider.

Step 4: remove old MX records when ready

Old MX records are one of the most common causes of forwarding failure.

For example, if you want to use Cloudflare Email Routing but DNS still has Google Workspace MX records, Google receives the email, not Cloudflare. Cloudflare cannot forward a message it never receives.

Common bad setup:

example.com MX 1 smtp.google.com
example.com MX 5 route1.mx.cloudflare.net
example.com MX 10 mail.oldhost.com

That mixes providers. It usually creates confusing routing.

Use the MX records required by the provider that should receive the mail. If Cloudflare Email Routing should receive it, use Cloudflare's required MX records. If Google Workspace should receive it, use Google's current MX instructions. If Microsoft 365 should receive it, use the domain-specific Microsoft 365 MX record from Microsoft.

Step 5: confirm the forwarding address exists

DNS does not automatically create forwarding addresses.

If you want this to work:

hello@example.com -> yourname@gmail.com

Then hello@example.com must exist as one of these:

• Forwarding address
• Email alias
• Group
• Shared mailbox
• Distribution list
• Real mailbox with a forwarding rule
• Catch-all route

A common mistake is configuring MX correctly, then testing hello@example.com when no route for hello exists inside the forwarding provider.

Result: MX is correct, the provider receives the email, but the address is unknown. Mail may bounce or disappear depending on provider settings.

Step 6: confirm the destination address is verified

Many forwarding services require the destination mailbox to approve forwarding.

hello@example.com -> yourname@gmail.com

The forwarding service may send a verification email to yourname@gmail.com. Until the destination accepts or verifies, forwarding may stay inactive.

• Did the destination mailbox receive a verification email?
• Did the user click the verification link?
• Did the verification email go to spam?
• Was the destination address typed correctly?
• Is the destination mailbox active?
• Did the forwarding service mark the destination as verified?
• Is forwarding paused until verification is complete?

This is especially common with forwarding-only services.

If the destination verification or MX records were just added, use the Email DNS Propagation guide before repeatedly deleting and re-adding records.

Step 7: check whether you need a catch-all

A catch-all receives mail for undefined addresses.

anything@example.com -> inbox@example.com

Without catch-all, only explicitly created addresses forward. If you created hello@example.com but someone emails hi@example.com, that message may bounce unless hi exists or catch-all is enabled.

For a business, explicit addresses are usually cleaner than relying only on catch-all. Use catch-all carefully.

Step 8: check destination spam and filters

Sometimes forwarding works, but the message is not in the inbox.

• Spam folder
• Junk folder
• Promotions tab
• Quarantine
• Rules or filters
• Blocked senders
• Auto-archive rules
• Forwarding provider labels
• Security quarantine
• Mailbox storage limit
• Inactive account status

A forwarded email may arrive in Gmail or Outlook but land in spam because the message failed authentication after forwarding. In that case, forwarding is not completely broken, but delivery is poor.

Use the Email Going to Spam guide when forwarded mail arrives but is filtered.

Step 9: understand that receiving and sending are separate

Forwarding can help you receive email at hello@example.com. It does not automatically let you send from hello@example.com.

Receive: hello@example.com -> personal Gmail
Send: From hello@example.com

Those are separate setups.

A common mistake is setting up hi@example.com -> personal Gmail, then replying from personal Gmail and expecting the reply to come from hi@example.com.

Forwarding solves receiving. It does not automatically solve sending identity. If you need to send professionally from the domain, a real mailbox or properly configured send-as setup may be better.

Step 10: email forwarding and SPF

SPF checks whether the sending server is authorized to send for the domain used in the envelope sender.

Forwarding can affect SPF because the message may be resent by the forwarding provider.

1. Original sender sends from sender.com.
2. Message goes to hello@example.com.
3. Forwarding service forwards it to yourname@gmail.com.
4. Gmail receives it from the forwarding service's server.
5. SPF may fail because the forwarding service is not authorized in sender.com SPF.

This does not necessarily mean your forwarding provider is broken. It is a known issue with forwarded mail.

Forwarding providers may use techniques such as sender rewriting to reduce SPF problems. DKIM can also help if the original message was signed and the forwarding process does not modify the signed content.

For SPF cleanup, use the SPF Record Checker guide.

Step 11: email forwarding and DKIM

DKIM can survive forwarding better than SPF, but only if the message is not modified in a way that breaks the signature.

DKIM may fail if forwarding or filtering changes:

• Message body
• Signed headers
• Subject line
• Footer
• Disclaimer
• Mailing list tags
• Tracking links
• Attachments

If forwarded mail lands in spam, check whether the final mailbox shows:

dkim=pass

dkim=fail

If DKIM fails after forwarding, the forwarding path may be modifying the message. For selector and provider setup help, use the DKIM Record Checker guide.

Step 12: email forwarding and DMARC

DMARC checks whether SPF or DKIM passes and aligns with the visible From domain.

Forwarding can create DMARC problems because SPF often fails after forwarding. If DKIM survives and aligns, DMARC may still pass. If both SPF and DKIM fail, DMARC fails.

Common forwarding result:

spf=fail
dkim=pass
dmarc=pass

That can be acceptable because DKIM carried DMARC.

More serious result:

spf=fail
dkim=fail
dmarc=fail

That can cause spam placement or rejection.

For forwarded mail, DKIM becomes especially important. If you use forwarding heavily, make sure your own outgoing mail and third-party senders have proper DKIM.

For policy rollout, use the DMARC Record Checker guide, and for the relationship between the three records use the SPF vs DKIM vs DMARC guide.

Step 13: Cloudflare Email Routing troubleshooting

Cloudflare Email Routing is a forwarding service. It receives mail for your domain and forwards it to destination addresses. It is not a full mailbox provider.

• It can forward incoming email.
• It does not give you a normal inbox.
• It does not automatically let you send from the forwarded address.
• It requires correct MX records.
• It requires routing rules.
• It may require destination verification.

• Cloudflare is the active DNS host.
• Email Routing is enabled.
• Required Cloudflare MX records exist.
• Old MX records are removed if Cloudflare should receive mail.
• Destination address is verified.
• Custom address is created.
• Routing rule points to the correct destination.
• Catch-all is configured only if intended.
• Destination spam folder is checked.
• The sender receives no bounce.
• Cloudflare Email Routing dashboard shows no DNS warning.

Common mistake: you create hi@example.com -> yourname@gmail.com, but MX still points to Google Workspace or Microsoft 365. Cloudflare never receives the message, so the route never runs.

If Cloudflare-specific DNS records are involved, keep MX and TXT records DNS-only. Email-related CNAME records should generally be DNS-only too.

Step 14: Google Workspace forwarding and aliases

In Google Workspace, forwarding may involve user aliases, groups, routing rules, Gmail forwarding, domain aliases, or secondary domains.

An alias is not exactly the same as a forwarding service. A user alias delivers mail to the same mailbox as the primary user.

alice@example.com
alias: hello@example.com

Mail sent to hello@example.com arrives in Alice's mailbox.

• Google Workspace MX records are active.
• Domain is verified in Google Admin.
• Gmail is activated.
• The user mailbox exists.
• The alias is added to the correct user.
• The group exists if using a Google Group.
• Group posting permissions allow external senders if needed.
• Routing rules are active if using advanced routing.
• The destination mailbox is not filtering the message.
• The address is not duplicated as another user, alias, or group.

Creating an alias does not necessarily mean every user can send from it automatically in the way they expect. Test both receiving and sending.

For Google DNS setup, use the Google Workspace and Cloudflare guide.

Step 15: Microsoft 365 forwarding and shared mailboxes

In Microsoft 365, forwarding can involve user mailbox forwarding, shared mailbox forwarding, aliases, distribution groups, Microsoft 365 groups, mail flow rules, or Outlook inbox rules.

• Microsoft 365 MX record is active.
• Domain is verified.
• User mailbox exists.
• User has a license if needed.
• Shared mailbox exists if using one.
• Alias is added to the correct mailbox.
• Forwarding is enabled on the mailbox if using mailbox forwarding.
• Distribution group exists if forwarding to multiple people.
• External forwarding is allowed by policy if forwarding outside the organization.
• Mail flow rules are not blocking or redirecting unexpectedly.
• Junk/quarantine is checked.

Forwarding one mailbox to multiple people may require a group or rule rather than just one forwarding field. If you need team delivery, a shared mailbox, group, or distribution list is usually cleaner than stacking individual forwarding rules.

For Microsoft DNS setup, use the Microsoft 365 and Cloudflare guide.

Step 16: email forwarding from registrar or hosting provider

Some domain registrars and web hosts offer basic email forwarding. This can work, but it often depends on their MX records.

• Registrar email forwarding
• cPanel forwarders
• Web host mail forwarding
• Domain parking email forwarding

• Does the provider require specific MX records?
• Are those MX records active publicly?
• Is the forwarding address created?
• Is the destination address verified?
• Are old MX records removed?
• Does the hosting account still exist?
• Is the service still included in your plan?
• Is the destination mailbox blocking forwarded mail?
• Are replies coming from the expected address?

If business email is important, a full mailbox provider is usually more reliable than basic registrar forwarding.

Step 17: forwarding from one domain to another

You may want:

hello@old-domain.com -> hello@new-domain.com

This is common after rebranding or buying a supporting domain.

• Old domain has active DNS.
• Old domain has MX records pointing to the forwarding provider.
• Forwarding address exists on the old domain.
• Destination address exists on the new domain.
• Destination mailbox accepts forwarded mail.
• Old domain has basic SPF/DKIM/DMARC where relevant.
• Test from external senders.
• Keep old domain renewed.
• Keep old DNS zone active.

A domain redirect for the website does not automatically forward email.

Website redirect: old-domain.com -> new-domain.com
Email forwarding: hello@old-domain.com -> hello@new-domain.com

Website redirects and email forwarding are separate setups. If the website works but email does not, use the Website Works but Email Does Not guide.

Step 18: forwarding and domain aliases

A domain alias can make every user receive email at another domain.

Primary domain: example.com
Alias domain: example.net
User: alice@example.com
Alias address: alice@example.net

This is different from creating one manual forwarding address.

• Alias domain is added to the email provider.
• Alias domain is verified.
• Alias domain MX records point to the email provider.
• User addresses map as expected.
• Role addresses such as hello@ are handled properly.
• Sending from the alias domain is configured if needed.
• SPF, DKIM, and DMARC are configured for the alias domain if it sends mail.

Do not assume adding a website redirect for the alias domain handles email.

Step 19: forwarding and send-as setup

Many users want both receiving and sending:

Receive: hello@example.com -> personal Gmail
Send: From hello@example.com

Forwarding handles the first part. Send-as handles the second part.

• Does your destination mailbox allow sending as external addresses?
• Does your domain have SMTP access?
• Does your email provider require verification?
• Does SPF include the sending server?
• Does DKIM sign the outgoing mail?
• Does DMARC pass?
• Does the recipient see the correct From address?
• Does the reply go to the right inbox?

For serious business use, a real mailbox at Google Workspace, Microsoft 365, or another mailbox provider is often cleaner than forwarding to a personal mailbox and trying to send as the domain.

Step 20: forwarding to personal Gmail

Forwarding business email to personal Gmail can be convenient, but it has limitations.

• Verification email not clicked
• Messages go to spam
• Gmail filters or labels hide messages
• Reply comes from personal Gmail
• Send-as setup is incomplete
• SPF/DMARC issues appear after forwarding
• Personal mailbox storage or rules interfere
• Customer trust may be weaker if replies come from Gmail

Forwarding to personal Gmail can be acceptable for a small test project. For a real business, use a professional mailbox or shared inbox when the address becomes important.

Step 21: forwarding to multiple people

Forwarding one address to multiple recipients can be done in several ways.

For business addresses such as support@example.com, sales@example.com, and billing@example.com, a group or shared mailbox is usually cleaner than forwarding to several personal inboxes.

A group or shared mailbox can make it easier to add and remove team members, keep history, avoid duplicate replies, control permissions, monitor ownership, and keep the business address independent of one person.

Step 22: forwarding and bounce messages

Bounce messages are useful. If forwarding fails, check whether the sender receives a bounce.

Do not ignore bounce text. It often tells you which layer failed.

Step 23: check for forwarding loops

A forwarding loop happens when mail is routed in a circle.

hello@example.com -> inbox@gmail.com
inbox@gmail.com -> hello@example.com

support@example.com -> team@example.com
team@example.com -> support@example.com

• Repeated duplicate messages
• Bounce mentioning loop detected
• Mail disappears after several redirects
• Delivery delay
• Provider disables forwarding
• Messages show many repeated Received headers

Simplify the route. Make sure each address forwards in one direction only.

Step 24: check whether external forwarding is blocked

Some organizations block automatic forwarding to external addresses for security reasons.

employee@company.com -> personal@gmail.com

This may be blocked by admin policy. This is common in Microsoft 365 and other managed business environments.

• Admin outbound forwarding policy
• Mail flow rules
• Security defaults
• Anti-spam outbound policy
• Compliance rules
• Whether forwarding is internal or external
• Whether user-created forwarding rules are allowed

If internal forwarding works but external forwarding fails, policy may be the cause.

Step 25: check security and suspicious forwarding rules

Forwarding rules can be abused by attackers. If email is disappearing or forwarding unexpectedly, check for unauthorized forwarding rules.

• Unknown forwarding destination
• Inbox rules that redirect mail
• Hidden rules
• Delegates you do not recognize
• Filters that archive or delete messages
• Suspicious login activity
• Recently changed recovery details
• Admin audit logs

• Change password if compromise is suspected.
• Enable two-factor authentication.
• Remove suspicious forwarding rules.
• Review mailbox delegates.
• Review admin users.
• Review DNS access.
• Review recent login activity.
• Check recovery email and phone.
• Check mail flow rules.

Do not treat unexpected forwarding as only a DNS issue.

Step 26: test forwarding properly

Use a clean test process.

Test 1: external sender to forwarding address

Send from a mailbox outside your domain.

personal@gmail.com -> hello@example.com

Test 2: different external sender

Send from another provider, such as Outlook.com, to detect sender-specific filtering.

Test 3: check spam and filters

Check inbox, spam, junk, promotions, quarantine, archive, filters, labels, and forwarding provider logs if available.

Test 4: inspect headers

Check whether authentication changed after forwarding:

spf=
dkim=
dmarc=

Test 5: reply test

Confirm the reply goes to the expected recipient, the From address is correct, the customer sees the expected business address, and the reply does not expose a personal mailbox unintentionally.

Common forwarding scenarios

Forwarding troubleshooting checklist

Use this checklist:

• Active nameservers are confirmed.
• DNS is edited at the active DNS host.
• MX records point to the forwarding or mailbox provider.
• Old MX records are removed when ready.
• Forwarding address exists.
• Alias, group, shared mailbox, or route exists.
• Destination address is typed correctly.
• Destination address is verified.
• Catch-all is configured only if intended.
• Destination spam folder is checked.
• Filters and rules are checked.
• Provider dashboard shows forwarding active.
• External forwarding is allowed if forwarding outside organization.
• Bounce messages are reviewed.
• Headers are checked for SPF, DKIM, and DMARC.
• Reply-from behavior is tested.
• No forwarding loop exists.
• Suspicious forwarding rules are checked.

What not to do

• Do not add MX records at the registrar if DNS is managed elsewhere.
• Do not mix MX records from multiple providers casually.
• Do not assume DNS creates forwarding addresses.
• Do not assume forwarding also configures sending.
• Do not forget destination verification.
• Do not rely on catch-all without understanding spam risk.
• Do not ignore spam/junk folders.
• Do not blame SPF/DKIM before checking MX and routes.
• Do not move DMARC to p=reject while forwarding is untested.
• Do not create forwarding loops.
• Do not use personal Gmail forwarding forever for important business addresses.
• Do not leave unknown forwarding rules in a mailbox.
• Do not delete old provider access during migration until forwarding is tested.

Final recommendation

Forwarding problems are usually caused by one of four things:

1. Wrong MX records: mail never reaches the forwarding provider.
2. Missing route or alias: the provider receives mail but does not know where to send it.
3. Unverified destination: forwarding is paused until the destination approves it.
4. Authentication or filtering: forwarding works, but mail lands in spam or fails SPF/DMARC.

Fix forwarding in this order:

Nameservers -> MX -> Forwarding route -> Destination verification -> Mailbox filters -> SPF/DKIM/DMARC -> Reply-from setup

For serious business email, consider whether forwarding is enough. A real mailbox, shared mailbox, or group is often more reliable and easier to manage.

Run an email forwarding DNS check

Use Domain Email Doctor to scan your domain's public email DNS records before changing anything.

A scan can help show whether MX records point to the expected provider, whether old providers are still present, whether SPF, DKIM, and DMARC may affect forwarded mail, and whether the domain's nameservers point somewhere unexpected.

Start with MX and the forwarding route. Then check authentication and spam placement after the message actually reaches the destination.