What systems handle each step (client → MTA → DNS → receiving MTA)?

You hit send. Now what? Your email doesn't magically jump from your outbox to someone else's inbox. It passes through a series of systems, each with a specific job. Here's who does what.

The sending client (your email app, your ESP's interface, or an API call) composes the message and hands it off to a sending MTA (Mail Transfer Agent). The MTA is the actual mail server doing the work. If you're using Mailchimp or SendGrid, they run the MTA infrastructure for you. If you're self-hosting, you're probably running Postfix, Exim, or something similar.

Once the sending MTA has your message, it needs to figure out where to deliver it. That's where DNS comes in. The MTA queries DNS to fetch the recipient domain's MX record (Mail Exchanger record), which lists the mail servers that accept mail for that domain. DNS resolvers translate those hostnames into IP addresses the MTA can actually connect to.

Now the sending MTA connects to the receiving MTA listed in the MX record using SMTP (Simple Mail Transfer Protocol). The two servers have a conversation. The receiving MTA doesn't just accept the message blindly. It runs a series of checks: SPF (is this server allowed to send for this domain?), DKIM (is the message cryptographically signed?), DMARC (what should happen if SPF or DKIM fail?), sender reputation, spam scoring, and content analysis. Based on those checks, it decides whether to accept the message, reject it, or delay it.

If everything checks out, the receiving MTA passes the message to the recipient's mailbox, and it shows up in their inbox (or spam folder, or promotions tab, depending on those checks).

And worth noting: if DNS lookup fails at any step, delivery stalls. That's why DNS issues are such common culprits when emails don't arrive. You can test your DNS setup with our free SPF checker to make sure your MX and SPF records are configured correctly.