How We Connected PlaySport Business Email to Mailcore

About PlaySport

PlaySport helps people find sports clubs and venues in Uzbekistan and, where a schedule is connected, book time online. It is built by the same team as Mailcore, and we state that relationship openly: PlaySport was our first complete Mailcore deployment on a real domain.

The project needed email at playsport.uz for operational contacts. For Mailcore, it was an opportunity to verify the entire route on more than a demonstration address—from DNS and mailbox creation through receipt and delivery events.

The objective

The team needed to receive messages at @playsport.uz, access them through webmail, and route messages sent to any domain address into an administrator mailbox.

We also wanted to verify authentication for outgoing test messages, secure mail connections, and an infrastructure design that would not require repeated changes to the PlaySport DNS zone.

What mattered in testing

• A real incoming message had to reach the mailbox, not merely pass a DNS syntax check.
• Addresses such as support@playsport.uz had to retain enquiries even before a dedicated mailbox existed.
• SPF, DKIM, and DMARC had to pass at an external recipient.
• Webmail, IMAP, and SMTP had to use a valid TLS certificate.
• Delivery, rejection, delay, and complaint events had to enter the monitoring workflow.
• The technical route had to remain movable without another change to the client domain's zone.

What the Mailcore team did

Prepared the domain and working access

We added playsport.uz to the mail system, created an operational mailbox, and connected Roundcube webmail. For addresses not yet requiring separate sign-in, we configured catch-all routing into the administrator mailbox.

The mailbox quota was set to 1 GB and maximum message size to 35 MB. We verified the limit with an intentionally oversized test message so users receive a clear rejection before trying to upload an undeliverable attachment.

Configured routing and authentication

Incoming mail routes through mx.mailcore.uz. We published SPF, DKIM, and DMARC for the domain and connected outgoing tests through Amazon SES. Email clients use encrypted channels, and the certificate renews automatically.

Added delivery monitoring

For outgoing tests, we configured delivery, delay, rejection, and complaint events. We verified the chain end to end: a message passed through the mail server and external relay, then its delivery event returned to a mailbox monitored by a person.

Made future infrastructure changes simpler

We later moved incoming routing onto dedicated Mailcore infrastructure by changing one technical DNS record, mx.mailcore.uz. The playsport.uz zone needed no further change: its public destination remained stable while Mailcore changed the underlying target.

What the tests confirmed

• A real incoming message reached the PlaySport mailbox.
• Catch-all accepted a message to an arbitrary domain address.
• A test message reached Gmail with spf=pass, dkim=pass, and dmarc=pass.
• TLS was verified on IMAP and SMTP connections.
• The chain from test-message submission to delivery event was confirmed.
• Before moving infrastructure, we checked the server address against Spamhaus, SpamCop, and Barracuda; it did not appear on the checked blocklists.

Outgoing delivery in this case was tested in a controlled mode. We will publish bulk-production results separately when there is enough deliverability data.

What PlaySport received

PlaySport received a managed incoming email environment on its own domain, a web interface, and routing rules for work addresses. The domain authenticates test messages with SPF, DKIM, and DMARC, while the Mailcore team receives technical delivery events and can investigate rejections from evidence.

For us, the launch validated the operating process on our own project before offering the same route to an external company.

What we repeat for external clients

1. Confirm the domain, required addresses, current service, and enquiry-routing rules.
2. Prepare an exact DNS record list and guide its installation.
3. Create mailboxes, aliases, and routes for the company's needs.
4. Configure SPF, DKIM, DMARC, and encrypted connections.
5. Test real correspondence with external systems—not only DNS records.
6. Before production switchover, add an independent backup environment and prove recovery with a control test.
7. Give the responsible employee credentials, settings, and a clear acceptance checklist.

The connection scope is agreed in advance, so the client knows what will be configured, which information its team must supply, and how Mailcore will prove readiness.

What this means for your role

For an owner

Email remains on the company domain, work and price are agreed before DNS changes, and acceptance uses clear tests.

For an office manager

You do not need to design mail infrastructure. Collect the address list, current provider, and access owners; Mailcore prepares the records and sequence.

For an IT specialist

You receive a concrete routing design, DNS values, TLS on mail ports, and technical acceptance through external messages and authentication headers.