none
Exchange 2013 - Unable to send email, Internally & Externally RRS feed

  • Question

  • Hi,

    I have new testing lab to play around with which is starting to drive me insane. I have exchange 2013 and outlook 2013. I can receive emails from external domains but I am unable to send emails internally or externally!

    Now I would know what to look at if I couldn't send externally, But not being able to send internally has completed confused me!

    anyone got any tips where to start troubleshooting for not being able to send internal mail? Once internal mail works I should then be able to get external mail working as well....

    Thanks



    • Edited by Casey03 Sunday, February 3, 2013 7:28 PM
    Sunday, February 3, 2013 7:10 PM

All replies

  • On Sun, 3 Feb 2013 19:10:50 +0000, Casey03 wrote:
     
    >I have new testing lab to play around with which is starting to drive me insane. I have exchange 2013 and outlook 2013. I can receive emails from external domains but I am unable to send emails internally or externally!
    >
    >Now I would know what to look at if I couldn't send externally, But not being able to send internally has completed confused me!
    >
    >anyone got any tips where to start troubleshooting for not being able to send internal mail? Once internal mail works I should then be able to get external mail working as well....
     
    Saying that you can't do it without saying WHY or HOW it fails isn't
    going to help anyone help you.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Sunday, February 3, 2013 10:24 PM
  • You cannot send email from Outlook using the default install. You must create a Receive connector.
    Friday, February 8, 2013 7:26 PM
  • You cannot send email from Outlook using the default install. You must create a Receive connector.

    according to http://technet.microsoft.com/en-us/library/aa996395.aspx no additional connectors are necessary to be able to receive mails!

    "In a typical installation, no additional Receive connectors are required."





    • Edited by dw_at Sunday, February 10, 2013 1:09 PM
    Sunday, February 10, 2013 10:58 AM
  • I am also haveing problems sending mail internaly.  I have two accounts configured and am OWA to send mail between them.  Can't even send it to my self.  I have check my recieve connector and my internal domain name is in the accepted domains.  I have been looking around and can't find anything wrong.  Any ideas?

    Thanks

    DT

    Wednesday, February 27, 2013 12:57 AM
  • Having problems sending email might be a symptom of having name resolution problems. Can you verify your DNS settings and make sure that the Exchange Server can resolve the domain names you are trying to send email to.

    So, if you are trying to send amil to gmail.com, your Exchange Server should be able to get an answer back from your preferred DNS server as to what IPs that name is on.

    But as Rich said, just saying it isn't working doesn't give us much information to troubleshoot from. Please try to give more details as to what's happening when you try to send the email, log entries, and what steps you already have taken in your troubleshooting.


    Jesper Bernle | Microsoft Community Contributor 2011 Awardee

    Tuesday, March 19, 2013 2:22 PM
  • To clarify the details of the problem, when using OWA to send an e-mail to another mailbox on the server it says it sent but the e-mail shows up under the Drafts folder immediately.  When I use a domain account with outlook configured and send to another mailbox on the server it shows it as sent and it is in the sent items folder but never shows up in the mail box.  I have even tried both just sending to myself.  I have setup the MX record on my DNS to point to the exchange server and still nothing.   Is there anything I am missing?  I have the connectors all setup and configure as per all the guides.

    Tuesday, March 19, 2013 8:33 PM
  • Try opening Exchange Management Shell and enter Test-ServiceHealth | FT Role,RequiredServicesRunning -AutoSize and see if all comes back as True.

    Jesper Bernle | Microsoft Community Contributor 2011 Awardee

    Wednesday, March 20, 2013 7:12 AM
  • The following is returned on this test.

    [PS] C:\Windows\system32>Test-ServiceHealth | FT Role,RequiredServicesRunning -AutoSize

    Role                          RequiredServicesRunning
    ----                          -----------------------
    Mailbox Server Role                              True
    Client Access Server Role                        True
    Unified Messaging Server Role                    True
    Hub Transport Server Role                        True

    [PS] C:\Windows\system32>

    Friday, March 22, 2013 11:11 AM
  • Okay, so that looks fine. Hmm ....

    Can you descibe your setup a bit more, perhaps with a qick Visio image? It's strange the problem you have. It should just work, right out of the box.

    BTW, you did create a Send Connector, right?


    Jesper Bernle | Microsoft Community Contributor 2011 Awardee

    Friday, March 22, 2013 1:34 PM
  • I have installed Exchange with the default setting and have created a send connector for all domains.  I have tested sending mail to my self from both a outlook client as well as the OWA and does not go through.  in OWA every time I try to send mail it just goes into the draft folder and does not get sent.  when sending from the outlook client it goes into the outbox then sent items but never show on the other side.  I have check every thing have tried to find the message on the server and could not.  When using the OWA I have done it from both the computer running the outlook client as well as the server system itself.
    Friday, March 22, 2013 4:05 PM
  • Run Test-SmtpConnectivity -Identity <Name of your 2013 MailboxServer>

    Test-SmtpConnectivity


    Jesper Bernle | Microsoft Community Contributor 2011 Awardee

    Sunday, March 24, 2013 12:45 PM
  • Also have alook at this brand new blog post by Tony Redmond - http://thoughtsofanidlemind.wordpress.com/2013/03/25/exchange-2013-dns-stuck-messages/

    Jesper Bernle | Microsoft Community Contributor 2011 Awardee

    Monday, March 25, 2013 9:31 AM
  • I have the same issue. Test-SMTPconenctivity comes up with success. I have exchange 2007 servers as well.

    Malli Boppe MCITP Enterprise Messaging Exchange 2010

    Tuesday, April 30, 2013 6:11 AM
  • In my case ,on the exchange 2007 server receive connector exchange authentication was removed  by some one.Once I enabled the option its working now.

    Malli Boppe MCITP Enterprise Messaging Exchange 2010


    • Edited by mboppe Wednesday, May 22, 2013 6:39 AM
    Wednesday, May 1, 2013 7:09 AM
  • I am experiencing same problems with migration from Exchange 2007 to 2013.

    I have installed one Exchange 2013 multi-role server to co-exist with Exchange 2007 and the installation was successfully done by following instructions ExDeploymentAssistant and with no errors on installation.

    I can send email from Exchange 2007 test user to my 2013 test mailbox but when sending mail from 2013 test user's OWA or Outlook the messages are stuck in drafts folder in OWA and in Outlook they go to sent items but never appear in queues or anywhere. Same issue occurs also when trying to send mail to another 2013 test user located in same server and database.

    I've tried to change DNS settings according to this article but this does not solve the issue for me:

    http://thoughtsofanidlemind.wordpress.com/2013/03/25/exchange-2013-dns-stuck-messages/

    I can send unauthenticated email using telnet from 2013 server to 2007 so there should be no problems with receive connectors.

    Test-ServiceHealth cmdlet shows that everything is ok and all the services are up and running and there is no errors in event logs or anything.

    This clearly is some sort of transport issue in co-existence with Exchange 2007. There is some reports to this issue where installing another Exchange 2013 mailbox role server might correct this issue but I would not like to try that first since I am running in a production environment.



    • Edited by udam1 Wednesday, May 8, 2013 4:25 AM
    Tuesday, May 7, 2013 4:32 PM
  • Strange... I returned all the DNS settings from EAC (Servers -> DNS lookups setting) to default (All network Adapters (All available ipv4). That is exactly how it was after installation.

    But when I started to work with the issue today all send and receive is working correctly from OWA and Outlook!!! So I'd suggest that if you experience same problems, wait over night and try it the next day and it might be working. Could this issue be related to AD replication (Which is working fine by the way at the environment I am configuring )

    There is also a miss leading thing in Tony Redmond blogpost, where it is said that ExternalDNSServers and InternalDNSServersproperties would show you the DNS servers, but in fact they won't show you anything if you have the All network Adapters setting chosen in Exchange settings and this is normal behavior since you have to set ExternalDNSAdapterEnabled and InternalDNSAdapterEnabled values to $false in order to use the DNS addresses listed in those attributes or you have to set the external and internal DNS settings to custom from EAC  (Servers -> DNS lookups setting)

    Look at: http://technet.microsoft.com/en-us/library/bb124238(v=exchg.150).aspx

    The ExternalDNSAdapterEnabled parameter specifies one or more Domain Name System (DNS) servers that Exchange uses for external DNS lookups. When theExternalDNSAdapterEnabled parameter is set to $true, DNS lookups of destinations outside the Exchange organization are performed by using the DNS settings of the external network adapter specified by the value of the ExternalDNSAdapterGuid parameter. If you want to specify a custom list of DNS servers used for external Exchange DNS lookups only, you must specify the DNS servers by using the ExternalDNSServers parameter, and you must also set the value of the ExternalDNSAdapterEnabled parameter to $false. The default value of theExternalDNSAdapterEnabled parameter is $true.

    Wednesday, May 8, 2013 6:12 AM
  • I rebooted the server and the issue is now back! Not sending mail from owa -> goes to drafts and sending from Outlook goes to sent items but no messages are transferred. This is really strange. Test-Smtpconnectivity is showing success but still the issue is on again.

    Looks like the Exchange 2013 transport is really buggy... Nice feature that you have to wait hours after reboot to get the mail flowing...


    Wednesday, May 8, 2013 7:59 AM
  • Ok, seems that after reboot you have to restart Microsoft Exchange Mailbox Transport Submission -service and drafts folders in OWA will get empty and then you can send messages. We tested this many times and everytime when rebooting the server messages got stuck in OWA's drafts folder and Outlooks sent items. Restarting the service will correct the issue. Now we'll wait if you have to kick the service often if it stops working without reboots which I am a bit afraid it will do.

    EDIT: Setting this service to Delayed Start will also fix the issue during reboot.
    • Edited by udam1 Wednesday, May 8, 2013 12:22 PM
    Wednesday, May 8, 2013 11:55 AM
  • Hello,

    I´m facing the exact same annoying issue.

    See the this thread I started Yesterday.

    http://social.technet.microsoft.com/Forums/en-US/exchangesvrdeploy/thread/571afb12-cabe-4b42-8957-2d07973d89d8/


    Thx /Tony

    Wednesday, May 22, 2013 6:35 AM
  • Hi I found a solution to the same exact problem you had. Double check the following:

    1. disable all other network interfaces that you are not using with Exchange.

    2. Make sure that you select the correct DNS setting in Server\<Excahgne server Name>

    3. Make sure to create a reverse lookup zone along with configuring the DNS setting with the right IP to listen.

    Those three points solved my problem

    • Proposed as answer by Enjora Monday, January 20, 2014 9:49 AM
    Monday, January 20, 2014 9:47 AM
  • The following is returned on this test.

    [PS] C:\Windows\system32>Test-ServiceHealth | FT Role,RequiredServicesRunning -AutoSize

    Role                          RequiredServicesRunning
    ----                          -----------------------
    Mailbox Server Role                              True
    Client Access Server Role                        True
    Unified Messaging Server Role                    True
    Hub Transport Server Role                        True

    [PS] C:\Windows\system32>

    What if this test says nothing? not even false or True...
    Saturday, May 24, 2014 2:26 PM
  • I have a single 2012 R2 domain controller and single Exchange 2013 SP1 installation.  

    It looks like the internet has run out of suggestions.  I've used NSlookup with set q=mx to make sure the internal DNS server points to the only Exchange server.  I made reverse lookup zones and make a PTR record for the mail server and domain controller.  

    Like badguy643, my results to test-servicehealth comes out all True.  

    The results of get-transportservice | Format-list shows internalDNSservers and externalDNSservers to be correct.  Oddly enough, it says that internalDNSAdapterEnabled to be false.  But when I use set-TransportService to change the attribute, it says that it was successful but no setting was changed.  Perhaps the get-transportservice has a false negative?

    I've rebooted a few times and restarted the Transport Submisison Service after waiting 10 minutes after bootup with no better results.  

    What do I need to do to make my single Exchange server recognize it's own hand?  All my tests are with internal email from one mailbox to another.  I'm getting desperate enough to pay the $270 to have Microsoft fix it . 

    Edit - it seems as though I'm getting an non-existent domain error on the connectivity log.  Since my logon domain is different from my email domain, it's causing this problem as it's trying to send internal email using my logon domain.  I'll have to remove the public DNS server since it doesn't want to prioritize the internal one.    
    • Edited by mplichta Sunday, August 3, 2014 11:52 PM
    Sunday, August 3, 2014 11:48 PM
  • Yes! that did it.  

    The log with the error was this one.  

    C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\Connectivity

    Since my logon domain is not publicly routable, I had to remove all public DNS servers and only put my internal DNS server in the list.  It was sending internal email using the logon domain rather than the public email domain.  

    OWA and Outlook both say the correct public email domain, but the internal routing is all by logon domain, despite changing the default.

    • Proposed as answer by fganter Tuesday, August 23, 2016 10:08 AM
    Sunday, August 3, 2014 11:57 PM
  • Also try adding the mailbox server ip address to (c:\windows\system32\drivers\etc\host) 

    Wednesday, January 7, 2015 2:48 PM
  • In addition to setting the External DNS server on the server transport settings and setting the Microsoft Exchange Mailbox Trasport Submission to delayed-start (which by themselves did not resolve the issue), I also set the -UseDowngradedExchangeServerAuth parameter to $true (previously $false) on the Set-TrasportService comandlet. Since the error in OWA when attempting to send an email on the Drafts folder indicated ""You don't have permission to perform this action", figured it was a matter of permissions on the transport service, receive or send connectors. The later I've checked extensively and found no issues with permissions.

    Set-TrasportService -Identity <Server> -UseDowngradedExchangeServerAuth $true

    ...and then restart the transport related services.

    Get-Service | where {$_.displayname -like "*transport*"} | Restart-Service

    Emails stuck in the Drafts folder will immediately go out on their merry way!

    Hope this helps somebody with this super fraking annoying issue.

    Fred


    Fred Larracuente Stronghold System Solutions Corp. Guaynabo, PR USA www.strongholdcorp.net

    Wednesday, May 6, 2015 5:35 PM
  • There are several problems that can cause these symptoms.  In my case, it was because I had deleted the default receive connector operating on port 2525, which is necessary for the internal proxy of SMTP traffic between the various Exchange services.  Recreating the connector solved the issue.

    : Default EX2013
    AuthMechanism    : TLS, Integrated, BasicAuth,BasicAuthRequireTLS, ExchangeServer
    RemoteIPRanges   : {::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff,
    0.0.0.0-255.255.255.255}
    TransportRole    : HubTransport
    PermissionGroups : ExchangeUsers, ExchangeServers, ExchangeLegacyServers
    MaxMessageSize   : 35 MB (36,700,160 bytes)
    Port 2525

    • Proposed as answer by Stoutner Tuesday, July 28, 2015 5:57 AM
    Tuesday, July 28, 2015 5:56 AM
  • This blog just solved the issue for me Jesper, Thanks a ton. I had internal DNS resolving External addresses and it was causing delays in mail transport. Set the external resolution to 8.8.8.8 and internal to my domains DNS server and bam. Good to go Sir!
    Monday, October 5, 2015 11:47 PM
  • Old thread but here's another thing to keep an eye on....

    Just one thing I ran into (trying to test Exchange in my Dev environment with a different IP scheme) I had all the same symptoms and turned out someone had configured static IPs in my host file for my Exchange server (which I copied the VHDXs from Production)... once I cleared the host file I was able to send email without an issue.



    • Edited by JoeFri Monday, April 11, 2016 2:47 PM
    • Proposed as answer by networksplus Thursday, May 26, 2016 8:24 PM
    • Unproposed as answer by networksplus Thursday, May 26, 2016 8:24 PM
    • Proposed as answer by JoeFri Thursday, October 24, 2019 1:35 PM
    Monday, April 11, 2016 2:44 PM
  • check the permissions on the receive connector. Make sure the security on each of the transports includes exchange/windows authentication.
    Thursday, May 26, 2016 8:28 PM
  • Deleting the default receive connector for Port 2525 and recreating a custom hub connector for port 2525 with all of the same settings worked for me.
    Thursday, June 9, 2016 2:29 PM
  • It's DNS. It's ALWAYS DNS with Microsoft.

    Delete external DNS servers in the Exchange server use ONLY the AD DNS server.

    Despite reading like a "permissions" issue, it is not.

    Monday, June 13, 2016 8:11 PM
  • This led to the solution for us.

    As the saying goes, "What doesn't kill you, makes you stronger."  Turns out we had a public DNS server in IP settings for the email servers.  Once we removed that, things starting talking!  Effectively, streamlined our communications going forward.

    I wonder if there's a bug in the Exchange code.  Even though the internal DNS server was first in the list, the communications appeared to have been shooting out to the external DNS server first.

    Thanks for taking the time to post the details of your solution.

    Tuesday, August 23, 2016 10:26 PM
  • Yeah, I wish it were that sample.

    It appears for many people (including us) it's a DNS issue.  See posts later in this thread.

    Tuesday, August 23, 2016 10:27 PM
  • Same was the issue with me. Removing the external dns server from the adapter resolved it 
    Monday, October 17, 2016 7:59 AM
  • You saw this behavior because that's how DNS works: if the first server in the list doesn't respond, it starts using the second one...and won't switch back until you restart the server or until the second server doesn't respond. So if you reboot your DC or internal DNS server at some point, from then on the server is going to use the public DNS. That's why it's always bad to use a public DNS IP on domain-joined systems--it will eventually cause more problems than it is supposed to solve.
    Tuesday, January 10, 2017 7:34 PM