The DANE TLSA record for incoming mail is not correct / MTA-STS policy is missing: STSFetchResult.NONE

I’ve been getting this for the past 48 hours after performing an upgrade to a new 22.04 installation.

Along with the “MTA-STS policy is missing: STSFetchResult.NONE” error.

Any way to force a DNS update, or to dig up the status of the propagation (if that’s what is happening)?

The MTA-STS policy is missing report might resolve itself after a day or so. I’m not sure if that would also apply to the DANE report.
You can force a dns update by running sudo tools/dns_update --force from the mailinabox installation folder. Another check you can make is to look under the TLS (SSL) Certificates menu in the admin portal. There might be a button there to renew the certificates (only needed if the certificates are indicated as invalid or not present)

1 Like

All certificates are up to date.

Both these errors are now going on Day 3 without being resolved.

I had run both the mailinabox reinstallation script (followed by reboots), as well as the dns_update --force previously, to no avail.

I’ve also tried to turn off IPv6 (the prior box being migrated from didn’t have IPv6, only IPv4), but predictably nsd name services didn’t work then, so I re-enabled it.

Now, emails appear to be working, but these errors persist (also, for some reason, I can’t SSH or ping the VM this is sitting on right now, which is kinda weird, but all email services and web services appear to be working).

Are you letting the mailinabox handle dns?
If you’re not able to ping or ssh, that might point at firewall issues.

It’s possible that ufw got enabled. I’ll connect via single-user mode in a bit and check firewall and ufw. Do you have any suggestions regarding firewall and how to reset it?

Yes, I’m having mailinabox handle DNS. The name servers are appropriately configured at the registrar (GoDaddy)

Mailinabox has default settings for ufw, I would keep those.
Depending on your deployment, there might be other firewalls. E.g. your VPS provider might have a firewall, or if you’re running from home your internet provider. You can check the ufw rules by running sudo ufw status It should show something like:

Status: active

To                         Action      From
--                         ------      ----
22                         LIMIT       Anywhere
53                         ALLOW       Anywhere
25/tcp                     ALLOW       Anywhere
465/tcp                    ALLOW       Anywhere
587/tcp                    ALLOW       Anywhere
993/tcp                    ALLOW       Anywhere
995/tcp                    ALLOW       Anywhere
4190/tcp                   ALLOW       Anywhere
80/tcp                     ALLOW       Anywhere
443                        ALLOW       Anywhere
22 (v6)                    LIMIT       Anywhere (v6)
53 (v6)                    ALLOW       Anywhere (v6)
25/tcp (v6)                ALLOW       Anywhere (v6)
465/tcp (v6)               ALLOW       Anywhere (v6)
587/tcp (v6)               ALLOW       Anywhere (v6)
993/tcp (v6)               ALLOW       Anywhere (v6)
995/tcp (v6)               ALLOW       Anywhere (v6)
4190/tcp (v6)              ALLOW       Anywhere (v6)
80/tcp (v6)                ALLOW       Anywhere (v6)
443 (v6)                   ALLOW       Anywhere (v6)

You can also use this list to check the ports of any other firewalls

Just to be sure: the Mail-in-a-Box status page does not show any other errors then the DANE TLSA and MTA-STS?
One more thing: you can try resetting the dns servers: sudo systemctl restart nsd and sudo systemctl restart named

Correct. There are two domains on this mailinabox server, and - only shows these errors (for and

→ only shows the DANE TLSA error (that’s also the same hostname of the box), while shows only the MTA-STS error. has everything green, no errors.

Strange - I turned UFW off, including verifying status reflects ‘inactive’ - and I still can’t ping the box (yet mail works).
There’s no other firewall active - the VM runs on an ESXI server that doesn’t have any odd firewalls installed either. There’s definitely something odd going on.

Also, just re-enabled ufw, and status shows the exact same as what you provided in your status list

Where is the ESXI box hosted?
I don’t understand the DANE TLSA error report. Do you have custom dns entries?

The ping issue is resolved - for some reason, the VPN I had running on my desktop machine caused me not to connect. Fixed now.

The DANE TLSA and MTA-STS issues remain.

Local data center in Los Angeles. Never had these issues previously on the same mailinabox VM (just running older version). I kept same IP address etc when I migrated.

Only custom entries for A and AAAA records for Should I remove those?

Screenshot 2023-05-19 at 12.58.38 AM has the errors. has no errors.

Screenshot 2023-05-19 at 1.00.11 AM

Interesting, when I attempted to remove one of the custom entries, I got this error message - but upon reloading the page, the entries appear to have been removed. This is an odd error.

Solution at the end of the thread - using the web interface to delete the erroneous Custom DNS entry.
I just deleted all of these DNS entries, and all, EXCEPT ONE, gave me that same internal 500 server error. Status page right now gives me a bunch of red errors for that domain, while I’m waiting for the usual propagation delays to resolve.

I think this might fix this issue (:crossed_fingers:), but this also indicates that there is a pretty serious bug underlying this (going back to at least 2015).

If you get an error on the admin portal, there might be interesting debug info under sudo journalctl -u mailinabox
I know I asked before, but did you actually restart the dns servers?
Also, you might want to take a look at /home/user-data/dns/custom.yaml and see if there are entries there that you can’t place.

Only now I think of this :confounded:
There have been some issues with not using ipv6 and mailinabox on ubuntu 22.04. Do you e.g. disable ipv6 for ssh? I also notice an AAAA record for There might be unwanted side effects from that.

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