It would be more like receiving mail from a service than sending mail to a service which isn't a problem. There isn't really a spam component.

I show up to bigsaas.com. Big SaaS asks me to identify myself. I submit that I am rob@robmccoll.com optionally with a proof of that claim.

If I have provided a proof (think attestation along the lines of "The holder of this certificate is rob@robmccoll.com requesting to use bigsaas.com at time T using signing key Kpub") it will be signed under a key chain whose root can be obtained from a specifically formatted DNS TXT record under robmccoll.com (similar to DNSSEC or DKIM - maybe it gets a custom record type). bigsaas.com can fetch said key and verify the signature.

If I haven't provided a proof, bigsaas.com looks up a DNS record under robmccoll.com that points to which server provides this authentication service for the domain and does something like an OAUTH or SAML type of exchange but without the need for point-to-point pre-configuration. It beings this exchange with a signed request "This is bigsaas.com attempting to authenticate rob@robmccoll.com at time T" which is signed under the key in its own DNS records (or at least a chain that can be verified under that key).

Either way, the service doesn't have to have some pre-seeded trust beyond trusting DNS (and this should probably insist on DNSSEC and TLS-only for whatever interactive authentication gets layered on top)

Edit: I guess this is kind of OpenID, but to be honest, OpenID looks way more complex than necessary.