Any mail server out there can literally say “Hi, I’m
[email protected]” to the next mail server it’s attempting to deliver the message to, there is absolutely nothing you can do to prevent that.
We do however have various things such as e.g.
DKIM for domain authentication.
We also have
DMARC to signal to receivers what you want them to do with messages that neither pass
SPF (with alignment to your own domain), nor
DKIM (with alignment to your own domain).
In order to be able to pass
SPF (with alignment to your own domain), people must either:
Have access to control your domain, such as e.g. by having access to your Cloudflare account.
Have (unrestricted) access, for example, to pretend to be your domain, on some service that you already authorize to send emails on behalf of your domain.
If you set up a DMARC policy, with “
v=DMARC1; p=reject; sp=reject; np=reject;”, you’re literally signalling to the world that you would like them to reject messages pretending to be from your domain, but that hasn’t been properly authenticated.
A such policy obviously doesn’t prevent rogue actors from continuing to try pretending to be your domain at all, but several receivers out there (including lager ones like e.g. Microsoft’s Outlook/Office 365, Google’s Gmail, et al) typically reject messages that fail authentication, when your policy is set to reject.
In the end a such policy will often make it purpose-less to attempt to “spoof” your domain, as it will likely fail, and as such, rogue actors may move on to the next domains in their lists to try.
The way you say you don’t use your domain, it sounds like it would be fine to lock it down with strict DMARC and
However, if you actually send messages on behalf of your domain, yourself, you would have to make sure that it is set up properly, before moving to that reject policy, as otherwise your legitimate messages might be rejected as well (e.g. if they don’t yet authenticate properly).