확인 메일이 도착하지 않는 원인 가운데 하나는 주소 입력 실수입니다. 자주 쓰는 도메인과 비슷한 철자를 입력했다면 제출 전에 확인을 요청할 수 있습니다. 다만 낯선 도메인이 모두 틀린 것은 아닙니다. 서비스가 추측한 주소로 몰래 바꾸기보다 입력한 주소와 제안한 주소를 보여 주고 이용자가 선택하도록 해야 합니다.
확인 문구는 틀렸다고 단정하지 않고 이 주소가 맞는지 묻는 방식이 적합합니다. 원래 입력을 유지하는 선택도 쉽게 찾을 수 있어야 합니다. 회사나 개인이 사용하는 도메인을 인기 서비스 목록에 없다는 이유로 거부하지 않습니다. 앞뒤 공백 같은 형식 문제를 처리하더라도 이용자가 최종 발송 주소를 검토할 수 있게 보여 주세요.
주소의 모양이 정상이라는 것과 그 사람이 메일을 받을 수 있다는 것은 다른 문제입니다. 입력 단계에서는 형식을 확인하고, 발송 단계에서는 어느 주소로 보냈는지 명확히 알립니다. 확인 메일을 기다리는 화면에 주소 수정 경로가 있으면 오타를 뒤늦게 발견해도 처음부터 양식을 다시 작성할 필요가 줄어듭니다. 수정 후 재발송 여부도 분명히 알려야 합니다.
점검용 주소에는 흔한 도메인, 별도 업무용 도메인, 긴 주소를 포함해 보세요. 작은 화면에서 중요한 부분이 잘려 잘못 입력한 문자를 확인할 수 없는지도 살펴봅니다. 메일이 없다는 문의가 들어오면 오타만 원인으로 단정하지 말고 표시된 수신 주소와 발송 상태부터 확인합니다. 주소를 바로잡은 뒤에도 이전 주소에 관한 안내가 남지 않는지 검토하세요.
가상의 확인 화면에서 이용자가 업무용 주소를 입력했는데 널리 알려진 메일 서비스 주소를 제안받았다고 해 보겠습니다. 제안 버튼만 두고 원래 주소를 유지하는 방법을 작은 닫기 아이콘으로 숨기면 사용자가 원하지 않은 변경을 받아들이기 쉽습니다. 두 주소를 읽을 수 있게 보여 주고, 주소 변경은 선택한 뒤에만 반영되도록 합니다.
이메일을 수정한 뒤에는 수신 주소 표시뿐 아니라 다음 확인 화면도 확인합니다. 재발송 버튼이 이전 주소를 대상으로 작동하거나 완료 문구에 옛 주소가 남으면 어느 메일함을 봐야 할지 알 수 없습니다. 시험은 오타 입력, 원래 주소 유지, 제안 수락, 수정 후 재발송을 각각 따라가며 진행합니다. 정상적인 주소를 불필요하게 고치게 만드는 경우도 실패 사례로 기록해야 제안 기능이 실제 불편을 줄이는지 판단할 수 있습니다.