When you send an email with Dialog Insight, several mechanisms come into play before the message is delivered to the recipient’s mail server. Some of these mechanisms identify the sender and authenticate the message, while others handle message routing and delivery error reporting.
This article describes the main steps in this process, from sending the email to its handling by the recipient’s mail server. It also explains how delivery error notifications work.
Overview of the Process
- You initiate the sending of an email or campaign in Dialog Insight.
- Dialog Insight transmits the email to the recipient’s mail server.
- The server checks the message and may accept it, defer acceptance, or reject it. After accepting the message, it may also filter it.
If the message cannot be delivered, an error may be reported and appear in your sending results.
1. Preparing and sending the email
Before sending, you prepare your email and define the information that will help recipients identify your organization.
You choose, among other things:
- The sender name, which tells recipients who is contacting them. For example: My Company Team.
- The sending address, which appears in the email’s From field. For example: newsletter@c.mycompany.com.
The sender name and sending address make up the sender’s visible identity. The domain in the address, which is the part after the @ symbol, also plays a role in email authentication and how the recipient’s mail server handles the message. Depending on your account configuration, you may have access to predefined senders.
Once the email is ready, you initiate the sending of the email or campaign in Dialog Insight. The platform then handles transmitting the message to the recipient’s mail server.
To learn more about choosing a sending domain, see Understanding Domains and Email Authentication.
2. Message routing
Dialog Insight sends your email from its sending servers, which use an IP address. The message is routed to the mail server that handles the recipient’s email address.
The email contains its content, the information visible to the recipient, and technical information required for routing. The latter can be compared to an envelope: this information indicates, among other things, which recipient the message should be delivered to and which address should be used for delivery error notifications.
The message envelope includes a technical sender address, defined during transmission through the MAIL FROM field. This address is used, among other things, to route delivery error notifications. During final delivery, the receiving server generally records this address in the Return-Path header.
| From | Identifies the sender visible to the recipient. |
| MAIL FROM | Defines the technical address used, among other things, to route delivery error notifications. |
| Reply-To | Specifies the address to which replies to the email should be sent. |
| The technical address used for delivery errors may differ from the sending address visible to the recipient and from the address used to receive replies. |
3. Receiving and checking the message
The recipient’s mail server performs various checks. These may include examining the message’s authentication, the sender’s reputation, and the email content.
Depending on its rules, the mail server may:
- Accept and deliver the message: The server accepts the message and passes it to its processing system. The message may then be placed in the inbox or another folder.
- Accept the message and then filter it: The email may be classified as spam or subjected to a security rule, such as quarantine.
- Defer acceptance: The server temporarily indicates that it cannot accept the message. Another delivery attempt may be made.
- Reject the message: The server refuses to accept it, which may result in a delivery error.
| An email marked as delivered has not necessarily reached the inbox or been read. The server may have accepted the message and then filtered it or placed it in another folder. Delivery status therefore does not guarantee that the message is in the inbox or that the recipient has read it. |
SPF, DKIM, and DMARC mechanisms allow mail servers to verify different aspects of email authentication. However, successful authentication alone does not guarantee that an email will reach the inbox.
To learn more, see Understanding Domains and Email Authentication.
Delivery errors
A delivery error may occur, for example, if the recipient’s address does not exist, their mailbox is full, or the server refuses the message.
Errors may be reported at different stages of the process.
Error reported during transmission
The recipient’s server may reject the message when Dialog Insight attempts to transmit it. The rejection may be temporary or permanent. A temporary rejection may trigger another sending attempt.
Error reported after acceptance
A server may accept the message, but an error notification may be received later if the message ultimately cannot be delivered to the recipient. This notification is generally routed to the technical address associated with the MAIL FROM field. It may arrive after the initial sending attempt.
Check your sending results in Dialog Insight to review reported errors and determine what action to take. However, some filtering performed by mail servers does not generate an error notification.
To learn more, see Understanding Email Delivery Errors.