Released: PelNet v2.0
Published Aug 22 2014 06:33 AM 16.8K Views

EHLO Exchange community,

It seems that PelNet has been well received and I’ve been receiving requests to add much wanted functionality to PelNet. So this article is a quick update on some of the cool new features that administrators can use to help troubleshoot and validate mail flow.

The new features added in this release:

  1. Ability to test against multiple recipients – this is useful if you want to test to multiple external domains without having to run the tool again.
  2. Optimized remote execution against transport servers for better performance across a large amount of servers.
  3. The ability to validate if TLS negotiation is working. This is one of the most useful feature additions.

The above features gave birth to two new parameters validateTLS and CertThumbPrintOverride.

Let’s recap the parameters with the new ones introduced.

  • AddressSpace: Which AddressSpace should the script look for in the Send Connectors?
  • sendConnector: Specify if you want the scope to be a single Send Connector.
  • SourceTransportServers: Accepts comma separated list of transport servers to test from.
  • smartHost: The smarthost you want to test against. Accepts comma separated list value. (when validating TLS be sure to use FQDN of remote host – certificate validation will fail if IP is used)
  • mailSubmissionTest: Use this switch if you want the script to submit the mail to the mailbox. If you omit the parameter the script will skip the DATA portion of the SMTP verb.
  • From: From address (
  • Rcpt: Recipient Addresses –accepts comma separated list of addresses (,
  • LogFolderPath: Log file and report location, default will be current path if not specified.
  • Port: Default is 25, but you can specify a custom port if you need to.
  • validateTLS: This switch will enable TLS validation – this changes the SMTP verb array being used to include the STARTTLS verb (and some other more complicated stuff).
  • CertThumbPrintOverride: This allows the operator to override the logic used to determine the SMTP certificate assigned to the transport servers.

    This can also be used to test TLS to a specific host before assigning the certificate to the SMTP service in Exchange, i.e. pre-validations prior to production change. The certificate needs to be in the local machine certificate store.

    It’s important to note that the code logic uses best effort to determine the SMTP certificate assigned. Using the CertThumbPrintOverride parameter allows you to override this easily.

Script Execution Examples

Show the full help with examples

Get-help .\pelnet.ps1 -full

To test mail flow and validate TLS to a smarthost against all the transport servers on port 25 to multiple recipients. (Will not submit the message for delivery)

.\PelNet.ps1 -From -Rcpt,, -smarthost -validateTLS

To test mail flow and validate TLS to a smarthost against all the transport servers on port 25 to multiple recipients. (Submits the message for delivery and override the certificate to use)

.\PelNet.ps1 -From -Rcpt,, -smarthost –validateTLS –mailsubmissiontest –certThumbprintOverride 1A13124HJG1234K12JHG312J123D

To test mail flow and validate TLS to EOP from your hybrid servers on port 25 to multiple recipients (also submit the mail to EOP).

.\PelNet.ps1 -From -Rcpt,, -smarthost –validateTLS –sourceTransportServers E15HYBRID01,E15HYBRID02 -mailsubmissiontest

The TLS validation logic will authenticate against the remote server with the certificate assigned to SMTP or the certificate that matches the thumbprint used in the override parameter. If the remote host is configured with Opportunistic TLS and the handshake fails the session will fall back to unencrypted SMTP.

The console output won’t show the verb’s being sent as the code is invoking on multiple servers concurrently, but the final output table and output file will be exactly as previously described in PelNet 1.0.

From the below output:

STARTTLS verb being sent with server responding with 2.0.0 SMTP Server Ready and subsequent SSL Stream is established by authenticating against target host using certificate that matches thumbprint provided (or dynamically found using best effort).

Verbs being sent over SSL stream and successful recipient lookup.


The following is an example of a certificate validation issue on one server:


Some of the most common certificate validation errors are:

  • Certificate revocation list not found.
  • The remote hostname does not match the name on the certificate.
  • Certificate is expired.
  • The root certificate is not installed on the sending server, i.e. the server does not trust the remote certificate it received.

The above validation error was quickly fixed by installing the root certificate from the Contoso environment on the EX14- 02 server.

Until next time,

Michael Hall
Service Engineer
Office 365

Version history
Last update:
‎Apr 28 2020 02:20 PM
Updated by: