Quickstart: send your first email

1. Sign in

Open the sign-in page and continue with GitHub or Google. The first sign-in creates your workspace on the Free plan: 75 emails a UTC day and 2,000 a UTC month. Until your first message is delivered, the Overview page shows a Get started checklist that tracks steps 2 to 6.

2. Add your sending domain

Open Sending domains, enter the domain your mail will come from under Add a sending domain, and press Add domain. It can be your main domain, such as yourdomain.com, or a subdomain, such as notifications.yourdomain.com. Enter internationalized names in punycode.

The From address of every message must use exactly this domain. A verified yourdomain.com does not cover mail.yourdomain.com; add each domain you send from, up to 20 per workspace.

3. Publish the DNS records

The domain's card lists the records to create at your DNS provider, each with a copy button. For yourdomain.com they look like this:

Copy each value exactly as shown. The SPF value already merges the SPF record your domain publishes today, so replace that record rather than adding a second one. On Cloudflare or any provider with a proxy toggle, set these records to DNS only. Copy agent instructions copies the same records as a brief for a coding agent. DKIM, SPF and DMARC setup explains each record.

4. Check DNS

Press Check DNS on the domain's card. Each record gets a status: published, missing, mismatch or no answer. When every required record is published, the badge changes from awaiting DNS to verified and the page says "Verified. This domain can send." A record you just created can show missing until your provider publishes it; wait and check again.

5. Create an API key

Open Credentials, enter a Credential label under New credential, such as the name of the application, and press Create credential. The key, mr_ followed by 64 hexadecimal characters, is shown once; store it in your secret manager. Afterwards the list shows only its last four characters. Create one key per application, so you can revoke one without stopping the others. The examples below read the key from VIESTI_API_KEY:

export VIESTI_API_KEY=mr_…

6. Send a test email

Replace [email protected] with an address at your verified domain and [email protected] with an inbox you can read.

Over SMTP

With swaks:

swaks --server smtp.viesti.email:587 --tls \
  --auth-user apikey --auth-password "$VIESTI_API_KEY" \
  --from [email protected] --to [email protected] \
  --header "Subject: Your receipt" --body "Thanks for your order."

The transcript ends with 250 2.0.0 OK: queued. SMTP settings covers ports, TLS and every reply code.

Over the HTTP API

curl https://viesti.email/v1/send \
  -H "Authorization: Bearer $VIESTI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "[email protected]",
    "to": ["[email protected]"],
    "subject": "Your receipt",
    "text": "Thanks for your order."
  }'

A 202 response with {"id":"…","status":"accepted"} means the message is queued. The API reference lists every field and error.

7. Find it in Activity

Activity lists every message the workspace submitted, newest first, under the tabs All, In flight, Delivered and Problems. A new message moves from queued to relaying to delivered. Open it to see the Recipients table, with each recipient's status, attempts and the receiving server's last response, and the Delivery timeline. The id the API returned is the message's Message ID on that page.

delivered means Viesti's outbound mail server accepted the message for delivery; it does not confirm that the recipient's server accepted it or where it was filed. A failure reported later changes that recipient to bounced, as bounces and suppressions describes. A quarantined message was flagged by the content screen and waits for staff review.

Next: set up your framework with one of the guides, and read sending limits before you go to production.