Now then... Your question was a bit fuzzy, so I'm going to guess about what's happening.
returns a 200 header code
Do you mean #1 the server sends out a 200 or #2 the recipient gets a 200 ?
Most of the time they are the same. But if the process involves sending a request to a preliminary file which then returns a header, your server will always show a 200. The obvious example is a php page which has to process some parameters before showing any content. If the parameters are bad, the resulting 404 or 403 comes from the php, not the server.
This in turn means the user won't get an error page, because the server does not know there has been an error. So you need to include the content of your error page. Do not redirect; show the content of the page at the originally requested URL.
if I put that same fake url into my browser it takes me to a Verizon search page
If you can come up with a simple tool that can distinguish mechanically between
-- typo or alias domains that redirect to a different domain of the human owner's choice and -- parked domains that either redirect or show content from the dragon in residence
... well, you'll be able to retire to Aruba next year. Identifying domains that aren't registered at all is trivial by comparison: your robot will go the rounds of DNS and will come up empty-handed. But it sounds as if that isn't what you're looking for.
My application parses user in putted urls and determines if they are real or not by if it is returning a 200 header code only, using php and curl
The problem comes when I use a fake url like 1.com for example My application gets a 200 header code returned even though it doesn't exist Through research I have determined that my web host might be redirecting that fake url that is being parsed by curl to one of their error pages
Would there be any way to catch this and have it handled by my own custom error page?
Another example of what my web host might be doing is when I enter that fake url myself into my browser and end up getting redirected to a Verizon search page saying that url could not be found
if i had to guess it's not your web host doing this. verizon is probably your ISP and when the DNS lookup fails they are hijacking your request and returning their search page. do a search on "verizon NXDOMAIN response hijacking".