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 hardCopy Anchor Link

When you hand a message to Samva, Samva delivers it 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 authenticationCopy Anchor Link

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 sends only from a verified sending domain or a sender address you have verified, and rejects a send from an unverified domain. There is no shared Samva sending domain to fall back on; see Before your first send.

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 suppressionCopy Anchor Link

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. Samva records every bounce, complaint, and successful delivery, and adds the address to a suppression list when it bounces or complains. A hard bounce or a complaint suppresses the address permanently; a soft bounce suppresses it for 30 days, so it can be retried once the receiving server recovers. While an address is suppressed, Samva won't send to it, 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.

Each organization sends with its own sending reputation, so the sending behavior of one customer 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 pauseCopy Anchor Link

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 organization 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 an organization 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 organization is untouched.

Probation for new organizationsCopy Anchor Link

Mailbox providers judge a new sender by its first mail, and so does Samva. A new organization can send as soon as its domain is verified, and it sends on probation until its own delivery record shows its mail is wanted.

Some new organizations are reviewed before their first send instead, when something about the signup calls for a person to look, such as a recently registered domain or a name that resembles another brand. Sends are refused until that review finishes; see Check email review status. A sending domain added later gets the same check, and one that calls for review returns an organization to probation.

What applies while on probationCopy Anchor Link

• Probation limits. Hourly, daily, and per-domain recipient limits apply beside your plan's. The values and the 429 they return are in Probation limits.
• A content check before sending. An automated content check looks at each distinct email before it goes out: each template version, or each distinct subject and body once the recipient's own details are set aside. Content that passes is not checked again for every recipient. Content the check flags as possible phishing or fraud is held for review: the send is accepted, its deliveries stay queued with wait reason content-review, and the delivery's scheduling.reviewExpectedAt says when the review is expected. After review Samva sends the email, or fails it with error code CONTENT_REVIEW_REJECTED and a message.failed webhook. See Accepted, queued, and expired email. Content the check judges clearly fraudulent also pauses the organization's sending.
• A temporary content-check outage. When Samva cannot complete its content check, the accepted email stays queued with wait reason screening-unavailable and no expected review time. Samva retries the check automatically when the service recovers. This reason reports a service outage rather than a finding about your content.
• Bounces and complaints count from the first one. The automatic sending pause waits for enough volume to read a rate; probation does not. Sending pauses at 3 hard bounces over the last 24 hours, and a single spam complaint opens a review of your organization while sending continues.

GraduationCopy Anchor Link

Open Settings → Sending Access to see your organization's sending tier, current limits, graduation criteria, progress, and any blockers. Settings → Organization also shows its sending tier.

Your organization graduates from probation when its record since it entered probation meets all of these at once:

• at least 14 days have passed since its first email on probation was sent;
• at least 500 emails delivered;
• no risky or severe content findings remain held or rejected, and sending has never been paused;
• no spam complaints;
• hard bounces under 2% of the email it has sent.

A temporary content-check outage does not count against graduation, whether the email is still waiting for recovery or has been released after a clear check. A risky or severe finding counts while it is held or rejected. Releasing the held email clears that finding from the graduation record.

An organization with an unresolved or rejected content finding, or a sending pause on its record, needs review before it can graduate; email support@samva.dev to have it reviewed. When the review finds the record sound, Samva graduates the organization. A review can also return an established organization to probation, where it graduates again on its new record.

Graduation is checked as your deliveries arrive, so it happens on the delivery that completes the record, with nothing to request. An organization that stopped sending graduates on its next delivered email once the rest holds. After graduation your plan's limits and the automatic sending pause apply on their own, and the content check looks at a sample of new content instead of all of it.

Engagement: tracking opens and clicksCopy Anchor Link

Beyond authentication and reputation, mailbox providers can use aggregate engagement patterns as one signal of wanted mail. Replies, complaints, and 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 opens through its open pixel and clicks through tracked links, and shows each observation in the message timeline. Analytics counts unique messages with at least one observation not classified as automated 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, and a single inbox open can produce more than one Open observation. 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 tracking limits.

How the pieces fit togetherCopy Anchor Link

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 stepsCopy Anchor Link