This workflow covers cases when a user says they are not receiving their confirmation email.
GitLab.com::Account does not existor if you believe it's applicable use
General::Verify self-managed or .com.
If the user made a typo:
On the first attempt, if our email system could not get through (usually server says it's non-existent or similar), then our mail server will put a suppression on sending further emails.
supporteamcredentials in the Support Team vault in 1Password.
Sendingalong the left-hand side navigation bar.
mg.gitlab.comis set as the domain above the activity graph.
Suppressionsalong the left-hand side navigation bar.
mg.gitlab.comis set as the domain at the top of the page.
Search for recipientssearch bar and perform a search.
Deletebutton next to an entry and then confirm your selection to remove the suppression.
Appsbutton located in the top right of the Zendesk interface.
Email Suppressionsapp located below the tag locker app.
copybutton to save the log from Mailgun to your clipboard that you can then paste into an internal comment on the ticket.
Remove the suppression?button.
Once the suppression is removed you can then use the quick links menu that is displayed to either resend a new confirmation email, send a password reset email, or perform another search.
Once the problem has been fixed, you can send the user a new confirmation email if it's the primary email address.
Let the user know you've sent a new confirmation email and ask them to check their inbox and spam folders.
Instruct the user to sign in and trigger a new confirmation email through their profile: https://gitlab.com/profile/emails
If the user is unconfirmed, but their primary email address does not match the unconfirmed email address (see this internal example), then two options: