There is no attribute that emails you a form. HTML describes the form and the browser posts it; sending mail is something a server does, over a protocol the browser has no access to. Every working version of this is therefore the same shape: the form posts to a URL, and whatever is behind that URL sends the message. What follows is the honest version of each way of doing that, including the one that looks easiest and is not.
Why mailto looks like the answer and is not
Setting the form's action to a mailto: address is the trick everybody finds first. What it does is ask the operating system to open the default mail client with a draft, which assumes there is a configured mail client, that the person notices the new window, and that they then press send themselves. On a machine using webmail there is often nothing registered at all and the click does nothing visible. It also publishes your address in the page source for anything crawling the site. It is not a way of receiving mail; it is a way of losing most of it.
What a working setup is made of
Three moving parts, always the same three. Something receives the POST: a serverless function, a small server, or a hosted endpoint. That thing validates what arrived, because the browser's required attributes proved nothing. Then it hands the message to a mail service over an API or SMTP, with a from address on a domain you control and a reply-to set to whoever filled the form in, so hitting reply in your inbox answers the person rather than your own server. Skip the reply-to and you will find out about it the first time you try to reply.
Email is a poor place to keep what arrives
Notification and storage are different jobs, and the mistake is asking email to do both. Attachments get stripped by filters, long submissions get truncated in previews, a message deleted by accident is gone, and nothing is searchable in a way that survives changing employer. Send the email because you want to know now, and keep the submission somewhere durable because you will want to look it up later. Anything that receives your form should be doing both, and the storage is the half people notice they are missing about a year in.
Deliverability, briefly, before it bites
Mail sent from a new domain with no records lands in spam, and the first thing you will conclude is that the form is broken. Send from a domain you control with SPF and DKIM set up, do not put the visitor's address in the from field even though it seems convenient, and expect to check the spam folder during testing. This is the tax on doing it yourself, and it is the main reason people stop doing it themselves.
Questions people ask about html email form
Is there any way to send email straight from HTML?
No. HTML has no mail capability and neither does the browser, by design: a page that could send mail from your machine would be a gift to every spammer on the web. Something on a server has to do it, which is why every real answer involves a URL the form posts to.
What should the from address be?
An address on a domain you control, with the visitor's address in reply-to. Putting their address in from is the intuitive choice and it fails authentication checks, because your server is not authorised to send as their domain, which is precisely the pattern spam filters exist to catch.
Do I still need to store the submission if I get the email?
If it matters, yes. An inbox is a notification channel that happens to keep history until somebody tidies up. Anything you would be annoyed to lose belongs somewhere it can be searched, exported and read by more than one person.