애플이 개발자 뉴스 공지를 통해 'Sign in with Apple(애플로 로그인)'이 발급하는 이메일 릴레이 주소의 도메인을 변경한다고 밝혔다. 올해 말부터 새로 만들어지는 주소는 기존의 privaterelay.appleid.com이 아니라 private.icloud.com에서 발급된다. 사용자가 앱이나 웹사이트에 애플 계정으로 로그인할 때, 실제 이메일 주소 대신 무작위로 생성된 전달용 주소를 서비스 측에 제공하는 기능의 도메인이 바뀌는 것이다.
애플은 이번 변경이 기존 주소에는 영향을 주지 않는다는 점을 분명히 했다. privaterelay.appleid.com으로 이미 발급된 주소는 계속 작동하며, 사용자에게 메일을 전달하는 기능도 중단 없이 유지된다. 즉 이번 조치는 신규 발급분에만 적용되는 도메인 추가에 가깝고, 과거 주소를 소급해 강제로 옮기는 마이그레이션은 아니다. 결과적으로 앞으로 시스템 안에는 두 개의 도메인이 공존하게 된다.
또 하나 눈여겨볼 대목은 iCloud+의 '나의 이메일 가리기(Hide My Email)' 주소는 이번 변경 대상이 아니라는 점이다. 애플은 추가 검토와 커뮤니티 피드백을 반영한 결과, 이 주소는 그대로 icloud.com에 남겨 두기로 했다고 설명했다. 공지의 제목 자체가 이 결정을 담고 있는데, 이는 애초에 더 광범위한 도메인 개편이 논의됐다가 개발자 반발 등을 거쳐 범위가 좁혀졌음을 시사한다. 다만 원문은 구체적인 피드백 내용이나 당초 계획을 밝히지 않았으므로, 정확한 배경은 공개된 정보만으로는 단정하기 어렵다.
개발자가 실제로 해야 할 일
애플이 개발자에게 요구하는 조치는 명확하다. 'Sign in with Apple'을 사용하는 앱이나 웹사이트를 운영한다면, 계정 시스템과 이메일 검증 로직, 그리고 허용 목록(allowlist)이 기존 privaterelay.appleid.com에 더해 새로운 private.icloud.com 주소도 받아들이도록 해야 한다. 핵심은 '교체'가 아니라 '추가'라는 점이다. 두 도메인이 모두 유효한 전달용 주소로 취급돼야 하므로, 한쪽만 인정하는 방식은 곧 신규 가입자를 막는 결과로 이어질 수 있다.
실무적으로 가장 위험한 지점은 이메일 도메인을 하드코딩해 둔 검증 코드다. 예컨대 특정 도메인만 통과시키거나 반대로 릴레이 도메인을 걸러 내기 위해 문자열을 고정해 둔 경우, private.icloud.com 주소를 가진 사용자는 회원가입이나 로그인 단계에서 거부될 수 있다. 정규식으로 도메인을 검사하는 로직, 마케팅 메일 발송을 위한 수신 도메인 필터, 스팸·중복 계정 방지용 블록리스트 등도 함께 점검 대상이다. 이런 검증은 눈에 잘 띄지 않는 곳에 흩어져 있는 경우가 많아, 코드베이스 전반을 훑어보는 편이 안전하다.
전달 경로와 SPF 설정도 함께 점검
릴레이 서비스는 사용자에게 실제로 메일을 전달할 때 애플의 서버를 경유한다. 애플은 이와 관련해 '비공개 이메일 릴레이 서비스를 통한 통신' 문서를 안내하고 있는데, 서비스에서 사용자에게 보내는 메일이 정상적으로 전달되려면 발신 도메인과 인증 설정이 애플의 요구 조건을 충족해야 한다. 도메인 전환 자체가 이 인증 체계를 바꾸는 것은 아니지만, 릴레이 관련 설정을 다시 확인해 전달 실패가 발생하지 않도록 대비할 필요가 있다.
정리하면 이번 공지는 기능이나 정책의 대대적 변화라기보다, 개발자 측 시스템이 새 도메인을 무리 없이 수용하도록 준비하라는 사전 안내에 가깝다. 변경 시점이 '올해 말'로만 제시돼 정확한 날짜는 아직 알 수 없으므로, 그 전에 검증 로직과 허용 목록을 손봐 두는 것이 안전하다. 기존 주소가 계속 유효하다는 점 덕분에 급박한 장애 위험은 낮지만, 신규 사용자 유입을 놓치지 않으려면 여유를 두고 대응하는 편이 바람직하다.