- by x32x01 ||
Have you ever sent an important email, seen it appear in your Sent folder, and wondered how it reached someone using a completely different email provider?
For example, you use Outlook, but the recipient uses Gmail. How does Outlook find the right mail server? How does Gmail verify that the sender is allowed to send emails for a particular domain? And why can a message arrive late or end up in the Spam folder even when the email address is correct?
The answer involves several technologies working together: DNS, SMTP, delivery queues, SPF, DKIM, DMARC, and spam filtering.
Let's walk through the entire process, from the moment you click Send to the moment the email reaches the recipient's mailbox.
The simplified process looks like this:
However, there's a problem: your email application needs to know which mail server is responsible for receiving messages for the recipient's domain.
For example, if you send a message to
This is where DNS comes in.
An MX record identifies the mail servers responsible for receiving email for a domain.
When a sending mail server needs to deliver a message, it performs an MX lookup for the recipient's domain.
The process looks like this:
The domain's MX records tell the sending server which mail servers to contact. The server then resolves the selected mail server's hostname to an IP address when needed.
MX records can also include priorities, allowing administrators to specify preferred and backup mail servers.
For example, a domain might have multiple MX records with different priority values. A server with a lower numerical preference value is generally preferred over one with a higher value.
Important: MX records identify the servers responsible for receiving email. They don't authenticate the sender or guarantee that a message will reach the inbox.
That protocol is SMTP, which stands for Simple Mail Transfer Protocol.
SMTP is used to submit and relay email. Email applications commonly submit outgoing messages to their provider's mail service, while mail servers use SMTP to transfer messages to other mail servers.
A simplified delivery flow looks like this:
For example, when you send a message from Outlook to a Gmail address, Outlook typically submits the message to its configured outgoing mail service. That service handles the next stages of delivery.
The sending server establishes an SMTP connection to the appropriate receiving server and attempts to transfer the message.
But what happens if the receiving server is temporarily unavailable?
The message doesn't necessarily disappear. Most production mail systems use delivery queues and retry mechanisms to handle these situations.
To handle temporary failures, mail systems typically place outgoing messages in a delivery queue and retry them later.
SMTP response codes help the sending server understand what happened.
For example, if the recipient's server returns a temporary error, the sending system may keep the message queued and try again after a delay.
If the recipient address doesn't exist and the receiving server returns a permanent rejection, the sending system may generate a delivery failure notification.
This explains why an email can take minutes or longer to arrive.
Seeing a message in your Sent folder doesn't necessarily mean it reached the recipient's inbox. It generally means your email application successfully submitted or recorded the outgoing message, depending on the service's implementation.
There's another important problem: how can a receiving server determine whether a sender is authorized to use a particular domain?
An attacker could create a mail server and attempt to send a message that displays
The displayed sender address alone isn't sufficient proof of identity.
Three important email authentication technologies help domain owners reduce this type of spoofing:
It allows a domain owner to publish a DNS record describing which sending servers are authorized to send email using that domain in the SMTP envelope identity.
For example, a company might use an external email delivery provider. Its SPF policy can authorize the appropriate sending infrastructure.
When a receiving server evaluates SPF, the simplified process is:
If the sending IP address is authorized under the relevant SPF policy, the check may pass. Otherwise, it may fail or produce another SPF result, depending on the circumstances.
However, there's an important detail: SPF doesn't directly authenticate the visible From address.
SPF normally checks the domain associated with the SMTP MAIL FROM identity, or the HELO identity in certain circumstances.
That means an email can pass SPF while displaying a different domain in its From address.
This limitation is one of the reasons DKIM and DMARC are also important.
It uses digital signatures to help receiving servers verify that specific parts of an email haven't changed since the message was signed.
The sending system signs selected message headers and, depending on the signature configuration, the message body. It generates the signature using a private key.
The corresponding public key is published in DNS, allowing receiving servers to verify the signature.
Here's the simplified process:
A DKIM signature includes a signing domain and a selector that helps the receiving server locate the appropriate public key in DNS.
If signature verification succeeds, the receiving server gains evidence that the signed content has not been altered in a way that invalidates the signature.
It also establishes that the signature corresponds to the signing domain and its published key.
However, DKIM has limits.
A valid DKIM signature doesn't automatically prove that the message is trustworthy, that the visible sender is who they claim to be, or that the email is safe to open.
A legitimate domain can send unwanted email, and an attacker may abuse a compromised account or authorized sending service.
DKIM is therefore one part of a broader email authentication system.
This is where DMARC comes in.
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance.
It introduces a concept called alignment.
Alignment checks whether the domain authenticated by SPF or the domain associated with a valid DKIM signature matches, or is aligned with, the domain in the visible From address according to the domain owner's DMARC settings.
For a message to pass DMARC, at least one of these conditions must be satisfied:
A domain owner publishes a DMARC policy in DNS to tell receiving systems how to handle messages that fail DMARC evaluation.
The three main policy values are:
The receiving provider ultimately decides how to apply the policy, subject to its own processing rules.
The evaluation process looks like this:
DMARC also supports reporting mechanisms that help domain owners identify authentication failures and understand how their domains are being used.
These reports can be valuable when configuring legitimate email services or investigating potential spoofing.
Does that guarantee delivery to the inbox?
No. Authentication and spam detection are different processes.
Email authentication helps verify the sending infrastructure's authorization and the integrity of signed message data. Spam filtering evaluates whether a message should be treated as unwanted, suspicious, or potentially harmful.
Receiving systems may consider many additional signals, including:
For example, a legitimate company may pass every authentication check but still have poor sending reputation because it repeatedly sends unwanted messages.
Likewise, an email from a compromised account may pass authentication checks even though its content is malicious.
Passing SPF, DKIM, and DMARC improves email authentication, but it doesn't guarantee inbox placement or prove that a message is safe.
Opening thousands of simultaneous SMTP connections and attempting to deliver every message at once can put unnecessary pressure on the sending infrastructure. It can also trigger rate limits or temporary rejections from receiving providers.
Large email systems therefore use queues, workers, connection management, and rate controls.
A simplified architecture looks like this:
Each worker processes messages from the queue and attempts delivery according to the system's rules.
A well-designed system may:
There are two common categories:
Tracking bounces is essential for reliable email delivery. Repeatedly sending messages to invalid addresses can harm sender reputation and reduce deliverability.
Email systems should suppress confirmed invalid recipients and investigate repeated temporary failures rather than retrying indefinitely.
This is a conceptual architecture, not an exact representation of Gmail's or Outlook's internal implementation.
Real email services may include additional systems for authentication, policy enforcement, malware scanning, message routing, filtering, storage, and mailbox rules. Some checks may occur at different stages or be performed by different components.
Still, the diagram captures the essential idea: email delivery involves multiple systems, each responsible for a different part of the process.
The most important lesson is that sending an email isn't simply a request traveling from one server to another.
It's a process involving DNS lookups, SMTP connections, authentication checks, queues, retries, reputation systems, and recipient-side decisions.
These components work together, but they don't all guarantee the same thing.
A successful SMTP submission doesn't necessarily mean the message reached the destination server. Acceptance by the receiving server doesn't guarantee inbox placement. And an authenticated email isn't automatically trustworthy.
This is also a great example of a distributed system: you can control your own sending infrastructure, but you don't control every decision made by the systems receiving your messages.
Understanding that distinction makes it much easier to troubleshoot delayed emails, authentication failures, rejected messages, and unexpected Spam folder placement.
For example, you use Outlook, but the recipient uses Gmail. How does Outlook find the right mail server? How does Gmail verify that the sender is allowed to send emails for a particular domain? And why can a message arrive late or end up in the Spam folder even when the email address is correct?
The answer involves several technologies working together: DNS, SMTP, delivery queues, SPF, DKIM, DMARC, and spam filtering.
Let's walk through the entire process, from the moment you click Send to the moment the email reaches the recipient's mailbox.
📩 1. How Does an Email Reach Another Mail Server?
At first, sending an email might seem straightforward. Your email application sends the message directly to the recipient's server, and the server delivers it to the inbox.The simplified process looks like this:
Code:
Sender
↓
Send Email
↓
Recipient Mail Server
↓
Recipient InboxFor example, if you send a message to
rawan@example.com, knowing the email address alone doesn't tell your application which server should receive it.This is where DNS comes in.
🌐 2. How DNS MX Records Find the Recipient's Mail Server
DNS (Domain Name System) helps applications find services associated with domain names. For email delivery, the important record type is the MX record, short for Mail Exchange.An MX record identifies the mail servers responsible for receiving email for a domain.
When a sending mail server needs to deliver a message, it performs an MX lookup for the recipient's domain.
The process looks like this:
Code:
Recipient: rawan@example.com
↓
Extract Domain: example.com
↓
DNS MX Lookup
↓
Find the Destination Mail Server
↓
Connect to the Mail ServerMX records can also include priorities, allowing administrators to specify preferred and backup mail servers.
For example, a domain might have multiple MX records with different priority values. A server with a lower numerical preference value is generally preferred over one with a higher value.
Important: MX records identify the servers responsible for receiving email. They don't authenticate the sender or guarantee that a message will reach the inbox.
✉️ 3. How SMTP Transfers Email Between Servers
Once the sending server identifies the destination, it needs a protocol to transfer the message.That protocol is SMTP, which stands for Simple Mail Transfer Protocol.
SMTP is used to submit and relay email. Email applications commonly submit outgoing messages to their provider's mail service, while mail servers use SMTP to transfer messages to other mail servers.
A simplified delivery flow looks like this:
Code:
Email Client
↓
Outgoing Mail Server
↓
DNS MX Lookup
↓
SMTP Connection
↓
Recipient Mail ServerThe sending server establishes an SMTP connection to the appropriate receiving server and attempts to transfer the message.
But what happens if the receiving server is temporarily unavailable?
The message doesn't necessarily disappear. Most production mail systems use delivery queues and retry mechanisms to handle these situations.
⏳ 4. Why Email Delivery Can Be Delayed
Email delivery isn't always immediate. A receiving server might be temporarily unavailable, overloaded, or unable to accept messages at that moment.To handle temporary failures, mail systems typically place outgoing messages in a delivery queue and retry them later.
Code:
Outgoing Mail Server
↓
Delivery Queue
↓
Attempt Delivery
↓
Successful Delivery?
├── Yes → Complete Delivery
└── No
↓
Temporary Failure?
├── Yes → Retry Later
└── No → Report Failure2xx: The requested SMTP operation succeeded.4xx: A temporary failure occurred, so retrying may help.5xx: A permanent failure occurred, so retrying the same request usually won't solve the problem.
For example, if the recipient's server returns a temporary error, the sending system may keep the message queued and try again after a delay.
If the recipient address doesn't exist and the receiving server returns a permanent rejection, the sending system may generate a delivery failure notification.
This explains why an email can take minutes or longer to arrive.
Seeing a message in your Sent folder doesn't necessarily mean it reached the recipient's inbox. It generally means your email application successfully submitted or recorded the outgoing message, depending on the service's implementation.
🔐 5. How Do SPF, DKIM, and DMARC Protect Email?
Finding the destination server and transferring a message are only part of the process.There's another important problem: how can a receiving server determine whether a sender is authorized to use a particular domain?
An attacker could create a mail server and attempt to send a message that displays
support@google.com in its visible From address.The displayed sender address alone isn't sufficient proof of identity.
Three important email authentication technologies help domain owners reduce this type of spoofing:
- SPF: Checks whether a sending server is authorized under a domain's published policy.
- DKIM: Uses a digital signature to help verify the integrity of signed message content and its association with a signing domain.
- DMARC: Connects SPF and DKIM authentication results to the domain shown in the visible From address and defines a policy for handling failures.
🛡️ 6. What Is SPF (Sender Policy Framework)?
SPF stands for Sender Policy Framework.It allows a domain owner to publish a DNS record describing which sending servers are authorized to send email using that domain in the SMTP envelope identity.
For example, a company might use an external email delivery provider. Its SPF policy can authorize the appropriate sending infrastructure.
When a receiving server evaluates SPF, the simplified process is:
Code:
Incoming Email
↓
Identify the SMTP Envelope Domain
↓
Check the Sending IP Address
↓
Look Up the SPF Record
↓
Evaluate the SPF ResultHowever, there's an important detail: SPF doesn't directly authenticate the visible From address.
SPF normally checks the domain associated with the SMTP MAIL FROM identity, or the HELO identity in certain circumstances.
That means an email can pass SPF while displaying a different domain in its From address.
This limitation is one of the reasons DKIM and DMARC are also important.
✍️ 7. What Is DKIM (DomainKeys Identified Mail)?
DKIM stands for DomainKeys Identified Mail.It uses digital signatures to help receiving servers verify that specific parts of an email haven't changed since the message was signed.
The sending system signs selected message headers and, depending on the signature configuration, the message body. It generates the signature using a private key.
The corresponding public key is published in DNS, allowing receiving servers to verify the signature.
Here's the simplified process:
Code:
Outgoing Email
↓
Sign Selected Message Data
↓
Use the Private Key
↓
Send Email
↓
Recipient Mail Server
↓
Retrieve Public Key from DNS
↓
Verify DKIM SignatureIf signature verification succeeds, the receiving server gains evidence that the signed content has not been altered in a way that invalidates the signature.
It also establishes that the signature corresponds to the signing domain and its published key.
However, DKIM has limits.
A valid DKIM signature doesn't automatically prove that the message is trustworthy, that the visible sender is who they claim to be, or that the email is safe to open.
A legitimate domain can send unwanted email, and an attacker may abuse a compromised account or authorized sending service.
DKIM is therefore one part of a broader email authentication system.
🧩 8. What Is DMARC and Why Is It Necessary?
SPF and DKIM provide useful authentication checks, but receiving servers also need a way to connect those results to the domain users see in the From field.This is where DMARC comes in.
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance.
It introduces a concept called alignment.
Alignment checks whether the domain authenticated by SPF or the domain associated with a valid DKIM signature matches, or is aligned with, the domain in the visible From address according to the domain owner's DMARC settings.
For a message to pass DMARC, at least one of these conditions must be satisfied:
- SPF passes and the authenticated SPF domain aligns with the visible From domain.
- DKIM passes and the signing domain aligns with the visible From domain.
A domain owner publishes a DMARC policy in DNS to tell receiving systems how to handle messages that fail DMARC evaluation.
The three main policy values are:
| DMARC Policy | Purpose |
|---|---|
p=none | Monitor authentication results without requesting a specific quarantine or rejection action |
p=quarantine | Request that failing messages be treated as suspicious, often by directing them to Spam |
p=reject | Request rejection of messages that fail DMARC |
The evaluation process looks like this:
Code:
Incoming Email
↓
SPF and DKIM Evaluation
↓
Check Domain Alignment
↓
Evaluate DMARC Policy
↓
Apply Receiving Server's HandlingThese reports can be valuable when configuring legitimate email services or investigating potential spoofing.
📬 9. Why Can an Authenticated Email Still Go to Spam?
Suppose a message passes SPF, DKIM, and DMARC.Does that guarantee delivery to the inbox?
No. Authentication and spam detection are different processes.
Email authentication helps verify the sending infrastructure's authorization and the integrity of signed message data. Spam filtering evaluates whether a message should be treated as unwanted, suspicious, or potentially harmful.
Receiving systems may consider many additional signals, including:
- IP and domain reputation: Whether the sending infrastructure has a history of trustworthy or abusive behavior.
- Sending patterns: Whether message volume or frequency looks unusual.
- Message content: Whether the message resembles spam, phishing, or other unwanted content.
- User engagement: How recipients interact with messages, where those signals are available.
- Recipient settings: Whether the user has blocked the sender, created a filter, or configured other mailbox rules.
Code:
Email Authentication
↓
Reputation and Spam Evaluation
↓
Recipient Rules and Other Checks
↓
Inbox / Spam / Rejection / Other HandlingLikewise, an email from a compromised account may pass authentication checks even though its content is malicious.
Passing SPF, DKIM, and DMARC improves email authentication, but it doesn't guarantee inbox placement or prove that a message is safe.
⚙️ 10. How Do Mail Servers Handle Large Email Campaigns?
Imagine sending a newsletter to 100,000 recipients.Opening thousands of simultaneous SMTP connections and attempting to deliver every message at once can put unnecessary pressure on the sending infrastructure. It can also trigger rate limits or temporary rejections from receiving providers.
Large email systems therefore use queues, workers, connection management, and rate controls.
A simplified architecture looks like this:
Code:
Email Campaign
↓
Message Queue
↓
Delivery Workers
↓
Managed SMTP Connections
↓
Recipient Mail ServersA well-designed system may:
- Control how many messages are sent per second.
- Limit concurrent connections to each destination domain.
- Retry temporary failures with appropriate delays.
- Track successful deliveries and permanent failures.
- Pause or reduce sending when a receiving provider applies rate limits.
- Monitor sender reputation and authentication results.
📊 What Are Email Bounces?
A bounce is a notification that an email couldn't be delivered or accepted.There are two common categories:
- Hard bounce: A permanent delivery failure, such as a confirmed nonexistent recipient address.
- Soft bounce: A temporary delivery problem, such as a full mailbox or a temporarily unavailable receiving server.
Tracking bounces is essential for reliable email delivery. Repeatedly sending messages to invalid addresses can harm sender reputation and reduce deliverability.
Email systems should suppress confirmed invalid recipients and investigate repeated temporary failures rather than retrying indefinitely.
🏗️ 11. Putting the Entire Email Architecture Together
Now let's combine the main components into one simplified view. Code:
User
↓
Email Client
↓
Outgoing Mail Service
↓
Delivery Queue
↓
SMTP Delivery Worker
↓
DNS MX Lookup
↓
Recipient Mail Server
↓
SPF / DKIM / DMARC Evaluation
↓
Spam and Reputation Checks
↓
Recipient Mailbox or Other HandlingReal email services may include additional systems for authentication, policy enforcement, malware scanning, message routing, filtering, storage, and mailbox rules. Some checks may occur at different stages or be performed by different components.
Still, the diagram captures the essential idea: email delivery involves multiple systems, each responsible for a different part of the process.
🧠 12. Key Takeaways
Here's what each major component does:| Technology | Main Purpose |
|---|---|
| DNS MX records | Identify the mail servers responsible for receiving email for a domain |
| SMTP | Submit and transfer email messages between mail systems |
| Delivery queues | Store messages awaiting delivery |
| Retries | Handle temporary delivery failures |
| SPF | Check whether a sending server is authorized for the relevant envelope domain |
| DKIM | Verify a digital signature associated with a signing domain |
| DMARC | Evaluate aligned SPF or DKIM authentication and publish a policy for failures |
| Spam filtering | Evaluate unwanted or suspicious messages using additional signals |
| Bounce handling | Track and respond to failed deliveries |
It's a process involving DNS lookups, SMTP connections, authentication checks, queues, retries, reputation systems, and recipient-side decisions.
These components work together, but they don't all guarantee the same thing.
A successful SMTP submission doesn't necessarily mean the message reached the destination server. Acceptance by the receiving server doesn't guarantee inbox placement. And an authenticated email isn't automatically trustworthy.
This is also a great example of a distributed system: you can control your own sending infrastructure, but you don't control every decision made by the systems receiving your messages.
Understanding that distinction makes it much easier to troubleshoot delayed emails, authentication failures, rejected messages, and unexpected Spam folder placement.