1) From your browser to Google (submission)

You: You compose an email in Gmail (attach your CV, hit Send).
Transport: Your browser or Gmail mobile app talks to Google over HTTPS (HTTP/2 or HTTP/3 over TLS).
At Google’s edge:

• Google authenticates your account (OAuth/session).

• Gmail builds a standards-compliant message: headers (From, To, Subject, Date, unique Message-ID), a MIME body (text + attachment part), and base64-encodes the attachment if needed.

• Gmail may compress the body where appropriate and checks size limits.

• Gmail signs the message with DKIM (adds a DKIM-Signature header).

• The envelope sender is set (often bounce+...@gmail.com) for delivery status handling.

• SPF/DMARC alignment is ensured for the domain you’re sending from (gmail.com).

Key protocols here: HTTPS/TLS, MIME, DKIM, DMARC (policy), SPF (published by the sending domain).

2) Google acts as your MSA/MTA (outbound transfer)

Gmail’s outbound mail transfer agents (MTAs) now have to deliver your message to the recipient’s domain.

a) Find where to deliver:

• Google’s MTA queries DNS for the recipient domain’s MX records.

• If multiple MX hosts exist, the MTA uses their priority (lowest preference value first) and tries in order; if no MX is present, it may fall back to the domain’s A/AAAA record.

b) Open an SMTP session to the chosen MX:

• Gmail’s MTA connects on SMTP (TCP port 25).

• It uses ESMTP features (e.g., PIPELINING, 8BITMIME, SIZE).

• It attempts STARTTLS to encrypt the hop; if the recipient enforces MTA-STS or DANE, Gmail follows those rules. If STARTTLS isn’t offered and no policy requires it, Gmail may still deliver in clear (opportunistic TLS).

c) Transfer the message:
Typical command flow: EHLO → (STARTTLS) → EHLO → MAIL FROM → RCPT TO → DATA → message body → . → QUIT.

Key protocols: DNS (MX, A/AAAA), SMTP/ESMTP, STARTTLS, optionally MTA-STS/DANE for transport security policy.

3) The recipient side (inbound acceptance)

If the recipient’s server is up and willing to accept mail:

• It evaluates the connection and message:

  • IP reputation / rate limiting

  • SPF check (does the sending IP match the domain’s SPF?)

  • DKIM verification (valid signature?)

  • DMARC policy (does From: align with SPF/DKIM?)

  • Spam/virus scanning of the MIME parts and your CV attachment

• If all looks reasonable, it replies 250 OK after DATA to accept the message.

• The server stores it in the recipient’s mailbox (Mail Delivery Agent / storage).

Now the message is “delivered” server-side, but not yet read.

4) How the recipient actually reads it

• Their mail client (Outlook, Apple Mail, Gmail app, etc.) accesses the mailbox over IMAP (most common) or POP3, almost always protected with TLS.

• The client downloads headers and, when opened, the body and attachment.

• They open the CV attachment (still the same MIME part you sent).

Key protocols: IMAPS (IMAP over TLS) or POP3S, plus HTTPS if they use webmail.

What if the recipient’s mail server is temporarily down?

This is where SMTP’s design for store-and-forward with retry really helps.

A) Temporary failure detected

When Gmail’s MTA tries to deliver:

• The DNS resolves, but the server won’t accept mail (e.g., maintenance, overloaded), or the TCP connection fails, or it responds with a 4xx temporary SMTP code such as:

  • 421 Service not available

  • 450 Mailbox unavailable

  • 451 Local error in processing

  • 452 Insufficient system storage

Result: Delivery is deferred, not failed.

B) Queueing and retries (exponential backoff)

• Gmail queues the message and retries periodically.

• Retry intervals typically grow (exponential backoff) to reduce load.

• Gmail keeps trying for a maximum retry window (commonly several days). During this period you may see a “Deferred” or “Delivery incomplete” status if you check message details.

C) Secondary/backup MX and failover

• If the recipient domain publishes multiple MX records, Gmail will try the next one by priority.

• If a backup MX exists, that server may accept the message and queue it locally until the primary comes back, then forward it internally. From your perspective, the email is “delivered” (accepted by an MX), even though the recipient might not see it until their primary processes the queue.

D) When the server comes back

• On a subsequent retry, gmail’s MTA connects again, the server replies 250 OK, and delivery completes. The recipient’s mailbox gets the message timestamped with the final acceptance time (headers will also show the earlier “Received:” hops).

E) If the outage lasts too long

• If all retries fail past Gmail’s max retry window, Gmail gives up and sends you a bounce / Delivery Status Notification (DSN) with a 5.x.x permanent failure code explaining the reason (e.g., 452 4.2.2 The email account that you tried to reach is over quota).

• Your original message is not lost while queued; it’s either eventually delivered or returned to you with an explanation.

What changes if the server is up but rejects the message permanently?

• If the recipient’s server responds with 5xx on first attempt (e.g., policy block, invalid address, domain does not exist), Gmail does not queue. You immediately receive a bounce explaining the permanent failure. Examples:

  • 550 5.1.1 User unknown

  • 550 5.7.1 Message rejected due to content policy

  • 554 5.7.1 SPF/DKIM/DMARC failure (policy-dependent)

Example timeline for a temporary outage

1. T=0: You press Send. Gmail signs (DKIM), enforces DMARC alignment, and attempts delivery.

2. T=+30s: Recipient’s MX returns 421 (temporary). Gmail queues the message.

3. T=+10m: Retry 1 → still failing.

4. T=+1h: Retry 2 → success; server accepts with 250 OK.

5. T=+1h+: Recipient’s client syncs via IMAP; they see your email. No action was needed on your part.

Quick reference: layers & roles (what did the heavy lifting?)

• Application & Message Format: MIME, base64, attachments, Message-ID.

• Authentication/Trust: SPF (sender IP authorization), DKIM (content integrity), DMARC (policy/alignment).

• Transport between servers: SMTP/ESMTP on port 25, STARTTLS for hop encryption, MTA-STS/DANE for TLS policy.

• Name resolution: DNS (MX, A/AAAA, TXT for SPF/DMARC/DKIM keys).

• Client access: IMAP/POP3 (over TLS) or HTTPS for webmail.

• Reliability: SMTP’s store-and-forward + queues + 4xx (temporary) vs 5xx (permanent) semantics.

Practical tips for sending a CV successfully

• Use common formats (PDF), reasonable size (<10–20 MB) to avoid rejection.

• Keep your subject and body clear (spam filters like clarity and relevance).

• Authenticate your domain if sending from a custom address (publish SPF, DKIM, DMARC).

• If you get a bounce, read the DSN code—it tells you whether to retry later (4xx deferred) or fix something (5xx permanent).