How transactional email actually works: from API call to inbox

Your code sends JSON - from, to, subject, html, text - with an API key in the Authorization header. The provider checks the request before accepting it: is the key valid, is the from domain verified on this account, is any recipient on the suppression list, is the account within its quota? Any of those failing comes back straight away as a 4xx with a machine-readable error type, not as a bounce email hours later.

If everything checks out you get 200 with an id. That id is the message's permanent handle - store it next to the order or user it belongs to, because every event about this email will carry it.

The provider builds the MIME message - headers, a multipart body with your HTML and text, attachments - and signs it with DKIM. The signature covers the body and key headers, uses a private key held by the provider, and names your domain in its d= tag. Anyone can later check it against the public key published in your DNS.

It also sets the envelope sender, called the Return-Path or MAIL FROM. This is not the From address your recipient sees; it is where bounces go. On Sendpository it lives on a sp. subdomain of your domain, so bounces come back to us to be processed and your own SPF record is never edited.

The sending server looks up the MX record for the recipient's domain - for gmail.com, Google's mail servers - opens an SMTP connection, upgrades it to TLS, and hands the message over. This is the step an email API saves you from writing: connection handling, TLS, per-provider throttling and retries all happen here.

Before accepting, the receiving server authenticates the message. SPF checks the connecting IP against the envelope sender's domain. DKIM verifies the signature. DMARC checks that at least one of those passed for the domain in the visible From line. The message is then scored for spam using those results, the sending domain's reputation, and its content.

The server answers with a three-digit SMTP code. 250 means accepted - into the inbox or the spam folder, which the sender is never told. A 4xx means "not now" (mailbox full, rate limited, greylisted) and the sender should retry. A 5xx means permanent failure, such as an address that doesn't exist.

The provider turns every outcome into an event on the message: email.delivered, email.delayed, email.bounced, email.complained when the recipient marks it as spam, and email.opened or email.clicked if you enabled tracking. Each is recorded on the message's timeline and posted to your webhook.