In most organizations there are several devices or applications that need to use an SMTP service to send email messages. An Exchange 2016 server can provide that service for you, however the configuration required on the server depends on the SMTP relay requirements of your scenario.
The steps for how to configure Exchange Server 2016 SMTP relay are:
- Determine whether your scenario is internal relay or external relay
- Determine whether devices and applications will authenticate or connect anonymously
- For authenticated relay, configure the TLS certificate for the client front end connector
- For anonymous relay, configure a new receive connector that is restricted to specific remote IP addresses
Determining Internal vs External Relay Scenarios
There are generally two types of SMTP relay scenarios that Exchange Server 2016 is used for:
- Internal relay – devices and applications that need to send email messages only to internal recipients in the Exchange organization.
- External relay – devices and applications that need to send email messages to external recipients.
Let’s take a look at each of those scenarios, and then some additional considerations when you are deploying this in your own production environments.
Internal SMTP Relay with Exchange Server 2016
When Exchange Server 2016 is first installed the setup routine automatically creates a receive connector that is pre-configured to be used for receiving email messages from anonymous senders to internal recipients. This allows inbound internet email to be received by the server, and is also suitable for internal relay scenarios.
The receive connector is named “SERVERNAMEDefault Frontend SERVERNAME”, for example, “EXSERVERDefault Frontend EXSERVER” in my test environment.
[PS] C:\>Get-ReceiveConnector
Identity Bindings Enabled
-------- -------- -------
EXSERVER\Default EXSERVER {0.0.0.0:2525, [::]:2525} True
EXSERVER\Client Proxy EXSERVER {[::]:465, 0.0.0.0:465} True
EXSERVER\Default Frontend EXSERVER {[::]:25, 0.0.0.0:25} True
EXSERVER\Outbound Proxy Frontend EXS... {[::]:717, 0.0.0.0:717} True
EXSERVER\Client Frontend EXSERVER {[::]:587, 0.0.0.0:587} True
You can test this connector by making an SMTP connection using Telnet and issuing SMTP commands. For example:
C:\>telnet exserver 25 220 EXSERVER.exchange2016demo.com Microsoft ESMTP MAIL Service ready at Thu, 22 Oct 2015 11:39:23 +1000 helo 250 EXSERVER.exchange2016demo.com Hello [192.168.0.30] mail from: test@test.com 250 2.1.0 Sender OK rcpt to: adam.wally@exchange2016demo.com 250 2.1.5 Recipient OK Data 354 Start mail input; end with . Subject: Test email Testing . 250 2.6.0 <f7c2f921-ff7e-4ce4-b2eb-a70dc52f225f@EXSERVER.exchange2016demo.com> [ InternalId=854698491929, Hostname=EXSERVER.exchange2016demo.com] Queued mail for delivery
So there’s no specific configuration required on the server or the connectors to allow this scenario, however it is recommended that you use a DNS alias instead of the real server name. This will allow you to configure all of your devices and applications with the DNS alias, and you can later move that DNS alias to point to a different Exchange server during a migration.
TEC Talk: Making Generative AI Work for Microsoft 365 Active Directory
AI-based Microsoft 365 Copilot is coming. But before you commit, join this TEC Talk to understand the technology behind Copilot and how it generates information from M365 applications.
External SMTP Relay with Exchange Server 2016
Continuing from the previous demonstration, let’s see what happens if I try to use Telnet to send an email message from a valid internal address to an external recipient.
220 EXSERVER.exchange2016demo.com Microsoft ESMTP MAIL Service ready at Thu, 22 Oct 2015 12:04:45 +1000 helo 250 EXSERVER.exchange2016demo.com Hello [192.168.0.30] mail from: adam.wally@exchange2016demo.com 250 2.1.0 Sender OK rcpt to: exchangeserverpro@gmail.com 550 5.7.54 SMTP; Unable to relay recipient in non-accepted domain
An SMTP error code “550 5.7.54, Unable to relay recipient in non-accepted domain” is received instead. The receive connector will not allow an anonymous, unauthenticated sender to relay to external domain names, which prevents your server from being exploited as an open relay.
There are two ways you can resolve this and allow your devices and applications to send to external recipients:
- Using authentication for SMTP connections
- Configuring an anonymous SMTP relay connector
External SMTP Relay with Exchange Server 2016 Using Authentication
The first method is to use authenticated SMTP connections. Exchange Server 2016 has a receive connector designed to be used by clients that need to send via SMTP called “SERVERNAMEClient Frontend SERVERNAME”, for example “EXSERVERClient Frontend EXSERVER” in my test environment.
[PS] C:\>Get-ReceiveConnector
Identity Bindings Enabled
-------- -------- -------
EXSERVER\Default EXSERVER {0.0.0.0:2525, [::]:2525} True
EXSERVER\Client Proxy EXSERVER {[::]:465, 0.0.0.0:465} True
EXSERVER\Default Frontend EXSERVER {[::]:25, 0.0.0.0:25} True
EXSERVER\Outbound Proxy Frontend EXS... {[::]:717, 0.0.0.0:717} True
EXSERVER\Client Frontend EXSERVER {[::]:587, 0.0.0.0:587} True
Minimal configuration is required to get this working. Assuming you’ve already configured an SSL certificate for Exchange Server 2016, and added a DNS alias for your SMTP devices and applications to use (I’m using a DNS alias of mail.exchange2016demo.com in this example), you should then also set the TlsCertificateName for the receive connector.
Use Get-ExchangeCertificate to identify the thumbprint of the SSL certificate you’ll be using.
[PS] C:\>Get-ExchangeCertificate Thumbprint Services Subject ---------- -------- ------- FC5259C0528657EF22BB818CA9B23FD220A9DE83 ...WS.. CN=mail.exchange2016demo.com, OU=IT, O=LockLAN Systems Pty Ltd,... FE6528BE1548D81C794AE9A00D144FF3D16E0CD2 ....S.. CN=Microsoft Exchange Server Auth Certificate DAB089E53CA660DEF7B8EE303212C31C0E3D3499 IP.WS.. CN=EXSERVER 17839AF62AA3A1CBBD5F7EC81E92A609976D8AD9 ....... CN=WMSvc-EXSERVER
The syntax of the TlsCertificateName string is made up of two different attributes of the certificate, so I use the following commands to apply the configuration to my receive connector.
[PS] C:\>$cert = Get-ExchangeCertificate -Thumbprint FC5259C0528657EF22BB818CA9B23FD220A9DE83 [PS] C:\>$tlscertificatename = "<i>$($cert.Issuer)<s>$($cert.Subject)" [PS] C:\>Set-ReceiveConnector "EXSERVER\Client Frontend EXSERVER" -Fqdn mail.exchange2016demo.com -TlsCertificateName $tlscertificatename
To test using the Client Frontend connector to send an email message I’m going to use PowerShell’s Send-MailMessage cmdlet instead of Telnet. First, capture some valid credentials to use for authentication.
PS C:\>$credential = Get-Credential
Next, use the Send-MailMessage cmdlet with parameters specifying the server, to and from addresses, subject line, and the port number.
PS C:\>Send-MailMessage -SmtpServer mail.exchange2016demo.com -Credential $credential -From 'adam.wally@exchange2016demo.com' -To 'exchangeserverpro@gmail.com' -Subject 'Test email' -Port 587 -UseSsl
In the above example the email is successfully received by the external recipient. So any device or application on the network that can use authenticated SMTP can be set up to use that connector listening on port 587 on your Exchange 2016 server.
External SMTP Relay with Exchange Server 2016 Using Anonymous Connections
When authenticated SMTP is not an option you can create a new receive connector on the Exchange 2016 server that will allow anonymous SMTP relay from a specific list of IP addresses or IP ranges.
In the Exchange Admin Center navigate to mail flow and then receive connectors. Select the server that you want to create the new receive connector on, and click the “+” button to start the wizard.
Give the new connector a name. I like to keep the name consistent with the other default connectors. Set the Role to “Frontend Transport”, and the Type to “Custom”.
The default Network adapter bindings are fine. This represents the IP and port that the server will be listening on for connections. Multiple receive connectors on the Frontend Transport service can listen on the same port of TCP 25.
Remove the default IP range from the Remote network settings, and then add in the specific IP addresses or IP ranges that you want to allow anonymous SMTP relay from. I do not recommend adding entire IP subnets that contain other Exchange servers as this can cause issues with server to server communications.
Click Finish to complete the wizard, then there is some additional configuration still required.
In the Exchange Management Shell run the following two commands.
[PS] C:\>Set-ReceiveConnector "EXSERVER\Anon Relay EXSERVER" -PermissionGroups AnonymousUsers [PS] C:\>Get-ReceiveConnector "EXSERVER\Anon Relay EXSERVER" | Add-ADPermission -User 'NT AUTHORITY\Anonymous Logon' -ExtendedRights MS-Exch-SMTP-Accept-Any-Recipient
We can now test the connector using Telnet from the IP address that was added to the remote network settings of the receive connector. In my test environment that IP address will now be allowed to send email from any email address (whether it is a valid internal address or not) to any external address.
220 EXSERVER.exchange2016demo.com Microsoft ESMTP MAIL Service ready at Thu, 22 Oct 2015 12:59:39 +1000 helo 250 EXSERVER.exchange2016demo.com Hello [192.168.0.30] mail from: test@test.com 250 2.1.0 Sender OK rcpt to: exchangeserverpro@gmail.com 250 2.1.5 Recipient OK Data 354 Start mail input; end with . Subject: test . 250 2.6.0 <e1739c5f-db11-4fdd-aa27-a9702bc15b15@EXSERVER.exchange2016demo.com> [ InternalId=863288426497, Hostname=EXSERVER.exchange2016demo.com] Queued mail for delivery
Additional Considerations
Here’s some additional items that you should consider when you’re providing SMTP relay services with Exchange Server 2016 for your environment.
High Availability and Load Balancing
If you want to provide a highly available SMTP service then a load balancer is the natural solution. If you plan to load balance you’ll need to ensure that the same receive connectors exist on all of the servers in the load balanced pool. This means creating the same relay connector on multiple servers and managing the same list of permitted IP addresses on those connectors.
However, as you’ll see by reading my article on issues with load balancing SMTP traffic, when a load balancer is source NATing the connections the only IP address that will appear to the Exchange server is that of the load balancer itself, not the source device or application. While this simplifies the receive connector configuration (only the load balancer IP needs to be added as an allowed IP) it opens up a number of concerns:
- Access control (which IP’s are allowed to send) needs to be applied at the load balancer, or you risk having a wide open anonymous SMTP relay service on your network
- Depending on the load balancer, health probes to the Exchange servers may not detect all health conditions, resulting in traffic being sent to unhealthy servers (and failing)
- Connections made via the load balancer are anonymous and in some cases untraceable to the source IP (depending on what logging your load balancer is capable of)
You can read more about these issues here.
If a load balancer is not an option for you and you still want some high availability for SMTP services, then you can consider DNS round robin. However, many devices and applications do not handle DNS round robin as well as Outlook or a web browser would. Some devices, when they attempt a connection to one of several IP addresses available in DNS round robin and that IP address is not responding, will not try other IP addresses that are available and will simply consider the connection attempt failed. So it really depends on how well your devices and applications deal with that situation as to whether DNS round robin will be suitable for your environment.
Security vs Convenience
A lot of organizations simply go with the anonymous relay option and set up a connector that allows wide ranges of IP addresses to relay email anywhere. This is the simplest approach, but clearly not the best in terms of security and auditing. Anonymous relay relies on trusted, identifiable IP addresses. If the IP addresses are in a DHCP pool, are associated with a load balancer (see above), are multi-user (such as terminal servers), or the IP/host itself is compromised in some way, then your ability to trace emails back to the real source is difficult if not impossible.
Although authentication adds some complexity, it may be worth it from security perspective. However it does mean managing credentials for all of your devices and applications. Sharing SMTP credentials across multiple systems might seem like a way to avoid complexity, but it re-introduces the problems associated with anonymous SMTP.
Encryption
In the tutorial above I demonstrated configuring a TLS certificate name for a receive connector and also used TLS/SSL for my testing with Send-MailMessage. If you are going to use authentication for SMTP in your environment, or the SMTP traffic is in any way sensitive, then you should protect it with TLS/SSL encryption.
Multiple Receive Connectors
You may be wondering how the Exchange server is able to differentiate between traffic destined for one receive connector vs another receive connector, when both of them are listening on the same IP address and port number, for example “EXSERVERDefault Frontend EXSERVER” and “EXSERVERAnon Relay EXSERVER”.
The answer is in the Remote network settings of the receive connectors. Exchange will use the receive connector that is the most specific match for the source IP address of the SMTP connection.
In my examples above this means that the default connector with its remote network settings of 0.0.0.0-255.255.255.255 (which is basically “anywhere”) is less specific than the relay connector with its remote network settings of 192.168.0.30. So when an SMTP connection comes from IP 192.168.0.30 to port 25 on the server it will be handled by the relay connector, while everything else connecting to port 25 will be handled by the default connector.
Troubleshooting
One of the most common issues when troubleshooting receive connector behaviour on an Exchange server is determine which connector is actually handling a given connection. There are two ways to approach this type of troubleshooting.
The first is to set different SMTP banners on each connector. Exchange MVP Jeff Guillet has a PowerShell example that you can run to configure each connector’s SMTP banner with the name of the connector itself, so that when you connect with Telnet you can immediately see which receive connector you’ve connected to.
[PS] C:\>$rc = Get-ReceiveConnector -Server EXSERVER
[PS] C:\>$rc | % {Set-ReceiveConnector $_.Identity -ProtocolLoggingLevel Verbose -Banner "220 $_"}
Now when you use Telnet to connect you will see the connector name in the banner.
C:\>telnet exserver 25 220 EXSERVER\Anon Relay EXSERVER
The other troubleshooting method is to use protocol logging. In the PowerShell example above the protocol log level for each connector was also set to “Verbose”. You can set this on individual connectors if you need to by running Set-ReceiveConnector.
[PS] C:\>Set-ReceiveConnector "EXSERVER\Anon Relay EXSERVER" -ProtocolLoggingLevel Verbose
You can then review the protocol logs to determine what is happening to SMTP connections. I generally recommend you leave protocol logging enabled for receive connectors at all times.
Summary
This article demonstrates how Exchange Server 2016 can be used to provide SMTP relay services to devices and applications on your network. As you can see there are multiple approaches that you can take to achieve this, each being suitable for different scenarios, and each having some pros and cons associated with it.
Internal relay needs are already met with the default configuration of an Exchange 2016, and authenticated SMTP for external relay is also available with minimal setup. When anonymous relay is required an additional receive connector can be easily configured.
I do recommend that you consider your actual requirements and implement the most appropriate solution to meet them, instead of simply configuring an anonymous relay connector for all devices and applications on your network.
First thanks for this article.
I have a coexistence scenario with Exchange 2013 and Exchange 2019, and with HCW configured for Exchange Online. My flow is ok, but I have a relay name concept in exchange 2013, and I created a connector with exactly the same settings called relay2019. I added the Exchange 209 in the MX and antispam flow.
When my application tries to send an email to internal users relay2019 works correctly. But when it is an external one like for example a gmail.com I have the error “550 5.7.54 SMTP; Unable to relay recipient in unaccepted domain”. Follow all the steps in your article, but the problem remains. When I point the application to the relay in Exchnage 2013 it is sent normally. Both relays are enabled (relay and relay2019). Can you give me some guidance on what I should do?
Thank you very much
Tengo el mismo problema, no lo has solucionado?
Thanks so much for this article. Nice and simple to understand.
Has anyone seen where anonymous senders can access the Office 365 SMTP server to send emails even when not part of the IP set in the connector? I have done some testing when not connected to the domain or VPN and when I send a message using powershell or even telnet to the xxx-xxx-com.mail.protection.outlook.com on port 25 it works, even when using a bogus email address as the sender. Not sure where the problem is, but this has suddenly come up and I am worried that there is no working restriction to our external IPs that are in the connector setup. Any suggestions?
Would I need a additional connector in o365 in a hybrid environment for this to work?
Can anyone confirm if the Exchange 2016 Exchange Edge Transport server can be used for mail submission from clients via port 587 with authentication? Everything I have read is that it that the Edge Transport is only used for inbound and outbound mail flow via TCP:25. Not for clients.
Regards,
Adam Tyler
Hi Paul,
thank you for article.
My receive connector works fine as you explained but I have a specific problem with display name.
my smtp server accepts email from external apps with the sender’s display name and send to exch servers.
and I have a contact that have same smtp address.(it’s for receive permissions of security groups).
In the send connector of smtp server;
when I use Exch2010 , display names seems as apps set
when I use Exch2016, display names seems as in contact.
how can avoid display name seems as in contact? (I have hidden it from oab).
Hi Paul,
Thanks for the article. I think we have a internal relay server which user can access via telnet and can send email from any user to any user. May be this is a normal behavior but we wanted to block this option as its possible to impersonate/spoof anyone and send false emails with in the organization. Wondering what would be the process in restricting that. Would authenticated flow work for internal relay server?
Thanks,
Mahmud
Hi Paul,
Thanks for the PowerShell trickery for testing. For starters it’s not necessary to assign a SSL cert to the receive connector since it appears to go ahead and use whatever valid SSL certs there are anyway. I’m not even sure if -UseSSL does anything to Send-Message anyway, it may just automatically try a TLS connection. In addition you should include some paragraphs about viewing the various logs in Exchange in order to verify what is going on in case the message doesn’t go out, instead of pawning it off to another web page. Lastly keep in mind that many mail services, like Gmail, will automatically put test messages in Junk Mail so if an admin sends out a test message to Gmail and doesn’t get it, they might check that it is not going to their junk folder at gmail before tearing apart the exchange server to “fix” it.
Next a word about high availability. There are many layers of “availability” but in my view full availability means independent physical servers with independent UPSes, power supplies, network connections, etc. I think you would have an even better article if you scotched all the high availability SMTP stuff (which needs it’s own article)) and replaced it with an enhanced and larger section on logging.
Hello Paul..
Amazing article !!!
I would be thankful to you if you could help me with below situation:
We have legacy domino infra in our environment with Postfix as the Mail transfer Agent.
We are now looking to replace this with a Microsoft solution.
There have been many issues lately with this legacy set up; hence we are moving out to Microsoft provided solution.
I have studied :- https://docs.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-office-3
There are many applications that we use. For example:- There is an oracle application that uses a workflow as:
It shoots and email to user mailbox(o365), the user replies to that email it goes to the mbx of the application (legacy domino) and again that app acts on that email (say it replies or does some action)
This app sends emails on IMAP and since it is an IMAP request, it would need a mailbox to process and as per above document (it had a part where IIS was mentioned, now it has been removed) so I need to know that setting up an exchange server would be a good option for such email relay ?
but for handful of these apps, would it be a wiser option to set up exchange server?
Again, as per the above document, option 1 seems to be relevant (after migrating the app mailbox to o365), but how can we over come the throttling limit?
Any other suggestions that would be useful for us?
Awaiting your response.
You can’t “Send on IMAP” what is probably going on is the app is using the trick of making an authentication with IMAP then immediately sending mail from the same IP. That was an antique method of authentication that used to be supported by some email clients. Exchange has no equivalent and even when that option was supported it was done by hacks on the back end (Linux scripts and the like)
I would bet money your Oracle app can be configured to just anonymously relay. You have a lot of work in reviewing your apps ahead of you to get away from kludges like what I described. You also have a lot of work migrating from O365 to self-hosted Exchange server. Personally if I was consulting for your company I would say if you have more than 80 users it’s cheaper to run Exchange than o365 so that is the criteria that the decision needs to be made on – but no matter what, you are going to have a lot of work, and a lot of problems ahead of you before email gets smoothed out. Going to Exchange isn’t going to “reduce issues” If your goal is to “reduce issues” then go back to typewriters.
Hi,
Why we use front end connector for anonymous? Generally, we use the anonymous connector for internal purposes where the application can’t authenticate and usually all recipients are inside the organization.
When we use front end connector all messages go to the transport front end service and then to transport service and mailbox transport. Front end can’t communicate directly with mailbox transport.
When we use Hub connector to anonymous: messages go directly to the transport service and then to mailbox service so it is a shorter process then if we use front end connector. What is the benefit of use front end connector?
Hi Paul,
Excellent post!
I was just wondering, if the Default Frontend connector was meant for internal relay only, why do they put “ms-Exch-SMTP-Accept-Any-Recipient” on it? I checked it both on Exch2013 and on 2019 and it’s the same on both.
Also if you manually create any receive connector, you will get by default the “ms-Exch-SMTP-Accept-Any-Recipient” when you add for example Exchange Servers/ Externally Secure Servers groups. Is this by design? Why? If you need that connector for internal recipients only, would that mean you would have to remove “ms-Exch-SMTP-Accept-Any-Recipient” manually?
Hi,
interesting article. I find it particularly interesting that you do all your testing whilst including a subject-line. Have you noticed that Exchange SMTP relay strips the first paragraph / section of the message body when you do NOT include a subject line…?
Any idea how that behavior can be disabled? The use of a Subject line is NOT a requirement for SMTP messages so why is Exchange not conforming to the standard?
Great article once again,
So in resume any hint / suggestion about how to block authenticated service accounts / users on port 587 from sending email as another valid internal email address?
We´re just trying to minimize as much as possible any kind of internal spoofing alternatives.
Thanks in advance.
Thanks for the article. We recently migrated to Exchange2016 and mail flow is working from Outlook, OWA, and smartphones but forgot about a server needing to send email.
Followed this article and now mail is flowing from the server, thanks.
Hello Paul,
In my hybrid environment there are 2 mail server : 2016 on premise exchange server and office 365.
I want to configure the inbound mail flow in on premise exchange server like : internet>Mimecast> on-premise sever 2016.
AND
I want to configure the inbound mail flow on 365 server like : Internet>Mimecast>eop>office 365.
Note : my on premise inbound mail should not route from eop it directly route from mimecast to on premise exchange server what kind of settings i need to do.
Please suggest.
Hi, on Exchange 2010, we have to tick the Externally Secured checkbox under the authentication tab for external SMTP relay.
For Exchange 2016, do we still need to tick the Externally Secured checkbox?
Thanks.
No. You shouldn’t have had to do it on E2010 either. If you had to that meant you had something screwed up in your configuration. You probably have too many receive connectors defined and your config is too complex, with unexpected overlaps that the server can’t figure out.
According to Microsoft, yes you have to use “externally secured” of you want to relay externally. Internally it will work with TLS
https://docs.microsoft.com/en-us/exchange/mail-flow/connectors/allow-anonymous-relay?view=exchserver-2019#step-1-create-a-dedicated-receive-connector-for-anonymous-relay
Hi Paul,
meanwhile i’ve already benefit a lot from your competence/articles – thank you very much this way.
I’m administering a big enterprise hybrid infrastructure and again and again i’m struggling with one question regarding relaying with Exchange:
Is there any possibility to relay via authenticated connection without having exchange verified the sender address’ access rights for mail sent ?
Simply stated: Any internal application get access to SMTP relay with userxyz+pw but sending address is various. Is there really no other way than 1. upgrading SMTPAuth-user with EXO-license and 2. add this account to every mbx for sendas access ? Adding extended access rights to permission group (here e.g. “ms-exch-accept-any-sender”) doesn’t help.
Any hint or idea is helpful i think. Becoming desperate on this topic xD
Thanks very much in advance 🙂
Tobias,
Did you figure this out? I don’t believe you’ll need to get an EXO license to achieve this, you only need an AD account with rights to the frontend and/or client proxy connector.
Regards,
JB
In these sorts of complex setups where defining static IP addresses is not good enough (some people allow printers to “float” via DHCP and use the printers mac address with the vendor software that can tolerate this) I generally run VirtualBox or HyperV on a convenient server and then run a copy of FreeBSD or Linux on that with a static IP, and setup authenticated SMTP on the Unix system and then use the userID/password on that server. Exchange isn’t really good for this sort of thing. It prefers any authentication requests to come in from domain accounts. Some of the newer printers can do this but a lot of other older network gear and many programs fall down on the job. It’s easy to run webmin or something like that on the Unix box so the lesser admins (who are afraid of the command line) can manage the IDs in that system. And it also greatly enhances security because an attacker that grabs a domain account and steals the password can’t then use that to relay spam through the Unix box.
Paul, all great advises. My issue with exch 2016 is that we keep get blacklisted.
I have deployed a std exchange 2016, no much changes from default installation but it started a month ago getting blacklisted from some “modern” spam solution… talking about :
Misdirected Bounces or Misdirected Autoresponders or Sender Callouts
I’m confused. We are olny blacklisted on backscatterer.org
is your exchange behind an address translator that uses the same public IP for the rest of the network? If so you may have a spambot on one of those. Make sure your address translator/router only permits outgoing SMTP from the exchange server.
I meant to post: Set-ReceiveConnector “servername\connectorname servername”
As stated on your tutorial. I did not include -identity when configuring the cert.
This article will save my bacon shortly! Thanks for all the effort you put in here.
Im a little confused about this command, though.
Set-ReceiveConnector -Identity “servername\connectorname servername”
Gets me: The operation couldn’t be performed because object “servername\connectorname servername” couldn’t be found on (my DC)
if i use: Get-ReceiveConnector -Identity “servername\relayname”
I get a return value. What gives with the syntax on that command?
We added 2 new exchange 2016 hybrid servers for SMTP relay in office 365 environment . We got the smtp relaying to external and internal senders without any issues . But we are facing issues with Distribution list smtp relay mails.
When we send mail using internal application or telnet to on premise DL previously it will consider It as an internal e-mail address and send mail to recipients of the DL in old setup which was also an hybrid environment in different site.
But now mails are getting failed to DL with the error stating sender is not authenticated or don’t have permission . We would have allow external senders to relay mails to internal DL with internal applications .
Your inputs on this matter would be appreciated
Hi Paul,
Thanks for the great article. This covers things really well. We have another situation which I’m struggling to get working. We are in the process of locking down port 25 to only come from specific hosts. For anything else internally, we would like to only allow people to relay email externally if they authenticate against Exchange.
An application that we have has a global setting for SMTP where we can set a username/password for application. We have created a service account in AD (as well as a corresponding mailbox), however when testing it comes back with ‘550 5.7.60 SMTP; Client does not have permissions to send as this sender’. The service account has extended rights set as follows on the receive connector;
{ms-Exch-SMTP-Submit}
{ms-Exch-SMTP-Accept-Any-Recipient}
{ms-Exch-SMTP-Accept-Any-Sender}
Should this work without having to set send-as permissions on every account that sends mail through the application?
Thanks for the share Paul you’re mo “go-to” for technical Exchange information.
Just a note here if anyone wants to create a custom Application Relay Frontend receive connector to restrict internal smtp relays instead of allowing all internal relays via the default Front End connector but are currently running a DAG with two network adapters.
I have implemented DAG replication over a second Network Adapter over IPv4. If you are trying to restrict internal application relay by IP Internally when you have more than 1 network adapter you will need to specify the IP of your MAPI adapter instead of using “All Available IPv4 Addresses” for your scoping under “Network Adapter Bindings”.
I didn’t see a lot of examples on this scenario so i figured i would share my solution after some hours of troubleshooting the relay.
Cheers,
Marc Tremblay
I’ve placed exactly the same question now 🙂
Dealing with exactly the same topic but i’ve still no idea how to implement it resp. work around those sendas access rights.
If you had any new insights there i would be glad you share it 🙂
Thanks in advance and good luck !
Andrew,
I had the same issue. If you look at the logs, you should see that your custom frontend connector is accepting the message… but then rejected after being passed to the (default) client proxy connector. I was able to get this working by adding the same extended rights permissions to the client proxy connector.
The only issue with doing that is that sending servers can send directly to the client proxy connector (via port 465) and it makes the custom frontend connector (which limits by IP) moot.
Regards,
JB
Hi Paul,
This is a really good article, but how the receive connecter decides whether it will relay email to an external recipient is still unclear to me.
When you first show External SMTP routing (and your example where it fails), you say:
“The receive connector will not allow an anonymous, unauthenticated sender to relay to external domain names….”
How does this work? I find nothing in the Receive Connector that would specify which type of user can route externally, and “Anonymous Users” is checked by default under permission groups on the “Default Frontend ” connector. Also: there is nothing I see in the receive connector that addresses the outgoing address, only the incoming connection.
The error message says “Unable to relay recipient in non-accepted domain” – so is this true because you’ve also defined “Accepted Domains” in the mail flow section of Exchange Admin Center? If so: such configuration seems to be missing in this article. Even so – i’m still stumped with why an authenticated user can route outside, but an anonymous user cannot.
Does this have to do with an outbound connector? a send connector? What am I missing?
Hi Paul,
I have a question:
In case an application resides outside the network and wants to smtp relay through the exchange server, do i need to specify the application server “Gateway IP address” in the Remote network settings, and removing the “any”.
Pingback: Evergreen Traffic Academy
I can;t seem to get it to work with authentication on my 2016 exchange server
When I try to run the last command, I get Authentication failed because the remote party has closed the transport stream. I tried over and over.
Pingback: report writing formats for students
Ran into an issue on recent deployment of Exchange Server 2016 on Windows Server 2016 while trying to run the second command for an unauthenticated SMTP relay. More specifically, when I ran:
PS> Get-ReceiveConnector “\SMTP Relay” | Add-ADPermission -User ‘NT AUTHORITY\Anonymous Logon’ -ExtendedRights MS-Exch-SMTP-Accept-Any-Recipient
I got the following:
The pipeline was not run because a pipeline is already running. Pipelines cannot be run concurrently.
+ CategoryInfo : OperationStopped: (Microsoft.Power…tHelperRunspace:ExecutionCmdletHelperRunspace) [],
PSInvalidOperationException + FullyQualifiedErrorId : RemotePipelineExecutionFailed
The fix was to encapsulate the ExtendedRights in quotes as well. For example:
PS> Get-ReceiveConnector “\SMTP Relay” | Add-ADPermission -User ‘NT AUTHORITY\Anonymous Logon’ -ExtendedRights ‘MS-Exch-SMTP-Accept-Any-Recipient’
Hi Paul
Can you please tell me the Default Setting of this command.
$rc | % {Set-ReceiveConnector $_.Identity -ProtocolLoggingLevel Verbose -Banner “220 $_”}
I Need to set the Default Settings.
Thanks André
Thanks a lot Paul.
We have one doubt here, if we configure anonymous external relay, is there a way to mention accepted / sender domain to be our domain only (like we mentioned accept any recipient AD permission -ExtendedRights MS-Exch-SMTP-Accept-Any-Recipient). With anonymous relay we can mention any sender (eg. sender@hotmail.com)
The Real Person!
The Real Person!
Nothing that I’ve seen documented or that works. But if you only want them to send email to internal domains, you don’t need to set up a special connector for that.
Thanks Paul.
We tried below command.
Get-ReceiveConnector “Server1\Ext Relay SERVER1” | Remove-ADPermission -User ‘NT AUTHORITY\Anonymous Logon’ -ExtendedRights MS-Exch-SMTP-Accept-Any-Sender
And kept only 3 permissions (SMTP_Submit, Accept-Any-Recipient & ms-exch-smtp-accept-authoritative-domain-sender )
With a test receive connector everything worked fine, it accepted mails only from (MAIL FROM:) authoritative domains. But later once we created the production receive connectors it’s accepting any domains
Can you help to correct the issue
The Real Person!
The Real Person!
Like I said, I haven’t seen any solution that works.
This is impossible by definition. A spammer can forge an internal domain name on an anonymous external relay. There is no possible way an anonymous relay can only relay “inside domain only” unless it does it with an IP block filter. But without a filter, anyone on the Internet can forge whatever they want and it will relay. This ISN’T an Exchange issue it’s a fundamental misunderstanding of email protocols and securing the mailserver.
Hello Paul, I believe you got a lot of error “554 5.7.1 Relaying denied”. Using telnet I can send external email from the exchange server and from my own computer but from other servers it doesn’t work, I always get Relaying denied. On relay configuration, scoping, I have entered the server ip address and the full network (10.0.0.0/24), but it didn’t fix the problem. Do you have any thoughts on it? Anyway, Thank you for all you help and guides, they are awesome.
The Real Person!
The Real Person!
There’s no setting called “scoping” so I’m not sure where you’re putting those IP addresses. I suggest you go back through the entire tutorial and make sure you haven’t skipped any steps. There is also troubleshooting tips in the tutorial using protocol logs if you’re still stuck.
Hello Paul, sorry my delay, I gave up for a bit. Scoping I meant on ECP/mailflow/receive connector, relay name, edit,then you have scoping (3rd option on the left side), where you add *remote network settings, bind adapter and FQDN. The weird thing is that I have 2 server in a DAG, my primary server does not send email relay, however the secondary server sends. on the application that will send email using relay, if I use fqdn like mail.domain.com it does not send email, but if I point the application to the secondary server, like exch-server-02.domain.com it sends. again. Any thoughts, direction is deeply appreciated! thank you very much.
Hi Paul, so we have 2 toshiba studios scanners than we scan and email out. they were both fine on the old email 2010 exch server, they both are not working on the new exch 2016 server, getting a comm error when scanning and emailing outside. any ideas would be helpful !!!!!!!!!
Thx
The Real Person!
The Real Person!
Have you followed the steps in the article? What testing and troubleshooting have you already done?
outstanding, it works
HI Paul,
I have followed ur great article to setup Authenticated Relay and when I try to Send Email using 587 I am getting the Error :550 5.7.54 SMTP; Unable to relay recipient in non-accepted domain
I am able to relay on Port 25 to External recipients, however when I test with my Applications on Port 587 it fails.
The Real Person!
The Real Person!
Did you configure the relay connector for port 25 or port 587? There is already a connector on port 587 for authenticated SMTP connections, if that’s what you’re trying to use.
Hi Paul,
I have a hybrid environment with two CAS servers connected to exchange online behind a load balancer. The hybrid configuration ran successfully. Mail flow between on-prem and exchange online are working; however, exchange online mailboxes are not able to relay through on-prem exchange servers. The exchange online users get “An SMTP error code “550 5.7.54, Unable to relay recipient in non-accepted domain” Shouldn’t the connector configured to work properly by hybrid configuration wizard?
Mail flow is centralized through the on-premise exchange servers array behind a VIP on the F5.
The Real Person!
The Real Person!
Does it work if you bypass the load balancer for hybrid mail flow?
Hi Paul
I have a new exchange 2016 edge server I want to move services to.
I cant use edge subscription and have followed MS tech net article how to do so without EdgeSync
How ever I am getting the error “550 5.7.54, Unable to relay recipient in non-accepted domain” when external points to new exchange as well as when internal try’s to email out.
Any ideas where I have gone wrong?
Thank you
The Real Person!
The Real Person!
Sounds like you haven’t configured the accepted domains on the edge server.
Thanks Paul answer was right in front of me :/
This article is just what I was looking for. However, I’m having trouble making my external SMTP Relay with Exchange Server 2016 Using Authentication work. I carefully followed your instructions and when testing a Send-Message I get the error “5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM”. I verified I entered the right credentials but still get this error. Any help will be greatly appreciated.
Hi.
I have the same problem
Did you solve it ?
Thanks a lot
Hi Paul,
When receiving mail on my connector in Exchange 2016 to a public folder. The from name is shown only as the e-mail address.
When receiving on an exchange 2010 connector it displayed the Display Name of the user.
One difference I found was that now on exchange 2016 I have
X-MS-Exchange-Organization-AuthAs: Anonymous
On 2010 I had
X-MS-Exchange-Organization-AuthAs: Internal
Can I make a setting on the relay so that it translates known users as Internal?
The Real Person!
The Real Person!
Your 2010 connector probably has the checkbox ticked to treat the emails as authenticated, and the email gets resolved in the address book. The 2016 connector (if you followed my instructions above) treats them as anonymous.
IMO it’s better to treat them as anon, but if you want to treat them as authenticated its the “Externally secured” option in the security settings of the connector that will do that.
As always, test to make sure you don’t end up with an unintended outcome.
Hallo.
I have the same problem
Did you solve it ?
Thanks a lot
I continually reference and use many of your Exchange 2016 articles to get through the HELL that is called setting up Exchange! 🙂
In any case, just wanted to say THANK YOU for writing these. They are very easy to understand, and very informative.
If I could send you a virtual bottle of wine, I would!
we have configured exchange server 2016 as an SMTP server, we are sending mail as an authenticated user, not able to send mail more than 5.
application was able to send unlimited mails successfully with 2007 but limiting to 5 with exchange 2016 smtp relay.
please respond.
The Real Person!
The Real Person!
Google “Exchange 2016 throttling” to read about the default throttling that is configured on an Exchange server. You can increase thresholds if necessary.
Devices which are sitting in internet (out side of my corporate network) have to send email notification using Relay connector.
What is the best approach for this.
We are having Hybrid setup with Exchange Online Protection.
The Real Person!
The Real Person!
Set up an SMTP relay for them to use. You can either use the on-premises server, or use Exchange Online. Or use a different SMTP server that you host in your DMZ, or use an external SMTP service like AWS SES, Mailgun, Mandrill, etc.
Hello, Incredible Guide …
I have a problem, perform all the steps but in my organization we send mail through Java with non-US characters and the mails arrive but with strange characters instead of what should be … Any suggestions on how I can configure the charset For emails to arrive in the proper format …
I configure with Set-RemoteDomain, and configure charsets to UTF-8 and only I get that the mails arrive well inside the organization, doing with Telnet only arrive well if I start the STMP conversation with Helo, when using ehlo the mails arrive badly they are sent inside Or outside the organization …
Thanks for your time…
Paul,
I have followed your document and confirmed via telnet that my server is accepting anonymous connections to the new receive connector. However, it appears that the email is getting blocked by the default content filter and immediately sending out a 550 error. The funny thing is we can send email via this method to those outside of our domain using the same receive connector. Kinda stumped. Any ideas?
The Real Person!
The Real Person!
I think you should stop using the anti-spam agents.
http://www.expta.com/2017/03/how-to-uninstall-antispam-agents-on.html
If you don’t want to do that, set up a bypass for the email address(es) that are sending email via that connector.
Would it be possible to add how to do this to the article?
We ran in a very specific problem, where our Protection declines the E-Mails from a service but does not leave a record of this event and the only solution left is to create a bypass, but sadly i cannot find any information on how to do that for outgoing mails, only the incomming ones..
Thanks again Paul for a great article,
Default is that it doesn’t allow to relay to non accepted domains. This mean that spammers can still send to internal recipients or those in accepted domains.
Can we disable relay to internal domains (accepted domains) as well?
Thanks!
The Real Person!
The Real Person!
No, that’s how regular email is received as well. If you’ve got a spam problem then you need to deploy an anti-spam solution.
I ran into an issue today where adding an allowed IP address in the “receive mail from remote servers that have these IP addresses” section didn’t actually allow our Exchange server to receive connections on port 25 from those newly added IP addresses until I restarted store.exe.
Is this expected behavior?
The Real Person!
The Real Person!
No, nor does it make sense to me that the store service would need to be restarted for a transport config change.
Is it me or in 2016 shouldn’t it be:Add-ADPermission -User ‘NT AUTHORITY\Anonymous Logon’ -ExtendedRights MS-Exch-SMTP-Accept-Any-Recipient
instead of
Add-ADPermission -User ‘NT AUTHORITYAnonymous Logon’ -ExtendedRights MS-Exch-SMTP-Accept-Any-Recipient
Missing \ between NT Authority and Anonymous
Hi Paul,
Recently i have migrated from Exchange 2010 to Exchange 2016CU4 with DAG in Windows 2012R2 Standard Edition. I have followed this https://www.practical365.com/exchange-server/exchange-2016-smtp-relay-connector/ to configure the External Relay Connector still i am facing the 550 5.7.54 smtp; unable to relay recipient in non-accepted domain error while sending error. I am using the DNS round robin and i configured the load balancing Round Robin in the Firewall. Still i am facing the error. How to fix this issue?
Thanks,
I got almost the same error as Jose above:
Cannot process argument transformation on parameter ‘TlsCertificateName’. Cannot convert value “<i>CN=Go Daddy
Secure Certificate Authority – G2, OU=http://certs.godaddy.com/repository/, O=”GoDaddy.com, Inc.”, L=Scottsdale,
S=Arizona, C=US<s>CN=webmail.ramahberkshires.org, OU=Domain Control Validated” to type
“Microsoft.Exchange.Data.SmtpX509Identifier”. Error: “”<i>CN=Go Daddy Secure Certificate Authority – G2,
OU=http://certs.godaddy.com/repository/, O=”GoDaddy.com, Inc.”, L=Scottsdale, S=Arizona,
C=US<s>CN=webmail.ramahberkshires.org, OU=Domain Control Validated” isn’t a valid Certificate Identifier.”
+ CategoryInfo : InvalidData: (:) [Set-ReceiveConnector], ParameterBindin…mationException
+ FullyQualifiedErrorId : ParameterArgumentTransformationError,Set-ReceiveConnector
+ PSComputerName : crb01.ramah.local
Paul,
I’m following the “External SMTP Relay with Exchange Server 2016 Using Authentication” guide and receive the following error when I Set-ReceiveConnector
Cannot process argument transformation on parameter ‘TlsCertificateName’. Cannot convert value “<i><s>” to
type “Microsoft.Exchange.Data.SmtpX509Identifier”. Error: “”<i><s>” isn’t a valid Certificate Identifier.”
+ CategoryInfo : InvalidData: (:) [Set-ReceiveConnector], ParameterBindin…mationException
+ FullyQualifiedErrorId : ParameterArgumentTransformationError,Set-ReceiveConnector
+ PSComputerName : lab1-svr3.domain.local
Have you seen this error before? Thank you for all you do.
Sorry I copied the wrong error, here is the correct error
Cannot process argument transformation on parameter ‘TlsCertificateName’. Cannot convert value “<i>CN=Go Daddy
Secure Certificate Authority – G2, OU=http://certs.godaddy.com/repository/, O=”GoDaddy.com, Inc.”, L=Scottsdale,
S=Arizona, C=US<s>CN=mail.bugwerx.com, OU=Domain Control Validated” to type
“Microsoft.Exchange.Data.SmtpX509Identifier”. Error: “”<i>CN=Go Daddy Secure Certificate Authority – G2,
OU=http://certs.godaddy.com/repository/, O=”GoDaddy.com, Inc.”, L=Scottsdale, S=Arizona,
C=US<s>CN=mail.bugwerx.com, OU=Domain Control Validated” isn’t a valid Certificate Identifier.”
+ CategoryInfo : InvalidData: (:) [Set-ReceiveConnector], ParameterBindin…mationException
+ FullyQualifiedErrorId : ParameterArgumentTransformationError,Set-ReceiveConnector
+ PSComputerName : lab1-svr3.bugwerx.local
Hi Paul
Very informative Post. Thanks a lot.
Paul, Love your website. Thanks for all you do. We recently migrated from 2010 to 2016 and thanks to you the migration has been fairly uneventful. One issue I am having is when I create receive connectors the Exchange FrontEndTransport service won’t start after I reboot the server. If I disable the receive connectors the service starts and external mail flows as normal.
I created the connectors with Powershell and they are all FrontendTransport connectors not HubTransport. Any help is much appreciated.
The Real Person!
The Real Person!
The most likely cause is a port conflict. Are the custom receive connectors configured a port other than 25?
You can also check the event log for more info on what’s causing the service to fail to start.
Hello Paul,
Can you please let me know how to disable the anonymous relay?
Dilshan
The Real Person!
The Real Person!
If you’ve created a custom receive connector, you can disable the connector or delete it entirely.
I followed article section “EXTERNAL SMTP RELAY WITH EXCHANGE SERVER 2016 USING AUTHENTICATION” to configure default client frontend connector ERVERNAMEClient Frontend SERVERNAME. So everyone can send email outside now. I just need to stop it. Please advice
If you want to use STARTTLS via 25 instead of 587 is it safe to change the FQDN on the Default Frontend Connector or do you recommend creating a new connector and setting the FQDN to the namespace in your cert?
The Real Person!
The Real Person!
“Unable to relay recipient in non-accepted domain”
Well that’s a clue I guess. Are you sure the connections are being handled by the correct receive connector? Turning on protocol logging and looking in the receive protocol logs should help you identify if that’s the issue.
Not sure why you’re using port 1501 either.
Hi Paul,
Your article is excellent. We recently deployed our Exchange 2016 server and copied the External Mail Relay connector from the old Exchange 2013 server. The settings are exactly the same “anonymous users, port 1501, IP address of the server we allow relay from” but relay continues to fail on 2016 server with 550 5.7.54 SMTP; Unable to relay recipient in non-accepted domain. Is there anything else you can suggest we try for troubleshooting this problem?
Hi Paul.
Thank you for the excellent article.
I have configured both authenticated and anonymous relay. Authenticated relay fails with error ” 5.7.60 SMT, client does not have permissions to send as this sender. Not sure what I am missing from your steps. Your advice to for troubleshotting steps is highly appreciated.
Thank you
Sonam
The Real Person!
The Real Person!
Sounds like you’re trying to send as an address that the account doesn’t have permissions to send as. If you’re using authenticated SMTP, the credentials you use either need to own the mailbox that has that From email address, or have permissions to send as the user it is impersonating.
Hi Paul, does it mean the account has to have an Exchange Mailbox? Or can it be just an AD user that will have send-as on other user? Thanks a lot
The Real Person!
The Real Person!
Just the AD permissions I believe.
First of all thank you Paul thank you for all of your fantastic articles you write. You just seem to have a way to teach it explain it from others that makes is some much easier to understand so thank you! One item on the above am I not quite 100% sure on is this: Your example to allow anonymous external relay are you adding the exchange server of 192.168.0.30 in the remote network settings page or is that IP the IP of the device you want to be able to relay? I am confused on that part – I guess I was thinking in that screen you enter the IP/IP Range of the devices (printers, scanners, etc.) you want to able to send out to the Internet. Can you clarify more for me please. And also, the two PS commands you have to run after that can you not configure those settings within the ECP under the security settings/properties of that Receive Connector? Thank you Paul
The Real Person!
The Real Person!
Remote IPs are the addresses you want to allow relay from.
No you can’t configure the settings in the ECP.
So sorry to need clarification again – so would that be my exchange servers or the servers that need to relay?
The Real Person!
The Real Person!
Not your Exchange servers.
Try to create a new receive connector for anonymous users but unable to select the “Frontend Transport” role, the role pre-selected “Hub Transport” and it’s grayed out.
Any suggestion?
Thanks
The Real Person!
The Real Person!
There’s a bug that comes up in some environments where the options are greyed out. The solution is to use PowerShell to create the connector instead.
Thank you for this excellent article on relay settings. We are getting ready to migrate from an open source/ postfix based email system to Office 365/Exchange Online, and we’ve got a great number of servers running services that will require internal relay. Since the new Exchange server will be in the cloud, does this mean that I will continue to need having a local relay server on our private network, and I’m wondering how I would set this up on the Exchange server? Would I continue to use our current postfix relay server, or would it be better to set up a local Exchange server for the relay?
Thanks!
Mark
I forgot to mention that i have single server installation and no Edge server.
Maybe Edge server would do all the things I’m looking for?
Hello, Paul!
I have couple of probably very basic questions as I’m only learning Exchange but they are &%^$ important.
In other mail servers like Kerio, MDaemon etc you have simple checkbox:
“User must authenticate in order to send from local domain.”
But i could not find anything similar to this in Exchange.
The idea is: Internet->SMTP Frontend transport->…
Spamers can send mail from: domain_user@mydomain com rcpt_to: domain_user@mydomain.com
Normally other mail servers would say that if you want to send from internal user to internal user using internet facing smtp you should authenticate.
In exchange default install you can even send email from non-existent_user@mydomain.com rcpt to: domain_user@mydomain.com
Question.
What to do to prevent receiving spam from “local” users? SPF is nice thing of course, but i cannot enforce SPF on all incoming traffic as there are a lot of domains that don’t have SPF defined.
How to prevent sending from non-existent_domain users to existing domain users?
Thanks
any answers on this ?
Hi Paul
I am experiencing delays in sending emails out.
I found out that our exchange server is identified with it’s internal fqdn and ip…
This may have happened because of a wrong definition of the send connector, or something else which is not defined correctly.
The configuration is like this:
The exchange “farm” has two exchange servers 2016 (DAG), two AD DCs, and a witness server.
The majority of the users are on an RDS cloud farm, which is in the same subnet and is considered “internal” and users are using Outlook 2013 SP1
I thought that I could use internal separate to external sending method.
I assume that I’m lacking some knowledge but I think that part of our problem is that the server is identified by it’s internal ip and fqdn.
Your help will be appreciated.
Hi Shimon,
Did you find an solutionfor for your problem?We have the same problem.
Your help will be appreciated.
Hi Paul,
described also on this post (http://serverfault.com/questions/693987/exchange-server-2013-receive-connector-confusion) I’m also confused wit my new Exchange 2016 system enviroment.
With your perfect article here I understand more abaout the new EC, THX.
For me it looks like a inbound mail gateway connector, as in the past (Exchange 2010).
But I dont understand the reason and how I can setup more security to the “Default Frontend” EC?
Goal is to “allow only authenticated users NOT anonymous users” to send messages on port 25 (not 587) to accepted smtp-domains, since I can not restrict this, because this “Default Frontend ExNode” connector should remain unchanged!?!
For Example
Sending to Exchange 2010 ExNode on Port 25:
$Cred = Get-Credential # Feak Credential Input
Send-MailMessage -SmtpServer ‘Ex2010Node@domain-tld’ -From ‘NoName@domain.com’ -To ‘MySmtpAddress@domain.local’ -Subject ‘SMTP CHECK’ -Body ‘HuHu’ -Credential $Cred
#
Result >> “5.7.1 Client was not authenticated”
Sending to Exchange 2016 ExNode on Port 25:
$Cred = Get-Credential # Feak Credential Input
Send-MailMessage -SmtpServer ‘Ex2010Node@domain-tld’ -From ‘NoName@domain.com’ -To ‘MySmtpAddress@domain.local’ -Subject ‘SMTP CHECK’ -Body ‘HuHu’ -Credential $Cred
#
Result >> “Successful” no Error
I know that I can set up additional connectors with IP’s or ranges, but how can I limit the “Default Frontend” EC on port 25 access from the entire internal network?
Thanks in advance for an answer.
Sending to Exchange 2016 ExNode on Port 25:
$Cred = Get-Credential # Feak Credential Input
Send-MailMessage -SmtpServer ‘Ex2016Node@domain-tld’ -From ‘NoName@domain.com’ -To ‘MySmtpAddress@domain.local’ -Subject ‘SMTP CHECK’ -Body ‘HuHu’ -Credential $Cred
Very well written article, thanks heaps sir!
Hi Paul,
Have you done anything with message throttling in Exchange 2016? One of the biggest challenges we’ve been unable to overcome so far is it seems like throttling doesn’t take place at all on the frontend transport but all frontend transport connections are routed via the two default hub transport receive connectors. If you up the rate limits on the default hub transport receive connectors you up the rate limit for all frontend transport receive connectors and it doesn’t seem like you can scope to IP through the hub transport.
Hi,
I have problem to connect my Iphone to Exch2016. User verification and connect is OK but can’t read mail. OWA works
Excellent article and in detail, as always from Mr. Paul