I cannot receive Microsoft's mails

[alzalia1]

I recently created my domain, and added DMS to have more control over my mail. So far, everything has worked great, except when it comes to Microsoft.

For some obscure reason, DMS blocks microsoft's mail with the following error :

NOQUEUE: reject: RCPT from unknown[172.18.0.1]: 550 5.7.23 <ADDRESS@MY_DOMAIN.fr>: Recipient address rejected: Message rejected due to: SPF fail - not authorized.; from=<snds-authorization@outlook.com> to=<ADDRESS@MY_DOMAIN.fr> proto=ESMTP helo=<SN4PR2101CU001.outbound.protection.outlook.com>

Now, this doesn't really make sense to me : in what world would Microsoft not have a valid SPF record ?

Following the (not so good) advice of an AI, I then edited my SPF record to look like this :

v=spf1 mx include:_spf-a.microsoft.com ~all

Which litteraly whanged nothing. I tried going to the SDNS website to register my VPS's IP address... but of course I can't receive mails from them, so I can't continuer the procedure.

(I should also add that I can sen mails to outlook users, I don't know yet if I can receive them. But clearly automated mails don't work).

Plus, the "received from" IP address seems to be an allocated private address... which makes even less sense.

So, I don't know why this happens, why only with microsoft (maybe it's not the only one but I haven't got the problem elsewhere for now), and I frankly don't een really know what is going on. So, any help would be gladly welcomed.

(PS : I know this was discussed already in #4017 but the only solution proposed is to whitelist on sdns... and I can't receive mails from them)

Thanks for helping !

[casperklein]

I cannot reproduce this. I've send an email from outlook.com to my DMS and it worked just fine.

Plus, the "received from" IP address seems to be an allocated private address...

That could be an issue for the SPF check. Is your host IPv6 enabled? If so, try disabling it (temporary). IIRC, IPv6 traffic is "hidden" behind a local IPv4 gateway address.

So it's possible, that this issue only occurs, if mail is delivered via IPv6.

[alzalia1]

Indeed, IPv6 was the problem ! Deactivating it solves the problem with microsoft/outlook.

But... does that mean I have to keep it disabled at all times ? Doesn't that come with less compatibility for "newer" mails that would use IPv6 ? Or is there a way to have both ? (Or maybe I just don't need to care about IPv6 ?)

Anyway thanks a lot !

Edit : I apologize, I didn't search the documentation before asking this... Found the page about IPv6 ! I'll look at it if I ever have the time and energy, meanwhile I'll just keep using IPv4 only...

Thanks again !

[polarathene]

Plus, the "received from" IP address seems to be an allocated private address... which makes even less sense.

Please look at our docs regarding IPv6 support.

If your containers only offer IPv4 private IP but your Docker host receives IPv6 connections, the default /etc/docker/daemon.json setting userland-proxy: true will allow accepting such connections instead of rejecting them. It does so by proxying through the docker networks IPv4 gateway IP which becomes the new source IP instead of the original connections. That isn't permitted by the external service SPF, hence the failure.

If you want to serve IPv6 correctly, you'll need to enable IPv6 support in Docker (from Docker v27 this should work out of the box I think), which requires updating your daemon.json config and ensuring your container also has an IPv6 network (ULA subnet advised) attached.

If you disable IPv6 from the host, you may also want to avoid any AAAA DNS record too so no service thinks they can reach DMS via IPv6 only to get rejected. For disabling IPv6 on the Docker host itself, you only should need to disable the userland-proxy in daemon.json as per our docs guidance. Docker v27 may however implicitly enable IPv6 network support when it detects an IPv6 capable network interface is on the host, but that should not be an issue as the connection should work with IPv6 properly at that point.

---

There is one other caveat where the above advice isn't sufficient. If there is any proxy layer in between the client and the DMS container, you'll additionally need to follow our reverse proxy docs for configuring PROXY protocol support. You shouldn't need a proxy with DMS, but I hear it is more relevant for Kubernetes due to some limitations there.

[alzalia1]

What a timing ! I found the IPv6 documentation page and edited my above answer a second before receiving yours...

But thanks a lot ! For now I do think that I'll just keep using IPv4 only, until I have the time to try and enable IPv6. From what I understood, not enabling it shouldn't be that much of a deal anyway, would it ?

So thank you a lot for your answers, and DMS as a whole, it's amazing !

Have a nice day (or night).

[polarathene]

From what I understood, not enabling it shouldn't be that much of a deal anyway, would it?

I'm not aware of any issues by not having IPv6 support. Most clients / MTAs should have IPv4 support.

thank you a lot for your answers, and DMS as a whole, it's amazing!

❤️