Website on your hosting, email at a dedicated provider. It is the most common arrangement there is, and the most commonly half-finished.
The two halves are independent
The A record answers "where is the website". The MX records answer "where does mail go". They are different record types answering different questions, and nothing requires them to point at the same place.
example.com. 3600 IN A 203.0.113.10 example.com. 3600 IN MX 10 mail.provider.com. www.example.com. 3600 IN CNAME example.com.
That is the whole arrangement, and it works. What breaks is not the DNS.
The trap: local delivery
Your hosting server hosts the domain. When something on that server sends mail to an address at that domain, the server may deliver it locally (to a mailbox on the hosting account) instead of looking up the MX record and sending it out.
The symptom is confusing because it is partial. Mail from outside arrives correctly at the real provider. Mail from your own contact form, order confirmations, or anything the website sends to [email protected], lands in a mailbox on the hosting account that nobody has ever opened.
Enquiries appear to vanish, and every check of the DNS says the configuration is right.
The fix is to tell the hosting account that this domain's mail is remote. In cPanel it is the email routing setting, and it must be set to remote rather than local or automatic, automatic guesses, and it guesses wrong often enough to matter.
Email routing and track delivery in cPanel walks through where the setting is.
Remove the old mailboxes
Once routing is remote, mailboxes on the hosting account are unreachable and inert, but any mail already delivered to them is still there.
Check them before removing anything, because the period between changing the MX record and fixing the routing is exactly when messages landed in them.
SPF must cover both senders
The other half of a split arrangement, and the one that produces mail marked as spam.
Your mail provider sends mail for the domain. Your website also sends mail for the domain: contact forms, receipts, password resets. Both must be authorised, or one of them is treated as forged.
example.com. IN TXT "v=spf1 include:_spf.provider.com include:_spf.yourhost.com -all"
One TXT record, not two. Two SPF records for the same domain is an error, and the usual result is that neither is honoured, which is worse than having none.
Understanding SPF, DKIM and DMARC walks through combining them properly.
The extra records the provider needs
Mail providers typically require more than MX: a DKIM record for signing, a verification TXT record, and often autodiscover records so mail clients configure themselves.
Add all of them. A provider set up with only the MX record works and delivers poorly, because the signing records that establish its legitimacy are missing.
Changing the MX record
Lower the TTL on the MX records a day ahead, then change them. Mail in flight during the change is delivered to whichever server the sender's resolver had cached, which is why the two systems must both be able to receive during the window.
Do not shut down the old mailboxes on the day of the change. Leave them for a fortnight and check them, understanding TTL deals with the timing, and migrating email to a new host walks through moving the existing messages.
Verify from outside
dig example.com MX +short dig example.com A +short dig example.com TXT +short
Then send a message from an external address and confirm it arrives at the new provider. Then submit your own contact form and confirm that arrives too. The second test is the one that catches the local delivery trap, and it is the one people skip.
Using dig and nslookup explains reading the results.
Find every place the domain is configured
A split arrangement has more moving parts than the two records, and the ones that get missed are on the hosting side.
dig example.com MX +short dig example.com TXT +short dig autodiscover.example.com CNAME +short dig _autodiscover._tcp.example.com SRV +short
The last two matter more than people expect: mail clients use them to configure themselves, and a stale record pointing at the old server sends every new client to the wrong place, while the MX record is perfectly correct.
That produces the specific complaint where mail works for existing staff and fails for every new person, which is otherwise very confusing to diagnose.
Subdomains inherit nothing
Mail for example.com and mail for mail.example.com are separate as far as MX records are concerned, and a subdomain with no MX record of its own falls back to its own A record rather than to the parent's mail configuration.
So an application sending to [email protected], on a domain where only the bare domain has an MX record, delivers to whatever the subdomain's A record points at, usually your web server.
Either give the subdomain its own MX record or do not send mail to it. A null MX makes the intention explicit:
notifications.example.com. IN MX 0 .
What the website should send as
With mail hosted elsewhere, the site is still sending, forms, receipts, resets, and the from address it uses decides whether that mail is accepted.
Sending as an address at the domain, from a server that SPF does not authorise, is the arrangement most likely to be rejected. The reliable answer is to send through an authenticated service and authorise it in the same SPF record as the mail provider.
One record, both senders listed, sending application email through a relay service goes over the setup, and it removes the local-delivery question entirely because the mail never touches the hosting server's queue.
Test the direction that fails silently
External mail arriving is easy to test and rarely the problem. The paths that fail quietly are the internal ones.
Three tests, all worth doing after any change: send from an outside address to the domain; submit the site's own contact form; and, if the site sends order or account mail, trigger one deliberately.
The second and third are where the local-delivery trap shows itself, and neither is exercised by checking that your own inbox receives a test message. There is more on seeing where the server actually sent it in email routing and track delivery.