Sending as your own domain

Two ways to make replies leave from your address instead of ours — DKIM domain verification, or your own SMTP server. DKIM is the one you want.

Out of the box a brand-new workspace can already send. Replies leave from a Leodesk-owned address that carries your workspace name as the display name, with your own channel address set as Reply-To. Nothing is broken — it just does not say your domain, and recipients see a sender they do not recognise.

Making replies come from your own domain is the single highest-value thing you can do during setup. There are two routes, and you can use either or both. When both are configured on a channel, Leodesk prefers the DKIM path and falls back to your SMTP credentials automatically.

Option A — verify your domain with DKIM (recommended)

Go to Settings → Email → DKIM and add the domain your support address lives on, for example acme.com. Leodesk generates four DNS records for you to publish: three CNAME records for the rotating DKIM keys, each on a randomly generated selector under _domainkey.acme.com, plus one CNAME return-path record on a uniquely prefixed host.

CNAME  a3f1._domainkey.acme.com     wl9c2b1as1.domainkey.leodesks.com
CNAME  7d04._domainkey.acme.com     wl9c2b1as2.domainkey.leodesks.com
CNAME  b52e9._domainkey.acme.com    wl9c2b1as3.domainkey.leodesks.com
CNAME  crfwd-9c2b1a.acme.com        spfmx1.domainkey.leodesks.com

Every host is namespaced per domain rather than using a fixed, well-known name. That matters if you are migrating: providers that use a static host name collide with whatever your previous vendor left behind, and you get a "record already exists" error from your DNS provider. These will not clash with records from another service.

Publish all four, then click Verify. Leodesk performs a real DNS lookup for each record rather than trusting a timer — it resolves the CNAME and compares the target, ignoring case and trailing dots. The domain shows as verified only when every record resolves, pending when some do, and failed when none do. Each record reports its own error, so a message like "Resolves to …; expected …" tells you exactly which one your DNS provider mangled.

One tip on provider interfaces: if a record type offers a separate priority or weight field, put the value there rather than gluing it onto the record data. That single mistake accounts for most failed first verifications.

What changes when it verifies

Your domain becomes a verified sending identity inside Leodesk's own mail infrastructure. From then on, replies on any channel using that domain go out as [email protected], carry a DKIM signature that authenticates your domain, and use a white-labelled return path. There is no "via" line in Gmail and no third-party sending domain visible to the customer.

You never need an AWS account or an account with any mail provider. Publishing the records is the whole integration. Bounce and complaint notifications come back to Leodesk rather than into your support mailbox, so a hard-bounced address is suppressed automatically instead of quietly being re-sent to forever.

Domain verification and custom domains are Pro plan features.

Option B — send through your own SMTP server

If you cannot change DNS, or you are required to relay through an existing mail server, open Settings → Email, pick the channel, and switch its outgoing mode to SMTP. Enter host, port, username and password, save, then press Test SMTP.

Host  smtp.acme.com
Port  587      # STARTTLS  (25 also uses STARTTLS)
Port  465      # implicit TLS
User  [email protected]
Pass  <an app password, not your login password>

Two behaviours are worth knowing. First, the port decides the TLS mode: 465 is implicit TLS, while 587 and 25 use STARTTLS. Leodesk derives the setting from the port and then stores the exact value the successful test used, so a channel cannot end up marked verified while every real send times out on a TLS mismatch.

Second, the channel only earns its SMTP verified pill when the details you tested match the details you saved — same host, same port, same user. Test a different set of unsaved form values and the probe still runs, but the channel is not promoted. Until a channel is verified, its outbound falls back to the platform address with the channel as Reply-To. If a later test fails, the verified flag is cleared rather than left stale.

Which one should you pick?

Choose DKIM if you control your domain's DNS. It gives the best deliverability, stores no mailbox credentials in Leodesk, and needs no maintenance once the records are live. It is the right answer for almost everyone.

Choose custom SMTP when policy requires that all mail leaves through a specific relay, when your DNS is managed by someone who will not add records, or when you already pay for a transactional provider whose sending reputation you want to keep using. The trade-off is that you own the credentials, their rotation, and the reputation.

Setting up both is a reasonable belt-and-braces choice: DKIM handles normal sending, and SMTP is there when the DKIM path is unavailable for a channel.

Sending guards you should expect

Leodesk is a support desk, not a bulk sender, and the outbound path is deliberately constrained. These rules are enforced server-side and are worth knowing before you wonder why something did not send:

• Replies go to people who wrote in. An outbound message may only be addressed to someone who already exists as a contact in your workspace — usually because they emailed you first, or because you created them in the New Ticket dialog.
• Hard bounces and spam complaints suppress an address. Once suppressed, Leodesk refuses further delivery to it rather than burning your domain's reputation.
• New workspaces start with a conservative daily cap and a trust tier that lifts as the workspace establishes a track record.
• Free plan workspaces get 100 outbound emails per rolling 24 hours. Paid plans are uncapped.

Verify it end to end

Email your support address from a personal account, wait for the ticket, then reply from Leodesk. On the received copy, open the original message headers and check three things: From is your own address, there is a DKIM-Signature naming your domain, and Gmail shows no "via" line under the sender name.

If a reply does not send, the message in the ticket thread carries a Not delivered badge with a plain-language reason — an authentication failure, a suppressed recipient, or a daily cap reached. Fix the cause and send again; nothing is silently dropped.

With outbound working, the next job is getting customer mail into Leodesk. That is covered in receiving customer email, and if you are moving from another mailbox, in importing historical email.