Hi,
Could you please elaborate on this? At end of a successful setup, a DKIM key is displayed to be inserted in DNS zone: https://gitlab.e.foundation/e/infra/ecloud-selfhosting/-/blob/master/scripts/postinstall.sh#L113.
I’m not aware of SPF/DKIM problems related to residential IP addresses and could not find any further information; if you have any feedback on this I’ll be happy to learn 
IMHO the biggest problem would be with residential IP address: some spam filtering solution would look at the originating AS number and flag messages if they come from residential ISP. Then your IP address is likely to be blacklisted 
As for spam fighting, if you use self-hosted /e/ Cloud as provided it comes with RSpamd, which is IMHO one of the best (maybe the best) Open-Source solution at this time. I recently proposed a MR to allow admins to manage blacklist, which was accepted and merged (tracking issue https://gitlab.e.foundation/e/backlog/-/issues/5292).
Back to your Cloud, at first please be aware that OnlyOffice is no longer included with /e/ Cloud (it’s been a while).
Assuming you already own a DNS domain, after reading your message (which make great sense 
) I could see 3 solutions:
1/ hybrid solution: rent an entry-level VPS (i.e. CX21 @Hetzner will only cost you the price for a good beer, monthly); then install a standard /e/ Cloud and expand storage with your home-hosted (https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/external_storage_configuration_gui.html). As mentioned before no OnlyOffice OOTB, but it should be possible to connect an existing to your /e/ Cloud (never tested here …), please see 2/
2/ all-in-home solution: give up on self-hosted email, install a standard Nextcloud at home, then connect it with home-hosted OnlyOffice. You can apply some /e/ or Murena branding to your NextCloud if you like
3/ continue with the actual solution (standard /e/ Cloud at home). But I sincerely doubt that /e/ Team will accept your DNS check bypass request. Anyway it could be interesting to see if everything continue to work fine, through time!
For solution 2/ you may find difficult to connect a /e/ device to it. Simply ignore the integrated /e/ Accounts Manager and install NextCloud client app.
For solution 3/ you may see from docker stats that the eager RAM container will be mailserver, and this is due to clamd, which is useless to you…
About passwords storage: all serious solutions come with a client-side E2E encryption (see for example https://git.mdns.eu/nextcloud/passwords/-/wikis/Users/Encryption). So, IMHO, the problem is not where the database is stored, but how secure is your client (for example your client computer & browser).
However, as risk zero doesn’t exist, I’ll strongly advise not to mix password storage with “daily activities” storage. You may find something like this interesting: https://bitwarden.com/help/install-on-premise-linux/.
About NextCloud branding: if you want to apply /e/ or Murena branding to an existing Nextcloud, you may be interested with what happen “under the hood” when firing up a /e/ or Murena Nextcloud.
First, look at the Docker file: starting with a standard official image, some apps are added, then patches and customization. You may pick up some of them.
Note that the apps installation is done here: https://gitlab.e.foundation/e/infra/ecloud/nextcloud/-/blob/main/custom_entrypoint.sh.
Then, at last, some configuration is applied here: https://gitlab.e.foundation/e/infra/ecloud-selfhosting/-/blob/master/scripts/postinstall.sh. As for Docker file, many are related to /e/ Cloud infrastructure (i.e. email) and will be useless for a standalone NextCloud.
As a side note, I wrote something about securing your server: Securing your self-hosted using CrowdSec