Before switching browsers, it is worth working out which of two different things is happening here, because the fix is different for each.
Test the link outside the browser first. Right click the Download Data button in the email, copy the link address, then run:
curl -L -o export.csv "PASTE_LINK_HERE"
curl ships with macOS, Linux and Windows 10 or later, so this works anywhere. Then open export.csv in a plain text editor and look at the first line.
If the first line is your column headers, the file was always a real CSV and the browser was only previewing it. That happens when the response arrives without a Content-Disposition: attachment header, so the browser renders it inline instead of saving it. Nothing is wrong with the export, and the file curl just saved is the one to import into your spreadsheet.
If the first line is <!DOCTYPE html> or <html, you did not get the file at all. Open that saved file in a text editor and look for an href or a meta refresh inside it. Buttons in automated emails often pass through a click tracking redirect, and some of those land on an interstitial page rather than on the file itself. Run curl again against the inner link and you get the real CSV.
One more thing worth ruling out: a CSV viewer extension. If you have one installed in Chrome or Edge it intercepts navigation to .csv and renders it in a tab instead of downloading it. Open the same link in an incognito window, where extensions are off by default, and see if it saves normally. Safari previews text files natively too, so trying Chrome is a fair test, it just is not the whole story.
If you are pulling this export more than about once a week, I would stop doing it by hand. A scheduled workflow that writes the same rows into a Google Sheet, or a small script that reads the table on a cron and writes the CSV itself, takes the email step out of the loop completely. I build a lot of this kind of plumbing for clients and the manual export is usually the first part of the chain to break.