451 4.4.0 primary target IP address responded with 421 4.4.2 connection dropped


  • Hi all,


    Recently i setup an Exchange 2007 server.

    Everything is working fine. Only sometimes when one of the users send an email outside of the organisation, the message will be in the queue for a long time.


    The error message i get is: "451 4.4.0 primary target IP address responded with:  "421 4.4.2 connection dropped".

    After a while (sometimes 1 hour, sometimes more then 1 day) the message will be sent.


    Does anyone know why this is happening? Most of the time it is happening when sending mail to a certain domain.


    Some tips or hints will be very appreciated!


    Kind regards,


    Tom van Hoof

    Friday, July 13, 2007 9:39 AM


All replies

  • Hi,


    Have you checked this domain. Do they have more than one MX record and the primary one does not respond?


    Can you telnet to the primary server on port 25?




    Saturday, July 14, 2007 6:39 PM
  • HI ,


    I have been facing the same issue, My org is still on the co-existence stage, where im having exchange 2003 and exchange 2007 main servers at my Headquaters. i have added a new exchange 2007 server at my branch office. The server holds the Hub transport and Mailbox role. But im not able to send and receive the email and when i check the mail Q its there with this error "451 4.4.0 primary target IP address responded with 421 4.4.2 connection dropped".


    And my MX record are set to automatic. Port 25 telnet is ok from my branch office exchange server to both Exchange 2003 and 2007. Please advice ASAP.


    Thank you.






    Tuesday, July 17, 2007 1:07 AM
  • Is the receiving server using RBL's or Greylisting


    Tuesday, July 17, 2007 7:28 AM

    We are having a NIGHTMARE of a time with a brand new 2007 install. Our server was hijacked a few days ago, which then got us listed on a few blacklists, apparently. We have a queue FULL of messages that have been stuck for more than 2 days now. The majority now have the 421 4.4.2 Connection dropped error. WT to do?? I got us removed from 1 of 3 lists right away and am waiting from one more. The third is not supposedly used by anyone.


    This has brought our business to a near halt. The users are furious that their outgoing mail (incoming is fine) isn't going out for hours or even days. And there's no way for us to force send these stuck messages.


    We were on the phone with MS Support last night for over 6 hours with no solution. And additional session this morning lasted only 30 minutes, as the tech pointed me to the blacklists. However, we don't know what else to do.

    Friday, August 17, 2007 5:03 PM
  • How about changing NAT rule i your firewall to use another IP when Exchange sends mail to Internet.

    Hopefully the new IP is is not member on any RBL lists and should therefore work.


    Friday, August 17, 2007 7:29 PM
  • We're having the same problem but only sending to 1 remote domain. We also have no clue as to why this is happening. It's a really strange case.

    • Proposed as answer by Fui Fan Friday, August 21, 2009 4:16 AM
    • Unproposed as answer by Mike CrowleyMVP Tuesday, March 22, 2011 3:20 AM
    Wednesday, August 22, 2007 1:05 PM
  • The remote server could be using RBL's or Greylisting.

    Exchange 2003 have an issie with remote servers that dont play nice.

    There is thing that often work in this scenario, setting the Glitch Retry Interval between 60 and 120 seconds.


    Wednesday, August 22, 2007 9:34 PM
  • I couldn't find our servers in any RBL's. We have tryied sending emails from multiple SMTP (Hub Transport Servers) in seperate sites with use differnent public IP's but same result. I can send email to the destination using telnet 25 but no other way. The queue just gives the error in this forum subject. Connection logs don't provide much detail either except for the same type of error.

    Monday, August 27, 2007 6:15 PM

    We are having the same issue.  We were thinking that it's due to the configuration of the PTR record but since the change of pointing them to our new Exchange server the messages are still in the Queues - and GROWING.  We could really use a better explantion on this... hopefully before I am out of work!
    Tuesday, September 04, 2007 10:04 PM
  • Check your application log for certificate errors. It probably says the default domain cert has expired, even though it looks valid. Use cert snap-in to remove it, generate a new one and enable it for smtp.


    Wednesday, September 05, 2007 2:06 PM
  • Has someone found a solution for this? I have exactly the same problem. Majority of the emails just stucked in the queue for a long time with error message "451 4.4.0 primary target IP address responded with 421 4.4.2 connection dropped". But some of the emails like gmail or yahoo are just touch & go from the queue.


    I read from other forum that they have the same problem but it was resolved by disabling the TCP offload engine of the NIC. Does anyone knows how to disable TCP offload engine?



    Tuesday, October 16, 2007 1:55 AM

    Can anyone experiencing this problem respond back with what outbound (SMTPSend) protocol logs are reporting? Is this hanging up on Mail from / RCPT TO / connect? Sometimes a good textual reason is given before a remote server hangs up.
    Wednesday, October 17, 2007 10:45 PM

    A couple of questions....


    1. Do you have an Edge server?

    2. If not, did you installed the anti-spam feautures in your hub server?

    3. If you did did you enabled the "Block messages sent to recipients not listed in the GAL" ?


    Did you test your enviroment to make sure you are not relaying?



    Friday, October 19, 2007 7:22 PM

    The above was for DevCom666
    Friday, October 19, 2007 7:33 PM
  • I'm having the same problem others have mentioned.  Most of my problems are with emails that contain attachments(damn engineers!).  Still, our DSL line for outgoing mail is dedicated and shouldn't be a problem.

    I've turned off the TCP Offlload engine on the HP ML350 G5 server, but no improvement. 

    Anyone else have ideas on this issue?
    Saturday, November 03, 2007 11:46 PM
  • Guys! Seriously, there is a major problem with EXCH... We have two hub Transport servers that exist in the *same* domain but both reside in two differnt sites. Since Exchange 2007 now uses Sites and Services to route mail, our site connectors are setup properly allocating networks to the proper site. We have *NO FIREWALL* for this test, *NO Compression Device*, *NO Software Based Firewall*. This is a straight up 10Mbit ENLAN circuit with 3 users ( so far ) peaking at 1.76Mbit one day so *NO Satuation* and still when sending mail to a users mailbox that resides in site B which Hub Transport and Client Access server exist, my queue in site A says:

    Delivery Type:
    "SMTP Relay to Remote Active Directory Site"

    Last Error:
    "451 4.4.0 Primary target IP address responded with: "421 4.4.2 Connection dropped." Attempted failover to alternate host, but that did not succed. Either there are no alternate hosts, or delivery failed to all alternate hosts."

    I can connect to site B Hub Transport TCP 25 and manually send a test message to a user mailbox existing in that site no problem. Ahhhhhh, this is driving me mad --- It's either something *really* stupid, OR a huge bug...

    We are running Roll-Up pack 5 on all Exchange 2007 servers. Windows 2003 x64 RC2 all patched latest and greatest.

    Thanks for any help here ---
    Saturday, November 17, 2007 5:12 AM

    My issue appears to be resolved now.  In addition to turning off the TCP Offload engine on the Broadcom gig NIC, I had to turn off all other advanced features using the HP NIC config utility.  Since doing that, the queue looks better.  Additionally, a co-worker discussed Exchange 2007 with MS Business Critical and they mention to uninstall the previous roll-up pack prior to installing the latest version.  Not sure why, but hey, that's what they said.  Also, SP1 is supposedly set for an end of November release from what we heard.  I sure hope so.


    On my Firewall(Watchguard X700 running Fireware Pro), I found that the firewall was disabling the external interface because it detected a 'gateway probe' on the interface.  Well, turns out the gateway probe was generated BY THE DAMN FIREWALL!  It checks the gateway via a ping test to see if it is available, and if not, it uses the failover connection.  My work-around until I get Watchguard on the line is to increase the amount of time it takes before it disables the interface.  The default was 15 seconds - I increased this to 1200 seconds.  What was happening was the SMTP transmission would begin, and then the interface would get disabled and that's where I'd get the '4.2.2 Connection Dropped' issue.  You might try putting in a different NIC if you have one and turn off all advanced TCP stuff.

    Saturday, November 17, 2007 5:55 PM
  • Figured it out... This is kinda crazy. It actually had to do with SSL certificates for the SMTP service, and “adding” Client Access as an additional role on site B. Also, we have an internal root Certificate Authority which was dishing out certs upon sysem requests automatically. By issueing the following EXCH-PowerShell CMD: Get-ExchangeCertificate displayed two certs for which one was given by the root CA, and the second was self generated/signed by the Exchange server itself... There wasn't one article out there yet that had our situation but reading multiple posts and TechNET articles led to try the following:
    0.  Disabled our internal root CA to set any certificate requests to a pending state so any automated request of a cert was not automatically handed out. At this point, any automatic or manuel requests sit in a Pending Requests area and someone has to go in and manuelly decide who/what gets a certificate. By doing this would stop the certificate hand out I list below. I wanted Exchange to create the cert as I'm sure most places don't have a central root CA and with Exchange 2007 being so new and a little hokey at times, I wanted to keep everything native to Exchange 2007 server roles as possible.
    1.  Launch MMC and add the Certificates Snap in
    2.  Choose "Computer Account" as the certificate object to load from
    3.  Expand the Personel tree-view on the left and in the right pane deleted both certificate
            A. I had to do this on both Hub Transport servers in Site A and Site B
    4.  Request certifiactes from the local Hub Transport server itself for the SMTP Service by issuing the following command from the Exchange PowerShell CMD
            new-exchangecertificate -services SMTP
            If you are using OWA and HTTPS:
            new-exchangecertificate -services IIS
            get-exchangecertificate  if you want to see the two new certs and associated thumbprint
    There was another step of "setting/enabling" these certificates but I had only done that on one HT and didn't on the other so my guess is once you request a new cert, it's dymanically associated to the service.

    Once I did that on both HT servers, my queues flushed to and from and mail reached their destinations. Good times, great oldies I say!

    The bottom line:
    Our HT server in site B was later added to have Client Access role, by doing this "expired" the certificate that our root CA handed out. I don't think it matters what CA hands out a certificate as long as the thumbprint matches but in this case, just to keep it simple, I used Exchange native new-exchangecertificate to request instead of getting from our root CA. ( look at step 0 above ) Did this for for IIS and SMTP services. Automatically, my queues destined to each site flushed out and mail was delievered.

    Saturday, November 17, 2007 7:44 PM
  • I got this error when I forgot to create the Send Connector.

    Go to Organization Configuration

    then Hub Transport

    Click on the Send Connectors tab

    Create a new Send Connector with internal as the type.




    Wednesday, January 02, 2008 9:37 PM
  • 421 4.4.2 Connection dropped error Exchange 2007


    I had the same error but it was down to an RBL entry.. problem in Exchange 2007 doesn't tell you that!


    My advice if you are till having problems is to have a "conversation" with the SMTP server that you are experiencing difficulties with using good old command prompt:


    See on how to do this.


    I found this response:


    554 Service unavailable; Client host [] blocked
    using Barracuda Reputation;


    Hope that helps someone ;-)

    Monday, November 24, 2008 11:56 PM
  • In my case the problem was with the configuration that I had and the default behavior of Exchange 2007.


    Organization Configuration -> Hub Transport -> Send Connector tab you have one or more send connectors configured to use a FQDN that is not the name of your Exchange server AND you have not installed a certificate for this FQDN; then you will get this error when the Exchange server encounters an SMTP server that is willing to accept TLS connections. This is because your Exchange server is unable to provide a valid certiifcate and hence the connection is dropped.


    To resolve this problem you can do one of the following:

    1. Add a certiifcate for the FQDN that you specified OR

    2. Using the Exchange Powershell run the following command: Set-SendConnector -Identity "<The name of your send connector>" -IgnoreSTARTTLSEmbarrassedtrue


    Hope this helps others


    • Proposed as answer by Petr Kasl Wednesday, February 29, 2012 12:06 PM
    Sunday, November 30, 2008 11:44 PM
  • Hi guys,

    I solved the problem last week, actually its nothing related to certificates, DR site hub server time is not same as primary site hub server due time sychronization issue. when this corrected mail flow between both hub servers are fine.

    Thanks for the valuable info...

    Cheers Afraz
    • Proposed as answer by maafraz Monday, February 02, 2009 1:20 PM
    Monday, February 02, 2009 1:19 PM
  • Had similar problem one time. Worked for several hours on it, and tried a lot of the suggestions listed on this forum. Found out it was our anti-virus software on the server. An update had been pushed out to it the day before, and something with that update was causing the problem. As soon as we paused the anti-virus software service, the e-mail flowed out to the world without problem.
    Friday, February 20, 2009 1:39 PM
  • Great posting.  Your info helped me out, had exact same issue the day my ssl cert expired.
    It's hard to find info on all the interconnections between Exchange 07 and SSL certs.  ARGHH!!!
    Monday, February 23, 2009 2:57 AM
  • We had a similar problem and I tired all forums but no  luck. Finally we opend up acase with microsoft and workked with them for 2 days to resolve this issue.  You ahve to disable the autotunnuing feature in windows 2008. You can run 

    netsh interface tcp set global autotuninglevel=disabled commnad

    Kind Regards
     Jix Patel
    • Proposed as answer by Jix Patel Wednesday, July 29, 2009 8:25 PM
    • Proposed as answer by Jix Patel Wednesday, July 29, 2009 8:25 PM
    Wednesday, July 29, 2009 8:21 PM
  • McAfee McSheld is what got me on this problem. If Access Protection is turned on and you a have Block for Prevent mass mailing worms from sending mail. You need to add edgetransport.exe and telnet.exe to your exclusion list. Once I added this to McAfee mail started flowing between Exchange 2007 and Exchange 2003 for me.
    • Proposed as answer by emsik Thursday, February 06, 2014 1:57 AM
    Thursday, August 20, 2009 5:54 PM
  • Hi All

    I am getting same error for few domains. Else the mail flow for other domains is working perfectly. I am using Exchange 2007 Sp1 with windows 2003R2 64 bit. Also we had Cisco ASA5520. 

    "451 4.4.0 Primary target IP address responded with: "421 4.4.2 Connection dropped." Attempted failover to alternate host, but that did not succed. Either there are no alternate hosts, or delivery failed to all alternate hosts."


    Mahesh Khanolkar
    Wednesday, November 25, 2009 5:04 AM
  • this great my problem was solved by this atricle thanks

    Monday, December 21, 2009 11:13 AM
  • Hi MrFrankieG

    I used this comman but it givein g me error

    Help me


    Monday, February 01, 2010 9:31 AM
  • Which method you have use to resolve the issue?

    I have tried all mentioned but no luck.
    Tuesday, February 09, 2010 9:58 AM
  • Hello! We just had the same issue with a newly installed SBS 2008 and the Exchange 2007 was giving us the same behavior in regards to sending email to a couple of external domains. We figured out that it was one of the AVAST (antivirus) email scanner tasks causing this. After disabling this task everything works like it should.
    - Igor
    Thursday, February 25, 2010 3:43 PM
  • Hi, I undertook my first sbs2003 -sbs2008 with exchange 2007 last week. all went well apart from the messages getting stuck and then returning with NDR. I then spent the last 7 days trying to work out why this was happening.

    I just ran the following command as suggested above,

    netsh interface tcp set global autotuninglevel=disabled 

    and all the mail flowed out of the queue! 

    Many thanks for all of the posts. I was beginning to doubt my skills....


    Monday, March 08, 2010 8:02 PM
  • I had this exact same problem and tried everything that was posted here. My solution was due to my server and a few domains not talking nicely with EHELO. I documented my solution here:



    • Proposed as answer by alhashim Saturday, July 24, 2010 5:35 AM
    Tuesday, April 27, 2010 10:14 PM
  • This worked great, thank you Craig for posting.
    Monday, May 17, 2010 1:48 PM
  • I had the sam problem on my TMG server with Edge Role and forefront protection 2010 for exchange.The queue was growing, without connection to the hub server(error 421 4.4.2). the problem came from the Network Inspection System(NIS) in the TMG, who was blocking the traffic(edge subscriptions) between the edge server and the hub transport server. The only solution is to create an exception in the NIS (a Microsotft case was open).
    Monday, June 21, 2010 10:00 PM
  • Thanks Craig, it worked.
    Wednesday, August 25, 2010 6:35 AM
  • Craig,


    You were a life saver!  I have never seen a queue clear out so fast.  I was having a problem with my HT/CAS Server in a remote site routing E-mails and this cleared it up perfectly. 

    Wednesday, December 22, 2010 3:59 AM
  • Glad I could help Paul!
    Tuesday, January 11, 2011 3:10 AM
  • This thread is getting pretty close to a KB.

    Here's another setting caused the same error:

    The send connector can be forced to send on port other than 25. Such was set with a smart host and caused 421 4.4.2 when it was switched back to "use DNS".  The send connector verbose logging and this thread helped. Check with EMS:

    Get-SendConnector | ft name, port


    Saturday, May 14, 2011 6:10 PM
  • Hi Craig,

    I found your solution of creating a forced HELO send connector solved my issue too. For the benefit of the community I manage an Exchange 2010 server and messages were queued for delivery to a clients Exchange 2000 server. After reviewing the send connector logs I could see that our server was initiating a STARTTLS connection, however the connection would timeout and get stuck, till the message expired from the queue. By creating a forced HELO send connector I was able to bypass the STARTTLS and the messages were delivered.

    Very pleased, thanks once again.


    Jay Valambhia
    Thursday, August 11, 2011 9:46 AM
  • I had a same problem and its resolve using the steps provided by you.

    Thanks for help

    Wednesday, August 24, 2011 5:40 AM
  • Instead of "true" it has to be "1"
    Tuesday, December 06, 2011 12:32 PM
  • I know this issue is very old but we just started experiencing this issue.  None of the fixes list have resolved our issue.  Does anyone have any other ideas?
    Thursday, February 16, 2012 7:58 PM
  • I know this issue is very old but we just started experiencing this issue.  None of the fixes list have resolved our issue.  Does anyone have any other ideas?

    Hi Jason, I found Craigs solution was spot on:

    In my case I found this issue happened out the blue when users were having difficulty emailing a client, upon troubleshooting our server (exch 2010) was trying to email the client (exch 2000). The client was using a self signed certificate which was not playing ball during the SMTP STARTTLS stage.

    Care to share a little about your environment? Have you reviewed your logs? What have you found so far? What service pack is your Exchange box on? Do you have a certificate from a public CA or selfsigned?

    Jay Valambhia |

    Thursday, February 16, 2012 11:21 PM
  • Hi Jay,

    We are running Exchange 2007 SP2.  We have one server that has the following roles:

    Hub Transport

    Client Access


    Our mx record is but all of our traffic goes out from our network as  We just recently purchased a new SSL cert from Digicert and it looks like the new cert is enabled.  But we started having problems when we installed the new certificate.

    Also, something weird, our A record for .100 is not the actual name of the server we are sending mail from.  Does that matter?

    Wednesday, February 29, 2012 6:37 PM
  • Hi Jason,

    I would first of all recommend when giving advise to always ensure you have a good backup of your system and ensure its up to date. I can tell you that SP3 is already out for Exchange 2007 - 

    The reason why your traffic goes out of another IP could be to do with your NAT rules on your firewall. Ideally your A record needs to point to .101, with an associated NAT rule inbound. 

    Check your certificate and external connectivity, by running the Exchange ActiveSync and autodisover test on 

    What have you found via your log files to indicate that Craigs solution didn't work?

    Jay Valambhia |

    Tuesday, March 13, 2012 12:53 PM
  • If you are using SonicWall as your firewall make sure that you let "Microsoft Exchange Server TNEF Message" through. IPS ID: 7521
    • Proposed as answer by Sharapov Saturday, March 17, 2012 1:22 AM
    Saturday, March 17, 2012 1:21 AM
  • This thread is getting pretty close to a KB.

    Here's another setting caused the same error:

    The send connector can be forced to send on port other than 25. Such was set with a smart host and caused 421 4.4.2 when it was switched back to "use DNS".  The send connector verbose logging and this thread helped. Check with EMS:

    Get-SendConnector | ft name, port


    Thank goodness you posted this. Forgot all about the port change I had to make a couple years ago.

    Friday, January 18, 2013 6:09 AM
  • This is usually a DNS issue. Go t ECP and specify the DNS of the domain under the send connector. I am talking about the DNS of the Activediretory Integrated Zone located on your Domain Controller.

    Saturday, June 01, 2013 1:22 PM