It seems to me that the question you are asking is perhaps not the one you meant to ask (if I may be so bold). I'm assuming that 18-20s response is unacceptable either because it's a poor user experience and/or it's annoying for any admin type work (perhaps undertaken by just you). Your analysis of the problem lying with e-mail dispatch suggests that by significantly altering that will improve the primary symptom - the 18-20s response.
So, perhaps your question should have been "How can I alter the mail dispatch process so that it doesn't block the remainder of the processing?"
The possible answers to that question depend on whether you are self-hosting / virtual-hosting or are using a shared server. With most mail dispatch procedures, mail(s) are submitted to an SMTP server for onward delivery to the final destination(s). Note, I make the distinction between dispatch (what you need to do) and delivery (what the SMTP server(s) do). For a variety of reasons, hosting providers normally recommend you send mail via one or other of their servers - which would normally respond much quicker than the 1.8-2.4s you quote - mail submission should be tens or hundreds of milliseconds only.
If you feel you have the skills, inclination and full server access, then you could implement one of the many available SMTP servers (for *nix systems, Postfix and Exim are good options - for Windows, you could try hMailServer). Then, that local SMTP server would handle your mail submissions, queue them up and then handle the onward delivery asynchronously. But, of course, this comes at the cost of setting up and managing those services (and ensuring you don't inadvertently set up an open mail relay (very bad)).
If you are already using your ISP's mail server (perhaps called a "smart host") and it is taking circa 2s per mail, you should check whether the bulk of that delay is in the PHP handling before submission to the server or whether it really is the server. If you have terminal access to your own server, then you could try telnetting from there to the ISP's mail server on port 25 and seeing if the response time for the banner does take a "long" time (many servers do, either by intention or due to loading). Here's a Microsoft link to how to do such testing: MS Technet article - SMTP telnet testing. If the delay is long, I'd ask the ISP why - if the response is unsatisfactory, you may have to go back to the own-SMTP-server scenario.
Incidentally, I assume you are using BCC to send the mails out, otherwise you can normally submit several e-mail addresses with one body (BCC does one body per recipient so that each one cannot see the others) - if BCC is not required, then this would potentially cut the response time from N x 2s to just 2s, for N recipients. N is limited to about 20, but there are many factors determining that which you would have to investigate in your environment.
If you want to stick with the original question about asynchronous PHP scripting - you might end up going down a complex but ultimately dead-end path. From what you say, I strongly advise making sure your mail submissions are quick and queued in a "fast" SMTP service.