Deliverability

Deliverability is the question behind every email API: not just whether a message was accepted for sending, but whether it actually reaches the inbox rather than the spam folder or a silent block. Sending is the easy part. Earning the trust of the mailbox providers that decide where your mail lands is the work, and most of that trust is built before you ever send a message.

This page explains the forces that shape inbox placement and where Samva fits into each one. It is background, not a checklist. For an explanation of how SPF, DKIM, DMARC, and alignment work together, read Email authentication: SPF, DKIM, and DMARC explained. When you're ready to act on it in Samva, start with verifying your sending domain, which is the single highest-leverage step.

Why inbox placement is hard

When you hand a message to Samva, it is relayed through AWS SES to the recipient's mailbox provider: Gmail, Outlook, and the rest. Each provider runs its own filtering, and none of them publish exactly how it works. Broadly, they weigh three things:

• Identity: can the provider prove the mail genuinely came from the domain it claims to be from?
• Reputation: does mail from this sender historically get delivered, opened, and left in the inbox, or does it bounce and get marked as spam?
• Engagement: do recipients actually want this mail, measured by opens, clicks, replies, and the absence of complaints?

You can't control a provider's filter directly. What you can control is the signal you send it. Samva's role is to make the strong signals easy to establish and the damaging signals automatic to suppress.

Identity: verified domains and authentication

The foundation of deliverability is proving that your mail is yours. A mailbox provider that can't authenticate a message has little reason to trust it, and increasingly will reject or quarantine it outright. Samva lets new accounts send a first test email right away, but production traffic should come from a verified sending domain. An unverified customer domain has no established identity, so sends from that domain are rejected.

Verification works by publishing DNS records that mailbox providers check at delivery time. Each record answers a different question:

• DKIM attaches a cryptographic signature to every message, with the matching public key published as a TXT record on your domain. The receiving provider verifies the signature against your DNS, confirming the message was authorized by your domain and wasn't altered in transit. Samva signs your outgoing mail with DKIM once the domain is verified.
• SPF, published as a TXT record, declares which servers are allowed to send on behalf of your domain. It lets a provider confirm the mail came from a sanctioned source rather than a spoofer.
• DMARC, also a TXT record, ties DKIM and SPF together into a policy: it tells providers what to do with mail that fails authentication, and gives you reporting on attempts to send as your domain. It's recommended rather than strictly required, but it's where casual authentication becomes a deliberate posture.

Verification also includes a MAIL FROM domain at mail.<your-domain>. Its MX and SPF records provide the custom return path used for bounce handling and SPF alignment. Samva requires that return path to remain verified and rejects sending when it fails, instead of falling back to a shared return path. The visible From address and a recipient's mailbox display are separate from this envelope address.

Customer email requires TLS on the connection to the receiving mail server. A server that cannot accept TLS cannot receive that delivery; TLS does not guarantee inbox placement.

The takeaway is that authentication isn't a formality you complete once and forget. It is the mechanism by which every message you send carries a verifiable claim of origin. Without it, reputation has nothing to attach to.

Reputation: bounces, complaints, and suppression

Once your identity is established, mailbox providers track how your mail behaves over time. Two signals damage reputation faster than anything else, and Samva is built to keep both of them from compounding.

Bounces happen when a message can't be delivered, most importantly hard bounces to addresses that don't exist. A sender that keeps emailing dead addresses looks careless or like a list buyer, and providers respond by throttling or filtering the sender. Complaints happen when a recipient marks your mail as spam; a complaint is the strongest possible signal that mail is unwanted, and a rising complaint rate is the quickest route to the spam folder.

Samva handles both automatically. Delivery events flow back from SES: bounces, complaints, and successful deliveries are all captured; addresses that hard-bounce or complain are added to a suppression list. Once an address is suppressed, Samva won't send to it again, so a single bad address can't keep accumulating bounces against your reputation. Bounce handling and suppression are managed for you, so you don't have to track dead or complaining addresses yourself.

Underneath this, each organization sends through its own isolated reputation context in SES, so the sending behavior of one tenant doesn't drag down another. Your reputation is yours to build, and it's insulated from everyone else's.

The practical consequence: keep your lists clean and let suppression do its job. Trying to route around a suppressed address, or repeatedly sending to addresses that bounce, works against the very reputation that gets the rest of your mail delivered.

Automatic sending pause

Suppression handles individual bad addresses. A whole list that is stale or was not collected with consent is a different problem, and Samva stops it rather than letting it run. If, over the last 24 hours, your workspace crosses either threshold, sending pauses automatically:

The check needs at least 200 emails in that window, so a handful of bounces while you are testing cannot pause you. Only hard bounces count; a mailbox that is temporarily full or a receiving server that is briefly refusing mail does not.

Samva's complaint threshold is stricter than the one Gmail and Yahoo publish for bulk senders. They act at 0.3%, at which point the damage is already done, so Samva acts earlier.

While a workspace is paused, the dashboard shows a banner naming the observed rate and every send returns 403 Forbidden. Suppression, delivery history, and Blocks all stay available so you can see which addresses caused it. Email support@samva.dev to have a pause reviewed; there is no self-serve way to lift one.

Each sending domain also keeps its own window against the same limits. A domain with a warming plan is held by that window: campaign runs from the domain pause while it is over a limit, direct sends continue, and the workspace is untouched.

Engagement: tracking opens and clicks

Beyond authentication and reputation, mailbox providers can use aggregate engagement patterns as one signal of wanted mail. Replies, complaints, and provider-observed Open and Click trends can help you assess whether a program is welcome, but a missing observation does not prove that a recipient ignored or deleted a message.

Samva records provider-observed opens and clicks in each message timeline. Analytics counts unique messages with at least one observation and divides them by the corresponding tracking-eligible delivered-message cohort. Repeated observations for one message do not inflate the rate.

These signals are useful but imperfect. Opens depend on remote image loads, while clicks pass through rewritten links. Mail privacy features, image proxies, caches, security scanners, bots, and prefetching can create or hide observations. In one controlled proof, a single inbox open produced two raw Open observations. Treat engagement as directional telemetry, not proof that a person intended an action. Use it alongside replies, complaints, and recipient consent when you decide what and how often to send.

See Control engagement tracking for policy precedence, recipient opt-outs, raw timeline behavior, analytics denominators, and provider constraints.

How the pieces fit together

These three forces aren't independent steps; they reinforce each other in order:

1. Authentication gives your mail a verifiable identity, so reputation has something durable to attach to.
2. Reputation, protected by automatic bounce and complaint suppression, determines whether providers keep delivering your mail.
3. Engagement signals from real recipients confirm the mail is wanted and sustain reputation over the long run.

Samva carries the parts that are mechanical: domain authentication during verification, suppression of bounced and complained addresses, and visibility into delivery and engagement. What remains yours is the judgment: sending relevant mail to people who asked for it, at a cadence they welcome. No API can manufacture that, but with the foundations handled, it's the part worth your attention.

Next steps