AvailableEvery application sends from its own domain.
Verification codes, password resets and receipts go out through a monitored relay with DKIM on your domain. Templates are published centrally; you pass variables. Reputation is never shared between customers.
console · send a test
POST /v1/applications/{id}/mail/send-test
{
"to": ["you@example.com"],
"template_key": "auth.verify_email_code",
"variables": { "app_name": "Acme", "code": "482913" }
}
→ { "message_id": "msg_7f1c…", "status": "queued" }What you get
Transactional Mail, without running it.
Served from mail.api.devsewa.com and managed from the console. Backed by MAIL_APP, mediated by the DevSewa control plane.
- Sender domain and alias per application
- Published templates with server-side variable substitution
- Send a test from the console before you wire anything
- Per-message delivery status and timeline
- Idempotency keys namespaced per tenant
- Sender-identity preflight catches misconfiguration before SMTP does
Isolation
How it stays yours.
- Sender lane
- A domain belongs to exactly one application
- Attribution
- Messages carry the tenant as their origin, never a header
- Relay
- Shared and monitored today; bring-your-own SMTP on the roadmap
Add Transactional Mail to your application.
Create an account, register a test application and exchange your first ticket in under ten minutes.