SyntrixOne sends transactional email via Resend. Two layers are supported:

• Platform level: set PLATFORM_RESEND_API_KEY and PLATFORM_EMAIL_FROM env vars. Used for verification/reset emails when a workspace has no provider configured.
• Workspace level: stored in the `email_settings` collection — the workspace can configure its own Resend API key and a verified sender domain.

Open /dashboard/settings/email-infrastructure. Enter the From email (e.g. "Acme Support <hello@acme.io>").

The domain MUST be verified in Resend — otherwise emails will silently bounce. Verify SPF, DKIM and (optionally) DMARC records as Resend instructs.

Configure a Reply-to address on the same Email Infrastructure settings page. Replies from customers can route to an external mailbox or back into the SyntrixOne inbox via the (future) inbound email channel.

On /dashboard/settings/email, click "Send test". POST /api/email/test fires a single transactional message to the email of your choice — same code path as production sends.

Open the email logs (next article) to inspect the result.

Open /dashboard/email-logs. Each row shows the recipient, template, subject, send status, delivered timestamp, open + click counts.

Resend webhook events feed into `/api/webhooks/resend` and update the log in real time.

Step 1: Email logs say "delivered"? Then the issue is on the recipient side (spam filter, mailbox full).

Step 2: Email logs say "bounced"? Open the error column. SPF/DKIM failures point to a domain config issue — re-verify in Resend.

Step 3: Nothing in the email logs? Either the send failed before reaching Resend (check workspace email settings) OR the workspace fell through to the platform fallback. Re-check PLATFORM_RESEND_API_KEY.

Step 4: Verification emails specifically — confirm the user has not hit the 10/day per-email or 50/day per-IP rate limits.