Email does not work

I'm sorry if it's obvious, but in order to receive the email from outside i-MSCP your sender should be able to resolve your new MX record.

If you are gonna to do just some tests and the sender pc is on your local network you can simply edit your LAN dns to match the values from imscp.
If you are trying to send email from a public email provider (such as Gmail) this is a little more complex, because you have to match the mx record on public DNSs (if the domain you used truly exists).

Try this, from the sender computer

1. type "nslookup" from a CMD (assuming che client is windows), or from shell (if it's unix like)
2. type "set q=mx" from che nslookup prompt
3. type the domain name you are using for test

If the result do not match the imscp dns entry, here is you problem.

Quote from marceloeng

The configuration used is:
domain.tld MX 10 mx10.domain.tld

You need an additional DNS Entry:

mx10.domain.tld IN A *Your Server IP*

Your domain is mydomain.com.br?
I don't think your public MX record is mx10.domain.tld, because "domain.ltd" do not exists.

Let's see what mxtoolbox says about your domain.

http://mxtoolbox.com/SuperTool…tion=mx%3amydomain.com.br

10 mx01.ctitech.com.br 200.220.150.82
10 zorak.ctitech.com.br 200.220.150.80

Is it correct?
Having two mx records with pref 10 means that both of them can be reached alternatively.
Maybe it's just a personal opinion, but I usually configure my first mx with pref 10 and the failover mx with an higher pref, let's say 30.
My first mx is configured on my best line. The second one on my failover line.

Now, let's see if they're ok.

mx01.ctitech.com.br SMTP check

OK - 200.220.150.82 resolves to mx01.ntsnet.com.br
OK - Reverse DNS matches SMTP Banner
Warning - Does not support TLS. (do not bother about this now)
0 seconds - Good on Connection time
OK - Not an open relay.
3.822 seconds - Good on Transaction Time

Blacklist check is fine too.

zorak.ctitech.com.br SMTP check

OK - 200.220.150.80 resolves to zorak.ntsnet.c
OK - Reverse DNS matches SMTP Banner
Warning - Does not support TLS. (do not bother about this now)
0 seconds - Good on Connection time
OK - Not an open relay.
3.136 seconds - Good on Transaction Time

Blacklist check is fine too.

So far everything seems fine.

Let's talk about your possibile port forwarding/nat/whatever configuration from the public IPs to your internal network.

mx01.ctitech.com.br 200.220.150.82
zorak.ctitech.com.br 200.220.150.80

One or both of theese IP does redirect port 25 (SMTP) to your i-MSCP?

My opition is that you have another mail server for your domain mydomain.com.br.
You want to try i-mscp as a possibile alternative, but you can't mess around with the current configuration. So you create with i-mscp a fake domain for tests. Is that correct?

If this is your case I think you have 2 options:
- Just test imscp locally, with a fake domain or configuring a new one with the same name of your true domain. Remember that you can send email from it (froum Roundcube), but replyes to that emails will follow the public configuration and will be received from your true mail server.
- Try to create a public subdomain with a new mx record. You just need another public ip address to forward the smtp connection to imscp.

mx10.drthiagoduarte.com.br 201.33.19.223

comdesk.virtuaserver.com.br shoud be the server that it' resonding to the smtp connection.
Are you sure that's imscp?

Quote

If I send messages from email ([email protected]) to a external mail (like gmail), the message appears:

Are you sendig from [email protected] (imscp domain I guess) to [email protected] and comdesk.com.br is hosted by gmail?
I just tried via telnet a simulation with theese data and everything seems fine.
Did you create on i-mscp the comdesk.com.br domain too? It seems that the replyng server do not know the user [email protected]

Quote

if I send messages from a external email, the message is returned:

Hard to guess with this data. It could be a postfix configuration problem, but I'm not so expert about it.
My advice is to concentrate on problems one by one.

1. Do you send to another (if exists) mail server in your locale network?
2. Do you receive from another (if exists) mail server in your locale network?

That is easier to test and debug and involves your local dns configuratin.
If 1-2 are ok

3. Do you send to another mail server on internet? Try something you don't use internally, maybe a private email address.
4. Do you receive from another mail server from internet? Same advice about a private email.