All the bounce we cannot see: A Deferral story

When we work in email deliverability, we constantly hear about the processing of bounces, sometimes about blocking bounces and more often about suppressing bounces... In short, as you will have understood, processing bounces is the absolute prerequisite to email deliverability ... But then, what about Deferrals... Should we process them? And if yes, how?

What is a Deferral?

To understand what a Deferral is, you must first understand what sending a message is: communication between two SMTP servers: a sender and a recipient.


Exactly as when loading a Web page, the destination server will provide a response to the sending server to indicate the result of the transaction:

  • 2XX - Success: Success means that the DSN (Delivery Status Notification) reports a positive delivery action. For example, code 250 indicates that the email has been accepted by the destination server (PLEASE NOTE: this does not mean that it will be delivered to the inbox).
  • 4XX - Persistent Transient Failure: A persistent transient failure is one in which the message as sent is valid, but the persistence of a temporary condition has caused attempts to send the message to be aborted or delayed.
  • 5XX - Permanent Failure: A permanent failure is one that is unlikely to be resolved by resending the message in its current form.

For more details on all of SMTP Enhanced Code, I invite you to consult RFC3453 and RFC5248.
We can therefore define that a Deferral is a temporary error, i.e. a transaction whose SMTP response contains an SMTP Enhanced Code of type

If it's a temporary error, what's the point of dealing with it?

This is indeed an excellent question, why should we process Deferrals and give them a particular importance? Quite simply because all SMTP servers have expiration times for messages: after this time, if the error/anomaly is not fixed, the email will be automatically bounced by the MTA.

Generally, dealing with bounces is pretty simple, there aren't many different reasons: 

  • The mailbox does not exist
  • The mailbox is full
  • The message has been blocked
  • The sender (domain or IP) has been blocked
  • The message has expired

For Deferrals, it's much more complex :

  • The mailbox is full (oh yes, it’s also in the bounces, but we’ll come back to that)
  • The receiving server does not manage the destination domain
  • You are experiencing Rate Limiting
  • You are blacklisted
  • You have a configuration issue
  • You have an authentication issue
  • You are greylisted

The goal of processing Deferrals is therefore to prevent messages from expiring and being automatically bounced by the MTA.
The Deferral rate is also a very good indicator of the reputation of an IP or a domain (particularly during a warm up phase), it can reveal a lot of information.

How to treat these different causes of Deferral?

In 99.9% of cases, all the information is present in the SMTP log messages, you simply need to read them!

Mailbox Full

The majority of Mailbox Providers notify full mailboxes with a bounce, but in rare cases it's a Deferral... In order to standardize their treatment, it is therefore preferable to ask the MTA to treat them as bounces! If we take the case of, by default an account has 15 GB of storage space. In fact, the probability of seeing the email being delivered on a new attempt is close to zero... A simple reading of the URL communicated by Google allows you to know that a mailbox which responded 452 4.2.2 The recipient's inbox is out of storage space. Please direct the recipient to is a mailbox that can no longer send messages... All the more reason to treat this response as a bounce!

The receiving server does not manage the destination domain

This happens often and can demonstrate the discontinuation of a domain... For example, a company simply changes the TLD of its domain name from .org to .com. If you do not deal with auto-replies that invite you to change the domain, after a while you may see this type of message appear: Host or domain name not found. Name service error for name=XXX type=MX: Host not found, try again or 451 4.4.4 Mail received as unauthenticated, incoming to a recipient domain configured in a hosted tenant which has no mail-enabled subscriptions. ATTR5.
These messages indicate that the MX server no longer exists or is no longer working because there is no subscription for the recipient domain: the domain is no longer used but the MX records have not been deleted!

Rate Limiting

Here, the Mailbox Provider asks you to reduce your sending speed, the causes are multiple: excessive increase in sending volume or complaints, or even a bad sender reputation! This is also what we can find in this explicit message, to say the least, which is sent by Comcast: 451 4.2.0 Throttled -
Reading the URL will give you the hints to correct this anomaly!

You are blacklisted

The operator tells you here that as long as you are blacklisted, it will not be possible to send the email and yes, you must read the content of the URL: 451 too many errors from your ip (XXX.XXX.XXX.XXX), please visit

You have a configuration issue

As the Mailbox Providers are rather friendly, they tell you when your configuration does not meet their expectations, this could be for TLS, a number of concurrent connections or even a number of messages per connection. This is the case with Yahoo which imposes a limit of 20 messages per connection… Beyond that, you will receive the message: 421 Max message per connection reached, closing transmission channel. A simple modification of your configuration will fix this problem!

You have an authentication issue

All email providers require that messages be authenticated, as is also the case with the new rules from Yahoo and Google recently! If messages are not authenticated properly, then you might see this log message: 421 4.7.32 Your email has been rate limited because the From: header (RFC5322) in this message isn't aligned with either the authenticated SPF or DKIM organizational domain. To learn more about DMARC alignment, visit To learn more about Gmail requirements for bulk senders, visit
Adding/correcting different authentications like SPF, DKIM and DMARC will allow you to have your messages accepted!

You are greylisted

This case is the only one where you have absolutely nothing to do, the destination server tells you that you are greylisted: they refuse all first attempts and accept the next one. This can be seen with the message: 451 4.7.1 Greylisting in action, please come back later [CC].

Processing all these Deferrals will allow you to optimize a certain number of elements:

  • List hygiene
  • MTA Configuration
  • Message authentication
  • Sender reputation

Believe it or not, this will have a positive impact on your bounce rate and your Inbox placement!
In conclusion, processing Deferrals will allow you to avoid all these bounces you cannot see!

To be alerted of your Deferrals, nothing could be simpler, use the Postmastery Console. Every hour, you will receive an alert informing you when your campaigns have generated too many Deferrals!

Postmastery Services

Postmastery offers comprehensive services designed to enhance email performance monitoring, manage email deferrals, and improve overall deliverability. Our deliverability dashboard provides real-time insights into your email campaigns, helping you identify and resolve issues promptly. With advanced email authentication solutions, we ensure your messages meet all authentication standards, significantly boosting your sender reputation and inbox placement.

More information
For more information on how Postmastery can help you optimize your email deliverability, contact us today. Enhance your email performance and achieve better results with our expert services.

Share this

Comments are closed.

There are many more interesting blogs by category for you to read.