Pular para o conteúdo

Silurian Docs

All documentation Web hosting and Site Studio

Hosting email and Silurian Webmail

Activate email for a hosted domain, create mailboxes, use Silurian Webmail and diagnose DNS, authentication and delivery failures.

Public guideReviewed 2026-09-02
01

Before creating addresses

The email service must be activated for the domain and the domain's DNS must be under your control. Decide which addresses need full mailboxes, which only forward elsewhere and which are role accounts such as sales or invoices. Use an individual mailbox for each person; shared passwords make access revocation and auditing unreliable.

02

Create a mailbox

Create the local part of the address, choose an available quota and set a unique strong password. Save the password in a password manager because it is never displayed again. After creation, sign in to Silurian Webmail and send a message to an external address before relying on the mailbox for production communication.

03

Use Webmail or a mail application

Silurian Webmail is the supported browser access for managed-hosting mailboxes: sign in with the complete email address and its mailbox password. Configure a desktop or mobile application only when Workspace displays verified Silurian incoming and outgoing server names, ports and encryption modes for the service. Do not guess a server, use a technical third-party hostname, accept an invalid certificate or replace a server name with its current IP address.

04

Configure DNS for delivery

MX records decide where incoming mail is delivered. SPF authorises sending systems, DKIM adds a verifiable signature and DMARC defines how receivers should handle authentication failures. Copy the records shown for the service exactly and remove obsolete or conflicting MX records. Never invent a DKIM selector or merge two SPF records as separate TXT records for the same domain.

05

Test incoming and outgoing mail

Send a message from an unrelated external mailbox to the new address, reply from Webmail, and inspect the received message's authentication result. Repeat the test from the desktop or mobile client. A successful login proves only the password and server connection; it does not prove that public MX records or sender authentication are correct.

06

Forwarding and automatic replies

Use forwarding when mail should be delivered to another address without maintaining a separate inbox. Avoid loops and confirm whether a local copy is retained. An automatic reply can be associated with a mailbox or used independently; set exact start and end dates, keep the message brief and do not disclose travel details or other confidential information.

07

Filters and mailing lists

A filter matches a message header and applies an ordered action such as delivery, redirection or deletion. Test new rules with harmless mail and place broad rules after specific ones. Mailing lists have separate owners, moderators and subscribers and are suitable for controlled group distribution, not unsolicited or large-scale marketing campaigns.

08

Website-generated email

Messages sent by PHP or a website form are separate from mailbox delivery. Prefer authenticated SMTP with a dedicated mailbox when the application supports it, use a sender address belonging to the domain and monitor bounces. Test password-reset, contact-form and order messages individually; one successful message does not validate every application path.

09

Diagnose delivery failures

If no mail arrives, confirm the public MX result first, then check mailbox quota and forwarding or filter rules. If sending fails immediately, verify SMTP authentication, port and encryption. If mail is accepted but reaches spam, inspect SPF, DKIM and DMARC results and the message content. Include the sender, recipient, timestamp with timezone and rejection text in a support request, but never the mailbox password.