> ## Documentation Index > Fetch the complete documentation index at: https://help.the-meridian.ai/llms.txt > Use this file to discover all available pages before exploring further. # Sends and deliverability A send is one email to one recipient. Meridian records every one, follows what the mail provider reports back about it, and tells you when deliverability starts going wrong. ## Recent sends Each email's page lists who recently received it, searchable by recipient, with each send's **status** and whether it was **opened**. A send that was skipped because the recipient is on your suppression list shows **Not sent** in place of a time. A send whose recipient unsubscribed after receiving it keeps its status, with an **Unsubscribed** marker next to it. Every send is tied to the [automation run](/automation-runs) that produced it, so a delivery question traces back to the event that caused it. ## What a send's status means | Status | Meaning | | - | - | | **Pending** | Recorded, not yet handed to the provider | | **Processed** | Accepted by the provider, not yet delivered | | **Delivered** | Accepted by the recipient's mail server | | **Deferred** | Temporarily rejected; the provider will retry | | **Bounced** | Permanently rejected: a dead address, or a server refusing you | | **Dropped** | The provider didn't attempt it, usually because the address is already suppressed | | **Complained** | The recipient marked it as spam | | **Not sent · unsubscribed** | Never handed to the provider: the recipient had already opted out of your app's emails | Statuses come from the provider's webhooks, so they update after the fact rather than at send time. Opens and clicks are recorded per send, with when each first happened. Treat opens as a floor and a ceiling, not an exact count. Apple Mail Privacy Protection fetches the images in a message before the recipient has looked at it, which would otherwise register as an open: Meridian detects those prefetches and keeps them out of your open rate. Security scanners that follow every link and image in a message can still be counted as opens, and a recipient who reads with images turned off is never counted at all. Clicks are the reliable engagement signal, so lean on the click rate when you are comparing two emails. A send that was never attempted because the address is on your app's suppression list (below) is recorded too, with no sent time: **Not sent · unsubscribed** when the recipient opted out, **Dropped** when the address had bounced or complained before. ## Unsubscribes and suppression Every email you send carries a one-click unsubscribe. Mail clients show it as a native **Unsubscribe** button next to the sender name, and a recipient who uses it lands on a short confirmation page served by Meridian. Either way the address goes on your app's **suppression list**, and so does any address that hard-bounces or reports one of your emails as spam. From then on, automations and the send API skip that address for your app: the send is recorded so you can see why the merchant received nothing, it is never handed to the provider, and it does not count against your monthly email quota. Test sends from the editor still go through, so you can keep previewing your own emails after unsubscribing from them. The send the recipient unsubscribed from keeps its status, usually **Delivered**, and shows an **Unsubscribed** marker in Recent sends, so you can see which message they left from. The message still reached them, so it keeps counting as delivered: an unsubscribe never changes the email's open, click or click-to-open rate. The list is per app. A merchant who opts out of one app's emails can still hear from another, and no developer sees another developer's list. Giving readers a working unsubscribe is also what keeps them from reaching for the spam button, and a spam complaint hurts the placement of every email sent from a shared domain, not just yours. ## Deliverability incidents A bounce, a drop or a spam complaint is treated as an incident: Meridian notifies on it, and separately watches the **rate** of them. If the proportion crosses the threshold, you get alerted. A sending reputation degrades quietly, and the whole point is to hear about it before your mail stops arriving. The usual causes, in order of likelihood: sending to addresses captured long ago, a [sending domain](/sending-domain) whose DNS records have drifted, or content that reads as bulk mail. ## What you can do about it * Keep your [sending domain](/sending-domain) verified, and add the recommended SPF and DMARC records. They aren't part of verification, but they are part of inbox placement. * Send from an address a merchant recognises, and keep automation email tied to real events rather than broadcast. * Watch the rates on [Analytics](/introduction-9): a fall in open rate with a rise in bounces is a deliverability problem, not a copy problem. * You don't need to write a plain-text version. Every send carries one next to the HTML, derived from your design, because mail filters treat HTML-only messages as bulk mail. Account emails (password resets, verification, invitations) are Meridian's own mail, not your app's. They always send from Meridian and never appear in your sends. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.