Email Delivery

Email Delivery decides how every email your workspace sends goes out: Helpdesk replies, receipts, and follow-ups, Forms auto-replies and notices, CRM emails and reminders, Chat transcripts, Proposals, Partners, Billing, and automation notices. You can use MountDev Ops' own sending, or connect your own SMTP server or email service, the same way you would in any email program. Owners and admins manage it in the workspace menu, Integrations, on the Email Delivery tab. AI agents and API keys never see or change it.

Choosing How Email Goes Out

The Email Delivery card (action core.email_delivery.get) shows the way chosen now, whether it is working, and when it was last tested. Save (action core.email_delivery.save) keeps a new choice:

• MountDev Ops (Cloudflare Email Service): the start. Email goes out through MountDev Ops' own sending service. The From address (such as your Helpdesk address) must be on a domain set up for MountDev Ops sending; if it is not, sending fails with the reason, and you can connect your own delivery instead.
• SMTP Server: any mail server or email service that offers SMTP, such as Google Workspace, Microsoft 365, Fastmail, or your web host. Enter the mail server's name (such as smtp.example.com), the port, the security, the user name, and the password.
  • STARTTLS (usually port 587): the connection starts plain and switches to encryption before anything is signed in or sent. If the server does not offer STARTTLS, nothing is sent, so your password never travels unencrypted.
  • TLS from the start (usually port 465).
  • Port 25 is not available for outgoing mail from the cloud.
  • The workspace signs in with AUTH PLAIN or AUTH LOGIN, whichever the server offers. Leave the user name empty only for a server that accepts mail without signing in.
  • Mail servers on private networks (such as 10.x, 192.168.x, or localhost) cannot be reached and are refused.
• Resend, Postmark, SendGrid, Mailgun, or Amazon SES: email services with an API. Enter the API key (for Postmark, the server API token). For Postmark you can name the message stream (outbound at first). For Mailgun, enter your sending domain and choose US or EU. For Amazon SES, enter the region (such as us-east-1), the access key ID, and the secret access key of an IAM user allowed to send email.

For any choice but the first:

• From name and From address: the address your account at that service may send from, used for the test email and whenever an email has no From address of its own.
• Send everything from this address: turn it on when your service only lets you send from one address. Each email then goes out from this address, keeping the sender's name, and the address it would have come from (such as your Helpdesk address) becomes the Reply-To, so answers still reach the right place.

The password or key is stored encrypted with a key only your company's workspace can use. It is never shown again, to anyone, and never written in any log. Leave it empty when you save to keep the saved one. A password or key saved for one service is kept if you switch away, so switching back does not need it typed again. Changing the choice, the server, the key, or the From address marks the delivery Not tested yet.

A company that chose its own delivery never falls back to MountDev Ops' sending: if your service refuses an email, the email is marked as not sent, with your service's answer, so nothing goes out from an address you did not choose.

Send Test Email

Send Test Email (action core.email_delivery.test) sends one email to you, the person signed in, the way you saved, and shows your service's exact answer: for example "250 2.0.0 OK queued as 4XyZ" from an SMTP server, "Accepted, id re_123" from an email API, or the refusal word for word, such as "Signing in (AUTH PLAIN) was refused: 535 5.7.8 Username and Password not accepted". The card then shows Working or Failing with the reason. Save your changes before testing; the test uses what is saved.

Recent Emails

Recent Emails (action core.email_delivery.log) lists the newest 100 emails the workspace sent or tried to send, newest first, and updates on its own as emails go out: when, which app sent it (such as Helpdesk), to whom, the subject, Sent or Not Sent, the service it went through, and the service's answer or the reason it failed. Only Not Sent shows just the failures. It never holds the email itself.

This is where to look when a client says they did not get a reply or a receipt: if the email is listed as Sent, your service accepted it, and the client's own mail system decides where it lands; if it is Not Sent, the reason is beside it.

Threading

Helpdesk replies carry the In-Reply-To and References headers of the conversation, so they stay in the same thread in your client's email program. With an SMTP server, Resend, Postmark, SendGrid, and Mailgun, each email goes out with a Message-ID the workspace keeps, so the client's answer joins the right ticket. Amazon SES and MountDev Ops' own sending give each email their own Message-ID, which the workspace keeps from their answer. Either way, an answer also joins its ticket by the ticket number in its subject or text.