External DNS with MIAB on Subdomain of Website

stuzbot · April 27, 2022, 7:39pm

OK. I’ve just got MIAB running and sending and receiving emails on a couple of pretty much unused domains I have. But, as this is all new to me [though I have a fair bit of experience running webservers] I want to make sure that I’ve got everything locked down and correctly configured before I migrate my main domain mail accounts over from Google Workspaces.

So here’s the scenario:

I have several websites running on a Linode VPS, including one on my main domain. Let’s call it maindomain.com. At the minute email for maindomain.com is handled by Google Workspace.
On that VPS I also have a few less used domains [let’s call them minordomain1.com, minordomain2.com, minordomain3.com. All those domains were using Yandex Mail for Domains [now rebranded Yandex 360] to handle their email.
I’ve set up MIAB on a separate fresh Linode VPS and I’m running my MIAB mailserver on that as the subdomain post.maindomain.com

Still with me? Good. Now, what I want to know is which of the configuration options listed on my MIAB servers ‘External DNS’ page are necessary for my setup?

For example, I get several config options given for things like A/AAAA records for maindomin.com should point at MIAB IP… which obviously they shouldn’t, because I want those to remain pointing at the VPS which is serving the website for that domain. Only the A/AAAA records for post.maindomain.com should be pointing at my MIAB VPS.

So, obviously some of the options given for external DNS config settings don’t apply to my particular setup. The trouble is, once I get beyond the ‘usual suspects’ like A/AAAA, MX, CNAME, TXT records etc. and into the more esoteric email specific ones, I’m a bit lost as to which ones are strictly necessary for my setup.

As I said at the top, I’m able to send emails back and forth from minordomain1.com, minordomain2.com, minordomain3.com by setting their MX records to use post.maindomain.com. So that much at least is working. But I’m wary of leaving something out in the more obscure config options that will either leave my server vulnerable, or will have my emails marked as spam and the server blacklisted.

So, any help would be appreciated with the following options. Given my setup, do I need to set any of the follwing or not on post.maindomain.com [MIAB server] or maindomain.com [webserver] or neither?

[At some stage, when I migrate from Google, I will be sending/receiving email from @maindomain.com so I don’t want to set any config options that will effectively block that, when the time comes]

* autoconfig.maindomain.com	TXT	v=spf1 -all
* autoconfig.maindomain.com	MX	0 .
* _dmarc.autoconfig.maindomain.com	TXT	v=DMARC1; p=reject
* autodiscover.maindomain.com	TXT	v=spf1 -all
* autodiscover.maindomain.com	MX	0 .
* _dmarc.autodiscover.maindomain.com	TXT	v=DMARC1; p=reject
* mta-sts.maindomain.com	TXT	v=spf1 -all
* mta-sts.maindomain.com	MX	0 .
* _dmarc.mta-sts.maindomain.com	TXT	v=DMARC1; p=reject
* post.maindomain.com	TXT	v=spf1 mx -all
* _dmarc.post.maindomain.com	TXT	v=DMARC1; p=quarantine
* mail._domainkey.post.maindomain.com	TXT	v=DKIM1; h=sha256; k=rsa; s=email; p=<snip>
* mta-sts.post.maindomain.com	TXT	v=spf1 -all
* mta-sts.post.maindomain.com	MX	0 .
* _dmarc.mta-sts.post.maindomain.com	TXT	v=DMARC1; p=reject
* www.maindomain.com	TXT	v=spf1 -all
* www.maindomain.com	MX	0 .
* _dmarc.www.maindomain.com	TXT	v=DMARC1; p=reject

I’d also like to keep the config options as simple as possible [more chance of me remembering what they all mean!]. So anything that’s not strictly necessary, can go. Unless it’s important for security or not being blacklisted.

For example: I think I’ve read somewhere that the autoconfig and autodiscover options are to allow email clients to automatically retrieve the correct IMAP/SMTP server settings. If that’s the case and that’s all they do, then I can live without them as I’ll only be setting up email accounts for myself and family members. So I can tell them what server settings to use. Like I say, the less options I can get away with having to configure, the better.

stylnchris · April 28, 2022, 12:58am

I think your main problem here is you can’t have MX records for your “maindomain.com” to be pointed to google and also expect that same domain to deliver mail to your MIAB server. (maybe your not?)

If you are migrating mail from google to miab then MIGRATE. Mail is all or nothing, you dont get the choice to pick and chose which dns records you use for your “maindomain.com” if you want mail to actually be delivered. So if its google then you keep them going to google. If its MIAB then you change dns records and send it to your VPS server running MIAB.

autodiscover and autoconfig are (in my opinion) vitally necessary for mobile phones to find email servers without driving you (or your users of the email system) crazy. Z-Push (the Active Sync server service) specifically uses those records [to my knowledge] this allows allows for a PUSH email update rather then a FETCH.

You are absolutely correct if you have no WEB being hosted on the MIAB server, any “www” type records are not needed. Including the dmarc, spf, etc.

Here is where I’ll say for the remaining ones that your not sure about - the admin interface explains exactly why each record is needed and if it its optional.
Look for “Recommended” and “Optional” in description of each entry.

I tend to use MIAB only to host mail.

I have the “naked domain” entries and my box lives on “mail.mydomain.com”
I also host at least 6-9 other domains on the same box.

Each domain you add you will be adding the dns entries manually for each domain / subdomain.

each email address you end up entering into your box (to setup a new user) will ditcitate where that email inbox lives.

so if that is tom@post.maindomain.com and once you eventually migrate from google you will need to either make an alias so that tom@maindomain.com works (keep in mind you will always need to log in with the tom@post.maindomain.com) or you will need to create the tom@maindomain.com and then move the mail from tom@post.maindomain.com to tom@maindomain.com) I hope that sorta makes sense.

If you plan on doing the full migration, dont bother with the @post.maindomain.com email address.

Add all your users (like tom@maindomain.com) and move the mail from Gsuite/Google Workplace – whatever they are calling themselves today to each mailbox.

This tends to be a very long process. When I migrated mail for my Google based mail I used nothing more then thunderbird email client. I setup the google mail box in thunderbird. I setup the miab server in thunderbird using (IP ADDRESS) and then dragged mail from one directory structure to the other. It takes awhile for it copy and sometimes you need to start all over again.

THE ABSOLUTE BEST ADVICE I CAN GIVE SOMEONE DOING THE MIGRATION IS TO USE GOOGLE TAKEOUT BEFORE. HAVE GOOGLE TAR.GZ YOUR MAIL FOR EACH USER. You can download that and use it later if mail goes “missing”

Lucky I have a pretty stable internet connection and migrating mail wasn’t an issue. I did have one user who claimed to be missing mail but I luckily mad the backups via takeout and was able to show them that the mail wasn’t there either.

I hope I’ve helped a bit?

stuzbot · April 28, 2022, 12:21pm

I think your main problem here is you can’t have MX records for your “maindomain.com” to be pointed to google and also expect that same domain to deliver mail to your MIAB server. (maybe your not?)

No. I think you’re misunderstanding me. My email on maindomain.com is still totally handled by Google and will be til I’m ready to migrate it to MIAB. The only connection my MIAB has [currently] with maindomain.com is that, instead of registering a new domain for my MIAB server, I’ve just set it up as a post.maindomain.com sub-domain. But it’s running on a separate VPS and with a separate IP address from maindomain.com [which is my company website].

Hence why a lot of the config options don’t apply as they assume you’ll either be running MIAB on its own dedicated domain, or running any website for the domain your MIAB is on, on the same MIAB server. As I said, It’s just a case of working out which ones don’t apply, when some of the more obscure email related config options are new to me.

What I have my MIAB server configured for at the mo’ is to serve email for 3 or 4 other domains [which are also hosted on my other maindomain.com VPS] and it all seems to be working OK. I’ve been sending and receiving on all the accounts, both amongst them and to other external accounts on Gmail and Yandex mail and I’ve only had two bounce back as spam so far. Both of which I was able to have successfully go through second time around, by sending them as replies to emails from those external providers, rather than sending ‘unsolicited’.

So, mechanically, the basics are working fine. I’m just trying to get my head round whether or not I’ve accidentally missed out setting an option which will be harming my server’s reputation, or which will present a security risk, or have set options on the domains using my MIAB for their email which should be set on the MIAB subdomain instead.

So far I have added the following options:

MAINDOMAIN.COM running on Linode VPS

* NS records  [unchanged. Pointing to Linode nameservers]
* MX records [unchanged for now. Still letting Gmail handle email for this domain]
* A/AAAA records [new record added for `post.maindomain.com` --> pointing to IP of my MIAB server]
* CNAME [unchanged. no records]

*TXT records
** v=spf1 mx include:aspmx.googlemail.com -all [still unchanged as I've not migrated email for this domain yet]
** _dmarc.mta-sts	v=DMARC1; p=reject 
** _dmarc.post	v=DMARC1; p=reject
** _dmarc.www.post	v=DMARC1; p=reject 
** mail._domainkey <snip>  [presuming I need this to prove identify of domain ???]
** mta-sts	v=spf1 -all
** post	v=spf1 mx -all
** www.post post	v=spf1 mx -all

Then, on each of the other domains minordomain1.com , minordomain2.com , minordomain3.com which I’ve so far migrated to MIAB, I have their records set as follows:

MINORDOMAIN[1,2,3].COM running on same  Linode VPS as MAINDOMAIN.COM

* NS records [unchanged. Pointing to Linode DNS]
* MX record  [changed to `post.maindomain.con` [ie my MIAB server running on a different VPS]
* A/AAAA records [unchanged]
* CNAME records [unchanged. None]

* TXT records
** v=spf1 mx ~all
** _dmarc	v=DMARC1; p=quarantine
** _mta-sts	v=STSv1; id=<snip>
** mail._domainkey	v=<snip>

So, I’m OK with most of this, with the exception of the _dmarc, _mta-sts, mail.domainkey ones. I’m still not sure if these should be on the domain records for maindomain.com [of which my MIAB server is a subdomain] or on all the individual domains which are using the MIAB server to handle their email.

I have read the guidance notes on the MIAB system report page but I’m still none the wiser.

stylnchris · April 28, 2022, 12:42pm

Thanks for the follow up post.

I believe I understand you a bit better.

I do not believe you would need anything for the “maindomain.com” then and this shouldn’t hurt your reputation. The records that you would need would only be for the subdomain so mail can be delivered (until the point at which you switch from GSuite to MiaB).

MX Toolbox is a great place to ensure you got the right records down.
SPF Check → SPF Check & SPF Lookup - Sender Policy Framework (SPF) - MxToolBox
Blacklist Check → Email Blacklist Check - IP Blacklist Check - See if your server is blacklisted
DMARC Check → DMARC Check Tool - Domain Message Authentication Reporting & Conformance Lookup - MxToolBox

The mail._domainkey is for DKIM which you can also check here: DKIM Check- DomainKeys Identified Mail (DKIM) Record Lookup - MxToolBox

domain: use your subdomain here post.maindomain.com and the selector is “mail” (no quotes)

Does that help?

stuzbot · April 28, 2022, 1:35pm

Thanks. I had the feeling that a few of those options I’d set on my main domain were redundant. But, as I said, the wording of some of the notes on the system status page on MIAB can be a bit confusing, when you’re not actually running the MIAB on TLD. I guess it’s just a case of learning which of MIAB’s error messages [apart from the A/AAAA ones, which I already knew were spurious in my setup] are safe to ignore.

I’ll check out some of those links and see what they say.

stuzbot · April 28, 2022, 4:28pm

Well, MX Toolbox seems to think my setup is pretty OK…

The 3 warnings are about minor DNS issues which [on reading the ‘More Info’ blurb] seem to be related to Linode’s DNS setup, rather than anything I’ve [mis]configured.

So, I’m tentatively thinking I may have got things set up reasonably properly here!

stylnchris · April 28, 2022, 7:16pm

Glad you got things worked out. Sorry for the misunderstand there in the beginning.

stuzbot · April 28, 2022, 7:35pm

No worries. My explanation was probably a bit confusing anyway.

In other news, I’ve managed to send a few test emails to a Yahoo email address tonight and they all got through. So, that’s Gmail, Yandex Mail and Yahoo I’ve been able to send to, from each of the domains my MIAB is serving email for.

So only Outlook to try next of the “notorious for blocking emails” internet email mafia!

stylnchris · April 28, 2022, 7:46pm

Ive been pretty lucky with MiaB, but I also host my own server on Business Class internet connection out of my house. If you go with Business Class you can typically get a static IP and have your ISP make reverse dns entries for that IP etc. Hosting yourself typically means you get a nice clean IP that isn’t on any block list. It also means your “subnet” range will never be blocked due to someone else in that same address space (some else spamming on another server in the same range as what your VPS Provider provided).

It def has its drawbacks though. While I have a pretty decent server infrastructure I’m not immune to Storms that have power and internet outages, etc. Was down for nearly 2 days recently → National Grid Restores Power to 90% of Upstate New York Customers Impacted by Damaging Snow and Wind Storm

Good part about email is most systems will queue it for a while and retry when your server becomes available again.

Not sure I really missed any emails.

Anyways reason I mention it is because if Outlook is a major concern you could always host the stuff “yourself” I do recommend server grade hardware though with “mirrored” disk and dual power supplies at a minimum.

stuzbot · May 4, 2022, 7:44pm

I don’t think I actually know anyone with an Outlook email address. So it’s not too high priority for me at present.

FWIW I finally bit the bullet yesterday and transferred my email out of Google. Around 20 years worth in my account ~5GB and the missus had about 2,5GB in hers. There were a couple more accounts too with lesser amounts in.

Took a day and a half for imapsync to migrate my account and about 3 hours for the missus’s.

Everything seems to be working OK now. And, as an added bonus, I can probably heat the house on the typhoon of hot air billowing from my laptop’s fans, as thunderbird downloads and re-indexes 30 thousand odd emails!

I was going to leave the Gmail migration for a bit longer, just to see how my MIAB server performed over a few weeks of uptime. But I was expecting some important emails to one of my Gmail aliases this week [which had previously been working perfectly], which never arrived and, when I logged into my Google Admin to try and check the mail logs, I couldn’t get anything to show up in their stupid interface whatsoever. No matter what I searched for.

Add to that I found a thread with about 60 “me too” on the Google support forums all with the same problem: ‘email alias suddenly stopped working, for no apparent reason’ and the fact that whenever I tried to access advanced server spam configuration in the Admin section, I kept being told I needed to upgrade to a paid account and I thought “F**k this for a game of soldiers!” and decided to bail out there and then.

At least when something goes wrong from now on, I’ll know it’s my fault and not another random Google “It’s not broken but let’s fix it anyway!” moment.

If I were more paranoid than I am already, I’d suspect google were deliberately degrading the service on their legacy free accounts, to try and ‘persuade’ people to upgrade sooner to the paid version. If that was the idea, it back-fired in my case.