Exchange 2016: tarpit event in SMTP-logs

Question

Exchange 2016: tarpit event in SMTP-logs

Евгений Котляревский 81

Hi!
We have an Exchange 2016 server with some custom receive connectors. Also we have our enternal application which send mail messages via one of these receive connectors.
And we have an issues from application, not all messages are sent the first time. Sometimes they are sent the second time, and sometimes the fifth time.
At SMTP receive logs I see corresponding events like:

Tarpit for '0.00:00:05' due to 'IP discredited'

and than
Remote(SocketError)

I believe this is due to some kind of limits or throttling within the Exchange. But which of them exactly? I'd like to do some tuning but I don't know what settings should I change?

Which Exchange limit is responsible for this?

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Hi @Евгений Котляревский

Based on your description, I understand you are running an Exchange Server 2016 environment where an internal application sends automated emails via a custom receive connector. However, some messages fail on the first attempt and require multiple retries to send successfully. Your Exchange SMTP receive logs specifically reveal the following events:

Tarpit for '0.00:00:05' due to 'IP discredited'
Remote(SocketError)

The specific limit responsible for this behavior is the TarpitInterval on your Receive Connector, not MessageRateLimit or connection throttling rules. In Exchange Server, tarpitting is an anti-abuse mechanism that intentionally introduces a delay in processing SMTP responses for unauthenticated connections that trigger protocol errors or rejections (such as trying to send to non-existent internal mailboxes or attempting to relay to external domains without permission).

Every time your application hits a protocol restriction, Exchange adds "bad points" to that source IP. Once a threshold is breached, Exchange flags the IP as "discredited" and penalizes it with a 5-second artificial delay (the default TarpitInterval). Because many internal applications are not built to gracefully wait out a delayed socket response, your application times out mid-execution, throwing a Remote(SocketError) and forcing a retry.

-If this is a dedicated connector handling trusted internal traffic, you can disable the artificial delays.

Open the Exchange Management Shell (EMS) and run the following commands:

# 1. Identify your exact connector (verify using the 'connector-id' field in your SMTP log)Get-ReceiveConnector | Format-Table Name, TarpitInterval, RemoteIPRanges, Enabled

Warning: Only disable this feature on connectors strictly bound to trusted internal servers via the RemoteIPRanges attribute. Never disable tarpitting on Internet-facing or default anonymous public connectors.

-Disabling the tarpit stops the 5-second delay, but it doesn't fix whatever error originally caused Exchange to discredit the IP. To fix this permanently, review your connector's properties:

$conn = Get-ReceiveConnector | Where-Object {$_.Name -like "*YourApp*"}   # Adjust filter$conn | Format-List Name, Enabled, TransportRole, Bindings, RemoteIPRanges, AuthMechanism, PermissionGroups, TarpitInterval

Ensure your application server's IP is explicitly defined in RemoteIPRanges. If your application needs to relay mail anonymously to external domains, ensure you have explicitly granted relay permissions to the anonymous logon group on that specific connector:

Get-ReceiveConnector "YourCustomConnectorName" | Add-ADPermission `

-If your application supports it, the most secure and modern configuration is to switch from an Anonymous SMTP Relay to Authenticated SMTP Submission:

Configure the application to connect via Port 587 using STARTTLS.
Pass dedicated service account credentials via SMTP AUTH.

Authenticated users bypass anonymous reputation tracking entirely, shielding your app from being marked as an "IP discredited" source.

When tuning, do not adjust these parameters first, as they handle separate volume throttling thresholds and are not the cause of an "IP discredited" log event:

MaxInboundConnection / MaxInboundConnectionPerSource
MessageRateLimit / MessageRateSource

Please refer to the official documentations for further deep dives into message handling mechanics.

https://learn.microsoft.com/en-us/Exchange/recipient-filtering-on-edge-transport-servers-exchange-2013-help

Receive connectors | Microsoft Learn

https://learn.microsoft.com/en-us/Exchange/mail-flow/message-rate-limits

I hope this information help.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click ""Comment"".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Michelle-N 20,735 Reputation points Microsoft External Staff Moderator

2026-07-07T13:59:54.7833333+00:00

Hi @Евгений Котляревский

Is there any update from you?

If yes, please feel free to let me know.
Евгений Котляревский 81 Reputation points

2026-07-07T14:23:39.6+00:00

Hi @Michelle-N !
Some details:

The receive connector used by App is available from internet. It is made for our another our services located at external locations.

The receive connector used by App is not enabled for anonymous relaying. only for authenticated connection.

This connector require starttls, no plain text

This connector is used to send messages to internal and external recipients.

IP Ranges is not configured on this connector.

So, given what I said above will it be an good idea to disable those artificial delays?
Michelle-N 20,735 Reputation points Microsoft External Staff Moderator

2026-07-08T13:15:04.6366667+00:00

Hi @Евгений Котляревский

Thank you for the update.

Based on what the logs show, the setting directly responsible for the visible 5-second delay is TarpitInterval, and if SMTP authentication failures are involved, it would also be important to review AuthTarpitInterval.

Successfully authenticated connections are generally not affected by TarpitInterval. Therefore, if this connector is intended for authenticated clients only, it is important to verify whether the application is actually authenticating successfully before the tarpit event occurs.

Microsoft also provides a separate AuthTarpitInterval parameter, which introduces a delay in responses to failed authentication attempts from remote servers that may be abusing the connection.

Because the Receive Connector is currently Internet-facing and has no RemoteIPRanges restrictions, I would not recommend disabling tarpitting on this connector. Instead, I would suggest the following:

Create a dedicated Receive Connector.

Restrict it to trusted source IP addresses.

Verify STARTTLS and SMTP authentication in the protocol logs.

Only then consider adjusting the tarpitting settings on that restricted connector.

This approach is generally safer and allows you to validate whether the root cause is related to authentication or connector configuration before reducing any built-in protections.
Michelle-N 20,735 Reputation points Microsoft External Staff Moderator

2026-07-09T13:52:38.4066667+00:00

Hi @Евгений Котляревский

Is there any update from you?

If yes, please feel free to let me know.
Евгений Котляревский 81 Reputation points

2026-07-10T10:43:32.1333333+00:00

Hi !
I've done some investigation, and found something you've been talking about: some time ago one of mailboxes our inernal application has been used was disabled, but this was not be reflected at App configs, and thats way in SMTP receive logs was auth errors. And this has causes tarpit delay.
Now App configs was corrected, and we don't see tarpit delays in log anymore. Thanks for you explanations in previous comments, it helped.
Your explanation about "tarpits" finally gave me a clearer understanding of this mechanism. Very appreciated that!
Michelle-N 20,735 Reputation points Microsoft External Staff Moderator

2026-07-10T10:47:03.29+00:00

Hi @Евгений Котляревский

Thank you for your update. If you have any other related questions, please let me know.