Spam Control Out of Control
Every email service we have is hosted by YunoHost, and configured manually using our own DNS stack. Our DNS and email configurations are as close to be RFC-compliant as practical
. There are a few issues, but DKIM, SPF, and DMARC are all standard-compliant, the IPv6 block is dedicated (Linode provides this when you ask for one), and the volume is low.
There ARE things we could do to make the service more
RFC-compliant, such as verify our domain with Google, move the service to a dedicated box so not even the IPv4 is shared anymore.
The emails I send from my fully (to a practical level) RFC-compliant email services are routed to spam by Google, by Office365, by other gateways. In many cases I never get a delivery receipt - which means the target MTA never received the email.
Between the domains I own (I own about 60, mostly under the .us TLD) the email service is 100% functional, as expected.
YunoHost has a terrific feature, it runs diagnostics and reports all issues back. On one of my domains this is forwarded to my Google workspace, and the message looks like this:
Again, the service is properly configured by YunoHost and in our DNS:
So.. what sending these emails to spam by other gateways? At the bank I started a process couple weeks ago all my emails are sent to spam, none of the email I sent returned a delivery receipt.
I asked all on the other end to add my firstname.lastname@example.org address to their address book - no change, they are still forced to fish my emails out of their spam bins.
If you are using your own email service keep an eye on this. Anything affecting email delivery cuts to the core of our fundamental communication infrastructure. A "solution" such as "just use Google or Office365 and stop complaining" is not a solution, its an unacceptable proposition. We are Fediverse, we build and use our own service stacks, we are an owner-operator community. We are not going to run to Big Tech for solutions - we are running from Big Tech trying to preserve our freedom of choices. We might not all be UNIX experts or coders, but we all have our purpose in Disroot.