Cannot send email through IONOS mail server

I have a domain with IONOS, & have a private email address through them as well. I have a Django web app that is hosted on the IONOS domain, & am using the Cloudflare nameservers & DNS configuration.

I’ve managed to successfully send a password reset email through the IONOS mail server on my development instance (not using the domain), but keep getting timeouts when attempting to send it on my production server (using the domain). It seems like it’s probably DNS related.

Here’s what my DNS config currently looks like, stripped of irrelevant records.

IONOS documentation (& support) recommended the two MX records.
IONOS support also recommended the _dmarc & spf entries.
The two A records I added myself based on what Set up email records · Cloudflare DNS docs said - it seemed like it wanted A records matching the IPs of the MX records, so I dug those two IPs up & added them unproxied. No difference whether or not these records are present.

Any suggestions? Even advice on how to debug this would be helpful, I’m fumbling in the dark here, with nothing but console logs telling me of timeouts for feedback.

How did you determine what was irrelevant? There could be more than the listed, that would affect your email set up.

Stuff like the MX records are for inbound (receiving), the SPF (TXT) record and _dmarc are related to email authentication, and what you want to do with messages that fail authentication.

Do you have any TXT with a name containing _domainkey?

How exactly has this Django app configured to send mail?

1 Like

That is fair, I’m not the one to determine what’s relevant here.

There’s my full DNS setup, with the IPs whited out. I changed the name of the A records from last time to ‘mail’ - no change.
No _domainkey record.

Django email settings:
EMAIL_HOST: smtp.ionos.com
EMAIL_PORT: 587
EMAIL_HOST_USER: [email protected]
EMAIL_HOST_PASSWORD: redacted
EMAIL_SSL_CERTFILE: /pathtocert
EMAIL_SSL_KEYFILE: /pathtokey
EMAIL_USE_TLS: true
DEFAULT_FROM_EMAIL: [email protected] (this was necessary due to Important Change for Sending Emails with Different Sender Addresses - IONOS Help)
Then the email itself gets sent by the standard Django PasswordResetView.

These same settings work when sending from my locally-hosted dev environment.

If the MX records are for receiving, does that mean they are not relevant for my current use case, which is just outbound password reset emails?

Still struggling with this. I figured I’d try a different email host, so set it up with my personal email with Gmail. Again got that to work with my local instance - had to make an application password via my Google account - & then tried it in production behind Cloudflare, no luck, still timing out.

As before, I followed what this link said: Set up email records · Cloudflare DNS docs
I ran dig smtp.google.com a & received these four IPs:

smtp.google.com.        281     IN      A       173.194.65.27
smtp.google.com.        281     IN      A       173.194.65.26
smtp.google.com.        281     IN      A       142.250.142.27
smtp.google.com.        281     IN      A       142.250.142.26

And then added four unproxied A records for each of these IPs under ‘mail’. Otherwise I updated my MX record to point to smtp.google.com & deleted everything else I had previously configured for IONOS, which was the CNAMES & the TXTs. Now looking like this:

And with the same Email settings set up in my Django project, except:
EMAIL_HOST: smtp.google.com
EMAIL_HOST_USER: [email protected]
EMAIL_HOST_PASSWORD: myGoogleApplicationPassword

Still using TLS on port 587 with the same certfile & keyfile. I did try setting EMAIL_USE_TLS to False to eliminate another possible variable, same result, but that’s probably expected since Gmail probably enforces the use of SSL/TLS (as did IONOS).

What am I missing? Is an SPF or DKIM or DMARC policy something I need? Do I have the A record from the Gmail/IONOS mailserver wrong?

I would ignore that advice.

Here Django will be attempting to connect to smtp.ionos.com.

Here Django will be attempting to connect to smtp.google.com.

As such, the mail record, according to the Set up email records · Cloudflare DNS docs guide has no use here.

With the MX records pointing towards mx00.ionos.com and mx01.ionos.com, those two hostnames are the ones that would need a such AAAA/`A´ record.

With your set up with Django pointing to either smtp.ionos.com or smtp.google.com, those two hostnames are the ones that would need a such AAAA/`A´ record.

In addition, since neither Google nor IONIS has a certificate on their mail servers matching the mail record on your domain, then even if Django was successfully connecting to their mail serves, the connection would fail due to certificate errors.

Things that are working in one place, but not in another, points towards that you must research the problem in the place where it doesn’t work.

I think you should look in to whether the hosting provider of your production server is blocking access to mail servers (e.g. port 587 (STARTTLS), as mentioned in your example, port 465 (TLS), et al).

It isn’t uncommon for hosting providers to block connections to mail servers (and various other things), for security reasons, and otherwise to limit e.g. outbound spam from originating from their network.

^

Both connection refused as well as e.g. the timeouts you’re mentioning are common results when your provider (of the production server) is blocking traffic.

As you’ve tried, and not been able to connect to neither smtp.ionos.com nor smtp.google.com from the production server, the issue seems to reside on the network that is housing your production server.

I would therefore suggest you to open a ticket with the provider of that production server.

In addition, … this change of MX record(s) will break the inbound mail traffic for that domain.

3 Likes

You were right on the money. I am using Linode, & their documentation does indeed say that most compute instances by default have outgoing email blocked. Got a ticket opened, got access granted, & now am able to send email successfully.

Thanks for your help! I went barking up multiple wrong trees trying to track this down.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.