活動期間隊列成長可能有多種原因。應用程式產生郵件的速度可能比其提供者接受郵件的速度快，提供者可能會減慢出站投遞速度，或者接收系統可能會推遲特定目的地的發送。將這三個都稱為「 Gmail限制」隱藏了瓶頸的位置。
找到第一個延遲階段
參考： RFC 5321 §4.2.1, RFC 5321 §4.5.4.1.
捕獲作業建立、提供者提交、提供者接受和每次交付嘗試的時間戳記。保留完整的回應文字和發出它的系統。成功的應用程式 API 回應與最終接收伺服器接受訊息不同。如果提供者未公開某個階段，請將其標記為不可用，而不是推斷確切的時間戳。
SMTP將臨時否定答覆與永久否定答覆區分開來。臨時響應並不是全速不斷重試的指示；發送系統需要一個隊列和適當的重試策略。永久性故障不應被視為無休止的臨時積壓。 RFC 5321第 4 節和 4.5.4.
檢查更改的工作負載
比較目的地組合、獨特的訊息和嘗試。發送多次重試的活動可能會增加嘗試計數，而不會代表其他收件者。將行銷作業與延遲敏感的事務訊息分開，並檢查它們是否競爭相同的並發或速率預算。
谷歌建議在監控回應的同時避免突發並逐漸增加流量。將目前的Gmail指南應用於其規定的範圍，而不是將其轉換為通用的每秒安全郵件限制。本文中的任何公眾號都無法證明發送者的身分。 Gmail寄件者指南.
進行隊列算術
參考： RFC 5321 §4.2.1.
本地綜合模型以空隊列開始。新作業以每分鐘 120 則訊息的速度到達，而假設的服務速率為每分鐘 80 條，持續 10 分鐘。積壓的訊息每分鐘增加 40 條，達到 400 條。如果隨後暫停到達並繼續保持相同的服務費率，則理想的流失時間為五分鐘。
這是隊列算術，而不是測量的提供者限製或即時恢復的預測。它故意排除重試、過期和更改服務費率。這些遺漏解釋了為什麼真正的隊列可能需要更長的時間。在計算的同時保留假設，這樣容量工作表就不會成為不受支援的服務水準承諾。
保留的確定性回應狀態模型在離線狀態下重新運行以進行此審核，並保留嘗試分類帳。在 UTC 時間 09:00，一項腳本化作業收到「451 4.7.0 臨時速率限制；稍後重試」。其狀態變為重試待定，受影響的流被標記為減壓，並且在 09:30 受控的本地重試收到“250 2.0.0 Accepted”。另一個作業在 09:00 收到“550 5.1.1 No such returned”，並進入永久失敗，無需重試；其下一步行動是批准收件人驗證。這些完整的回復是發明的本地測試輸入。三十分鐘是該燈具的重試設置，而不是通用的提供者指令。程式碼從回應類別派生狀態轉換，並禁止計劃外的第二次嘗試。
減輕壓力而不失正確性
參考： RFC 5321 §4.5.4.1.
透過核准的調度程序暫停或減少受影響的非必要流。讓負責的隊列使用其支援的策略重試臨時失敗。避免建立第二個佇列來重新傳送相同事務，因為儀表板會延遲。使用穩定的事務識別碼來協調不確定的提交結果。
對於緊急訊息，僅在驗證身份驗證和防止重複後才遵循批准的連續性路線。不要透過輪換基礎設施來逃避提供者的限制。使用時間戳、回應文字、目標範圍、路由標識符和修正變更的證據進行升級。
當積壓和年齡分佈在定義的合法工作負載下穩定時，恢復擴展。繼續檢查最舊的消息：較低的平均延遲可以隱藏一小部分嚴重逾期的重置或收據。