So normally in the cases like this, you also have to tell Google about this, and you typically do this by using one of their paid-for products like workspaces or apps for business or whatever they call it. So let's say that you decide to host skywall@skywall.example with Google. You pay them for workspaces and you likely tell them "I would like to use this domain I already have, with email". They then tell you "OK, add our servers as your MX record in your DNS, or transfer the whole domain to us and we'll do it for you". In this case we're doing the 'changing the MX records' part.

Now when a sending server asks "where should I deliver skywall.example email" by querying MX skywall.example it gets google's servers and starts an smtp conversation with them, saying "I'd like to deliver a message for skywall@skywall.example". At this point, Google knows it can accept that, so they say yes, and then continue doing whatever they do to check for spam beyond that, including queries for spf and friends.

The reason the parent suggests this is that if at any point you decide to move off Google, you can pay someone else, e.g. fastmail, for their services, and modify your MX record. 24-48 hours later, DNS around the world catches up and everyone will get fastmail as a response when they ask for your MX record. Any new email goes there instead of Google, and thus you aren't 'tied' to the provider: you just have to move all your old email over. Whereas Google cannot let you move a user@gmail.com address, because they can only change the MX records for the whole of gmail.

DNS is the source of truth here. Whatever your MX records are is where other servers will try to contact to send email. The MX record is typically just another DNS address that will be queried for AAAA/A (i.e. what is the IP), and that doesn't need to be on the same domain at all.

Here's an example of what it looks like:

    delv MX ycombinator.com @9.9.9.9
    ; unsigned answer
    ycombinator.com.        295     IN      MX      20 alt2.aspmx.l.google.com.
    ycombinator.com.        295     IN      MX      10 aspmx.l.google.com.
    ycombinator.com.        295     IN      MX      20 alt1.aspmx.l.google.com.
    ycombinator.com.        295     IN      MX      30 aspmx4.googlemail.com.

This is me using DELV to ask "where should I send email for ycombinator.com?" and I have four responses. Column 5 tells me the priority. Lower numbers are higher priority. Unsurprisingly, this is Google. But let's see where they host their DNS, shall we?

    delv NS ycombinator.com @9.9.9.9
    ycombinator.com.        159148  IN      NS      ns-225.awsdns-28.com.
    ycombinator.com.        159148  IN      NS      ns-1914.awsdns-47.co.uk.
    ycombinator.com.        159148  IN      NS      ns-1411.awsdns-48.org.
    ycombinator.com.        159148  IN      NS      ns-556.awsdns-05.net.

So AWS. So they have separate DNS to Email, and could change those MX records to host their email anywhere else, without needing to change or move ycombinator.com's DNS from AWS.

I'll cover off the SMTP outgoing as well while I'm at it. You _can_ also not run your own outgoing smtp server but use someone else's. The key here is that if you use SPF and DKIM, you should put their IPs into SPF and their keys into DKIM, as that is what the receiving server will use. So smtp.zahllos.example could be replaced by sendgrid, provided in my DNS I say so. This may work better, as sendgrid may have a better reputation than the server I chose.