The old inbox is changing, but messages sent to your existing aliases still need to arrive.
Before switching: add and verify the new forwarding destination, then test the route; disable the old destination only after the new one works. This week, record the current settings and identify any account that still depends on the old inbox.
This guide is for people changing their main inbox while keeping established aliases, and for freelancers who receive client or project messages through aliases. It also helps anyone who wants to distinguish a forwarding change from updating contact details on websites.
The email alias forwarding address change affects one layer
An alias setup can involve three separate addresses or settings:
- The alias: the address other people use when they send you mail.
- The forwarding destination: the inbox that receives messages addressed to the alias.
- The contact email on an external account: the address a website stores for notices, sign-in, or recovery.
Changing the forwarding destination changes where future messages sent to the alias are delivered, if the service supports that change. It does not rename the alias, move old mail from one inbox to another, or rewrite contact details stored by websites. Treat these as separate jobs.
That distinction matters when a service sends a password reset or a billing notice. The message may still be addressed to your alias, while the website continues to display an outdated contact email in its account settings. Conversely, updating a website’s contact address does not necessarily change any forwarding rule attached to your alias.
If the goal is simply to keep the same public-facing address while replacing the inbox behind it, focus on the forwarding route. Don’t begin by changing every website account or creating a replacement alias. For a broader overview of address structures, see the NixMX alias zones guide.
Before the change, map the mail that still matters
A successful handoff starts with knowing what uses the current route. Make a short list of senders and purposes rather than trying to reconstruct the whole inbox during the switch.
Group the list by what arrives at the alias:
- Long-term account messages: sign-in alerts, recovery messages, receipts, or service notices that may be needed later.
- Subscriptions and routine notifications: newsletters, product updates, and recurring reports.
- People and active work: clients, collaborators, suppliers, and project contacts.
- Low-priority or temporary messages: one-off registrations and services that no longer need a dependable route.
Mark which items still need to reach a mailbox you can access over the long term. An old destination may be doing more than collecting newsletters: it could be the only place receiving an account recovery message or an important client reply.
For each important account, check the contact address shown in that account’s own settings. A forwarding change is not a substitute for that review. If the account is important enough that losing access would cause a serious problem, keep a directly accessible, durable email address on file and confirm the recovery method separately.
Don’t treat old mail as part of this operation. The change concerns future delivery through the alias. If historical messages need to be retained, handle that as a separate mailbox backup or migration task.
Prepare the new destination before editing the route
First, sign in to the new inbox and confirm that it can receive an ordinary message. Check that you control the account and expect to keep access to it. A destination that works today but is temporary, shared, or about to be closed is a poor long-term target for established aliases.
Next, read the current instructions for the service that manages the forwarding route. Do not assume that two services use the same workflow. The Gmail automatic-forwarding instructions describe adding a forwarding address and verifying it before forwarding can be used. That is a service-specific requirement, not proof that every alias or forwarding service supports parallel destinations.
The Outlook.com automatic-forwarding guidance documents settings for that account’s automatic-forwarding feature. It does not establish how another provider handles aliases, verification, simultaneous destinations, or old-route shutdown. Check the instructions that match the service and account involved.
Some mail systems also distinguish forwarding from redirecting. The Microsoft mail rules guidance describes forwarding and redirecting as rule actions. Those terms can affect how a message appears to its recipient, so use the option that matches the service’s instructions and your needs. Don’t transfer a rule recipe from a different service without confirming that the same options exist.
Before making an edit, save the current destination and any rule conditions. Note where to find the setting again and how to restore the previous value. This is a practical rollback record, not a guarantee that the service can restore a deleted route.
Add and verify the new destination while the old one remains
If the forwarding service supports adding a new destination without removing the old one, do that first. Complete any confirmation it requires from the new inbox. A destination that appears in a settings screen but has not completed the service’s verification process may not be ready to receive forwarded mail.
If the service does not support parallel forwarding, don’t improvise by deleting the old destination and hoping the new one works. Record the old configuration, verify that you can access the new inbox, and identify the exact steps needed to restore the old route. Choose a low-risk time for the change, then test promptly after saving it.
The sequence is deliberately conservative:
- Add the new destination, if the service permits it.
- Complete the service’s verification step.
- Keep the old destination active while testing, where possible.
- If parallel delivery is unavailable, prepare the rollback route before making the switch.
- Avoid changing the alias itself unless the alias address also needs to change.
A verification email sent by the forwarding service only confirms the step described by that service. It does not prove that every message addressed to the alias will pass through every filter or arrive in the new inbox. Use a separate test sent through the actual alias route.
Test delivery, then review external accounts
Send a plain test message from an external mailbox you control to the alias. Use a subject line you can recognize. Check the new inbox, then look in spam, archive, and filtered folders if the message is not in the main view.
Confirm that the test reached the expected destination and that the message is the one you sent. If you can still receive through the old route, check that too. A test demonstrates that this particular message followed the expected path at that time. It does not establish universal delivery for every sender, message type, attachment, or filtering rule.
After the route test, compare the mail-use list against the inboxes that now receive messages. For website accounts that still use the old inbox as their stored contact address, decide separately whether to update that address. The Google Account email management guidance concerns email settings within that account. It should not be read as a mechanism for updating contact details held by unrelated websites.
Questions about changing the forwarding route
I changed my main inbox. How do I redirect messages from my existing alias?
Keep the alias unchanged and update only the destination that receives its messages. First sign in to the new inbox and make sure it can receive mail. Add and verify it in the forwarding service if supported, then send a test message through the alias. Keep the previous destination until the route test and account review are complete.
How can I tell whether the new inbox is receiving forwarded mail?
Send a message from an external account you control to the alias. Check the new inbox, including spam, archive, and filtered folders. Confirm that the message is your test and that it arrived through the expected route. This confirms that specific test, not that every sender, attachment, or message type will be delivered in the same way.
Should I leave the old forwarding destination active during the change?
Keep it active if the service permits parallel destinations. The old route gives you a way back while you check the new one and review important senders. If parallel forwarding is unavailable, write down the old settings and confirm how to restore them before switching. Do not remove the old destination until you know the recovery steps.
Will changing an alias destination also update my website contact addresses?
No. The forwarding destination controls where mail sent to the alias is routed. A website’s contact email is a separate record managed in that website account. Review accounts that need long-term access or recovery messages, update their details individually when needed, and verify those recovery routes rather than assuming the forwarding change updated them.
Complete the switch only after the route passes its checks
Once the new route has passed the test, use the list from the preparation stage to confirm that important senders still have a usable path. Check whether any client or project contact needs the alias to remain active, and whether any account still relies on the old inbox for recovery.
If the service supports parallel delivery, you can decide when to remove the old destination after this review. If it supports only one destination, make the change only after confirming the new inbox is ready and that the old setting can be restored if the test fails. Keep a brief note of the completed change and the date, so the next review starts with a known configuration.
Use this checklist before closing the old route:
- [ ] The new inbox is accessible, and it can receive ordinary mail.
- [ ] The forwarding service’s verification step is complete, if required.
- [ ] A test sent from an external mailbox to the alias arrived at the intended destination.
- [ ] Spam, archive, and filter folders have been checked if the test was not visible.
- [ ] The previous destination and restoration steps were recorded before the change.
- [ ] Important senders and active client or project messages have been reviewed.
- [ ] Any website that needs a different contact email has been updated separately.
- [ ] The old destination no longer handles a necessary recovery or notification path.
If a check fails, keep or restore the old route where possible. Recheck the destination spelling, verification status, and the service’s current settings before repeating the test. If the test succeeds but a particular sender’s message does not arrive, investigate that sender and route separately; one successful test does not rule out a sender-specific issue.
Choose the right address for the next use
A permanent alias with a changeable forwarding destination suits messages that should remain reachable over time, such as ongoing subscriptions or client correspondence. It also gives the owner a way to change the receiving inbox without necessarily changing the address known to senders, provided the service supports that arrangement.
A temporary address is a different choice. It can be appropriate for a low-risk, short-lived registration or a one-time confirmation when the sender does not need to reach the user again. It is not a sound replacement for a durable address on a financial, government, or other important account, or for any service that may need long-term recovery or replies.
A main inbox or a managed alias is the safer destination when continuity matters. For a short-lived signup, a temporary mailbox may keep the main address separate, but check the current NixMX service page to confirm that its available features fit the specific use before relying on it. Keep important accounts on an address that remains under direct, long-term control.
The handoff is complete when the new destination is verified, the alias route passes a real test, and any website contact changes have been handled separately. Until then, preserving a rollback path is more valuable than removing the old destination quickly.
Frequently asked questions
I changed my main inbox. How do I redirect messages from my existing alias?
Keep the alias itself unchanged and update only the destination that receives its messages. First make sure you can sign in to the new inbox and receive mail there. Add and verify it in the forwarding service if that option is available, then send a test message through the alias. Keep the previous destination until the test and your account review are complete.
How can I tell whether the new inbox is receiving forwarded mail?
Send a message from an external account you control to the alias, then check the new inbox, including spam, archive, and filtered folders. Confirm that the received message is the test you sent and that it arrived through the expected route. This verifies that specific test, not every sender, attachment, or message type.
Should I leave the old forwarding destination active during the change?
Yes, if the service permits parallel destinations. Keeping the old route gives you a recovery path while you test the new one and review important senders. If parallel forwarding is unavailable, record the old settings first, confirm how to restore them, and choose a low-risk time to switch. Do not disable the old destination before you know how to roll back.
Will changing an alias destination also update my website contact addresses?
No assumption is safe. The forwarding destination controls where messages sent to the alias go; a website account's contact email is a separate record maintained by that service. Review the accounts that still need long-term access or recovery messages, and update their contact details individually when necessary. Test each important account's recovery route rather than relying on the forwarding change.