Remove all

LOADING ...

Content

Transferring an email server between hosting providers and solving sending email issues

27.03.2026

12.04.2026

6 minutes

201

Tags:

Python

Server

Related to my website

Hosting

Where it all started

It all started when I decided to once again slightly redo the main page of the site. I've already done almost everything, all that remains is to insert the feedback form at the bottom of the page, which I did successfully. The problem was discovered when I tried to send a test email. I didn't succeed. The following error popped up:

The problem was that it was not possible to obtain the local SSL certificate file: CERTIFICATE_VERIFY_FAILED certificate verified failed: unable to get local issuer certificate (_ssl.c:1002).

This was about 4 months ago. Then my decision was to simply cut out the feedback form, because this is the only element on the site that the mail server required.

Why didn't I solve this problem right away? Probably due to the fact that this is one of those problems that is not worth the time to be solved. After all, no one used my feedback form, so it was decided not to bother and just remove the broken segment.

But now this is not a problem that can be ignored. Considering the fact that sending/receiving letters is a mandatory part for:

Registration of new users
Confirmation of completed purchases
Sending mailings to everyone who subscribes to it
And of course, sending feedback forms.

Now I have all this on my website, and accordingly, mail should be working, and it must be professional.

Solving the problem

Therefore, the problem needed to be solved. And as always happens, I came from the wrong end, namely, I decided to change the mail provider from beget.ru to hoster.by. Then my logic was simple, since I can send letters from a local computer, but not from a server, the site’s code base is the same as on website and also the same on the local device. This means that the provider himself is to blame and needs to be changed.

But this is fundamentally wrong - the provider has nothing to do with it. And just a list of installed packages in the virtual environment of my site, or rather the absence of one of them - pip-system-certs. To solve this problem, you just need to install it:

pip install pip-system-certs

The answer was obvious, and by the way, not a single AI had provided the correct solution that would have helped me. This person helped me with his answer, for which I send him my thanks.

What this article will be about

But since the email transfer had already been completed, I thought, why not dig deeper and understand the topic in full? Below, I'll describe the process of transferring email from one provider to another. The only thing you need is the domain itself, email on it, and it needs to be yours—obviously.

I'll use the domain registrar and hosting provider beget.ru as an example. My domain, website, database, and email are hosted there. We'll be transferring the email to hoster.by hosting.

I won't go into detail about what and where to click, but I will cover the basic principles of transferring email from one provider to another.

Corporate email migration process

There are many different specialized providers for this service, such as Google Workspace or Mail.com. These are designed specifically for creating corporate email accounts, managing mailing lists, and much more.

There are also so-called ESPs, which specialize in bulk email distribution. This activity is also called email marketing. While corporate email is created primarily for branding, ESPs are designed for bulk email distribution. In my case, I'm creating a specific corporate email linked to a domain.

Yes, I understand that for my purposes (sending checks, thank-you emails for donations, payment confirmations), I need to use ESPs, but for now, I have few visitors and even less income, corporate email will suffice. And when the time comes, I'll add a chapter to this article on migrating corporate email to an ESP.

Setting up DNS records

But every hosting provider has this service too, which is usually either free or cheaper than specialized ones.

Suppose you already have a domain. Open the DNS editor for that domain. For example, my domain is registered with beget and will look like this:

If you want to transfer (or create) your email to another hosting service, such as hoster.by, you'll need to find the domain record settings tab in the mail section. For example, using hoster.by, it would look like this:

This page will contain the corresponding MX, DKIM, SPF and CNAME records.

Type of DNS record	Description
CNAME	Allows you to link a subdomain to another domain. This means that if a request is sent to autodiscover.timthewebmaster.com, it will be redirected to autodiscover.hoster.by.
MX	The address of the mail server to which letters will be sent or from which they will be received is indicated.
DKIM	Stores a special key to confirm the authorship of the letter, that is, whether you sent it or whether this letter was forged and sent by someone else.
SPF	This is a "White List" from which you, as the domain owner, authorize emails to be sent. It's a security measure.
TXT	A general record that is used primarily to confirm ownership rights

Now we need to transfer all the generated records from hoster.by to beget.ru.

You might be wondering, but I can't create SPF and DKIM records on beget or any other hosting provider. What should I do in this case? You can use a universal TXT record, which you'll need to create on a separate subdomain of your website.

So, using my example, simply create a subdomain mail._domainkey.timthewebmaster.com and add a TXT record there in the format provided by your provider.

For SPF, you don't need to create a separate subdomain. You need to create it on the main domain, also using a TXT record.

It will take 1 to 15 minutes for the records to take effect. Be patient, my friend.

Setting up a Django application

If your site runs on a popular CMS, such as WordPress, the previous chapter should be enough to get your email client up and running. However, if you have a custom site built on Django, you'll also need to configure settings.py to correctly send emails using the framework's built-in utilities.

CMS (Content Management System) is a system, a "website engine," that allows you to manage website content from a dedicated admin panel and even configure it without server-side intervention.

In settings.py, we need to configure the following global variables:

EMAIL_USE_SSL and EMAIL_USE_TLS , one of which must be either True or False
EMAIL_HOST - mail server address
EMAIL_PORT - usually port 465 for the SMTP protocol
EMAIL_HOST_USER - the full name of your mailbox
EMAIL_HOST_PASSWORD - your mailbox password

This is what the mail settings for a hoster.by email connection might look like when connected via SMTP:

EMAIL_USE_SSL = True EMAIL_USE_TLS = False EMAIL_HOST = "smtp.hoster.by" EMAIL_PORT = 465 EMAIL_HOST_USER = "tima-chuduk@timthewebmaster.com" EMAIL_HOST_PASSWORD = "YouSTrangePassword11"

SMTP (Simple Mail Transfer Protocol) is a standard network protocol designed exclusively for sending email between servers and from client to server.

And of course, don't enter the password directly in settings.py; instead, place it in an environment variable or retrieve it from another file.

After that, restart the server and send your emails to whoever you want. Again, here's an example for Django sites using Django's built-in mail sending utility:

from django.core.mail import send_mail send_mail( subject="About this article", message="This is nice article BTW", from_email=EMAIL_HOST_USER, recipient_list=["people1@gmail.com", "people2@gmail.com"] )

Conclusions, or how it all ended

This completes the migration. It's not too difficult: buy a domain, set up email on one provider, and copy resource records from one DNS server to another.

Of course, don't forget the additional configuration of your Django app's settings.py file, if it's built on Django.

There are resource records like MX, CNAME, DKIM, SPF, and TXT, and they are all configured by simply copying them between servers. Plus, even if a record can't be created, it can always be replaced with a universal TXT record.

The question is whether you really need to do all this. As my experience has shown, it's absolutely not necessary. I jumped to conclusions and literally paid for it.

Returning to how my migration ended. It ended exactly where this article began, with the SSL error: CERTIFICATE_VERIFY_FAILED. When I sent the test email a second time, it returned the same error as before, but via beget. And then it dawned on me that something was wrong with my application.

And as I described in the certificate verification solution, I simply installed an additional library in the website's virtual environment. ╯︿╰

Deploying the BTCPay server on VPS

Previous article