Email works through a store-and-forward system in which a sender's email application submits a message to a mail server, mail servers determine where the message should be delivered, and a receiving system stores it until the recipient accesses it. The process normally involves an email client or web interface, an outgoing mail server, DNS lookups, SMTP connections, a receiving mail server and a mailbox-access mechanism. Unlike a direct device-to-device messaging model, the sender and recipient do not normally need to be online simultaneously. The receiving server can accept and retain the message until the recipient's device connects later.
When a user sends an email, the email application constructs a message containing headers and body content and submits it to an authorised mail-submission service. Modern systems commonly use authenticated submission over an encrypted connection. The submission server checks credentials and policies before accepting the message for delivery. The message includes a recipient address containing a local part and a domain part, such as user@example.com. The sending infrastructure uses the domain to determine where mail should be sent. The visible From address and the authenticated submitting account can represent different information, which is one reason email authentication mechanisms are important.
The Domain Name System helps mail servers locate destination infrastructure. A sending mail server can query DNS for MX records associated with the recipient's domain. The MX records identify mail-exchange hosts responsible for receiving email for that domain, and those hostnames can then be resolved to IP addresses. The sending server establishes an SMTP connection to a suitable destination server and begins an SMTP dialogue. It identifies itself, specifies the sender and recipient envelope addresses, transfers the message data and receives a response indicating whether the receiving system accepted the message. If the destination cannot be reached immediately, the sending server can retry later rather than necessarily abandoning the message.
SMTP is primarily a message-transfer protocol rather than a mailbox-browsing protocol. Once the receiving mail server accepts a message, it stores the message in a mailbox or passes it to another internal processing component. Filtering systems may inspect the message for spam, malware, policy violations and authentication results before final delivery. If a message cannot be delivered permanently, the sender may receive a non-delivery notification. Temporary failures can result in repeated delivery attempts. This distributed architecture means email delivery is not always instantaneous and can involve several independent administrative domains.
The recipient's device accesses the mailbox through a retrieval or synchronisation system. IMAP is designed to maintain messages on the server and synchronise folders, message state and other mailbox information across multiple devices. POP traditionally focuses more on downloading messages to a client, although implementations can provide options for retaining copies on the server. Webmail uses a web application to access the mailbox through the provider's own infrastructure rather than requiring the user to configure a traditional mail client. The recipient may therefore read the same mailbox from a phone, computer and browser while the server remains the central storage location.
Email messages can contain multipart content because MIME defines structures for combining plain text, HTML, attachments and other media types. A message can therefore have a plain-text alternative and an HTML representation, allowing compatible clients to choose an appropriate format. Attachments are encoded for transport and reconstructed by the recipient's mail application. Mail providers may scan attachments and links, impose size limits or quarantine suspicious content. HTML email can contain remote resources such as images, which creates both formatting and privacy considerations because retrieving those resources can disclose information about when or from where a message was viewed.
Email security involves several layers. TLS can encrypt communication between mail systems, while authentication mechanisms such as SPF, DKIM and DMARC help receiving systems evaluate whether messages claiming to come from a domain are consistent with authorised sending infrastructure and domain policies. These mechanisms address different aspects of email trust and are not interchangeable. Encryption in transit also does not necessarily mean that the message is encrypted end to end. Additional end-to-end encryption systems can encrypt message content so that intermediaries cannot ordinarily read it, but deployment and key management are more complex and require compatible software and recipient keys.
Email works because many independent systems follow common protocols and addressing conventions. The sender's device does not need a permanent connection to the recipient's device, and domains can operate their own mail infrastructure while still communicating with other domains. DNS provides routing information, SMTP transports messages, receiving servers store them, and IMAP, POP or web interfaces provide access. The architecture is deliberately decentralised compared with a single proprietary messaging platform, although many users rely on large hosted providers. Its interoperability, asynchronous operation and standard protocols explain how an email sent from one provider can reach a recipient using a completely different provider.
