If you can no longer send messages with your CURIAWEB email address, the cause can be in various places. Incorrect SMTP settings, a password that is no longer valid, or missing authentication of the outgoing mail server are often responsible.
However, it is important to narrow down the problem systematically. For example, if you can still receive emails, that does not automatically mean that the configuration for sending them is also correct. Inboxes and outboxes use different protocols and connections.
In this article, we will show you step by step how to figure out why shipping is not working.
CURIAWEB Standard: For normal email transmission, you use
mail.your-domain.chas SMTP server, port465, SSL/TLS and authentication using your full email address and the email account password.
First determine: Does the issue only affect shipping? #
First, check whether you can still receive messages with the affected email account.
If new messages are arriving normally, access to your mailbox is basically working. The problem can then be looked for specifically in the outbox or SMTP.
If, on the other hand, neither sending nor receiving works, you should also check the username, password, server settings, and the basic accessibility of the account.
Test sending via webmail #
One of the fastest ways to narrow it down is a test via webmail.
Log in to webmail using the affected email address and its corresponding password, and send a test message from there to another email address you have access to.
If sending works via webmail, but not via Outlook, Apple Mail, or Thunderbird, this strongly indicates a problem with the configuration of the email client being used.
If webmail cannot send a message either, the cause is probably not exclusively due to the local configuration of your email program.
We explain how to use webmail at Use Webmail.
Practical Tip: The webmail test saves a lot of time during troubleshooting. It helps you distinguish between a local problem in the email program and a problem with the actual email account.
Check SMTP settings #
The following settings apply for normal CURIAWEB email sending:
SMTP Server: mail.deine-domain.ch
Port: 465
Encryption: SSL/TLS
Authentication: required
Username: full email address
Password: email account passwordFor the email address info@meine-firma.ch would the SMTP server be, for example:
mail.meine-firma.ch
As a username you use:
info@meine-firma.ch
You can find detailed information on the basics of the inbox and outbox under IMAP, POP3, and SMTP explained.
Use the full email address as the username #
A common configuration error is an incomplete username.
Do not only use:
Info
but always the full email address:
info@meine-firma.ch
This also applies to logging in to the SMTP server.
SMTP authentication must be enabled #
The CURIAWEB mail server does not allow arbitrary users to send messages through it without logging in.
Your email program therefore has to authenticate with the SMTP server.
Depending on the email client, the corresponding setting can be found, for example, as Authentication required, SMTP authentication or bear a similarly corresponding designation.
Use the same full email address and password of the email account for this.
Typical error: The inbox was set up with a username and password, but the credentials were not entered for the outbox. In this case, receiving mail may work while sending fails.
Check SMTP port and encryption #
For the standard CURIAWEB configuration, you use for SMTP:
Port 465
with:
SSL/TLS
Server name, port, and encryption method must match each other.
Therefore, do not blindly change the settings to other ports or encryption methods just because sending does not work immediately.
Check password #
If the password is incorrect, your email program cannot correctly authenticate with the SMTP server.
Test the email address and password in webmail first.
If logging in fails there as well, you should check or reset the password for the email account.
Please note that the email account password is not automatically the same as your password for the CURIAWEB customer center or cPanel.
Problem right after a password change #
If sending no longer works immediately after a password change, the old password is often still saved in the email program.
Therefore, update the access credentials on all devices where the email account in question is set up.
Check in particular the password saved for the SMTP server.
Important: After changing a password, do not change server names, ports, or DNS settings first. If the problem started immediately after, check the saved credentials first.
Does shipping not work on only one device? #
If you use the same email account on multiple devices, you can use these devices to narrow down the problem.
Assuming that sending works on your smartphone and in webmail, but not in Outlook on your computer, it is very likely that the problem lies with the Outlook configuration.
If sending fails on any device and also does not work via webmail, the cause should be investigated further at the account or server level.
Check multiple SMTP accounts or outgoing mail servers #
Email clients can store multiple outgoing mail servers. This is particularly common when multiple email addresses have been set up.
This can cause an account to accidentally attempt to send messages via the SMTP server or credentials of another account.
Therefore, check whether the correct outgoing mail server is actually assigned to the affected email account.
This is an important source of errors, particularly in Thunderbird and various older or extensively configured e-mail clients.
Message gets stuck in the outbox #
If a message remains in the outbox, the email program has not yet been able to successfully transfer it to the SMTP server.
First, check the internet connection and then the SMTP server, port, encryption, and access credentials.
If only a certain message is affected while other messages can be sent, the cause may also lie with this specific message.
For example, very large attachments or unusual message content can cause a message not to be processed as expected.
Only a specific message cannot be sent #
If other emails can be sent without problems, there is probably no general SMTP configuration error.
Create a test message without attachments and send it to another address.
If this message works, you should examine the problematic message more closely.
Check, for example:
- the recipient's address
- the size and type of attachments
- whether the message is sent to a very large number of recipients at the same time
- whether your email program displays a specific error message
Only messages to a specific recipient fail #
If messages are successfully delivered to other recipients, but a specific destination address or domain causes problems, your basic SMTP transmission is likely working.
The cause may then lie on the recipient's side, for example.
What is important in this case is the exact error message or non-delivery report.
It may contain indications of whether the recipient address does not exist, the destination server has rejected a message, or another delivery problem exists.
Practical Tip: In case of delivery problems, the specific error message is much more meaningful than the general statement „the email is not going out.“ Keep error messages and non-delivery reports for analysis.
Sent does not automatically mean delivered #
It is important to distinguish between Shipping and Delivery to distinguish.
If your email program has successfully handed over a message to the CURIAWEB SMTP server, local dispatch has initially succeeded.
After that, however, the message still has to be transmitted to the recipient's mail server and accepted there.
Therefore, a problem further down this path is not the same thing as an error during SMTP login in your email program.
Read non-delivery report #
If a message cannot be delivered later, the sender often receives an automatic error message. Such messages are frequently referred to as bounces or delivery failure notifications.
This may contain technical information and SMTP status codes that describe the reason for rejection in more detail.
A notification can indicate, for example, that:
- the recipient address does not exist
- the recipient mailbox is unavailable
- the destination server rejects the message
- a message was rejected due to a policy
- there is a temporary delivery issue
Therefore, the exact message should not be deleted before the cause has been determined.
Distinguish between temporary and permanent SMTP errors #
SMTP error codes help classify a delivery problem.
Response codes in the range 4xx typically represent a temporary error. The sending mail server may retry delivery later.
Response codes in the range 5xx typically indicate a permanent error or rather indicate a rejection.
However, the specific code and the associated text are crucial for the actual cause.
Important: An SMTP code alone is often not sufficient for a reliable diagnosis. Always record or transmit the complete error message.
SPF, DKIM and DMARC can play a role in delivery #
If a message was successfully sent via the SMTP server, but is rejected or rated as suspicious by a recipient, the email authentication methods of your domain can also be relevant.
CURIAWEB automatically sets up SPF, DKIM, and DMARC in the hosting DNS zone by default for standard hosting email domains.
These entries should not be changed or deleted without a specific reason.
Adjustments become particularly relevant when additional external mailing services are used – for example, newsletter systems, CRM platforms, Microsoft 365, or other external SMTP services.
We explain the connections under SPF, DKIM, and DMARC explained with CURIAWEB Hosting.
Avoid multiple SPF records #
When external shipping services are used, an additional SPF record is occasionally created by mistake.
This is not the correct approach.
For a domain, the SPF policy should be mapped in a merged SPF TXT record.
Several competing v=spf1-entries can lead to an invalid SPF evaluation and thereby cause delivery problems.
DNS changes after a domain or hosting transfer #
If shipping problems occur immediately after a domain, DNS, or hosting change, it should also be checked whether the DNS configuration points completely to the current environment.
Mail and authentication records are particularly relevant in this regard.
Due to TTL and caching, DNS changes are also not always immediately visible worldwide.
If you need to check DNS records in cPanel, you can find the corresponding instructions at Using the DNS Zone Editor in cPanel.
Check email deliverability in cPanel #
cPanel introduces with Email deliverability a function with which, among other things, important DNS-related settings for sending emails can be checked.
You can find them in cPanel under:
Email → Email deliverability
If your email program can successfully pass messages to the server, but delivery problems occur, this check can provide additional insights.
Check mailbox or hosting storage space #
Storage space issues can also affect email operations.
When an email account or hosting account reaches a storage limit, various mail functions can be impaired.
You can check the storage usage of your email accounts in cPanel.
We explain how this works at Check email storage in cPanel.
SpamExperts Incoming is not your SMTP server #
If your domain uses SpamExperts Incoming Filtering, incoming messages run through the SpamExperts MX infrastructure.
However, these MX servers are not automatically the SMTP servers that you should enter for normal sending in Outlook, Apple Mail, or Thunderbird.
For the normal CURIAWEB configuration, you continue to use:
mail.your-domain.ch
with SMTP port 465 and SSL/TLS.
SpamExperts Outgoing Filtering is a special case #
If expressly for your email account SpamExperts Outgoing Filtering configured, outbound message traffic can be routed through the SpamExperts infrastructure.
In this case, different SMTP settings apply than for the normal CURIAWEB configuration.
Then use the access credentials and server settings intended for SpamExperts Outgoing.
We explain the configuration at Set up SpamExperts Outgoing Filtering.
When SpamExperts Outgoing blocks a message #
Outgoing Filtering is used, among other things, to check outgoing message traffic for spam, abuse, and suspicious sending behavior.
A blockade should therefore not simply be circumvented by relaxing the filter settings.
Particularly in the event of unexpectedly large shipment volumes, it must be ruled out that an email account or website has been compromised and is sending messages unintentionally.
Important: If an unusually high number of outgoing emails suddenly occurs, the cause of the transmission should be clarified first. A compromised password, an infected device, or a compromised website must be fixed—not merely the filter response.
Suddenly an unusually high number of sent emails #
If messages were sent in your name that you did not create yourself, you should assume there is a potential security issue.
Change the password of the affected email account and check the devices on which this account is set up.
If the messages might originate from a website, it should also be checked for a compromise.
In such a case, it is important not only to get the shipping working again, but also to eliminate the cause of the unauthorized shipping.
Firewall, security software, or network as the cause #
If the settings are correct and sending via webmail works, in rare cases the local environment can also affect the email program's connection to the SMTP server.
This includes, for example, security software, local firewalls, or network settings.
A helpful test can be to use the same device temporarily over a different internet connection.
Does SMTP sending work there; although the email program and account settings are unchanged, the original network environment should be examined more closely.
Do not bypass certificate warnings #
If your email program displays a certificate warning when establishing an SMTP connection, you should not simply accept it permanently.
Check the server name first.
In the normal CURIAWEB configuration, it follows this schema:
mail.your-domain.ch
Safety Notice: A certificate warning is not a problem that should be solved by blindly confirming it. Check the server name, port, and encryption first.
What you should document in case of a shipping problem #
If the problem cannot resolve itself, specific technical details help significantly more than a general description like „email is not working“.
Particularly helpful are:
- the affected email address
- the email client and operating system used
- if webmail works
- whether the reception works
- whether all or only individual recipients are affected
- the time of a failed delivery attempt
- the complete error message or non-delivery report
On the other hand, you should never send a password unencrypted in a normal support message.
The most logical order for troubleshooting #
If you cannot send emails, do not immediately assume it is a server problem and do not randomly change various settings.
A meaningful diagnosis starts with a webmail test. If sending works there, you then check the SMTP configuration of your email program.
Check server name, port 465, SSL/TLS, full email address, password, and SMTP authentication.
If the handover to the mail server works, but a specific message is not delivered, then investigate the non-delivery report and the recipient side.
Only after that should further factors such as SPF, DKIM, DMARC, SpamExperts, or network problems be investigated.
Note: First determine whether your email program can even pass the message to the SMTP server. Only after that, investigate whether the message was delivered or rejected on its further path to the recipient.
Summary #
If you cannot send messages with your CURIAWEB email address, you should first narrow down the problem using Webmail.
If sending works via webmail, the cause is likely your email program or its SMTP configuration.
For the normal CURIAWEB configuration, the following apply:
SMTP server:
mail.deine-domain.ch
Port:
465
Encryption:
SSL/TLS
Authentication:
required
Username:
full email address
Password:
email account passwordIf the message is successfully handed over to the SMTP server but does not reach the recipient, it is considered a delivery issue. In that case, the specific error message, the recipient side, and potentially SPF, DKIM, DMARC, or SpamExperts are relevant.
The most important rule for email problems is therefore: consider sending and delivery separately and systematically narrow down the cause, instead of changing server data or DNS settings on a hunch.
