Forwarding email to two different IP's using the same domain name.
Ideas needed for MX records sharing. A company used emailA.com for years and is splitting up. Now companyA needs to forward email from companyA.com to both new companies that comprise of now companyB and companyC. Is there a way to split the DNS management of the MX records on the hosting site so email is forwarded from companyA hosting (the MX records) to companyB and companyC. Both new companies do not trust the other with their email server managing the other and being responsible for forwarding to the other.
If I need to provide more information let me know.
If I need to provide more information let me know.
You need to configure some MTA for CompanyA that forwards all mail to two addresses..
(You will need some active server for this).
(You will need some active server for this).
noci I don't know if you understood the question or maybe I didn't explain myself well. Neither company wants to manage the others email accounts in their email server so configuring MTA is not an option.
Is there a way to have two MX records? The point is this happens before the exchange server receives email and would eliminate both parties worrying about managing the others email because it would never show up in their email server.
Is there a way to have two MX records? The point is this happens before the exchange server receives email and would eliminate both parties worrying about managing the others email because it would never show up in their email server.
So companyA.com will no longer exist but how are you going to differentiate companyb.com's users and companyC.com users?
companyA.com in the interim can forward to companyB and CompanyC all email or create a rule that returns all messages with a message to use another email address
So both new companies will have to set up their own DNS and email solution
Trying to be clear here. Email sent to Fred@CompanyA.com used to get delivered properly. Now you want it forwarded to Fred@CompanyB.com and to Fred@CompanyB.com? I don't think that can be done without an email server doing the forwarding.
You can set up more than one MX record, one pointing to CompanyB.com's email server and the other pointing to CompanyC.com's email server, but the sending email server will use just one MX record and ignore the other.
I think you'll have to get some agreement between them for the management of an email server that hosts @CompanyA.com addresses (and forwards them appropriately) for as long as it takes people to start using the new addresses.
You can set up more than one MX record, one pointing to CompanyB.com's email server and the other pointing to CompanyC.com's email server, but the sending email server will use just one MX record and ignore the other.
I think you'll have to get some agreement between them for the management of an email server that hosts @CompanyA.com addresses (and forwards them appropriately) for as long as it takes people to start using the new addresses.
David I agree something like this is ultimately the best option if they can't agree to get along. Hoping to find a solution to this prior to the split going happening that makes both parties satisfied.
ComproProSolv, thanks for the response and I agree. I think I'm shooting in the dark hoping for a small chance to make everyone happy.
What I'm really after is this and I know it's a long shot but better to ask.
One MX record directs email from user1 - user5@companyA forwards to user1 - user5@companyb.com. A second MX record directs emails from user 6 - user10@companyA.com to users6 - 10@companyB.com.
Complicated and highly unlikely but felt it's better to research to do my due diligence.
What I'm really after is this and I know it's a long shot but better to ask.
One MX record directs email from user1 - user5@companyA forwards to user1 - user5@companyb.com. A second MX record directs emails from user 6 - user10@companyA.com to users6 - 10@companyB.com.
Complicated and highly unlikely but felt it's better to research to do my due diligence.
a mx record can only point to one address
you can have multiple mx records if you have redundant smarthosts
if you have
mx companya.com companyb.com and
your results will be unpredictable it might round robin 1/2 going to each mx record.
companyb.com accepted domains companya.com companyb.com
companyc.com accepted domains companya.com companyc.com
this will cause a lot of user doesn't exist ndr's when someone is at companyc.com has mail delivered to companyb.com
Then you HAVE to configure MX records to both their mail servers and on both servers need to configure forward to the general companya.com to both their new companyb and companyc addresses.
All addresses that are not common anymore (like fred went to company B then fred@companya.com would end up to non-existing user fred@companyc.com)...
A far more granular forward is needed. So you will need to configure some way to handle the non existing address at their respective companies. Best solution is: ONE MTA in front with specific forwards for all addresses... and info@companya.com -> info@companyb.com & info@companyc.com. fred went to companyb... frd@companya.com -> fred@companyb.com wendy went to companyc => wendy@companya.com -> wendy@companyc.com.
Alternatively keep all addresses at BOTH companies and handle the fall out from cross managing addresses.
This is a technical issue... no political way around it.
All addresses that are not common anymore (like fred went to company B then fred@companya.com would end up to non-existing user fred@companyc.com)...
A far more granular forward is needed. So you will need to configure some way to handle the non existing address at their respective companies. Best solution is: ONE MTA in front with specific forwards for all addresses... and info@companya.com -> info@companyb.com & info@companyc.com. fred went to companyb... frd@companya.com -> fred@companyb.com wendy went to companyc => wendy@companya.com -> wendy@companyc.com.
Alternatively keep all addresses at BOTH companies and handle the fall out from cross managing addresses.
This is a technical issue... no political way around it.
Exim has support for this more or less: (shadow transport).
See also: https://www.exim.org/exim-html-current/doc/html/spec_html/ch-generic_options_for_transports.html
( the mail is only stored, no errors etc should ever be returned from them. If both organisation happen to use exim this is fairly easy to resolve.)
shadow_transport = local_copy_incoming
shadow_condition = ${if eq {$domain}{domain.com}{yes}{no}}
See also: https://www.exim.org/exim-html-current/doc/html/spec_html/ch-generic_options_for_transports.html
( the mail is only stored, no errors etc should ever be returned from them. If both organisation happen to use exim this is fairly easy to resolve.)
"One MX record directs email from user1 - user5@companyA forwards to user1 - user5@companyb.com. A second MX record directs emails from user 6 - user10@companyA.com to users6 - 10@companyB.com."
No. An MX record is simply DNS entry as I'm sure you know. Which means *server* name to IP addr. There is no scope for adding usernames.
You'll need a mail server to look into the actual mail to read the bit before the @ to determine the actual user and then make a routing decision as to which company to forward the mail onto. *Possibly* you could have a mail server forward all mail to both companies and ensure that user1-5 do not exist on companyc.com and user6-10 don't exist on companyb.com - therefore 'half' the mail is undeliverable is each case....ugly though
No. An MX record is simply DNS entry as I'm sure you know. Which means *server* name to IP addr. There is no scope for adding usernames.
You'll need a mail server to look into the actual mail to read the bit before the @ to determine the actual user and then make a routing decision as to which company to forward the mail onto. *Possibly* you could have a mail server forward all mail to both companies and ensure that user1-5 do not exist on companyc.com and user6-10 don't exist on companyb.com - therefore 'half' the mail is undeliverable is each case....ugly though
Premium Content
You need an Expert Office subscription to comment.Start Free Trial