Knowledge Base

MX records: how email delivery works

Guide objective

This guide explains MX records and mail routing from an operational perspective, with emphasis on correct configuration, security and troubleshooting. Before changing any setting, identify the affected domain, full email address, device or application in use and the exact error message. These details help separate a local client issue from a service, DNS or authentication problem.

Information to check first

Keep the full email address, current password, mail server hostname, required ports and encryption mode available. Do not use random settings found online: server names can differ between services. Provider-specific values always take precedence. Also verify that the device date and time are correct, because significant clock errors can interfere with TLS certificate validation.

Recommended configuration

For access from multiple devices, IMAP with encryption is normally preferred. Outgoing mail uses SMTP with authentication enabled. Standard references are port 993 for secure IMAP, 995 for secure POP3, and either 465 with implicit TLS or 587 with STARTTLS for SMTP. The username is generally the complete email address. Avoid unencrypted connections unless explicitly required by the service.

Authentication checks

If an authentication error appears, type the password again instead of relying on a stored credential. Check for leading or trailing spaces and confirm that the username is the full mailbox address. After a password change, update every configured device. An old phone or client that continues using the previous password may generate repeated failures and trigger temporary security blocks.

Secure connection checks

The certificate presented by the server must be valid for the hostname being used. Do not permanently accept warnings about expired, invalid or mismatched certificates. If a TLS warning appears, record both the configured hostname and the hostname shown by the certificate. The cause may be a wrong server name, traffic interception on the network or a service configuration that requires investigation.

Sending messages

Outgoing mail requires an SMTP configuration separate from IMAP. Make sure SMTP authentication is enabled and normally uses the same mailbox credentials unless the provider specifies otherwise. If receiving works but sending fails, focus on the SMTP hostname, port, encryption and authentication. Start with a simple message without attachments and send it to a reliable external address.

Receiving messages

When messages do not arrive, check Webmail first. If the message exists in Webmail but not in the local application, the issue is related to synchronization, filters or client configuration. If it is also missing from Webmail, check mailbox quota, spam, server-side filters and the domain's MX records. This distinction prevents unnecessary changes to Outlook, smartphones or other clients.

DNS and delivery

A domain must publish MX records consistent with the selected mail service in order to receive email. SPF, DKIM and DMARC do not replace MX records; they mainly help authenticate outgoing messages. DNS changes can remain cached until the relevant TTL expires. During migrations, avoid repeated changes: record old and new values, TTLs and change times so that delivery paths can be reconstructed.

Technical detail

An MX record contains a hostname and a priority, not an IP address. Lower numeric values normally represent higher priority. The hostname referenced by MX must itself resolve correctly. During a migration, verify that obsolete or unmanaged secondary MX records are removed, otherwise some mail may be delivered to an unexpected server.

Mailbox quota checks

A mailbox close to its storage limit may reject or have difficulty accepting new messages. Remove unnecessary mail, empty Trash and Spam, and inspect Sent, Drafts and messages with large attachments. With IMAP, synchronized folders consume server storage. Before deleting large amounts of important mail, create a local archive or backup using the procedure supported by your email client.

Network and firewall issues

If the settings appear correct but connections still fail, test from a different network. Local firewalls, antivirus products, VPNs, corporate networks and some access providers can filter particular ports. Comparing Wi-Fi with a mobile connection is a simple and useful test. Do not permanently disable security controls; temporary testing should only be used to identify the layer where the block occurs.

Structured troubleshooting

Work through the layers in order: credentials, server reachability, TLS, authentication, protocol and finally message delivery. Changing passwords, ports, DNS and applications at the same time makes it difficult to identify what fixed or worsened the issue. After each change, perform one controlled test and record the result. Preserve complete error codes because they often identify the cause precisely.

Common mistakes to avoid

Do not use an IP address instead of the server hostname when TLS expects a name; do not confuse the hosting-panel password with the mailbox password; do not publish multiple independent SPF records; do not point MX records directly to an IP address; do not accept suspicious certificates; and do not select random ports simply to bypass an error. Clean, consistent settings are more reliable than accumulated exceptions.

Account security

Use long, unique passwords and never reuse them across unrelated services. If compromise is suspected, change the password immediately, review unknown forwarding rules or filters and update every authorized device. A compromised mailbox can be abused for spam, damaging the reputation of the domain and infrastructure. Never send mailbox passwords through support tickets or unprotected messages.

When to contact support

If the issue persists, provide the domain, affected mailbox, client and version, operating system, network used, date and time of the test, and the complete error message. State whether Webmail works and whether the problem affects sending, receiving or both. Do not provide the password. This information significantly reduces diagnostic time and allows technicians to correlate configuration with server logs.

Final verification

Finish with an end-to-end test: sign in, synchronize folders, send to an external address, reply from that external address and confirm reception. Check Spam as well. If the issue involved DNS or domain authentication, verify that the published records match the intended configuration. Store the working settings securely so future device setup or migrations can be completed consistently.

Operational checklist

Before closing the investigation, compare configured values with the official service settings, run at least one Webmail test and one client test, record complete error codes and confirm whether the behavior is reproducible. If only one device is affected, recreate the account only after preserving any local data. If several devices and Webmail are affected, avoid unnecessary reinstalls and focus on the server, DNS, authentication or mailbox quota.