How do PowerMTA's retry-after, max-connect-rate, max-smtp-out, max-msg-per-connection, and max-msg-rate directives work?

Key findings

• Retry intervals: retry-after sets the minimum time before retrying a deferred email. Setting this too low (e.g., 1 minute) can be counterproductive and may be seen as an attempt to bypass ISP greylisting or throttling mechanisms. It is generally recommended to use longer retry intervals, sometimes even the default.
• Connection limits: max-smtp-out limits the total number of simultaneous outbound SMTP connections. This directive can be applied globally, per domain, or per virtual MTA. The max-connect-rate defines the maximum rate at which new connections are opened to a specific domain over a given time period (e.g., per hour or minute).
• Message throughput: max-msg-rate controls the total number of messages sent within a specific timeframe (e.g., 1000 messages per hour). max-msg-per-connection dictates how many messages are sent over a single SMTP connection before that connection is closed and potentially a new one is opened.
• Interconnectedness: All these directives work in concert. Misconfiguring one can affect the behavior of others and lead to unintended consequences, such as throttling or deliverability issues. For example, a high max-msg-rate might require a sufficiently high max-connect-rate and max-smtp-out to ensure messages are sent efficiently without being limited by connection availability.
• ISP sensitivity: Different Internet Service Providers (ISPs) have varying tolerance levels for connection rates and message volumes. For instance, Hotmail (Microsoft Outlook) is known to be particularly sensitive to aggressive connection attempts and high concurrent connections.

Key considerations

• Avoid aggressive retries: Setting retry-after to very short intervals, like 1 minute, can negatively impact your sender reputation and lead to throttling or blocks. Review common connection and message limits from major providers to align your settings.
• Balance connection and message limits: Adjust max-smtp-out, max-msg-per-connection, and max-connect-rate based on your sending volume, IP pool size, and the specific ISP you are sending to. For example, lower concurrent connections (e.g., 2-4) might be better for sensitive domains like Hotmail, especially with a single IP.
• Consider retry-recipients-after: This directive, which defaults to 10 minutes, sets the minimum recipient-level retry interval. It is important to consider its interaction with retry-after when configuring retry policies, particularly regarding soft bounce retry policies.
• Monitor and adapt: Continuously monitor your deliverability and adjust PowerMTA settings as needed. Start with conservative values, especially during IP warming or when sending to new domains, then gradually increase limits if deliverability remains good. Being listed on a blocklist or blacklist can also significantly impact deliverability.

Key opinions

• Aggressive retry-after is risky: Many marketers agree that setting retry-after to a very short interval, such as 1 minute, is too aggressive. It can lead to ISPs viewing your mail server as misconfigured or attempting to bypass their greylisting policies, potentially resulting in throttling or blocking.
• Hotmail (Microsoft) sensitivity: Microsoft domains, including Hotmail, are frequently cited as being particularly sensitive to high concurrent connections. Marketers often recommend lowering max-smtp-out and max-msg-per-connection values for these recipients to avoid email throttling.
• Interdependency of directives: It is widely acknowledged that PowerMTA directives like max-smtp-out, max-connect-rate, and max-msg-rate are closely linked. Adjusting one often necessitates adjustments to others to maintain desired sending speeds and deliverability.
• Starting conservative: A common approach is to start with more conservative rate limits, particularly for new IPs or domains, and gradually increase them as reputation builds and deliverability metrics allow.

Key considerations

• Default retry-after: Unless there's a specific and justifiable use case, many marketers advise sticking to PowerMTA's default retry-after settings or using longer intervals like 1 hour for deferred messages, especially when dealing with various domain connection limits.
• Adjust for specific ISPs: Tailoring your max-smtp-out and max-msg-per-connection values per domain or virtual MTA is crucial. Hotmail (Microsoft) often performs better with lower concurrent connections (e.g., 2-4 per IP), while Gmail is generally more forgiving.
• Prioritize deliverability over speed: While maximizing sending speed is tempting, prioritizing good inbox placement by respecting ISP limits and best practices is more important for long-term email program success. Overly aggressive settings can quickly lead to reputation damage and blocking (or blocklisting).
• Monitor queue behavior: Pay close attention to your queues. If messages are persistently backing up, it's a sign that your rate limits might be too high for the receiving ISP. Consider routing such queues to alternative virtual MTAs or even other PowerMTA instances to alleviate pressure, as discussed in PowerMTA configuration guides like the one on Dubai Web & IT Resource Center.

Key opinions

• Recipient-level retry intervals: Experts emphasize the importance of retry-recipients-after, which defaults to 10 minutes. This parameter controls the minimum retry interval at the individual recipient level and often takes precedence or interacts with the broader retry-after setting.
• ISP perception of retries: A 1-minute retry interval is generally viewed negatively by ISPs, as it resembles attempts to circumvent greylisting or other temporary deferral mechanisms. This can lead to your IPs being blocklisted or heavily throttled.
• Hierarchical control: Directives like max-smtp-out can be applied at different scopes—globally, per virtual MTA, or per domain. This allows for granular control over sending behavior, which is essential for managing different ISP requirements and preventing email throttling.
• Rate limit interdependencies: Experts confirm that PowerMTA's rate limiting parameters are deeply interconnected. For instance, a desired max-msg-rate cannot be achieved without an appropriate max-connect-rate and max-smtp-out to support the necessary connection volume.

Key considerations

• Understand the default retry: Before explicitly setting retry-after to very short intervals, understand the default retry-recipients-after (10 minutes) and the typical greylisting periods of major ISPs.
• Strategic use of max-connect-rate: Utilize max-connect-rate to fine-tune the pace of new connections to specific domains. This is particularly important for maintaining a good sender reputation with ISPs that have strict connection policies, as detailed in discussions about acceptable email sending speeds.
• Dynamic configuration: PowerMTA's flexibility allows for dynamic adjustment of these directives based on recipient domain, volume, and sender reputation. This enables senders to manage message connection limits and concurrent outbound connections effectively.
• Consult documentation: For specific use cases or troubleshooting, referring to the PowerMTA documentation (e.g., release notes) is crucial. It provides detailed explanations of each directive and their intended behavior.

Key findings

• Default values: The documentation specifies default values for directives like retry-recipients-after (10 minutes) which are important baselines. Understanding these defaults helps avoid unintended aggressive behavior when not explicitly set.
• Directive scope: Directives such as max-smtp-out can be configured at multiple levels—global, per <virtual-mta>, or per <domain>. This hierarchical structure allows for granular control based on specific sending needs or recipient policies.
• Rate limiting definitions: Documentation explicitly defines max-connect-rate as the maximum number of new connections to a domain over a given time, and max-msg-rate as the maximum message throughput per unit of time, clarifying the difference between connection rates and message rates.
• Deprecation notices: PowerMTA release notes, such as those for PowerMTA v4.5, outline changes like the deprecation of certain directives (e.g., route in favor of smtp-hosts), which are vital for maintaining up-to-date and effective configurations.

Key considerations

• Consult official sources: Always refer to the official PowerMTA documentation for the most accurate and up-to-date information on directive functionality and recommended usage. Relying on outdated information can lead to configuration errors.
• Version-specific changes: Be aware that directive behavior or available options might change between PowerMTA versions, as highlighted in changelogs. Always cross-reference the documentation for your specific PowerMTA version.
• System resource implications: The documentation often details how these directives impact system resources (CPU, memory, network). Understanding these implications is vital for ensuring your server can handle the configured sending rates without performance bottlenecks.
• Error handling: The documentation provides guidance on how PowerMTA handles soft and hard bounces, and how these interact with retry policies. Understanding these processes is key to managing bounce codes and tolerance for deliverability.