Feature Request: Natural support for mail forwarding services e.g. Sign in with Apple, Sneakemail

edited May 18 in Families

Warning: The winning feature of a Families account is post-mortem support. Skip this if you're in mourning.

My passwords are not the only type of credential that my executor will require. My contact-unique email addresses will be necessary too. It would be good if I could record the contact-unique email addresses in 1Password so that the executor will have all the credentials in one place.


Sign in with Apple and Sneakemail are two examples of mail forwarding services. The user generates a unique email address for every contact. If afterwards the user receives unwanted email at that address, perhaps do to a data leak, the user can generate a new unique email address and disable the compromised one.


Mail forwarding is useful in circumstances where no password is required, such as a pre-sale information request. Two fields are required:

  • the contact's name
  • the contact-unique email address

A URL field will be used very often, too, but it is not required.

Distasteful Workaround

There is a 1Password type with the appropriate field count, namely "Password." I can hijack "Password" for the purpose of recording contact-specific email addresses: I can put the email address in the Password field. I can warn the executor "Hey buddy if you're looking for an email address and you don't see it, look under 'Passwords'", but it's a speed bump, and I won't be there to answer the executor's questions.


Please consider adding a Contact type to a future release of 1Password.

Thanks for reading 8-)

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Referrer: forum-search:Mail forwarding services such as Sign in with Apple and Sneakemail


  • BenBen AWS Team

    Team Member

    Hi @TLH

    Thanks for taking the time to write in with this request. I'm trying to envision how Login items don't already serve this purpose. They have a username field, an (optional) password field, and an (optional) website field. :) I also do the "unique email per service" thing, but I've rolled my own instead of using Apple's or otherwise, largely because those weren't available when I started but continue because it still gives me more flexibility. That's really neither here nor there, but what is important is that I've never felt the need for any sort of different record type, so I'm curious to find what is different about my situation than yours where yours gives need for that. When I sign up for a service I use my unique email address as my username, generate a unique password using 1Password, and then save that into a Login item which also captures the URL of the service into a website field. I also title the item according to which service it is for, and if I plan to have multiple accounts for that service I also tend to include the unique email address in the title. Have you considered doing that, and if so, what are the downfalls for your use case?


Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file