Features to warm up IP address

Questions
1

Your question

Hi,

I’m trying to be a good email citizen and warm up my new mail server.

There are two main features I’m looking for on stalwart and I haven’t yet:

throttle the number of email sent per mx

This is a friend’s solution for postfix.

  https://code.mayfirst.org/mfmt/triptick

this does throttle how many emails can me sent to the same provider (mx) over a period of times, and optionally automatically increase it

 --interval string
      The minimum time between sending messages that, when exceeded, should
      trigger the fallback, e.g. send no more than one message every 3s, 10m,
      5h, etc. If empty, trigger on all email, subject to --mx.
  --half-life string
      How often the interval argument will be halved, e.g. if the initial
      interval argument is 1h and the half-life is 1d, the interval will change
      to 30m after 24 hours, 15m after 48 hours, etc until it reaches 50ms at
      which point it will stop halving.

Is there something similar on stalwart, either built in or as an external hook?

handling errors

most providers seems to alert when your IP address is sending too much

Yahoo TSS04: e.g. 421 4.7.0 [TSS04] Messages from temporarily deferred due to unexpected volume or user complaints - 4.16.55.1; see Ihre Datenschutzeinstellungen
Microsoft S775: The mail server [X.X.X.X] has been temporarily rate limited due to IP reputation. For e-mail delivery information, see Announcements (S775) [Name=Protocol Filter Agent][AGT=PFA][MxId=11BCD7A8383E2981] [AM1PEPF000252DC.eurprd07.prod.outlook.com 2026-02-24T07:17:38.549Z 08DE6BD4292A78FC]
Microsoft: S3150: 550 5.7.1 Unfortunately, messages from [x.x.x.x] were not sent. Please contact your Internet service provider since part of their network is on our block list (S3150).

Is there an easy way to identify these 4xx defer errors and adjust the route/throttle accordingly?

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

Let me research what Stalwart offers for outbound throttling and rate limiting.

Here is what Stalwart currently offers for IP warm-up, and where the gaps are.

1. Throttling sends per MX / recipient domain

Stalwart has built-in outbound rate limiting (MtaOutboundThrottle) that can scope a rate to the mx hostname, rcptDomain, or other keys. When the limit is reached, messages are not dropped – they stay in the queue and resume when the window resets. Example (25 messages per hour per recipient domain):

{
  "enable": true,
  "description": "Per recipient domain warm-up throttle",
  "key": ["rcptDomain"],
  "match": {"else": "true"},
  "rate": {"count": 25, "period": "1h"}
}

You can also key on mx instead of rcptDomain if you want to limit at the MX-host level, or combine multiple keys. These throttles are configured in the WebUI under Settings › MTA › Rates & Quotas › Outbound Rate Limits.

However, there is no built-in “half-life” / automatic ramp-up like triptick offers. You would need to manually update the rate values over time as your IP warms up. There is no external hook that automatically increases limits based on elapsed time.

2. Handling 4xx deferrals from providers (Yahoo TSS04, Microsoft S775, etc.)

When a remote server returns a 4xx temporary failure, Stalwart automatically retries the message according to the retry schedule configured on MtaDeliverySchedule. By default this follows a back-off pattern (2 min, 5 min, 10 min, 15 min, 30 min, 1 h, 2 h…). You can customize the intervals with a Custom variant on the retry field.

What Stalwart does not currently do automatically:

  • Parse a specific 4xx response body (e.g. “TSS04”) and dynamically tighten a throttle or switch routes in response.
  • There is no built-in mechanism that reads a 421 4.7.0 [TSS04] and says “reduce rate to this MX for the next N hours.”

The queue will surface these as TemporaryFailure with DeliveryErrorType: unexpectedResponse in the queue status, visible via the WebUI or JMAP API, but the adaptive response logic you are describing is not a built-in feature.

In short: Stalwart gives you the building blocks (per-MX/per-domain rate limits, configurable retry schedules), but the automated warm-up ramp-up and the “auto-tighten on 4xx” logic that triptick provides are not yet built in. A human can follow up on whether there are plans for this or workarounds via the scripting/hook system.

Relevant docs:

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

Partly. You can rate-limit outbound delivery per destination MX: configure an outbound throttle (Settings, MTA, rates and quotas) with the key including mx and a rate of N messages per period. That caps how fast you send to a given provider, which is the core of a warm-up.

What isn’t built in is an automatic ramp that increases the rate over days on its own; the throttle is a fixed configured value, so you’d raise it manually as you warm up. Stalwart already honors temporary 4xx/421 deferrals with its retry and backoff schedule, but it doesn’t parse provider-specific codes (Yahoo TSS04, Microsoft S775, and so on) to auto-adjust routing or throttles; you’d tighten the throttle for those MXes yourself, or drive it externally from the delivery trace events/webhooks. So the building blocks are there for a manual or externally-scripted warm-up, just not a turnkey adaptive one.