@Amy927
Is this just a guess from you? Or did you actually test it try it out?
Forms match based on email first. So if you have the main email be the one without + and the customer wants to update his data then everything is fine.
What does this have to do with the “+” thing?? You know that everyone can take any email and update any data via form right?
So your argument makes no sense.
And you can always just back this up/ work around it with a workflow its not that hard.
Worked for HubSpot for 4 years and solved over 7k customer tickets before moving to internal tech, so I’d say I’m qualified. You can do whatever you want. But if Jack and Jill share the same email address, water@thehill.com, and you give Jack the original and Jill water+1@thehill.com, and then Jill completes a form using the water@thehill.com address (because she would have no idea her record used a +1), her name, etc. will overwrite Jack’s on his contact record. I’ve seen it happen many, many times. That said, you are allowed to take any risks you please -- the beauty of HubSpot is there is no one way to do things -- but it’s important to take into account all of the pros and cons in a process before choosing.
@Amy927
You only take risks if your process is flawed. If you put some thought in and properly test things its gonna be fine.
I still use this to this day, but i know how to properly build a workflow around it since you can just back up the email and delete it and put it in.
And what you describe is like such a small issue whats so easy to check/care for, but yea.
Hi @MHolzer,
could you share this workaround with me as well? That would be great 
This won’t work for all email service providers. Yahoo for example does not support plus addressing and will result in a bounced email. So while this will allow you to create additional contacts. There will be an error rate on email delivery depending on how many contacts are using ESPs that do not support plus addressing.
If there are mulitple contacts using jane.doe@yahoo.com, then the contact using jane.doe+1@yahoo.com will bounce.
And any solution applied at the contact level would also potentialy prevent sending emails through custom object workflows. Given the example above, if you try to store the sending email, jane.doe@yahoo.com, in a property other than email and only load it into the email property when you are sending automated emails, then the email property will not be populated by default. This would prevent any use of the send email action in workflows other than contact workflows. Using other object-based workflows is helpful for personalizing with other objects.
Hey @MHolzer, if you don’t mind can you pelase share this work around to me too? 
Can you send it to me as well @MHolzer? Thank you!
Hi @MHolzer can send me the workaround aswell. Thank you so much
Hi @MHolzer can send me the workaround aswell. Thank you so much