How Email Delivery Works: From DNS and MX Records to the Inbox

When you send an email, it looks simple: you write a message, click Send, and it appears in the recipient's inbox.

But behind that simple action, several systems work together.

If you're building a web application that sends or receives email, understanding this flow is extremely useful.

While building InboxOro, I spent a lot of time working with email infrastructure, DNS, SMTP, and message processing. In this post, I'll break down the basic journey of an email from the sender to the recipient's inbox.

The Basic Email Delivery Flow

At a high level, an email travels from the sender through DNS and the recipient's mail server before being processed and delivered to the recipient's inbox.

Let's break down what happens at each stage.

1. The Sender Creates an Email

Suppose I send an email to:

[e-mail]

My email client or application needs to determine where that email should be delivered.

The important part here is the domain:

example.com

The receiving mail infrastructure for that domain is discovered through DNS.

2. DNS Helps Find the Mail Server

DNS is commonly associated with things like website domains and IP addresses, but it also plays an important role in email delivery.

For email, one of the important DNS records is the MX record.

MX stands for Mail Exchange.

An MX record tells sending mail servers which servers are responsible for receiving email for a domain.

For example, a domain might have an MX record pointing to:

mail.example.com

The sending system can then resolve that hostname to an IP address and establish a connection to the receiving mail server.

3. The MX Record Determines Where Email Should Go

When an email is sent to [e-mail], the sending mail server looks up the DNS records for example.com.

It then checks the domain's MX records to determine which mail server is responsible for receiving messages.

A domain can have more than one MX record.

MX records also have priorities, which allow mail systems to determine which mail server should be tried first.

This becomes important for reliability and redundancy.

If the preferred mail server isn't available, the sending system may try another server based on the configured MX priorities.

4. SMTP Handles the Transfer

Once the sending system knows where to deliver the email, it can communicate with the receiving mail server using SMTP.

SMTP stands for Simple Mail Transfer Protocol.

The sending server connects to the receiving server and begins the SMTP conversation.

At a simplified level, the conversation can include commands such as:

EHLO

The sending server identifies itself.

MAIL FROM

The sending server provides the envelope sender address.

RCPT TO

The sending server specifies the recipient.

DATA

The sending server begins transmitting the actual message.

The receiving server then responds with SMTP status codes indicating whether each step was accepted.

The real SMTP conversation can be more complex, but these commands provide a basic understanding of how mail servers communicate.

5. The Receiving Mail Server Processes the Message

Receiving the message is not necessarily the end of the process.

The receiving infrastructure may perform several checks and processing steps.

For example, it may:

• Validate the recipient
• Check the message structure
• Inspect authentication information
• Apply spam filtering
• Apply security policies
• Process attachments
• Store the message
• Deliver it to the appropriate mailbox

This is one reason email infrastructure can become considerably more complicated than simply "sending an email."

A message can be successfully transmitted between mail servers but still be filtered, rejected, or handled differently by the receiving system.

6. Where SPF, DKIM, and DMARC Fit

Email authentication is another important part of modern email infrastructure.

Three terms you'll often encounter are SPF, DKIM, and DMARC.

SPF

Sender Policy Framework

SPF allows a domain to publish which servers are authorized to send email for that domain.

The receiving mail server can check the sender's domain and compare the sending server against the domain's published SPF policy.

DKIM

DomainKeys Identified Mail

DKIM adds a cryptographic signature to an email.

The receiving system can use the sender's published public key to verify the signature and determine whether the signed parts of the message have been altered.

DKIM also helps associate the message with the sending domain.

DMARC

Domain-based Message Authentication, Reporting, and Conformance

DMARC builds on SPF and DKIM.

It allows domain owners to publish policies describing how receiving systems should handle messages that don't pass the domain's authentication requirements.

These technologies are important parts of modern email delivery and domain reputation management.

7. The Message Reaches the Inbox

After the receiving infrastructure processes the message, it can be stored in the recipient's mailbox.

The user's email application can then retrieve or display the message.

At this point, what looked like a simple "Send" action has involved several different systems, including DNS, MX records, SMTP, authentication checks, filtering, and message storage.

8. What Happens With a Temporary Inbox?

A temporary email system follows many of the same fundamental email-delivery concepts.

For example, imagine a temporary address:

[e-mail]

The domain needs email-receiving infrastructure so that incoming messages can reach the appropriate system.

Once an email arrives, the mail server can pass the message to the application's email-processing system.

The application can then process the incoming message and make it available through the temporary inbox.

Depending on the system, additional processing might include:

• Parsing the email
• Extracting the sender
• Extracting the subject
• Detecting OTP codes
• Processing HTML content
• Handling attachments
• Storing message metadata
• Applying expiration rules
• Automatically deleting old messages

This is one of the areas I've been working on while building InboxOro.

9. Why Developers Should Understand This

You don't need to become an email infrastructure expert to build a web application.

But understanding the basic email flow helps when you're debugging problems such as:

• Emails aren't arriving
• Verification emails are delayed
• A domain isn't receiving mail
• MX records are incorrect
• Messages are being rejected
• Emails are going to spam
• Attachments aren't being processed
• Authentication checks are failing

Instead of thinking:

"The email didn't arrive."

You can start asking more specific questions:

Did DNS resolve correctly?

Does the domain have the correct MX record?

Could the sending server connect to the receiving server?

Was the message accepted?

Did filtering reject it?

Was the message stored correctly?

That change in perspective makes debugging much easier.

Conclusion

Email delivery involves much more than clicking the Send button.

Behind a single email are multiple systems working together, including DNS, MX records, SMTP, authentication mechanisms, filtering systems, mail servers, and message storage.

Understanding these components gives developers a better foundation for building applications that depend on email.

I'm exploring these systems while building InboxOro, a temporary email and email infrastructure platform, and I'll share more of what I learn about email processing, APIs, and developer tooling in future posts.