I can send message from mdaemon web mail, with outlook works

>with outlook works

it might well say it's sent it, but I doubt whether it has been delivered, unless it was sent before the current outage.  You can check in the Mdaemon logs to see the fate of the message sent from Outlook (look in the Mail, SMTP (out) tab).

It's very strange. Two day ago all works OK,  but  I  added  reverse DNS (PTR) in ISP DNS,
so begin the story, I must change the SMTP server in all outlook client, but the web mail doesn' t work.
I verified that with outlook works because the user xxx@libero.it is mine, look width xxx@gmail.com:

 Sat 2009-05-30 23:36:32: Session 1578; child 1; thread 1112
Sat 2009-05-30 23:36:32: Accepting SMTP connection from [127.0.0.1 : 1404]
Sat 2009-05-30 23:36:32: --> 220-xxxxxxx.ws ESMTP MDaemon 7.2.1; Sat, 30 May 2009 23:36:32 +0200
Sat 2009-05-30 23:36:32: --> 220 Tutte le transazioni IP e gli indirizzi sono memorizzati
Sat 2009-05-30 23:36:32: <-- EHLO WorldClient
Sat 2009-05-30 23:36:32: --> 250-xxxxxx.ws Hello WorldClient, pleased to meet you
Sat 2009-05-30 23:36:32: --> 250-ETRN
Sat 2009-05-30 23:36:32: --> 250-AUTH=LOGIN
Sat 2009-05-30 23:36:32: --> 250-AUTH LOGIN CRAM-MD5
Sat 2009-05-30 23:36:32: --> 250-8BITMIME
Sat 2009-05-30 23:36:32: --> 250 SIZE 0
Sat 2009-05-30 23:36:32: <-- AUTH CRAM-MD5
Sat 2009-05-30 23:36:32: --> 334 PE1EQUVNT04tRjIwMDkwNTMwMjMzNi5BQTM2MzI0MjFNRDAwMTJAYWRpbnRlYy53cz4=
Sat 2009-05-30 23:36:32: <-- dGVzdEBhZGludGVjLndzIGVjOTdhZGUzMzBhNmM0MWZiNDM1MDA1ZWRhMzEzNzA0
Sat 2009-05-30 23:36:32: --> 235 Authentication successful
Sat 2009-05-30 23:36:32: Authenticated as test@domain.ws
Sat 2009-05-30 23:36:32: <-- MAIL FROM: <test@domain.ws> SIZE=659
Sat 2009-05-30 23:36:32: --> 250 <test@domain.ws>, Sender ok
Sat 2009-05-30 23:36:32: <-- RCPT TO: <me@gmail.com>
Sat 2009-05-30 23:36:32: --> 250 <me@gmail.com>, Recipient ok
Sat 2009-05-30 23:36:32: <-- DATA
Sat 2009-05-30 23:36:32: Creating temp file (SMTP): c:\mdaemon\temp\md50000000953.tmp
Sat 2009-05-30 23:36:32: --> 354 Enter mail, end with <CRLF>.<CRLF>
Sat 2009-05-30 23:36:32: Message creation successful: c:\mdaemon\inbound\md50001938664.msg
Sat 2009-05-30 23:36:32: --> 250 Ok, message saved <Message-ID: <WorldClient-F200905302336.AA36320004@domain.ws>>
Sat 2009-05-30 23:36:32: <-- QUIT
Sat 2009-05-30 23:36:32: --> 221 See ya in cyberspace
Sat 2009-05-30 23:36:32: SMTP session successful (Bytes in/out: 845/595)
Sat 2009-05-30 23:36:32: ----------

SMTP OUT

Sat 2009-05-30 23:38:15: Session 1586; child 2
Sat 2009-05-30 23:38:15: Parsing Message <c:\mdaemon\remoteq\pd50000399739.msg>
Sat 2009-05-30 23:38:15: From: test@domain.ws
Sat 2009-05-30 23:38:15: To: me@gmail.com
Sat 2009-05-30 23:38:15: Subject: test da webmail
Sat 2009-05-30 23:38:15: Message-ID: <WorldClient-F200905302336.AA36320004@domain.ws>
Sat 2009-05-30 23:38:15: MX-record resolution of [gmail.com] in progress (DNS Server: xx.xx.xx.x)...my domain
Sat 2009-05-30 23:38:15: The name server reports that it is having technical problems
Sat 2009-05-30 23:38:15: Attempting SMTP connection to [gmail.com : 25]
Sat 2009-05-30 23:38:15: A-record resolution of [gmail.com] in progress (DNS Server: xx.xx.xxx.x)...
Sat 2009-05-30 23:38:15: The name server reports that it is having technical problems
Sat 2009-05-30 23:38:15: This message is 1 minutes old; it has 59 minutes left in this queue
Sat 2009-05-30 23:38:15: SMTP session terminated (Bytes in/out: 0/0)
Sat 2009-05-30 23:38:15: ----------


I attach the dnsstuff regarding my primary domain:


INFO MX Record Your 1 MX record is:

10 mail.domain.ws. [TTL=3600] IP=xx.xx.xxx.x [TTL=3600] [IT]
 
PASS Low port test OK. Our local DNS server that uses a low port number can get your MX record. Some DNS servers are behind firewalls that block low port numbers. This does not guarantee that your DNS server does not block low ports (this specific lookup must be cached), but is a good indication that it does not.
PASS Invalid characters OK. All of your MX records appear to use valid hostnames, without any invalid characters.
PASS All MX IPs public OK. All of your MX records appear to use public IPs. If there were any private IPs, they would not be reachable, causing slight mail delays, extra resource usage, and possibly bounced mail.
PASS MX records are not CNAMEs OK. Looking up your MX record did not just return a CNAME. If an MX record query returns a CNAME, extra processing is required, and some mail servers may not be able to handle it.
PASS MX A lookups have no CNAMEs OK. There appear to be no CNAMEs returned for A records lookups from your MX records (CNAMEs are prohibited in MX records, according to RFC974, RFC1034 3.6.2, RFC1912 2.4, and RFC2181 10.3).
PASS MX is host name, not IP OK. All of your MX records are host names (as opposed to IP addresses, which are not allowed in MX records).
INFO Multiple MX records NOTE: You only have 1 MX record. If your primary mail server is down or unreachable, there is a chance that mail may have troubles reaching you. In the past, mailservers would usually re-try E-mail for up to 48 hours. But many now only re-try for a couple of hours. If your primary mailserver is very reliable (or can be fixed quickly if it goes down), having just one mailserver may be acceptable.
PASS Differing MX-A records OK. I did not detect differing IPs for your MX records (this would happen if your DNS servers return different IPs than the DNS servers that are authoritative for the hostname in your MX records).
PASS Duplicate MX records OK. You do not have any duplicate MX records (pointing to the same IP). Although technically valid, duplicate MX records can cause a lot of confusion, and waste resources.
PASS Reverse DNS entries for MX records OK. The IPs of all of your mail server(s) have reverse DNS (PTR) entries. RFC1912 2.1 says you should have a reverse DNS for all your mail servers. It is strongly urged that you have them, as many mailservers will not accept mail from mailservers with no reverse DNS entry. Note that this information is cached, so if you changed it recently, it will not be reflected here (see the www.DNSstuff.com Reverse DNS Tool for the current data). The reverse DNS entries are:

x.x00.xx.xx.in-addr.arpa mail.domain.ws. [TTL=86399]
 
Mail PASS Connect to mail servers OK: I was able to connect to all of your mailservers.
PASS Mail server host name in greeting OK: All of your mailservers have their host name in the greeting:

 mail.domain.ws:<br />    220-domain.ws ESMTP MDaemon 7.2.1; Sat, 30 May 2009 23:27:09 +0200 220 Tutte le transazioni IP e gli indirizzi sono memorizzati <br />
PASS Acceptance of NULL <> sender OK: All of your mailservers accept mail from "<>". You are required (RFC1123 5.2.9) to receive this type of mail (which includes reject/bounce messages and return receipts).
PASS Acceptance of postmaster address OK: All of your mailservers accept mail to postmaster@domain.ws (as required by RFC822 6.3, RFC1123 5.2.7, and RFC2821 4.5.1).
PASS Acceptance of abuse address OK: All of your mailservers accept mail to abuse@domain.ws.
INFO Acceptance of domain literals WARNING: One or more of your mailservers does not accept mail in the domain literal format (user@[0.0.0.0]). Mailservers are technically required RFC1123 5.2.17 to accept mail to domain literals for any of its IP addresses. Not accepting domain literals can make it more difficult to test your mailserver, and can prevent you from receiving E-mail from people reporting problems with your mailserver. However, it is unlikely that any problems will occur if the domain literals are not accepted (mailservers at many common large domains have this problem).

mail.domain.ws 's postmaster@[xx.xx.xxx.x] response:<br /> >>> RCPT TO:<postmaster@[xx.xx.xxx.x]><br /> <<< 550 <postmaster@[xx.xx.xxx.x]>, Recipient unknown <br />  
PASS Open relay test OK: All of your mailservers appear to be closed to relaying. This is not a thorough check, you can get a thorough one here.

mail.domani.ws OK: 550 <Not.abuse.see.www.DNSreport.com.from.IP.xx.xx.xx.xx@DNSreport.com>, Recipient unknown <br />
WARN SPF record Your domain does not have an SPF record. This means that spammers can easily send out E-mail that looks like it came from your domain, which can make your domain look bad (if the recipient thinks you really sent it), and can cost you money (when people complain to you, rather than the spammer). You may want to add an SPF record ASAP, as 01 Oct 2004 was the target date for domains to have SPF records in place (Hotmail, for example, started checking SPF records on 01 Oct 2004).  
DNS CONFIGURATION:
direct
                                    Type                             Data
                                     Host(A)                        xx.xx.xxx.x
                                     Mail Exchanger(MX)    mail.domain.ws
                                    (SOA)                          mail.domain.ws
                                    Name Server (NS)       mail.domain.ws
mail                              Host(A)                       xx.xx.xxx.x
www                          Host(A)                       xx.xx.xxx.x

Thanks in advance

I have a feeling the changes made to your domain are a red herring because if I were to send to xxx@libero.it from any of my accounts, according to the DNSReport for libero.it, an extract of which I previously posted, it would not get through.

How does mail normally find its way from xxx@libero.it  to your gmail account?  Have you set up some kind of divert in mdaemon if SMTP fails?  Or any other Content Filter?

I have found a solution!
i have changed DNS in MDaemon DNS
Thanks
Closed

That change you made was a coincidence.

The DNSReport I did over the weekend said that libero.it was having technical problems.  Doing it today, I get a report showing that it is up and working again.  If you go back to the old DNS settings they should work... unless there was something else wrong with those settings.