Could not deliver the message in the time limit specified.  Please retry or contact your administrator.

Hi Everyone,
Thank you very much ahead for your patience to read this long question!

We are getting some of the external email bounced back recently and they are legitimate email address. Error1:  Could not deliver the message in the time limit specified.  Please retry or contact your administrator.   <CCGEmail.ccgroup.org #4.4.7>.

 Error2:  You do not have permission to send to this recipient.  For assistance, contact your system administrator. <CCGEmail.ccgroup.org #5.7.1 smtp;550 5.7.1 Concordialc@concordiatx.org>... H:MXB [216.62.217.146] Connection refused due to abuse. Please contact your E-mail provider.>   

We can be able to receive any external email by the way.

We are using Outlook 2003, Exchange 2003 Enterprise running under the Windows 2003 Standard.

Today I ran the report from DNSstuff.com and here is WARN and FAIL:

DNSreport for ccgroup.org (ccgroup.org is our domain name)

WARN      Glue at parent nameservers      WARNING. The parent servers (I checked with b0.org.afilias-nst.org.) are not providing glue for all your nameservers. This means that they are supplying the NS records (host.example.com), but not supplying the A records (192.0.2.53), which can cause slightly slower connections, and may cause incompatibilities with some non-RFC-compliant programs. This is perfectly acceptable behavior per the RFCs. This will usually occur if your DNS servers are not in the same TLD as your domain (for example, a DNS server of "ns1.example.org" for the domain "example.com"). In this case, you can speed up the connections slightly by having NS records that are in the same TLD as your domain
WARN      Nameservers on separate class C's      WARNING: We cannot test to see if your nameservers are all on the same Class C (technically, /24) range, because the root servers are not sending glue. We plan to add such a test later, but today you will have to manually check to make sure that they are on separate Class C ranges. Your nameservers should be at geographically dispersed locations. You should not have all of your nameservers at the same location. RFC2182 3.1 goes into more detail about secondary nameserver location.

WARN      TCP Allowed      WARNING: One or more of your DNS servers does not accept TCP connections. Although rarely used, TCP connections are occasionally used instead of UDP connections. When firewalls block the TCP DNS connections, it can cause hard-to-diagnose problems. The problem servers are: 69.46.233.245: Error [Connection refused (10061)]. 69.46.234.245: Error [Connection refused (10061)].
FAIL      MX is host name, not IP      ERROR: You have one or more MX record(s) that contain an IP address. This is not valid. A fully RFC-compliant mailserver will not be able to send you mail (although some mail servers will, due to the TCP/IP functions that they use). The problem MX records are:
216.62.217.146.
FAIL      Reverse DNS entries for MX records      ERROR: None of your mail server(s) seem to have reverse DNS (PTR) entries (I didn't get any responses for them). 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. You can double-check using the 'Reverse DNS Lookup' tool at the DNSstuff site (it contacts your servers in real time; the reverse DNS lookups in the DNS report use our local caching DNS server).
Connect to mail servers ERROR: I could not complete a connection to any of your mailservers!
216.62.217.146: Could not connect without glue or A record.<br />
If this is a timeout problem, note that the DNSreport only waits about 40 seconds for responses, so your mail *may* work fine in this case but you will need to use testing tools specifically designed for such situations to be certain

Reverse DNS for 216.62.217.146 (our domain external ip)
Location: United States [City: Dallas, Texas]
Preparation:
The  reverse DNS entry for an IP is found by reversing the IP, adding it to "in-addr.arpa", and looking up the PTR record.
So, the reverse DNS entry for 216.62.217.146 is found by looking up the PTR record for
 146.217.62.216.in-addr.arpa.
All DNS requests start by asking the root servers, and they let us know what to do next.
See How Reverse DNS Lookups Work for more information.
How I am searching:
Asking b.root-servers.net for 146.217.62.216.in-addr.arpa PTR record:  
       b.root-servers.net says to go to dill.arin.net. (zone: 216.in-addr.arpa.)
Asking dill.arin.net. for 146.217.62.216.in-addr.arpa PTR record:  
       dill.arin.net [192.35.51.32] says to go to ns3.sbcglobal.net. (zone: 62.216.in-addr.arpa.)
Asking ns3.sbcglobal.net. for 146.217.62.216.in-addr.arpa PTR record:  Reports ccgroup.org. [from 65.68.49.6]

Answer:
216.62.217.146 PTR record: ccgroup.org. [TTL 300s] [A=216.62.217.146]

Any idea? Please Help! Thank you!
Shawyen Mei