This will allow your program to be used as a vector to attack the things your program depends on.
It's true that those bits of eMail infrastructure are probably more robust but it's still strictly bad practice.
Even if you're "just" storing it in your database, you should sanitise it on the way in so that when someone does something "unexpected" with it, such as display it in a web browser UI, you're not going to suffer from injection attacks there either.
Relying on sanitization is bad practice. Your systems should work properly and securely even if every text field in your database is filled with Robert'); DROP TABLE Students;-- or <script>alert(document.cookie)</script> - if displaying them in web UI leads to an injection or XSS, then the web UI code is horribly broken and needs to be fixed, input sanitization is at best a temporary workaround.
But what I'm trying to say is that what's in your database should be well defined. You shouldn't just put any old stuff in there. You should have a standard for exactly how everything is escaped (or not) so that your consumers have a spec to work to.
You'd do the same with, say, character encodings. One option is to convert everything to a single character set on the way in, such as UTF-8. Another option is to annotate everything with the character set it uses. You must chose one.
Relying on adhoc code spread across the codebase for the security properties of untrusted data leads to whack-a-mole security situations.
Being able to trust the data in your database is essential.
Note, that absolutely doesn't mean things like "Robert'); DROP TABLE Students;--" shouldn't appear in database fields.
It just means that if you define the type of a field to be "eMail address" then consumers of it really should be able to trust that it really is a legitimate and valid eMail address. What does "valid" mean in this context? Well, that's up to your spec. Perhaps just "legally structured". Perhaps "something that eMail can actually be delivered to". Perhaps "something that is known and assured to actually be associated with this particular user".
...but you must be explicit otherwise consumers have nothing to work from and you're building castles on the sand.
It's true that those bits of eMail infrastructure are probably more robust but it's still strictly bad practice.
Even if you're "just" storing it in your database, you should sanitise it on the way in so that when someone does something "unexpected" with it, such as display it in a web browser UI, you're not going to suffer from injection attacks there either.