The difference between hard bounce and soft bounce...doesn't exist!

When sending emailings it may occur that it does not reach the addressed inbox. Many marketers tend to make a distinction between hard and soft bounces when this happens. However, this dinstincition is far too simple. Much can go wrong when sending emailings that it is ridiculous to split these errors up into two categories. Copernica's marketing software provides better insights for the user without using vague terms such as 'soft' and 'hard' bounce.

But what actually happens when sending an emailing? Sending an email in fact consists of three steps: the emailing is compiled first, subsequently the emailing is sent © per message © from a sending (client) to a receiving (server) mailserver. However, it doesn't always mean a message will be delivered to the recipient when an e-mailing is accepted: a 'bounce' can occur and an error will be sent back to the client. In this document we will focus on these three steps.

Step 1: Compiling an emailing

Compiling an emailing itself also consists of several fases. For example:

• Generating the HTML code
  
• Personalizing using Smarty-code
  
• Uploading XML-feeds
  
• Embedding images
  
• Generating and personalizing attached PDF documents

Put briefly, even when compiling an emailing a lot can go wrong, long before actually sending the messages. How should this error be mentioned in the email statistics? As a hard bounce? As a soft bounce? Copernica doesn't make this distinction. When the emailing encounters an error upon compiling, the software will report an error has occured during the compiling of the e-mail. Obvious, isn't it?

Step 2: Sending an e-mailing © communication with receiving mailserver

Upon sending an email, an A-record is used to find the corresponding domain name that was given when sending the email. An error occurs if for example, the DNS data of the server are not correct.

• The user will possibly receive the report "Map domain name to IP address" from the software. This means that the domain of the addressee (@xxxx.xx) is not properly linked to an IP address. The emailing can not be sent.

In the next step, an MX-recordMX-record is used to check which server needs to receive the email. A (temporary) error could occur if the server is temporarily unavailable.

A connection is made with the receiving IP address with the help of an A-record, when it is known what mail server has to receive the email.

An SMTP-connection is made with the server after these steps. For example, at IP address 11.22.33.222 port 25 (default SMTP-server port). This connection can fail also resulting in an error report.

• For example, when a provides blocks the server port.

If the connection is made, the client will start communication with the server. The server will send a 'greeting'-reply using code 220. An error can occur when a server replies with code 554. This means the server does not accept the connection.

The client starts by giving a HELO command during the communication. This will start the SMTP-mail transaction. The server gives the answer: '250 Hello'. If no answer is given, a time-out will occur. The software allows you to register an error if this situation occurs more than once with the help of selections.

• In this situation, the software will register the error "Communication with receiving mail server". An error could also occur when the sender did not properly set the SPF-record. The server will refuse the email causing an error.

The client will send a MAIL command when the server gives an answer. This command informs about the sender of the mail. MAILFROM:. Three events can occur at this point:

• The server accepts the mail coming from this address.
• The server gives a time-out. The client will try sending the mail again later.
• The server does not accept any emails coming from this address as it is mentioned on a blacklist. An error will occur.

When servers continue communicating, the receiving server will also check who the email is addressed to using the RCPT command. RCPTTO:<john@company.com>. Same as before, three events can occur at this point:

• The server accepts the address.
  
• The server gives a time-out.
  
• The server indicates not knowing this email address. An error occurs.

After the server has approved both the MAIL and RCPT command, the other data of the email is checked. This is done using the DATA command. This includes all other content of the email such as different headers: From, To, Subject, List-unsubscribe,... and the actual content of the email (text and images). Once again, three events can occur:

• The server accepts the data.
  
• The server gives a time-out.
  
• The server does not accept the data. This may happen because the included data contains SPAM characteristics.

Don't forget to end all sent through data with a '.' on a new line at the end of the email.

The client terminates the mail transfer by sending a QUIT command. The server will then indicate if the email was received in good order. Or it will request a time-out, or it will indicate that sending the data failed. This results in an error.

Step 3: processing bounces

When an email is finally accepted by the receiving mail server, an error could still occur. This error will then result in a bounce. The server will send a DSN message (Delivery Status Notification) to the client with possible information on what went wrong. Or the server does not provide any information at all.

Copernica does not make the distinction between 'hard' bounce of 'soft' bounce. When an error occurs after an email was accepted and the server communicates this to the client, the software will clearly mention the receiving mail server sent a bounce. Using the statistics you may possibly see what specific error code it concerns. If the software does not recognize the error code sent back by the server, it will indicate it concerns 'other received emails' (errors). For example, in the case of out-of-office replies.