MDA (Mail Delivery Agent): what it is and how final delivery works

MDA (Mail Delivery Agent) is the software component responsible for the last leg of the journey: accepting a message from the MTA (Mail Transfer Agent) and writing it into the recipient's mailbox. If the MTA is the postal truck that carries letters between cities, the MDA is the carrier who drops the envelope into the door slot.

In the email processing chain, the MDA sits at the end. The sender composes a message in their MUA (mail client), the MUA hands it to the MTA over SMTP, the MTA routes it to the recipient's server, and the MDA takes it from there and writes it to storage.

Where the MDA fits in email architecture

Mail infrastructure has three main components:

• MUA (Mail User Agent) — the client through which a user reads and writes mail: Thunderbird, Outlook, the Gmail mobile app.
• MTA (Mail Transfer Agent) — the server that accepts messages over SMTP and relays them between nodes: Postfix, Exim, Sendmail.
• MDA (Mail Delivery Agent) — the agent that picks up a message from the MTA and places it into a mailbox: Dovecot LDA, Procmail, maildrop.

In practice the boundaries blur. Postfix includes a built-in local delivery agent that can handle MDA duties without any external program. In more complex setups, though, the MDA runs as a separate process because it takes on tasks that go beyond simply writing a file to disk.

What an MDA does beyond writing to the mailbox

A modern MDA is more than a file writer. Before placing a message into storage, it runs through a chain of steps:

• Rule-based filtering. The MDA can route messages into different folders based on headers, sender, subject, or size. Dovecot uses the Sieve language (RFC 5228) for this; Procmail has its own recipe syntax.
• Quota enforcement. The MDA checks whether the mailbox has space. If the box is full, it rejects the message and returns a 4xx temporary error to the MTA, which triggers a soft bounce and a retry. A hard policy returns 5xx instead, producing an immediate hard bounce.
• Vacation autoresponder.Out-of-office replies are generated by the MDA through the Sieve vacation extension. The MDA tracks who has already received an autoresponse to avoid creating mail loops.
• Index updates. Dovecot updates its search indexes at delivery time, which lets an IMAP client find messages instantly without scanning files on disk.

Storage formats: Maildir and mbox

An MDA writes messages in one of two main formats:

• mbox — all messages in a folder live in a single file, separated by "From " lines. Simple, but problematic at scale: the file must be locked during writes, random access to individual messages is slow, and a crash mid-write can corrupt the whole folder.
• Maildir — each message is its own file inside a directory tree (new/, cur/, tmp/). No locking needed, operations are atomic, concurrent access is safe. Most modern servers use Maildir.

The storage format affects performance and reliability but not the end-user experience. The IMAP server abstracts it away; the client sees the same folders and messages either way.

Common MDAs

• Dovecot LDA / LMTP. Dovecot is primarily an IMAP/POP3 server, but it ships its own delivery agent. Dovecot LDA is invoked as an external program by Postfix or Exim. LMTP (Local Mail Transfer Protocol) is the network variant: instead of spawning a process, the MTA hands the message to Dovecot over the LMTP protocol. LMTP is preferable in distributed setups where the MTA and mailstore live on separate servers.
• Procmail. A classic Unix-era MDA with a powerful filtering system configured through .procmailrc. The project stopped being maintained in 2001 but still turns up on older servers.
• maildrop. A maintained alternative to Procmail. Supports Maildir, virtual users, and quotas. Often paired with Courier IMAP.

MDA and bounce messages

When the MDA cannot deliver a message (mailbox full, user does not exist, a Sieve filter rejected it), it returns an error code to the MTA. The MTA generates a bounce message (DSN: Delivery Status Notification) and sends it back to the original sender.

The bounce type depends on the error code. A 452 (insufficient storage) causes the MTA to retry delivery for several days. A 550 (user unknown) produces an immediate hard bounce. For bulk senders, a 550 means the address should be removed from the list.

MDA in cloud mail services

Gmail, Outlook.com, and Yahoo Mail all run proprietary MDAs that are not accessible from outside. The logic is the same: accept the message from the MTA, apply filters (spam scoring, categorization, user rules), write to storage. The difference is scale: instead of Maildir on one server, these services use distributed storage across thousands of machines. Conceptually the MDA is still the same component performing final delivery.

MDA and email validation

During SMTP-level address validation, the checking service sends a RCPT TO command to the recipient's MTA. The MTA may consult the MDA to confirm whether the mailbox exists. If the MDA acknowledges the user, the MTA responds with 250 OK. If not, it returns 550 User unknown. That response is what a validator uses to determine address status.

Some MTAs, however, accept every address at the RCPT TO stage (accept-all), deferring the actual check to the MDA at delivery time. In those cases SMTP validation cannot determine whether a mailbox exists, and the address gets marked as indeterminate.