Hi,
yes, this is because logging of packets being dropped by conntrack as invalid was only implemented recently. These packets were always dropped, but earlier versions of IPFire did not log them, which made things hard to debug and troubleshoot.
So, has mail submission via the Apple client ever worked? If so, the DROP_CTINVALID could not have made the difference, since it is only about logging; nothing additional gets dropped.
From some other threads and my own system, I observed sometimes FIN-ACKs get dropped by conntrack, most commonly they originate from large CDNs such as Akamai or Cloudflare indeed. I guess they run a non-standard TCP stack, and conntrack mistakenly (or rightfully?) drops such packets.
However, since they are only FIN-ACKs, the TCP connection belonging to them was already closed, and just the final packet does not make it through. Oh well, I don’t think that is something to worry about, although it is certainly ugly to see. 
Do you have the IPS enabled? If so, some rules flag (and subsequently drop) certain DNS requests - see this thread for an example.
If these are all related to DROP_CTINVALID indeed, please try to change the DNS servers for once. If possible, use servers supporting DNS over TLS.
Yes, that would be, for example, true for the FIN-ACKs I mentioned above. In this case, the source IP address belongs to a CDN, while the destination IP is your IPFire’s RED interface. However, these are only incoming packets, not connections, since the connection was actually established by a client located behind IPFire. Otherwise, the packet would have been blocked as NEWNOTSYN.
Thanks, and best regards,
Peter Müller