There are some nitpicking DNS checkers which complain about non-optimal SOA records. In particular,
Primary Name Server Not Listed At Parent Zone
Invalid SOA SERIAL number
Invalid SOA REFRESH value
The two NS servers which I have registered with my domain’s registrar are ns1.desec.io. and ns2.desec.org. as instructed by the setup guide. Those also are listed at the parent de.-zone for my domain, i.e. dig SOA my-domain.de @a.nic.de. returns those. However, the SOA record refers to get.desec.io. as the MNAME and primary master which has neither a NS record for my-domain.de. at the de.-zone nor A/AAAA records in the io.-zone. This is considered an configuration error by some fussy DNS checkers.
The SOA SERIAL number does not follow the de-facto pattern YYYYmmddvv but equals 2026095961 at the point of writing. 59 is not a valid day. Again, this is considered a configuration error by some DNS checkers.
The SOA REFRESH value equals 86400 seconds or 24 hours. The recommended best practice is to use 12 hours (or 43200) as the maximum value.
Why am I writing this?
I am running a self-hosted SMTP server. I have set up all the bells and whistles, i.e. it’s not an open relay, SFP record is set, DANE is set up, DKIM/DMARC are set, my mail server properly advertises TLS as preferred over unencrypted and DNSSEC is enabled. Basically, I have done everything which is considered state-of-the art to run a mail server. However, I still have problems to successfully sent mails to domains hosted by Microsoft. Their latest excuse is that my DNS configuration would be invalid (see above).
None of the points above is a valid reason why mails shouldn’t be forwarded to the recipients mailbox. IMHO, they are just making up cheap excuses to block self-hosted mail solutions and promote their own Office365/Oulook Web/Hotmail services. (There is absolute no reasonable argument why a 12 hours DNS refresh is “good” and 24 hours “bad” and why it should affect mail delivery.) However, I kindly ask DeSEC to fix those “errors” and let it be alone to provide less attack surface for them.
The website MX Toolbox has an “email health check” and Microsoft redirected me to them and basically said unless those “errors” aren’t fixed any mail from my mail server would be considered spam.
I know it’s stupid, but I believe it’s easier to get it fixed on DeSEC side than fighting against Microsoft or MX Toolbox.
…and I’ll add that interpreting the zone serial number is particularly, well, not smart. The only actual requirements for the content of this field are in RFC 1982. Apart from that, it’s an opaque value, i.e. not to be interpreted. The recommendations that lead to the warning are operational in nature, to avoid common pitfalls when managing DNS serial numbers, but they are still not meant to encode information in the serial number that anyone could rely upon. These warnings can be informative to a novice DNS server operator. Nobody else has any business taking these warnings as a sign of bad practice.
I, too, run a mail server on my deSEC-hosted domain. So far, I have not run into any problems delivering mail to Microsoft or anyone else. So, deSEC’s setup does not seem to be the blocker here.
My guess is that the reference to MX Toolbox is a first level support answer that does not have anything to do with your specific issue.
Do you send from a residential IP address or from something more static (VPS, ISP “business” offering, etc.)? May email services block mail from residential addresses or classify them as SPAM. Not sure if MX Toolbox should catch this with some of it’s many blacklist checks.
I know all of this. I hoped that putting “errors” in quotation marks and using phrases like “making cheap excuses” would make unambiguously clear that I know that those aren’t actual errors. As I said they are cheap pleas on Microsoft’s side to block independent mail services which are too small to fight back. (I assume they would never dare to block and challenge Gmail like this.)
Here, a large company is abusing its market power to suppress unwanted competition using contrived pretexts, and gets away with it because the effort required to defend oneself properly is too great.
However, there are two options how one can deal with that situation:
Comply and eliminate their options for cheap excuses, i.e. “repair the alleged errors”. Not because they are errors (they aren’t!), but just because it’s the easier way. I just had hoped that deDEC might change they way how to use the serial counter, because that would give MS one aspect less they could come up with.
Stand your ground and fight back. I have already threatened Microsoft twice with a complain based on the Digital Markets Acts and then they “suddenly” were able to fix the issue on their side, but I know that I will never actually file a complain, because I just don’t have the energy, the time and the money to do it.
Again, I know that deSEC’s setup is not the error here. Also my self-hosted mail server is set up state-of-the-art and it has sent no single spam mail for the last seven years. My mail server even uses a stricter configuration than Microsoft’s own rules for SMTP hosts recommend. That makes it particularly preposterous. Here is what actually happens. I have been through that with Microsoft support six times:
Microsoft uses it’s own internal block list (OLC) and aggressively puts entire network ranges onto the block list.
MS blocks the entire sub-network (202.61.200.0/22) or autonomous system (AS 197540) of my hosting provider
My dedicated public, static IP is caught in the cross fire as collateral damage
I request MS to put my dedicated IP on an exception list (“allow list”)
This usually requires a lot of back-and-forth with MS and some treats from my side
Eventually, MS is able to to to put my IP on the allow list
Shortly, after MS delists the entire sub-network or autonomous system which they had initially blocked in step 1
As part of step 5, MS also removes my dedicated IP from their allow list as the exception rule from step 3 isn’t relevant anymore at this moment in time
MS blocks the entire sub-network or AS again, so we are basically back at step 1
I do not even mind that MS blocks entire networks. Spam mails are indeed an issue. However, there are two ways in which Microsoft is acting incorrectly:
Once, there is an exception rule for a dedicated IP address, that exception rule should be permanent. If MS continues to block they entire AS again in the future, an exception rule for a dedicated IP shouldn’t be removed, just because it isn’t technically relevant momentarily.
The complete intransparency of the process and artificial, made-up obstacles of step 3.
My hope was just that deDEC might help to remove some of those made-up obstacles in step 3. While it won’t completely fix the problem (MS will still continue to act as the do), it just might help me to cut the back-and-forth with MS a little bit shorter, because they run out of cheap excuses earlier.
It is a dedicated, static, public IP address which I own for 7 years now. It’s part of the AS 197540 and it terminates at a true private root server, i.e. no shared hosting, no virtual root server, it’s “mine”. I know all about the issues with dial-up IP addresses, etc., and I wouldn’t be ranting about MS if they were blocking those. (I probably would do the same.) Spam is a problem which needs to be fought.
I am hosting my own Nextcloud instance for me, my family and some relatives plus friends, because I don’t want to share my entire data with some of the big cloud providers which can just cut you off from your own data on their discretion. As part of that, I also roll my own mail server. (Just my own IMAP account holds 12GB of mails.) I have all the bells and whistles in effect (DKIM, SFP, DANE, etc., TLS 1.3 encryption, rsampd, …). My mail server gets A++ rating from most publicly accessible mail rating tools and my mail server is on no blocklist (I regularly check this), but Microsoft.
Microsoft is the only mail hoster I have problems with. And I insinuate they do it on purpose.
Changing the way we do serials isn’t a trivial ask; our reluctance to change it isn’t just about “being right” or what the standards say, it’s also about economics, service reliability, and development bandwidth.
While I certainly feel your pain in dealing with Microsoft, it’s currently not a fight that deSEC can pick up. If you have any concrete ideas on how to change our implementation, please feel free to open a pull request on GitHub so we can discuss the technical implications there.
I can also report that I’m aware of mail services running on deSEC DNS infrastructure that do not have the particular issue you’re describing, so changing the way the serials work, while being expensive, may not help solve your problem.
