How does Momentum's automatic IP warming feature assign an age to new IPs?

Key findings

• Rule-based automation: Momentum’s IP age assignment is part of its Adaptive Delivery feature, operating on a set of preconfigured rules to manage sending. This is more of an automation tool for traffic distribution rather than an active warm-up algorithm.
• Spike prevention: The primary goal of the IP age feature is to act as a safeguard, preventing senders from sending excessive volume from a new IP too quickly, which could lead to blocklisting or poor reputation. For more on this, see our in-depth guide to email blocklists.
• ISP feedback integration: Momentum’s Adaptive Delivery considers ISP feedback, FBLs, and bounces when determining how to manage traffic on new IPs, providing an important signal for deliverability.
• Per-domain/Per-binding: The IP age and Adaptive Delivery settings are applied on a per-domain and per-binding basis. This means if two bindings share the same external IP, Momentum treats them as distinct entities, which is a crucial detail for configuration.

Key considerations

• Not a comprehensive warm-up: While helpful, this feature does not replace the strategic approach to dedicated IP warm-up best practices. It's a traffic management layer, not a full-fledged engagement-driven warming solution.
• Lua logic for overflow: To manage traffic that exceeds the new IP’s rules, you might need to implement custom Lua logic to designate an overflow IP, sending a percentage of traffic to an already warm IP. MassMailer provides a useful reference on default auto-warmup schedules.
• Opaque schedule: The exact schedule and rules governing Adaptive Delivery may not be immediately obvious to users and are typically visible to the MTA administrator. Direct communication with your ESP or MTA provider is essential.
• Version dependency: Ensure your Momentum MTA is on a recent version, as older versions may not fully engage this feature and could require hotfixes to function correctly.

Key opinions

• Confusion with other platforms: Marketers frequently confuse Momentum's Adaptive Delivery with more advanced, engagement-based automated IP warming features found in other cloud ESPs, such as SparkPost's auto warm-up.
• Expectation of full automation: There's a common desire for a feature that automatically assigns an age to new IPs and handles the entire warm-up process without manual intervention or custom scripts.
• Need for clarification: Marketers often seek direct clarification from their ESPs or support teams regarding how specific features like Momentum’s IP age assignment actually function and integrate with their sending strategy. This can be complex, as discussed in our guide on the best approach for warming up an IP.
• Past issues with older versions: Some users have reported that the IP age feature in older Momentum versions might not fully engage or could be broken, requiring hotfixes or updates.

Key considerations

• Understanding limitations: Marketers should recognize that Momentum’s IP age feature is primarily for traffic shaping and preventing reputation damage from aggressive sending, rather than actively building positive engagement-based reputation.
• Strategic traffic injection: Even with automation, smart traffic injection is crucial. Marketers may still need to control how much volume goes to a new IP to ensure a healthy warm-up curve. Our guide on IP warm-up strategy after an ESP migration offers more insight.
• Vendor communication: It’s vital to engage with your ESP’s support or technical account manager to fully understand how their specific Momentum configuration manages new IPs and if any custom adjustments are possible.
• Engagement data absence: Since Momentum’s AD doesn't factor in recipient engagement for IP age, marketers need to ensure their overall strategy (including list hygiene and content quality) builds engagement independently. Ongage provides a helpful complete guide to IP warming.

Key opinions

• Automation, not magic: The IP age feature in Momentum is best understood as an automation tool built on preconfigured rules, designed to manage volume, not to perform magic in terms of reputation building.
• Distinction from other ESPs: Momentum's Adaptive Delivery (AD) is distinct from other cloud ESPs' auto IP warm features (like SparkPost’s), which may have more refined, engagement-aware mechanisms. Knowing why new IPs stay red in Microsoft SNDS is important here.
• ISP feedback matters: While engagement isn't a direct factor, AD does incorporate critical ISP feedback, including FBLs and bounces, which are vital for reputation management.
• Lua logic for control: Achieving more granular control, such as designating a warm IP as an overflow for a new IP, requires custom Lua scripting within the Momentum configuration.

Key considerations

• Understanding rules: Deliverability professionals must understand that Momentum’s IP age is based on a preconfigured set of rules. While these rules are visible to the MTA admin, their specifics depend on Adobe’s willingness to provide transparency and support. This differs from simple IP warming guides.
• Smart injection required: Momentum's feature does not have inherent logic to automatically spill over traffic that exceeds its defined rules. Therefore, senders still need to implement smart injection strategies to manage traffic volume effectively during warm-up. Consider if IP warming needs consecutive days.
• Per-domain/binding treatment: A crucial nuance is that Adaptive Delivery is configured on a per-domain/per-binding basis. This means if the same external IP is used across multiple bindings, AD treats them as separate entities, which requires careful configuration to avoid unexpected sending patterns.
• MTA administrator collaboration: Successful utilization of Momentum’s IP age feature relies heavily on the willingness and expertise of the MTA administrator (e.g., Adobe) to work with you, given the opaque nature of some of its internal schedules and rules.

Key findings

• Automated IP Warm-up Principles: Documentation often outlines that automated IP warm-up systems assign a gradual increase in sending volume to dedicated IPs according to a set schedule. This is generally a predefined progression rather than an organic, dynamic process.
• Recipient engagement evaluation: Some systems, like SparkPost, explicitly mention evaluating recipient interaction history (engagement age) against the dedicated IP's assigned engagement age to determine where to route emails (cold vs. warm IPs). This is a key differentiator from Momentum's AD.
• Rules and configuration: Documentation typically details the configuration parameters for these features, specifying how administrators can define IP pools, binding groups, and criteria for traffic distribution. These rules are usually static unless manually updated.
• Oversight required: Even with automation, documentation implies that human oversight is necessary. It clarifies that such features are aids to managing IP reputation, not replacements for sound deliverability practices.

Key considerations

• Feature variations: Different email service providers (ESPs) and MTAs (like Momentum) implement automatic IP warming features with varying levels of sophistication and underlying logic. Understanding these differences is crucial for effective warm-up. Carnegie Higher Ed provides an ultimate guide to IP warming.
• Admin access to rules: Access to and understanding of the specific rules configured within the MTA (e.g., Momentum’s Adaptive Delivery) is often necessary for troubleshooting and optimizing IP age assignment. This is similar to understanding Google Postmaster Tools V2.
• Custom scripting potential: Documentation may hint at or explicitly describe the ability to use custom scripting languages (like Lua in Momentum) to extend or modify the default behavior of automatic IP management features for specific use cases.
• Impact of domain separation: As noted in some documentation, the distinction between domains or bindings (even if sharing an external IP) can significantly affect how IP age is applied, requiring careful consideration of email architecture.