Every mailbox provider - Gmail, Outlook, everyone that matters - tracks sender reputation per sending address, not per company. That's a simple enough fact, but it has a sharp edge that's easy to miss when a product starts small and every outbound email comes from the same From address because there was never a reason to think about it.
WebForms sends two categories of email that have almost nothing in common except that they both leave our servers. One is submission notifications: "you got a new form entry," fanned out to whoever owns a form, often several times a day on a busy site. The other is account lifecycle mail: welcome emails, password resets, email verification. Low volume, high stakes - if a password reset lands in spam, someone is locked out of their account and annoyed at us specifically, not at the abstract concept of email.
The actual risk of sharing a sender
Submission notification volume is inherently the noisier stream. It's driven by other people's forms, which means it's driven by other people's traffic, spam bots included - a contact form on a customer's site can get hit by junk submissions, and if enough recipients mark those notification emails as spam (not unreasonable, if the form itself got spammed), that complaint rate attaches to the sending address. Mailbox providers respond to a rising complaint rate by throttling or filtering everything from that address, not just the pattern of email that caused it.
If password resets came from the same address, they'd inherit that throttling. The two email types have nothing to do with each other from the recipient's perspective, but they'd share a fate purely because of an infrastructure decision that was never actually a decision - just what the sender address happened to default to.
The fix
Two From addresses instead of one. submissions@ for anything driven by a form's own traffic. noreply@ for anything account-related - welcome mail, password resets, verification. Same domain, same SPF/DMARC setup underneath (nothing new to configure there), just a second identity that mailbox providers track separately.
EMAIL_FROM=submissions@emails.webforms.to ACCOUNT_EMAIL_FROM=noreply@emails.webforms.to
The account-lifecycle sender resolves independently from the submission sender in code, so a spam-adjacent problem on one stream can never bleed into the other's reputation - and a reader who gets a password reset with noreply@ in the From field also gets the correct expectation set by the address itself: don't reply to this, it's automated.
When this actually matters to you
If you're building anything that sends more than one kind of email - transactional and marketing, account and notification, low-stakes and high-stakes - and they currently share a From address purely by default, that's worth a deliberate look before it becomes a real incident. The fix is nearly free. The cost of not doing it shows up later, at the worst time, as a password reset that nobody can explain silently landing in spam because an unrelated notification stream got reported by someone who never should have been able to affect it.