AI Is Rewriting Email Sending Patterns

The traditional email campaign had a recognisable shape.

A team selected a list, chose Tuesday at 10 a.m., and sent the same message to everyone. The resulting traffic appeared as a large, predictable spike: one campaign, one audience, one send time.

That pattern is disappearing.

The same campaign can now reach one customer in the morning, another after lunch, and a third the following evening. Some recipients receive email; others are routed to SMS or push. A highly engaged customer might receive the next promotion while a fatigued customer is held back. Different subject lines, offers, and content blocks can be selected automatically.

AI is moving deeper into the machinery of sending. It is no longer used only to write copy. It increasingly helps decide who receives a message, when it leaves, how often a person is contacted, and which version they see.

For marketers, that promises relevance at a scale manual campaign calendars cannot provide. For deliverability teams, it creates a new question:

What happens when your sending pattern becomes the output of a model?

What an email sending pattern actually is

A sending pattern is the shape and behaviour of your outbound traffic over time.

Mailbox providers do not see a campaign brief or a marketing calendar. They see messages arriving from domains and IP addresses. They observe volume, cadence, authentication, complaints, bounces, recipient engagement, and how those signals change.

A sending pattern includes:

• How many messages leave in a given minute or hour
• How volume is distributed across Gmail, Yahoo, Outlook, and other providers
• Whether traffic arrives as one burst or a gradual flow
• How frequently the same recipient is contacted
• How much of the audience is new, active, inactive, or recently acquired
• Whether transactional and promotional messages share infrastructure
• How bounce and complaint rates change as volume expands

Historically, people configured most of these decisions directly. They chose the list, schedule, batch size, and exclusions.

Now, predictive models and automated decision engines increasingly shape the pattern before the first message is handed to an SMTP provider.

AI is already changing when email gets sent

This is not a future prediction. Major email platforms already offer different versions of algorithmic timing.

Mailchimp optimises one campaign time

Mailchimp’s Send Time Optimization uses engagement data to identify an ideal time within 24 hours of the date selected by the sender. The recommendation applies to the campaign audience rather than creating a unique send time for every contact.

That is a relatively simple change to the traditional model: the campaign still has one main send time, but data chooses it instead of the marketer.

Salesforce predicts engagement across the week

Salesforce’s Einstein Send Time Optimization assigns contacts a predicted probability of engagement for each of the 168 hours in a week. In a customer journey, the activity can hold each contact until the best upcoming hour inside the chosen window.

The campaign is no longer one batch. It becomes a series of individual scheduling decisions.

Klaviyo personalises time for each recipient

Klaviyo’s Personalized Send Time, documented in August 2026, uses reinforcement learning to select the predicted best hour for each profile within a delivery window. The model can optimise using opens, clicks, and placed-order events, drawing on the recipient’s behaviour and patterns from similar profiles when individual history is limited.

This is a more consequential shift. Two customers in the same campaign can receive the same message at entirely different times because the model expects them to behave differently.

Braze combines timing with frequency and channel

Braze describes a broader decisioning model that adjusts timing, channel, content, offers, and frequency using individual behaviour. When multiple campaigns qualify the same customer, AI can prioritise which message is most likely to produce a meaningful action.

At that point, AI is not merely scheduling an email. It is deciding whether email should be sent at all.

The six decisions moving from calendars to models

Send-time optimisation is the most visible use case, but it is only one part of algorithmic sending.

1. Who should receive the message

Predictive segments identify people considered likely to purchase, renew, churn, or disengage. Instead of defining a group entirely through fixed rules, marketers can target a probability.

That can reduce irrelevant mail. It can also create blind spots when the model repeatedly excludes people with limited history or incorrectly treats low recent activity as low future value.

2. When each person should receive it

Personalised timing spreads a campaign across a window according to predicted receptiveness. One recipient gets the message at 8 a.m.; another receives it at 6 p.m.

The promise is better engagement. The operational consequence is that volume now follows the model’s preferred hours, time zones, and confidence levels.

3. How often the person should be contacted

Frequency models attempt to estimate individual tolerance instead of applying the same cap to everyone. Someone who engages daily might continue receiving frequent messages. Someone whose engagement is falling can be contacted less often.

This can reduce fatigue, but it must not become a licence to push highly engaged people until they stop responding.

4. Which channel should be used

If a customer tends to act on push notifications but ignores email, an AI decision engine can choose push. Another customer may receive email because that is where their history shows stronger engagement.

Email volume therefore becomes connected to decisions made across the entire messaging programme, not only inside the email calendar.

5. Which message or offer should be sent

Models can choose subject lines, content variants, products, discounts, or calls to action. Traditional A/B tests select one winner for a large audience. Continuous decisioning can select different winners for different recipients.

The traffic still leaves through the same sending infrastructure, but recipient reactions can vary sharply by variant. Deliverability reporting has to preserve that context.

6. Whether the message should be suppressed

Sometimes the best send is no send.

Smart-sending controls, fatigue models, journey exclusions, and predicted disengagement can prevent a message from leaving. Suppression is one of the most useful applications of automation because avoiding an unwanted email protects both the customer relationship and sender reputation.

Not every “smart send” is AI

The email industry uses overlapping language for very different mechanisms.

Send-time optimisation predicts when engagement is most likely.

Smart sending often applies a rule such as “do not contact this person again within 16 hours.”

Gradual sending divides an audience into batches released over time.

Throttling limits the number of messages handed to infrastructure or a receiving provider during a period.

Journey orchestration moves people through preconfigured paths based on events and conditions.

Some products use machine learning. Others are deterministic rules with a clever label. Both can be useful, but they create different risks and require different tests.

Calling every automation “AI” hides the operational question that matters: which system made the decision, using which data, subject to which constraints?

How AI can help deliverability

AI does not produce inbox placement directly. It can improve some of the behaviour that contributes to a healthy programme.

Better timing can improve relevance

A useful message arriving when the recipient is active has a better chance of earning attention. Stronger engagement can reinforce the relationship between recipient and sender.

The benefit is not that 10:17 a.m. is magically safer for Gmail. It is that recipient-level timing can make the message feel more relevant.

Frequency control can reduce fatigue

Over-messaging creates unsubscribes, complaints, and silent disengagement. A system that recognises declining interest and reduces frequency can protect list quality before the recipient reaches for the spam button.

Personalised scheduling can smooth volume

Moving away from a single global send can distribute traffic over several hours. A smoother ramp can be easier on sending infrastructure than a sudden campaign spike.

This benefit is not automatic. If a model assigns a large portion of the audience to the same “best” hour, it can create a new spike in a different place. Provider distribution still has to be monitored.

Suppression can protect reputation

Models that identify likely fatigue or low relevance can help teams avoid sending mail that has little chance of creating value. Reducing unnecessary volume is often safer than generating another personalised variation.

How AI can damage sending patterns

The same systems can create risk when optimisation is allowed to operate without deliverability guardrails.

1. The model can create invisible provider bursts

A campaign may look evenly distributed across six hours in the marketing platform while a large share of Gmail recipients cluster in one hour. The aggregate curve appears smooth; the provider-level curve does not.

Mailbox providers evaluate their own traffic. A deliverability team needs the same view.

2. The objective can be wrong

A model optimising for opens will learn from open data. Apple’s Mail Privacy Protection can preload remote content without a human reading the email, making the training signal less reliable.

Optimising for clicks or purchases is closer to business value, but those outcomes are less frequent and can take longer to observe. Teams need to understand the trade-off instead of accepting a generic “engagement” objective.

3. The model can overexploit engaged recipients

Highly engaged subscribers are attractive targets because they make performance dashboards look better. A system focused on short-term response can keep selecting them, increase their message frequency, and eventually create fatigue.

Frequency caps and complaint monitoring must remain hard constraints, not optional suggestions the optimisation layer can override.

4. New recipients can be treated as low-confidence inventory

Personalisation works best when a profile has history. New subscribers do not.

Platforms compensate with account-wide patterns or lookalike behaviour, but those are estimates. If the model consistently favours people with rich histories, new or unusual segments can receive inferior timing and fewer learning opportunities.

5. Automation can hide deterioration

A model can improve the average by sending less to a weak segment. That may be the correct decision, but it can also conceal the underlying problem: poor acquisition, stale consent, irrelevant content, or a broken onboarding journey.

An improved aggregate rate does not prove the programme became healthier. The model may simply have changed who was counted.

6. Optimisation can conflict with infrastructure controls

The predicted best time is a marketing decision. Rate limits, provider deferrals, IP warm-up plans, queue capacity, and reputation controls are infrastructure decisions.

If the timing model concentrates demand at 10 a.m. but the sending layer must slow delivery, many recipients will not receive the message at the promised “best” time. Send-time optimisation and throttling have to be planned together, even when separate products control them.

AI does not replace the sender requirements

No model can optimise its way around weak authentication or unwanted mail.

Google requires high-volume senders to personal Gmail accounts to use SPF, DKIM, and DMARC, keep spam rates low, and support one-click unsubscribe for marketing and subscribed messages. Yahoo expects bulk senders to meet similar requirements and keep complaint rates below 0.3%. Microsoft requires SPF, DKIM, and DMARC for domains sending more than 5,000 messages a day to its consumer Outlook services.

Those requirements apply whether a human scheduled the campaign or a model selected 100,000 individual send times.

The foundations remain:

• Permission and accurate subscriber expectations
• SPF, DKIM, and DMARC alignment
• Simple, functioning unsubscribe
• Clean acquisition and suppression practices
• Separation of traffic streams where appropriate
• Monitoring by recipient domain and sending provider
• Controlled volume changes

AI can improve decisions above this foundation. It cannot substitute for the foundation.

A safer operating model for AI-driven sending

The practical answer is not to disable optimisation. It is to surround it with observable constraints.

Define the objective precisely

Do not configure a model to “increase engagement” without knowing what that means. Is it optimising for opens, clicks, orders, replies, or long-term customer value?

The metric determines the behaviour the system learns to pursue.

Set hard deliverability guardrails

Create limits the optimisation layer cannot override:

• Maximum messages per recipient per day or week
• Complaint and unsubscribe thresholds
• Provider-level hourly volumes
• Maximum day-over-day volume growth
• Transactional-message priority
• Suppression rules for inactive or unconsented recipients

The model can choose within those boundaries. It should not choose the boundaries.

Keep a control group

Hold back a statistically useful portion of the audience from personalised timing or frequency. Compare like with like over enough campaigns to avoid mistaking seasonality or audience selection for model impact.

Measure conversions and delivery health—not only the metric the model was trained to maximise.

Monitor at the provider level

Aggregate reporting can hide the most important pattern. Break volume, deferrals, bounces, complaints, and conversions down by Gmail, Yahoo, Outlook, and other destinations.

If AI changes when messages leave, provider-level monitoring shows what those decisions create downstream.

Preserve the decision context

Log which model or rule selected the recipient, time, frequency, channel, and variant. Without that context, a deliverability incident becomes difficult to reconstruct.

“The campaign performed poorly” is not a useful diagnosis when every recipient effectively received a different campaign.

Maintain a fallback

Models encounter thin data, delayed events, and unexpected traffic. Define what happens when confidence is low or the optimisation service is unavailable.

A safe default schedule is better than an uncontrolled queue release.

What email teams should do in the next 30 days

Week 1: inventory the decisions

• List every feature that changes recipients, timing, frequency, channel, or content automatically.
• Label each one as predictive, generative, rule-based, or unclear.
• Record the metric it claims to optimise.

Week 2: map the resulting traffic

• Compare scheduled time with actual delivery time.
• Chart volume by hour, mailbox provider, sending domain, and IP or SMTP provider.
• Identify whether personalised timing creates new concentration points.

Week 3: connect performance to reputation

• Review clicks, conversions, complaints, bounces, and unsubscribes together.
• Separate new, active, and inactive recipients.
• Confirm that improved engagement is not coming only from excluding difficult segments.

Week 4: add controls and tests

• Set frequency and provider-volume guardrails.
• Establish a control group.
• Document the fallback schedule.
• Decide who can pause the model when delivery health deteriorates.

The new deliverability question

The old question was: When should we send this campaign?

The new system asks millions of smaller questions: Should this person receive it? On which channel? At what time? How soon after the previous message? With which offer? Through which journey?

That can create a better customer experience. It can also create a traffic pattern no person explicitly designed.

This is where deliverability becomes more important, not less.

When sending decisions are distributed across models, journeys, and providers, teams need a clear view of what actually left, where it went, how mailbox providers responded, and whether the business outcome justified the reputation cost.

AI is rewriting email sending patterns. The winners will not be the teams that automate the most decisions.

They will be the teams that can observe, constrain, and improve those decisions without losing control of the send.

Sources and further reading

• Salesforce — Einstein Send Time Optimization Dashboard
• Salesforce — Use the Einstein Send Time Optimization Activity
• Google — Email sender guidelines FAQ
• Yahoo Sender Hub — Sender best practices and requirements
• Microsoft — Outlook’s requirements for high-volume senders
• Apple — Mail Privacy Protection and privacy

This article describes publicly documented platform capabilities and sender requirements as of 3 September 2026. Product availability, model behaviour, and optimisation methods vary by plan, account, region, and data quality.