What actually happens when you click send

You’ve designed a campaign in your customer engagement platform. You’ve tested it. You’ve completed your pre-launch checklist.

You hit “Send”.

What actually happens now?

How does your message end up in front of your recipients? In their inbox, on their screen.

In this post we peel back the layers to explain what happens after you hit “Send”—for marketers. In this post I’ll be doing my best to keep jargon to a minimum.

If you’re a digital marketer or marketing leader, this knowledge is key to helping you:

1. Solve attribution and reporting issues.
2. Sustain or improve deliverability.
3. Evaluate vendors.

…and more.

These days, marketing is omni-channel, so we’re going to share knowledge on how email, iOS/Android push, SMS and in-app messages all reach the end user from your customer engagement platform/marketing automation provider.

How emails get into inboxes

Email is old. Real old in internet terms. The email system we know today had its genesis in the 1980s, with ancestors stretching back to the 1960s.

Each layer of the email delivery chain has a specific name and responsibility.

Service name	Description	Example provider
MUA (Mail User Agent)	Your email marketing/marketing automation provider.	Mailchimp, Vero
MSA (Mail Submission Agent)	Relays your message to a sending SMTP server.
MTA (Mail Transfer Agent)	Routes the message across the internet.	PowerMTA, GreenArrow
MDA (Mail Delivery Agent)	Accepts and stores the message for the recipient.	Dovecot
Client access layer	Lets the user fetch or view the message.	Gmail, Outlook, Mac Mail, etc.

Here’s an overview of what happens when you hit send on an email in a marketing platform.

We’ll break down each step in turn.

Queuing

Your email marketing platform will use some sort of queuing system to process your messages. Suppose you send an offer email to one million recipients.

In order to send one million emails, a “queue” will be used. Each message will be placed on the queue.

A series of “workers” will then process each email from the queue. A “worker” is essentially a little computer program. Typically many workers can run on one server and your marketing provider will probably run several servers. A server is a bit like your home computer, without a monitor. By running many workers at once, millions of emails can be processed in parallel, i.e. they do not need to run one-after-the-other.

Queuing is also important in handling retries in the event of temporary message failures, which we’ll get to in the next section.

Transfer to recipient email server (Gmail, Outlook, etc.)

Once a worker begins processing your email, it will transform the subject line, from address, to address, email body and more into a format it can send via SMTP to the recipient mail server.

SMTP stands for Simple Mail Transfer Protocol. It’s a standard format for a server to “send” an email message to another server. This process is handled by a piece of software called a Mail Transfer Agent (MTA) running on the sending server. You might have heard of software like PowerMTA or GreenArrow. These providers build MTA software.

In this case, your email marketing provider will run an MTA that will take your email and look up where to send it.

It will do this using the MX records associated with your recipient’s domain. If you’re sending to support@getvero.com, the MTA will look up the MX records attached to getvero.com and, based on these, will know where to send the message via SMTP.

The recipient server is running what is known as a Mail Delivery Agent (MDA), a piece of software that listens for incoming emails. Gmail, Microsoft Outlook, Yahoo! Mail, etc. all run MDAs. For example, messages are delivered to Google over SMTP at smtp.google.com.

The MDA is responsible for delivering the email to the recipient’s personal “mailbox”. A mailbox is ultimately just a secure database running on a server somewhere that contains all of an individual recipient’s emails.

Spam checks and filtering

When the recipient server receives the email they will often run scans for the purposes of both security and user experience. For example, when receiving an email, Gmail will run a number of checks before the message even reaches the MDA software.

They’ll check things like:

• IP reputation of the sending domain.
• Analysing message headers.
• Authentication checks (SPF, DKIM, etc.)

Once accepted by the MDA there will be further analysis to work out whether to store the message in the inbox, spam folder, promotions folder and so on. These checks will include things like:

• Language models that flag suspicious phrases.
• Rules-based engines that classify things like mis-matched names.
• Machine learning for more advanced detection of spammy content.
• URL and attachment scanning.

Recipient email servers will also observe user behaviour. They’ll see which emails users opened, which emails they clicked, what they marked as spam, etc. All of this will feed into their filters.

As a result of these checks, there are three typical outcomes:

1. Your message is temporarily not delivered (i.e. temporarily “fails”).
2. Your message is permanently not delivered (i.e. permanently “fails”).
3. Your message is delivered by ends up in the spam folder (or other undesirable folder).

Viewing the email (the recipient)

When the recipient opens Gmail, or Superhuman, or Microsoft Outlook, or Spark, or Mac Mail, etc. these software will use IMAP or POP3 to communicate with the Mail Delivery Agent (MDA) to load the emails for a particular recipient.

The MDA handles authentication and authorization to ensure that a recipient can only load their emails (and not someone else’s!)

How iOS/Android push messages arrive on phones

Just like email, the journey starts with “queuing”. From there, the steps are a little simpler.

Push messages are sent for delivery on two major platforms: Apple’s iOS and Google’s Android. Unlike email, which is an “open” platform, iOS and Android are proprietary platforms (technically, Android is open source).

Registering a device token

Email addresses, like support@getvero.com, are shared by your users with your business when filling out a login form or subscription form.

For push messages, things are a little different. For example, let’s say you use the Amazon mobile application: you never provide Amazon with the “address” at which they can send you push messages on your iOS or Android device. In fact, you wouldn’t even know the address, referred to as a “device token”, that can be used to deliver messages to the Amazon application on your phone. But such a token does exist.

When you download a mobile application and it asks if you’d like to “Allow push notifications” and you click “Allow”, the mobile application will make a request to Apple’s or Google’s servers and ask for a unique device token for you on this particular device.

This is known as your “device token” and is crucial for message delivery. Once you’ve registered this token, you will need to store it in your marketing platform. This is usually done via an API as well.

Transfer to Apple APNS and Google FCM

After you’ve scheduled a push campaign to go to your customers or users, it will be queued up, just like an email.

When each message is processed by the “workers” run by your push marketing provider, they will build a version of the message to send to Apple’s and Google’s APIs. In both cases the APIs are proprietary and have a strict format for the message format. As part of this API call, the marketing provider will provide the device token for the destination device.

The request from the marketing provider to Apple and Google is encrypted and authenticated. When setting up your marketing provider, you will have to provide a certificate that is used by Apple and Google to authenticate the incoming message, to make sure that no one else can send messages on your behalf.

Transfer to device

Based on the device token included with the message, Apple and Google will deliver the message to the appropriate device if the device is online.

The recipient’s device will then check to ensure that they still allow push notifications from the application sending the token and, if so, will show the message.

If the device is offline, Apple and Google will “hold” the message. Google will hold messages for four weeks. Apple will hold messages for four hours. If the device comes back online within this time frame, the message will then be delivered.

Displaying on the device

Both iOS and Android have standard styles and mechanisms for displaying push messages. Essentially, messages are shown the same for any application, typically featuring a title, a body and perhaps an image.

Handling interactions

When a user clicks on the push notification, the application that sent the message will open and process the message. This is where your iOS and Android engineering team can control the behaviour that follows.

Your marketing provider will require you to install an SDK or some lines of code that are responsible for processing and displaying messages that are sent. This SDK is responsible for determining what happens when a push message is received and when a user clicks on or otherwise interacts with that message.

Deep-linking

Typically, push messages open a specific screen in your application. For example, if you were Amazon and you sent a push notification about a special promotion or a certain product, clicking that message would open the relevant page in the Amazon application.

This is known as deep-linking. A native deeplink will look something like: myapp://sale/today and will be handled by the SDK or code in your application to open the correct page.

Alternatively, you might use “universal links”. These look like a standard URL, such as https://yourwebsite.com/sale/today that can load either a website OR your mobile application, if installed. Universal links are useful when sending on channels such as email, SMS or web-based in-app messages. Channels that might drive a user toward your mobile app but do not require the mobile app to be installed (after all, you can only get a push message if you DO have the app installed).

It’s important to mention them here as they’re part of picture for setting up high-quality interactions with your messages if you have a mobile application.

“Inbox” and message failures

Unlike emails, there is no permanent “inbox” for push messages. Once they’ve been clicked or “cleared” by the recipient, they can’t be easily seen again.

Further, it’s possible for the recipient to change their push notification preferences on the device itself.

• If a user disallows messages on the device then no failures is passed back to the sender (your marketing provider) so the message is essentially sent to a “blackhole”.
• If a user uninstalls your application then, next time you try to send to that user, you will receive a failure message and, as a result, know to delete the device token from your marketing application. Your marketing software should handle this automatically.

How SMS messages arrive on phones

Like email, the cell network is a relatively “open” network, with many carriers in many countries routing messages to end devices. Yet, while email delivery runs over the open internet, SMS rides on a closed telecoms network built decades ago. This introduces some unique quirks.

In order to send SMS messages you must register a phone number—or numbers—to send from. This process varies from country-to-country as each market has different rules and requirements to help prevent unwanted, spammy messages.

Sending to an SMS aggregator

When you send an SMS campaign from your marketing provider, they will send your message onwards to an “SMS aggregator” via API. Some of the largest, most well-known aggregators are Twilio, Bird (previously MessageBird), Sinch, Infobip and Telnyx.

Your marketing provider will send a copy of the message, the recipient phone number and the “sender ID” (i.e. the “from number”) to the aggregator.

Aggregators maintain direct connections with the telecom network and telecom providers around-the-world. Upon receiving the API request they will forward onto the telecom network.

The SS7 network

SS7 stands for “Signaling System Number 7”. It’s the global standard for telecommunications signalling. It was developed in the 1970s (yes!) and uses the phone number of the recipients to route the message to the correct carrier (e.g. Vodafone, AT&T, Verizon, etc.)

The message is then handed off to the correct carrier’s Short Message Service Center, the entity that stores and is responsible for delivering SMS messages for that carrier.

Delivering to cell phones

Once received by your telecommunications carrier, they will attempt delivery to the recipients’ device.

The possibilities at this stage:

• Message delivered. If the device is active and online, the message is delivered immediately.
• Message held for later delivery. If the device is active but offline, the SMS is held for up to 72 hours by the carrier. When the device is next seen on the network, the message is delivered.
• Permanent failure. If the number is invalid or blocked or otherwise doesn’t exist, the message is rejected.

SMS messages are simpler than emails in that there is no inbox vs. spam folder. The message is either delivered or it is not.

The SMS aggregator will receive a response from the SS7 network acknowledging successful delivery or these temporary or permanent failures, so you should be able to see this status in your marketing provider.

How in-app messages arrive on screens

Unlike the other channels, in-app messages are totally proprietary. Multi-channel marketing providers build their own in-app messaging frameworks. Each provider does this differently but the core use case is to give marketers a way to show:

• Popups (full-screen, modals or other)
• Banners
• Interstitial content (content that appears inline with other content, e.g. a carousel)

In-app messages can support both mobile and web-based software.

Campaign queuing

When you queue up an in-app message in your marketing platform, the marketing platform adds this to an internal queue for the recipient users based on the logic you’ve defined (segmentation) and the display rules (e.g. how many in-app messages a recipient can see per week).

The message queue is stored by your marketing platform until the next time the recipient user interacts with your mobile application or website.

Because in-app messages use proprietary frameworks, you need some internal “identifier” for each recipient when sending the message. This could be an email address or phone number but usually it’s a database ID or even an ID generated by your marketing platform.

Fetching and displaying messages

As part of setting up in-app messages, you will have installed an SDK (software development kit) or similar provide by your marketing platform.

When a recipient user next logs in or opens your mobile or web application, this SDK will make a request to your marketing platform and check if there are any messages queued up for the current logged-in user.

Unlike the other channels in this blog post, in-app messages are pulled from your marketing provider by the SDK, rather than pushed to the device.

The SDK is responsible for:

• Checking any in-app rules, such as whether the user has already seen and dismissed the in-ap message during the current session.
• Checking the current URL or screen and ensuring it aligns with any final delivery rules.
• Displaying the message in the correct format, i.e. modal, banner, etc. and placing this in the right area on-screen.

Different marketing providers will enable different options when it comes to designing in-app messages. Some tools give marketers “no-code” or “low-code” tools to build the in-app message, encouraging a lot of freedom in the in-app message design.

Other platforms give developers tools to flexibly design the frontend and marketers tools to update the text and image content within those components.

Tracking

In-app messages don’t live in an inbox: they’re transient and context-bound, generally only viewed once by a given user, and easily dismissed. That makes tracking critical.

As in-app messages are proprietary, your marketing platform should track:

• Impressions. When an in-app message is successfully seen by a recipient.
• Click events. When a recipient clicks on an aspect of the in-app message.
• Dismissals and closes. When an in-app message is closed by the recipient.

The SDK provided by your marketing platform will track these elements in the frontend and send API calls to the backend of your marketing platform, giving a lot of granularity in tracking.

With in-app messages there isn’t the same concept of a “failure”. Whilst it’s possible that a network connection is dropped or a recipient user closes their browser or your mobile app before the message is fully displayed, failure tracking is difficult: it’s more about tracking whether the message was displayed, than tracking the failure of the message to display.

Bringing it all together

Let’s zoom back out.

This post is all about helping give us marketers a better understanding of what happens behind-the-scenes after we hit “send”.

Each channel—email, push, SMS, and in-app—has its own stack of standards, rules, and failure cases. This knowledge can be extremely valuable when you’re troubleshooting your messaging metrics, understanding what each metric means and why metrics might be moving up or down as they are.

Modern marketing is infrastructure-dependent. Knowing what happens after you hit “send” is a great defense against blind spots — and a great advantage when aiming for relevance, reliability, and results.