Making the queue handler look at the type of the e-mail would make the microservice very domain specific. There are a few cases where this makes sense, but in general, you may want your microservices to be much more generic.
How to find if you need it to be specific or generic?
List the usages of the service. YAGNI; don't think necessarily about the usage two years in the future, but how you will use the service right now.
It might be that, like Philip Kendall said in his comment above, there are just two types of e-mails that you send. In this case, I'll question the choice of a separate microservice, but if separate it would be, a domain specific microservice would make sense.
Or you may be sending e-mails from multiple other services, each one having its own quirks, and you know that right now, there are other services being developed, and other types of e-mails being designed. In that case, design a generic microservice.
Think about the name of the service. If something such as “simple notification service” comes into mind, you may have a good sign that the service should be generic. If you're thinking more about “Winning project notification service,” then go for a specific one.
Imagine what would happen if you need to change a type or add one. Would you need to change only one service? Or you will have to modify two (or more) services side by side, and deploy them together? In this second case, you are doing it wrong: instead of a microservices architecture, you are just adding REST calls to a monolith.
By the way, check Amazon's SNS for inspiration. It may give you opportunity to see how Amazon designed a thing which may be similar to yours. Their microservice is also a many-to-many queue system, and is actually cleverly designed. One of the interesting things is that the consumer of SNS doesn't need to know whether the notification would lead to an e-mail, or a push notification, or an SMS—this is handled within the SNS configuration itself. This way, you get an ideal microservice which does one and one only thing: dispatching notifications.