What actually happens in the seconds after you hit send

You click send. The compose window closes. If you’re fast, you’re already onto the next email before the first one has technically gone anywhere.

That feeling of instantness is doing a lot of work to hide what’s actually happening. In the time it takes you to glance away, your email has left your server, asked a stranger’s DNS records where to go, knocked on a door it’s never opened before, negotiated an encrypted connection, and been judged — accepted, rejected, or quietly filed away — by a system that has never seen you before and has to decide, in real time, whether to trust you. Here’s that sequence, slowed down.

Step 1: the handoff you don’t see

The moment you hit send, your mail client stops being the thing doing the work. It hands the message to a sending server — yours, if you’re using your own domain and mailbox, or a provider’s infrastructure acting on your behalf — and that server takes ownership of getting it delivered. Your client’s job is done; it can tell you “sent” and move on, even though the actual delivery hasn’t started yet.

Step 2: asking where the recipient even lives

Your server knows the recipient’s address — name@theircompany.com — but an email address isn’t a location, it’s a name. Before anything can be sent, your server has to ask the internet’s directory system, DNS, a very specific question: which servers are authorized to receive mail for theircompany.com?

The answer comes back as an MX (Mail Exchange) record — usually more than one, each with a priority number. Lower numbers get tried first; if the top-priority server doesn’t answer, your server works down the list. This is also the exact mechanism that breaks when a domain’s DNS is misconfigured: no MX record, and there’s nowhere to even attempt delivery — the message fails before a single byte of content is transmitted.

Step 3: knocking, politely, in an encrypted room

With an address in hand, your server opens a connection directly to the recipient’s mail server — no intermediary, just one server talking to another over the open internet. The two negotiate an encrypted channel using TLS, the same technology that secures your browser’s padlock icon, via a process called STARTTLS: the connection starts in plain text just long enough to agree “let’s encrypt from here,” then upgrades.

Modern TLS versions compress this negotiation into a single round trip between the two servers, which is part of why the whole handshake finishes in milliseconds rather than seconds — network latency between the two servers usually matters more than the protocol overhead at this point.

Step 4: the message actually moves

Only now does the content itself transfer — headers first (who it’s from, who it’s to, the subject, the authentication signatures), then the body. This is also where SPF and DKIM get checked: the receiving server verifies that your sending server was actually authorized to send as your domain, and that the message wasn’t altered in transit. Fail either one and everything downstream gets more suspicious by default, regardless of what the email says.

Step 5: the verdict, computed before you’d notice a delay

This is the step that decides everything, and it happens fastest of all. The receiving server runs its spam-filtering system against your message — reputation history, authentication results, and a content read — and returns one of three answers: accept it into the inbox, quarantine it into spam, or reject the connection outright. We’ve written separately about how that filtering actually works and what a rejection versus a quarantine actually looks like from your side — the short version here is that this judgment is not a separate, later step. It happens inline, during the same connection, before the receiving server even finishes accepting the message.

Why the speed is the part that should unsettle you

Here’s the detail that matters for anyone sending outreach at any real volume: none of this waits for a human, and none of it gives you a second chance mid-flight. A brand-new sending domain runs through the exact same five steps as one that’s been sending cleanly for two years — the difference isn’t in the mechanics, it’s entirely in what the receiving server already knows about you from every message you’ve sent before this one. That’s why warming up a new domain gradually matters so much more than it sounds like it should: you’re not teaching the protocol anything, you’re building the only input that actually varies between sender and sender.

What Norbelys does with those two seconds

This whole sequence is exactly what Norbelys is built to get right on your behalf, every single send, without you having to think about DNS propagation or TLS negotiation or SPF alignment ever again. Domain health monitoring checks your MX, SPF, DKIM and DMARC records continuously — not just the day you set them up — so step 2 and step 4 above never quietly break without you noticing. Warmup handles the reputation-building that determines how step 5 goes for a new mailbox, and every send runs through infrastructure that’s already authenticated and trusted at scale, instead of a fresh domain hoping for the best on its first real morning of volume.

You don’t need to understand MX priority or TLS round trips to send outreach that lands. You need a platform that’s already handled that part correctly, every time, before your message is even a candidate for the inbox. See what a properly configured send actually looks like — start sending with Norbelys, and let the two-second journey above happen in your favor by default.