Email: Introduction and Getting Started

This article explains how email works, what DNS records are used for email delivery and verification, and how to prepare a domain to work with Cloud24.kz.

Specific server names, connection parameters, and DKIM keys must be obtained when connecting the service. RFCs define the rules of protocol operation, while the service parameters are determined by Cloud24.kz.

In the educational examples, domains example.com, .example and addresses from ranges reserved for documentation are used. Replace them with your own values. Basis: RFC 2606, RFC 5737.

1. Basic Email Protocols

SMTP — Email Submission and Transfer

SMTP — Simple Mail Transfer Protocol — is used for email transfer. It is necessary to distinguish:

• Client submission: the email program transfers the email to the sending server.
• Server-to-server transfer: the sender's email server transfers the email to the recipient's server.

These functions can be handled by different servers and ports. Server-to-server transfer typically uses port 25; client submission is configured according to the email service parameters.

Basis: RFC 5321, RFC 6409, § 3.

IMAP — Working with Email on the Server

IMAP — Internet Message Access Protocol — allows reading emails, managing server folders and message flags, performing searches, and synchronizing changes with the server.

For example, a read mark on an email can be displayed across multiple devices connected to the same mailbox. IMAP itself does not send emails: a separate submission protocol is used for that.

Basis: RFC 9051, § 1.

POP3 — Receiving Emails

POP3 — Post Office Protocol, version 3 — allows receiving messages from a mailbox.

Downloading an email by itself does not mean its deletion:

• RETR retrieves the message;
• DELE marks the message for deletion;
• the deletion of marked messages is performed in the UPDATE state after the QUIT command.

Whether emails remain on the server depends on the client settings and server policy.

Basis: RFC 1939, §§ 5–6.

2. What to Prepare Before Configuration

Before changing DNS records:

1. Ensure you have access to manage the domain's DNS zone. It may be with the registrar, hosting provider, or a separate DNS provider.
2. Obtain the current service parameters from Cloud24.kz:
   • MX servers and their priorities;
   • recommended SPF policy;
   • DKIM selector and DNS record value;
   • webmail address;
   • email client connection parameters.
3. Create the necessary mailboxes, addresses, and aliases.
4. Make a list of all systems sending emails from your domain: employee email, website, CRM, accounting system, mailing service, and other applications.
5. Save current DNS records, especially if migrating email from another provider.

This list will be needed to verify all permitted sending sources.

3. DNS Records for Email

DNS stores information about domain names, including server addresses and service records.

For email, the following are used:

MX, SPF, DKIM, and DMARC solve different tasks. To connect the service, you should fulfill the requirements of Cloud24.kz. The mere presence of these records does not guarantee delivery to the inbox.

In DNS management forms, the following notations are often used:

• @ — the root of the current zone, for example example.com;
• relative name, for example _dmarc, — a name within the current zone;
• fully qualified name — for example _dmarc.example.com.

Check the format with your DNS provider: some panels automatically append the zone name. After saving, verify the final fully qualified record name.

4. MX Configuration

The MX record specifies which servers accept incoming mail for the domain.

Adding a Record

1. Open the DNS zone management panel.
2. Select the MX type.
3. Specify the domain receiving the mail.
4. Enter the server name and priority from the Cloud24.kz connection parameters.

For example, if during connection you are given the server protectionmail-a.cloud24.kz with priority 10, the record will look like this:

The server field specifies the domain name, without https://, port number, or path.

Server Priority

A lower number means a higher priority:

A server with priority 10 is preferred over a server with priority 20. Multiple MX records do not mean automatic copying of emails to each server.

If there is no MX, the SMTP standard implies an attempt to deliver using the domain's own address records. To connect to the email service, configure the MX records provided by the provider.

Basis: RFC 5321, § 5.1.

The server name in the MX must resolve to address records and must not be a CNAME alias. Basis: RFC 2181, § 10.3.

5. SPF Configuration

SPF verifies the IP's right to use the SMTP MAIL FROM/HELO domain, not the From header.

Publish a single v=spf1 TXT record per name: multiple records result in a PermError. Supplement the existing policy.

Qualifiers: + — Pass; - — Fail; ~ — Softfail; ? — Neutral. The default is +. The final decision is made by the recipient.

redirect= — modifier: transfers verification to another domain if mechanisms do not match. Combination with ip4 and other mechanisms is allowed; the presence of all makes redirect ignored. The placement of redirect in the string does not determine the verification order.

Limit — 10 evaluated elements requiring a DNS lookup, including nested ones; exceeding this results in a PermError.

For two servers:

With an additional service:

If Cloud24 prescribed policy transfer:

include requires a published SPF policy; an SMTP server name by itself is not suitable for this.

Basis: RFC 7208, §§ 2–6.

6. DKIM Configuration

DKIM — DomainKeys Identified Mail — links an email to the signing domain via a digital signature.

The sending system:

1. Creates a signature with a private key.
2. Adds the DKIM-Signature header.
3. Specifies the signing domain in the d= parameter and the selector in s=.

The recipient finds the public key in DNS and verifies the signature.

The DNS record publishes the key, it does not sign emails. Signing must be enabled on the sending system.

DKIM does not encrypt the email, does not show whether it was read, and does not by itself confirm the author's identity. Verification applies to the signed parts of the message taking into account canonicalization rules.

Basis: RFC 6376, §§ 1 and 3.

Adding a Record

Obtain the selector and full public key from Cloud24.kz.

For example, with d=example.com and s=protectionmail-a:

Value structure for an RSA key:

The text in angle brackets indicates the field that needs to be replaced. The private key is not published in DNS.

Basis: RFC 6376, §§ 3.6.1–3.6.2.

For RSA signatures, rsa-sha256 is used; rsa-sha1 is forbidden. RFC requires keys no shorter than 1024 bits and recommends no shorter than 2048 bits. Basis: RFC 8301, §§ 3.1–3.2.

If the DNS panel splits a long TXT value into multiple strings, they must remain parts of a single record and be concatenated without added spaces. Basis: RFC 6376, § 3.6.2.2.

7. DMARC Configuration

DMARC links the SPF and DKIM results to the domain of the visible sender address in the From header.

DMARC passes if at least one condition is met:

• SPF passes, and the verified MAIL FROM domain aligns with the From domain;
• DKIM passes, and the signing domain d= aligns with the From domain.

A successful verification for an unrelated domain is not enough. With an empty MAIL FROM, SPF determines the identifier via HELO/EHLO.

Relaxed alignment is used by default: domains with a common organizational domain are allowed. Strict alignment requires an exact match.

Basis: RFC 9989, §§ 3.2.4 and 4.4.

Initial Record

First create a mailbox for reports, then add:

Policies:

The final decision is made by the recipient. Even p=none does not guarantee acceptance of the email.

Basis: RFC 9989, §§ 4.5–4.7 and 6.7.

Reports

rua specifies the address for aggregate reports. They contain information about sending sources and verification results, including successful and unsuccessful ones. For regular analysis, it is convenient to use an XML report processor. Basis: RFC 9990, § 3.

The optional ruf requests reports on individual failures. The address is also defined by a URI:

Such reports may disclose information about individual messages; their receipt is not guaranteed. Basis: RFC 9991, §§ 2 and 7.

Sending reports to an external domain requires confirmation from the report recipient. Use the DNS settings provided by the reporting service. Basis: RFC 9990, § 4, RFC 9991, § 5.

Transition to Restrictions

Start with p=none, collect reports and correct the settings of all legitimate senders. After verification, you can transition to quarantine or reject.

Basis: RFC 9989, §§ 5.1.4–5.1.7.

8. Connecting an Email Client

Use the server names, authentication method, and ports provided by Cloud24.kz.

Standard options for secure connection:

Support for each option must be clarified with the service. Port 25 is typically intended for server-to-server transfer.

Basis: RFC 8314, §§ 3.1–3.3, RFC 6409, § 3.1.

Use TLS version 1.2 or higher and server certificate verification. A certificate error should be resolved by checking the server name and connection parameters. Basis: RFC 8997, § 3.

9. Verification After Configuration

DNS Verification

Verify the records using their fully qualified names:

Compare the DNS responses with the saved values. Ensure that the panel did not append the zone name twice.

Email Verification

1. Send an email from the new mailbox to an external address.
2. Reply from the external address and check receipt.
3. Repeat sending from the website, CRM, mailing service, and other permitted systems.
4. Check the spam folder and delivery error messages.
5. Make sure that emails are signed with DKIM.

In the technical headers of the received email, the recipient's server may indicate the results in Authentication-Results, for example:
a
spf=pass
dkim=pass
dmarc=pass

Evaluate the results added by the recipient's trusted server: the mere presence of such a header does not prove successful verification. Basis: RFC 8601, §§ 2 and 7.

Passing the verifications confirms specific properties of the message but does not guarantee its placement in the inbox. The recipient also applies their own filtering rules. Basis: RFC 9989, § 6.7.

10. DNS Changes Propagation Time

Changes do not become visible to all recipients simultaneously.

TTL determines how long a DNS response can be stored in the cache. If the record was previously absent, the absence response can also be cached. Therefore, there is no universal timeframe of "up to 48 hours".

Basis: RFC 1035, § 3.2.1, RFC 2308, § 5.

During a planned email migration:

1. Check the current TTLs in advance and decrease them if necessary.
2. Keep in mind: decreasing the TTL does not shorten the storage time of responses already in the cache.
3. Prepare the new mailboxes and sending systems prior to switching the MX.
4. Coordinate a period of parallel operation for the old and new services.
5. After the switch, check delivery and reports.
6. Remove the settings of the previous provider when it stops participating in receiving and sending email.

11. If Emails Are Not Sending or Receiving

To contact support, prepare:

• the domain and the address of the affected mailbox;
• the date, time, and time zone of the problematic dispatch;
• the recipient's address;
• the error text or non-delivery notification;
• information about the system from which the email was sent;
• technical headers of the received email, if it was delivered.

This will help determine whether the failure is related to DNS, the client connection, the sending system, or processing on the recipient's side.