Throttling / rate limiting
The receiving server capping how much mail it will take from you at once, so a burst gets slowed down instead of delivered.
See it
What it is
Two ceilings sit between you and the inbox. Your own provider caps sends per second or per day (SES sandbox, plan quotas). The receiving side caps how much it takes from you, per connection, per hour, per domain, and answers a burst with a 4xx reply. Gmail, Outlook, and Yahoo all do it. Do not read every 421 or 450 as throttling, though: the same codes carry greylisting, mailbox problems, policy blocks, and plain server trouble. The enhanced status code and the diagnostic text are what tell you which one you got, and 4.7.x pointing at volume or reputation is a different problem from 4.2.2 mailbox full.
The ceiling is not a fixed pipe size, it tracks your reputation. A new domain gets a tiny allowance, a trusted one gets a generous one, which is exactly why domain warming works. Practical moves: cap concurrent connections per receiving domain, spread a big campaign over hours instead of firing it in one minute, and keep transactional mail on a separate stream so a newsletter burst never delays a password reset.
Gotcha: hammering retries makes it worse. A queue that immediately re-sends everything a receiver just deferred looks like an attack and gets you temporarily blocked. SMTP has no Retry-After header to obey either, so the schedule is entirely yours: back off with jitter, use any hint in the reply text for what it is worth, and treat sustained throttling as a reputation problem to fix rather than a wall to push harder against.
Ask AI for it
Build me a rate-limited email send scheduler. Use a token bucket per recipient domain (configurable messages per minute and max concurrent SMTP connections, defaults tuned low for gmail.com, outlook.com, and yahoo.com) and spread a campaign evenly across a configurable send window instead of firing it all at once. On a deferral, classify before you react: parse the enhanced status code and diagnostic text, and reduce that domain's rate only for rate or reputation deferrals, while greylisting, mailbox, policy, and server-side failures go to a plain retry path with no rate change. Retry with exponential backoff plus jitter, and do not expect a Retry-After header, since SMTP has none. Give transactional messages priority ahead of campaign traffic within the same per-domain capacity budget, and never let them bypass that budget. Include metrics for deferral rate per domain, split by deferral class.