邮箱已满的收件人可能仍然是有效且愿意的收件人。当前的任务是确定原始消息是否仍在排队，接收系统是否认为故障是暂时的，以及当空间可用时消息是否仍然有用。添加一个 SPF include 不会创建邮箱容量。
读取等级和容量诊断
RFC 3463将 X.2.2 定义为邮箱已满，并表示它应该用作持久的瞬态故障。第一个组件提供成功、持续瞬态故障或永久故障类别。保留完整的SMTP回复以及增强状态：仪表板的“软弹跳”标签可能会隐藏实际的响应和交易阶段。 RFC 3463第 3.3 节.
4xx 回复通常会将重试责任留给发送系统。 5xx 回复表示该尝试永久失败，并且不应在没有干预的情况下触发常规重复尝试。如果三位数SMTP类别和增强类别不一致，请保留两者并调查服务器或解析器行为，而不是默默地重写证据。即使特定尝试永久失败，基础存储条件也可能稍后发生变化。
确定哪些消息保持排队状态
捕获发件人的队列标识符、原始提交时间、失败的信封收件人、上次响应和下次计划尝试。多收件人消息可以有一个延迟收件人，而其他收件人已被接受。因此，重新发送到完整的可见收件人列表可能会为不受容量问题影响的人员重复邮件。
检查发件人是否仍然拥有传送尝试，或者下游中继是否接受责任并随后生成通知。延迟警告并不一定是最终的失败。将队列记录和特定于收件人的通知字段一起使用。将原始提交时间与通知到达时间分开，尤其是当发件人报告“刚刚”发生故障时。
处理假设的延迟消息
假设队列项 Q378 为一位收件人收到 452 4.2.2。接收方的管理员稍后会确认已批准的容量修复。在创建替换之前，请检查 Q378：如果它仍在等待计划的重试，请遵循该队列；如果其稍后的尝试已经收到最终数据接受，则旧的警告不是发送另一个副本的理由。
如果 Q378 在容量恢复之前过期，则保留其失败结果并单独识别任何授权的替代品。维修不会追溯交付过期的物品。其他收件人可能已经成功，因此请避免重新发送整个可见收件人列表。这些情况是假设的，不是实时邮箱测试、保留队列或测量的恢复。
在不增加邮件的情况下解决容量问题
对于组织控制的收件人，邮箱所有者或管理员应通过批准的程序审查配额、保留和可用存储空间。不要仅仅为了清除递送警报而删除用户数据。对于外部收件人，当业务消息紧急时，请使用已建立的替代渠道，并让该人解决自己的邮箱问题。
修复后，首先检查原始排队项目是否已成功。仅当了解其与原始尝试的关系时，才启动新的授权提交。尊重发送者记录的重试和过期政策，而不是打击接收者。 RFC 5321描述了重试间隔和可配置的放弃行为；它的一般指导并不是承诺每个提供商都会在同一时期内保留邮件。 RFC 5321第4.5.4.1节.
通过收件人处置、容量更正和最终交付证据结束事件。 SMTP接受建立了交接，而不是证明收件人已阅读邮件。如果原件已过期，请将该事实与任何成功提交的替换件分开记录。
决定是否需要更换
- 原件仍在排队：在制作另一个副本之前检查下一次重试和有用性。
- 修复后接受原件：不要仅仅因为收到旧警告而重新发送。
- 原件过期：单独记录该结果；仅在仍然有用时才授权更换。
- 混合收件人：将任何新发送限制到预期的未解析收件人。
- 容量修复：保留所有者认可的证据，而不暴露邮箱内容。