A password reset that lands in spam is not a marketing problem; it is a login failure. Yet most platforms hand you an API key and a warning, and leave the identity — the thing the mailbox provider is actually judging — implicit. Devotel Orbit models it explicitly: a sending identity is a registered object on your account that bundles a sending domain, its default From address and display name, a reply-to route, a sending-stream assignment, and a live DNS-verification state. This guide walks that model, the DNS verification posture behind it, why streams separate transactional from bulk traffic, and how email behaves when it is one step inside an omnichannel flow rather than a silo.
Transactional vs marketing email — and where each fails
The two kinds of mail fail in different places, and conflating them is the root of most deliverability incidents.
Transactional email — receipts, password resets, invoices, appointment reminders — is triggered by a recipient's own action, sent one-to-one, and expected. Its failure modes sit in identity and reputation: an unverified domain, a DKIM signature that no longer aligns, a hard bounce the sender keeps mailing, or a sudden volume spike from a domain with no history. Content is almost never the issue; authentication and hygiene are.
Marketing email — newsletters, promotions, announcements — is sent one-to-many on the sender's schedule. It fails on engagement and compliance: low open rates, spam complaints, missing unsubscribe handling, and volume spikes a flat IP reputation cannot absorb. A transactional sender gets the benefit of the doubt from receivers; a bulk sender earns its inbox placement campaign by campaign.
The practical consequence is separation. When receipts and newsletters share one domain and one reputation pool, a bad campaign (a mistargeted import, an unresponsive segment) filters your password resets with it — and the damage shows up as users locked out, not as a marketing metric. The separation has to exist in three places: the domain, the reputation pool, and the configuration object that ties them together.
The sending identity — Orbit's unit of configuration
Orbit expresses that separation in one object: the sending identity, managed under Email → Senders and over GET|POST|PUT|DELETE /api/v1/email/senders. One identity holds:
- A sending domain, e.g.
mail.acme.com— the reputation principal everything else hangs off. - Default From fields — a default From address (constrained to the sender's own domain) and a display name. When no default From address is set, sends from that identity go out as
noreply@<domain>until you set one. - A reply-to route — replies can go somewhere other than the From address, so receipts can send from
billing@mail.acme.comwhile replies land in a monitored support mailbox. - A sending-stream assignment — the reputation pool the identity's traffic belongs to (the next section).
- A derived DNS-verification state — true once the domain's SPF and DKIM records are observed valid.
Two behavioral details matter. Exactly one identity is the account default — the sender used when a send omits an explicit one (POST /api/v1/email/senders/{senderId}/set-default promotes it). And only verified identities appear in the compose dropdown, so an unverified domain cannot be picked by a teammate in a hurry.
Because the identity is an API object, deliverability configuration becomes reviewable: the senders list shows every domain's defaults, stream assignment, and verification state in one call, instead of tribal knowledge about which domain receipts use this quarter.
DNS verification as a posture, not an event
Mailbox providers in 2026 treat passing, aligned SPF and DKIM as the baseline for a trustworthy sender, not a bonus. Orbit's verification model matches that reality: registration issues real DNS records, and verification is a continuously re-checked state, not a one-time badge.
The walkthrough at concept level:
- Register the domain. Creating a sending identity registers the domain with the email provider and returns the exact DNS records to publish — SPF, DKIM, DMARC, and the Return-Path CNAME (full record table and limits). The DKIM public key is extracted and bit-length-validated, so a placeholder record with no real signing key never flips a domain to verified.
- Publish the records at your DNS provider. These records live under your domain — they are tenant-owned configuration. Orbit cannot publish them for you, and no platform should claim to.
- Verify, then keep verifying. An on-demand Verify DNS re-check (
POST /api/v1/settings/channels/email/verify-dns) confirms the records resolve as issued; a daily health check re-validates them afterward. If a record drifts — another team edits a TXT value, a key is rotated, a TTL expires — the regression is written to the domain's DNS history and surfaced as a notification, with a per-record traffic-light view onGET /api/v1/email/domains/:domainId/dns-status. - Send only when verified. Sending from an unverified domain fails fast — a 403 with a "domain is not verified" class error — rather than silently degrading inbox placement.
Treat a drift notice like a certificate-expiry alert: the domain stayed configured, but receivers stopped seeing an authenticated sender, and every day it drifts is reputation paid for nothing.
Sending streams — why separation protects deliverability
A sending stream is the reputation-pool assignment on a sending identity: the subaccount-like lane that keeps one class of traffic from inheriting another class's history. The separation works because mailbox providers build per-domain and per-pool history; mixing traffic classes within one pool hands the strictest traffic's fate to the loosest traffic's worst day.
- Transactional stream — receipts, resets, invoices. Small recipient counts, high open rates, near-zero complaints. This traffic is worth more than its sending cost, and its reputation should reflect only its own behavior.
- Bulk/marketing stream — campaigns and newsletters. Higher volume, complaints measured in basis points, occasional list mistakes. When a campaign underperforms, the hit lands in this pool, not in the pool your password resets draw from.
The mechanics of assigning an identity to a stream are two fields — streamId at registration, or a PUT on the sender to reassign — but the operational payoff is outsized: blast-radius containment by construction. A bulk mistake degrades the bulk stream's reputation while transactional senders on the transactional stream keep landing.
Where separation is not enforced by the identity model, it gets reinvented as folklore — "don't use the receipts domain for the newsletter" written in a wiki nobody reads. Modeled as a field on the identity, it survives staff changes.
Email as one step in an omnichannel flow
The same account that holds your sending identities also runs SMS, WhatsApp, RCS, and voice — and flows compose them. In the flow builder, email is a step beside those channels, not a separate system with its own contact list and event stream.
That changes where email failures get handled. An order-confirmation flow can send the receipt by email, then — when the send returns RECIPIENT_OPTED_OUT because the address is suppressed — route to SMS instead of dying at the email step. Delivery outcomes arrive on the channel-agnostic message events (message.delivered, message.failed carrying channel: "email"), so the same webhook surface that watches your SMS deliveries watches email; email.opened and email.clicked add the engagement layer for the flows that need it.
Suppression behaves the same way across the boundary: a hard bounce, complaint, or List-Unsubscribe on the email channel writes to the account's suppression list automatically, and a later flow step that tries the same address is refused before anything is queued — with the consumed quota refunded. The recipient's "no" follows them into the next flow, which is what a customer expects from one platform in the first place.
Frequently asked questions
What is a sending identity in Orbit, exactly?
A sending identity is the registered bundle of a sending domain, its default From address and display name, a reply-to route, a sending-stream assignment, and a derived DNS-verification state — one object per sending domain, managed under Email → Senders or the /api/v1/email/senders endpoints. Exactly one identity is the account default used when a send names no sender, and only verified identities can be picked in the compose dropdown.
Does verification ever expire?
Verification is re-checked continuously: an on-demand Verify DNS run plus a daily health re-validation. If a record drifts — edited TXT values, a rotated key, an expired TTL — the regression is recorded in the domain's DNS history and flagged with a notification, so a "verified" domain that no longer authenticates surfaces as a failing health state rather than a quiet inbox-placement drop.
How does the reply-to field actually behave?
The From address defines who the message is from; the reply-to defines where replies go. They can differ deliberately — invoices send from billing@mail.acme.com while replies route to a monitored support mailbox. Left unset, replies go to the From address. Per-message reply_to remains available on the send API when one identity needs occasional exceptions.
How should I warm up a new domain?
There is no fixed day count — warmup is about the pattern. Start at a fraction of steady volume, step up gradually, and gate each step on stable bounce and complaint rates, the same discipline the deliverability playbook describes. Orbit's reputation endpoint aggregates your sent/delivered/bounced/complaint rates and a health tier for exactly that monitoring, and the warmup-plan endpoints return a recommended daily-cap schedule if you plan dedicated-IP volume.
Why not send marketing and transactional mail from one domain?
Because they share a reputation. A bulk campaign that draws complaints recolors the domain's receiver-side history, and the transactional mail sent next inherits the verdict. Putting them on separate sending identities — separate domains, separate stream assignments — contains the blast radius: a bad campaign degrades the bulk reputation while receipts and resets keep flowing on their own.
Where to read next
The full channel contract — send shapes, templates, limits, suppression lifecycle, error catalog — is in the email channel docs. The email API landing page covers the product surface, the deliverability playbook walks the SPF/DKIM/DMARC checklist step by step, and the best email API providers 2026 comparison positions Orbit's model against the dedicated email platforms.