Receive, route, send
Inbound is half of Vela, not a feature bolted onto a send API.
Point the MX and the domain starts listening.
Every message to the domain is accepted, checked against SPF, DKIM and DMARC, then parsed and kept in full. Attachments and the original MIME stay with it.
MX · inbound enabledYour database is a destination.
Fan one message out to a signed webhook, a Postgres table, a libSQL database and a bucket you own. Rules match on the domain, and delivery retries with backoff until the destination answers.
webhook · postgres · libsql · s3Send as your domain in one request.
Sending identities are verified per domain, with SPF and DKIM published before the first message leaves. Bounces and complaints come back through the same webhook.
POST /api/v1/emailscurl -X POST https://vela.novacraft.africa/api/v1/emails \
-H "Authorization: Bearer vela_live_…" \
-H "Content-Type: application/json" \
-d '{
"from": "[email protected]",
"to": ["[email protected]"],
"subject": "Your invoice is ready",
"html": "<p>Thanks, it is attached below.</p>"
}'
# → { "id": "b7c3…" }DNS records and somewhere to put the mail
None of the setup is proprietary. It is SPF, DKIM, DMARC and an MX record, run properly.
Verify the domain
Publish the SPF and DKIM records Vela generates for you.
TXT _amazonses.yourdomain.com
CNAME a1b2c3._domainkey.yourdomain.comPoint the MX
Inbound starts flowing the moment DNS resolves.
MX 10 inbound-smtp.us-east-1.amazonaws.comChoose a destination
A webhook, your database, your bucket. Or just read it in Vela.
kind: postgres
schema: vela
table: vela_inbound_emailGive an agent a key that only reads what you allow.
Everything the dashboard does is available over REST, and an MCP server puts the same surface in front of an agent. Keys carry a permission and an expiry you set when you create them, and every webhook delivery is signed so the receiver can prove where it came from.
curl -X POST https://vela.novacraft.africa/api/v1/emails \
-H "Authorization: Bearer vela_live_…" \
-H "Content-Type: application/json" \
-d '{
"from": "[email protected]",
"to": ["[email protected]"],
"subject": "Your invoice is ready",
"html": "<p>Thanks, it is attached below.</p>"
}'
# → { "id": "b7c3…" }Where the mail actually lives
When the destination is yours, there is nothing to export later.
| You keep | How |
|---|---|
| Raw message | The original MIME is kept, not just the parsed fields. |
| Your database | Postgres and libSQL are destinations, so the mail lands in a table you control. |
| Your bucket | Point S3 at storage you own and Vela writes to it directly. |
| Scoped keys | Every key carries a scope and an expiry you choose, including none. |
What you hold when a message is disputed
Mail gets judged on the day an invoice or an approval is questioned. Each of these has a record in Vela rather than a guess.
- A customer swears they sent it
- Search inbound by address or subject. The original MIME is stored, so the headers that prove the route are still attached.
raw message retained - Your webhook was down for an hour
- Delivery retries with backoff, and the attempt log keeps every status code the endpoint returned.
retry · backoff - A message looks forged
- SPF, DKIM and DMARC results are recorded on the message as it arrives, not guessed at afterwards.
SPF · DKIM · DMARC - Someone disputes what you sent
- Sent messages keep their id, their recipients and their outcome, bounces and complaints included.
POST /api/v1/emails → id - You need the mail somewhere else
- It is already there. The destination was your Postgres, your libSQL or your bucket the whole time.
webhook · postgres · libsql · s3