Pressing Send looks like a single action. In practice it starts a chain of short conversations between computers, each with its own rules, retries, and failure modes. Understanding that chain explains most delivery delays, why some messages bounce, and why a message can show as sent and still not arrive. This article follows one message from your client to the recipient's mailbox.
Step 1: submission
Your mail client does not deliver the message itself. It hands the message to an outgoing server using SMTP submission, which runs on port 587 with STARTTLS or on port 465 with implicit TLS. The client authenticates, usually with your full address as the username and an app password, and then sends the message. For ITProMail that server is smtp.itpromail.com. Settings are in IMAP and SMTP settings.
Authentication matters here. The submission server accepts the message because you logged in, which is why it can accept mail for your domain without being an open relay. The server can also apply sending limits. For ITProMail, outbound mail is capped at 300 recipients per hour and 1000 per day.
Step 2: the envelope and the content
An SMTP transaction has two layers. The envelope is what the protocol uses for routing. MAIL FROM names the return path, and each RCPT TO names a recipient. The content is the headers and body, which the recipient's client displays. The two can differ. Bcc recipients appear only in the envelope, and the return path is often a bounce address rather than the visible From address. The distinction matters later, because SPF checks the envelope sender.
Step 3: finding the recipient's server
The submission server takes the domain from each recipient address and asks DNS for its mail exchangers. These are MX records, each with a preference number, and lower numbers are tried first:
$ dig +short MX example.com
10 mx1.example.com.
20 mx2.example.com.The sender then resolves the host names to addresses, using A and AAAA records, and connects to port 25 on the chosen host. Port 25 is the server-to-server port. Clients never use it for submission.
If the highest-priority host does not answer, the sender tries the next. If the MX lookup returns nothing, RFC 5321 falls back to the domain's address record, although a properly configured domain always publishes an MX.
Step 4: the server-to-server conversation
The sending server greets the recipient with EHLO, and the receiving server lists what it supports. If it offers STARTTLS, the sender usually upgrades the connection to TLS before sending the envelope and message. This is opportunistic by default. If the receiver does not offer TLS, or the certificate fails verification, many senders fall back to plaintext. That fallback is the gap that MTA-STS and DANE exist to close.
You can test the first part of this yourself:
$ openssl s_client -starttls smtp -connect mx1.example.com:25 -crlfThis shows the banner, the EHLO capabilities, and the certificate chain. Use it to check a server's TLS setup, not to send mail.
Step 5: acceptance and checks
The receiving server now checks the sender. It evaluates SPF against the envelope sender and the connecting IP address, verifies the DKIM signature over the signed headers and body, and evaluates DMARC by comparing the visible From domain with the SPF and DKIM results. Spam and malware checks run as well. The results are added to the message as headers, which you can read as described in reading email headers.
The receiver can accept the message, reject it with a 5xx code (a permanent failure that normally produces a bounce), or defer it with a 4xx code (a temporary failure). A 4xx tells the sending server to try again later.
Step 6: queues and retries
Sending servers keep a queue. A message deferred with a 4xx sits in the queue and is retried at increasing intervals, commonly over several hours to a few days, before the sender gives up and generates a bounce. Greylisting is a frequent reason for a first delivery attempt to be deferred and then accepted on retry. Busy servers, rate limits, and misconfigured DNS also produce deferrals.
When the message is accepted, it is written to the recipient's mailbox store, and the recipient's client sees it on its next sync. So "sent" in your client means only that your submission server accepted the message. Delivery to the final mailbox can take longer.
Where things go wrong
- Delayed: temporary failures and greylisting. Check the bounce or delay notice for the reason.
- Bounced immediately: a 5xx response, often for an unknown recipient or a policy rejection. The bounce message quotes the reason.
- Spam folder: the message was accepted but scored badly. Authentication failures are a common cause.
- Silent loss: rare, but possible if a server accepts a message and then fails to store it. This is why logs and queue behaviour matter to operators.
For ITProMail specifics, see troubleshooting delivery and bounce messages.