Offsite Subdomain Email
I wanted to ship email from a special domain that I’d purchased just for that purpose. Also, I needed to send from a server with reverse DNS and very reliable SLA. So, I decided to leverage a ‘managed’ VM from a smaller cloud company. But, I wanted to send with a ‘from’ domain that was different than the email domain. The email services of this managed server would use the from domain to write the DKIM. So, I had to setup my ‘from’ domain to be an email sender.
To setup a subdomain, the records and a little bit different information. Also, one shouldn’t have a receive MX record that’s different than the send security records in domain. To get a really clean bill of health, email wise, you need an MX, an rDNS, SPF, DKIM, records all for the same domain. SO, I made a subdomain for the send and put security records for it in a DNS external to the company serving my email server. But, these records pointed back to the IP of the cloud server. The records for my main domain had to remain aimed at my onsite server so I could receive here.
Get Sals Secrets’s stories in your inbox
Join Medium for free to get updates from this writer.
I really had trouble getting the email server to handle a subdomain and the details of the DKIM, etc. The web gui management software just didn’t seem to get it done. Of course, I knew little about the inner workings of the managed VM that I was renting. So, I was starting from scratch in digging in to it. I eventually found a utility on the machine that would cause DKIM’s to be added to a domain. I used it and it sort of worked. I did get DKIM to work with yahoo, but gmail still failed it! How bizare. I kept getting DKIM failures and couldn’t figure out why. I toggle back and forth with subdomain and not subdomain a little. I turns out that it also added the antiquated Domain_Key header that is no longer relevant and that probably caused the Gmail rejects, even when a passing DKIM header was present.
In playing around with adding and removing keys to/fro domains on the machine, it eventually, wouldn’t even put DKIM records in! With some creative web searches and digging around the file system, a lot of ‘find’s, etc. I determined where the DKIM was being appended.
It turns out that this server had a special ‘patch’ onto the send function, basically a bash script trampoline, that leverages a perl script to append a DKIM based upon content of keys in a directory named after the domain. So, inspecting this script, I determined where it was adding the old header and deleted that. Also, I determined that it was also doing an association and search based upon the ‘from’ field’s main domain. So, if I had keys for both domains, things might not work out so well! The DNS records are different. And, in fact, as mentioned, it actually stopped even appending it for some reason. I carved out that and made it operate on the whole subdomain only. With these two major edits, it would now use the correct keys matched to the correct offsite DNS records and append a passing DKIM record to the email.
A side issue is that all of the logging for running such scripts goes through a special security logging facility. When, I wanted to do some quick and dirty logging, I setup a file and tried to write to it. Nothin’ doin’! I found where it WAS writing and found that accessing that file was ‘permission denied’, a good thing I suppose. But, now I just knew to write to that file and tail it.
Suffice it to say that, I now have a server in the cloud, that has its own domain and hostname. It sends properly secured emails from my local machine with that machines subdomain as the ‘from’. And, the DNS records are at my IANA registry. And, I can receive email at my local machine with that same domain.
