Sign in with Apple Domain Değişiyor: Backend'in Kırılabilir

Apple, Sign in with Apple için kullanılan e-posta relay adreslerinin domain'ini değiştiriyor: bu yıl içinde yeni oluşturulan adresler privaterelay.appleid.com yerine `private.icloud.com` altında yayımlanmaya başlayacak, privaterelay.appleid.com üzerindeki mevcut adresler ise kesintisiz çalışmaya devam edecek. Backend'inde sabit-kodlanmış tek-domain kontrolü, regex veya allowlist varsa — kayıt formu, e-posta doğrulama filtresi, spam engelleme listesi — bu değişiklik sessizce yeni kullanıcıları reddetmeye başlayabilir. Bu yazıda ne değiştiğini, hangi tarihte hangi duyurunun geldiğini ve backend'ini nasıl kırılmaz hale getireceğini anlatıyorum.

💡 Pro Tip: Domain kontrolünü tek string karşılaştırması yerine bir suffix listesi olarak tasarla — Apple yeni bir relay domain'i eklediğinde (ki tam olarak bunu duyurdu) kod satırı değil, liste elemanı eklersin.

İçindekiler

• Ne değişti, hangi tarihlerde duyuruldu
• Sessiz kırılma senaryosu: allowlist, regex ve e-posta doğrulama
• Kayıt formunda tek-domain doğrulaması
• Spam/relay engelleme kuralı
• ESP tarafında suppression list / routing kuralı
• İki domain'i de kabul eden doğrulama kodu
• Backend: domain listesi + regex (TypeScript)
• Regex ile tek seferde eşleştirme
• Swift tarafında: gelen e-postayı kaynağına göre etiketleme
• Relay adresine e-posta gönderimi ve gönderen kaydı hatırlatması
• Aynı kullanıcı-farklı domain hesap birleştirme tuzağı
• Sandbox ve gerçek cihaz test planı
• Migration kontrol listesi
• SSS
• Sign in with Apple'ın yeni relay domain'i nedir?
• E-posta doğrulama/allowlist kodu nasıl güncellenmeli?
• Eski relay adresleri çalışmaya devam ediyor mu?
• Hide My Email adresleri de private.icloud.com'a mı taşınıyor?
• Geçiş ne zaman tamamlanmış olacak?
• Sonuç
• Kaynaklar

Ne değişti, hangi tarihlerde duyuruldu

Apple bu konuda iki ayrı duyuru yaptı ve ikisi arasındaki fark, makalenin en kritik noktası.

15 Haziran 2026 — Apple Developer News'te yayımlanan ilk duyuruda plan şuydu: Sign in with Apple ve iCloud+ Hide My Email için kullanılan e-posta domain'leri tek bir ortak domain'de (private.icloud.com) birleştirilecekti. Bu duyuru aynı gün MacRumors ve 9to5Mac tarafından da haberleştirildi.

Bu duyuru çok geçmeden topluluk tepkisi aldı. MacRumors'ın 17 Haziran 2026 tarihli haberine göre X kullanıcısı @vxdb, tek ortak domain'in bir gizlilik riski doğurduğuna dikkat çekti: platformlar artık tüm iCloud kullanıcılarını etkilemeden yalnızca bu yeni subdomain'i (yani Hide My Email takma adlarını) toptan bloklayabilirdi.

24 Ağustos 2026 — Apple, bu geri bildirim üzerine planı revize etti. Yeni karar: yalnızca Sign in with Apple adresleri private.icloud.com'a taşınacak; iCloud+ Hide My Email adresleri `icloud.com`'da kalmaya devam edecek. Haziran'daki eski duyuru sayfasına da artık bir uyarı notu eklendi: "Note: This announcement contains outdated information."

Burada iki resmi kaynağın kapsamı farklı ve ikisini birden bilmen gerekiyor. Apple'ın Sign in with Apple dokümantasyonu relay adreslerinin @private.icloud.com, @privaterelay.appleid.com veya @icloud.com ile bittiğini yazıyor. 24 Ağustos 2026 duyurusunun geçiş rehberi ise yalnızca private.icloud.com ve privaterelay.appleid.com'u adlandırıyor; Hide My Email adresleri icloud.com'da kalıyor. Yani geçiş için yapman istenen iş iki domain üzerinden tanımlı, ama icloud.com'un kendi verinde relay adresi olarak görünüp görünmediğini varsaymak yerine ölçmen gerekiyor.

Geçiş tarihi için Apple henüz kesin bir gün vermedi — duyuru metni "later this year" (bu yılın ilerleyen döneminde) diyor. Bu yazının yayınlandığı 8 Eylül 2026 itibarıyla resmi kaynaklarda net bir aktivasyon tarihi veya geçişin canlıya alındığına dair bir teyit yok. Yani hazırlığını şimdi yapmalısın; geçişin fiilen ne zaman başlayacağını Apple Developer News sayfasından takip etmen gerekiyor.

Sessiz kırılma senaryosu: allowlist, regex ve e-posta doğrulama

Apple'ın resmi çağrısı net: "Developers ... should ensure that their account systems, email validation logic, and allowlists accept addresses on the new private.icloud.com domain in addition to the existing privaterelay.appleid.com domain." Yani mevcut domain'i değiştirmek değil, yeni domain'i eklemek gerekiyor.

Sessiz kırılmanın tipik üç görünüm biçimi var:

Kayıt formunda tek-domain doğrulaması

"Sadece kurumsal e-posta kabul ediyoruz" veya "geçerli e-posta domain'i" gibi filtrelerde sıkça karşılaşılan uygulama, belirli suffix'leri whitelist'e almaktır. Yeni relay adresleri ([email protected]) bu listede yoksa, form kullanıcıyı sessizce reddeder — hata mesajı "geçersiz e-posta" der ama gerçek sebep domain güncellemesinin unutulmuş olmasıdır.

Spam/relay engelleme kuralı

MacRumors'ın aktardığı topluluk uyarısı Haziran planına aitti: Hide My Email de aynı subdomain'e taşınsaydı, platformlar tüm iCloud kullanıcılarını etkilemeden yalnızca bu yeni subdomain'i bloklayarak iCloud takma adlarını engelleyebilirdi. 24 Ağustos revizyonundan sonra private.icloud.com altında yalnızca Sign in with Apple adresleri olacak. Bugünkü risk ise şu: backend'in relay domain'lerini genel bir "şüpheli e-posta" kategorisine sokuyorsa, private.icloud.com'u tanımadığı için bu adresleri yanlış sınıflandırabilir.

ESP tarafında suppression list / routing kuralı

Apple, 15 Haziran duyurusunda e-posta servis sağlayıcılarına da doğrudan seslenmişti: domain-bazlı filtreleme, suppression list veya routing kurallarını enumere eden her yerde yeni domain'in de eklenmesi gerekiyordu. Bu paragraf 24 Ağustos güncellemesinde tekrarlanmadı. Çağrının muhatabı yalnız senin backend'in değildi; kullandığın ESP'nin (Postmark, SendGrid, Resend vb.) konfigürasyonu da listedeydi.

Domain'lerin hangi özelliğe ait olduğunu ve backend'inde nasıl davranman gerektiğini özetleyen tablo:

İki domain'i de kabul eden doğrulama kodu

Kural basit: domain kontrolünü tek bir string eşitliğine değil, bir listeye/regex alternatifine bağla. Aşağıda üç farklı katmanda (backend regex, TypeScript allowlist, Swift istemci tarafı) örnek var.

Backend: domain listesi + regex (TypeScript)

1const appleSignInRelayDomains = [
2  "privaterelay.appleid.com",
3  "private.icloud.com",
4] as const;
5 
6function isAppleSignInRelayEmail(email: string): boolean {
7  const domain = email.split("@")[1]?.toLowerCase();
8  if (!domain) return false;
9  return appleSignInRelayDomains.includes(
10    domain as (typeof appleSignInRelayDomains)[number],
11  );
12}
13 
14// Kayıt formu doğrulaması: relay adresini reddetme, yalnızca işaretle.
15function classifyEmailSource(email: string): "apple_relay" | "direct" {
16  return isAppleSignInRelayEmail(email) ? "apple_relay" : "direct";
17}

Dikkat: 24 Ağustos rehberi bu listeye icloud.com eklemeni gerektirmiyor; geçiş yalnızca iki Sign in with Apple domain'i üzerinden tanımlanmış durumda. Ancak Apple'ın relay dokümantasyonu @icloud.com'u da relay adresi son ekleri arasında sayıyor — bu yüzden listeden dışlamadan önce kendi kayıt verinde bu son ekle gelen Sign in with Apple adresi olup olmadığını doğrula.

Regex ile tek seferde eşleştirme

Bazı sistemlerde (log tarama, ESP kuralları, WAF filtreleri) liste yerine regex daha pratik olabilir:

1# Her iki relay domain'ini de yakalayan alternatif grup
2grep -E "@(privaterelay\.appleid\.com|private\.icloud\.com)$" access.log

Swift tarafında: gelen e-postayı kaynağına göre etiketleme

1enum EmailRelaySource {
2    case appleSignIn
3    case hideMyEmail
4    case direct
5}
6 
7func classifyRelaySource(email: String) -> EmailRelaySource {
8    let domain = email.split(separator: "@").last?.lowercased() ?? ""
9    let signInDomains: Set<Substring> = [
10        "privaterelay.appleid.com",
11        "private.icloud.com",
12    ]
13    if signInDomains.contains(Substring(domain)) {
14        return .appleSignIn
15    }
16    // Dikkat: icloud.com hem Hide My Email hem — Apple'ın relay dokümantasyonuna
17    // göre — Sign in with Apple relay son eki olabilir; kendi verinde doğrula.
18    if domain == "icloud.com" {
19        return .hideMyEmail
20    }
21    return .direct
22}

Bu üç örnekte de ortak nokta aynı: domain kontrolü tek bir sabit değer değil, genişleyebilen bir küme. Apple yarın üçüncü bir domain eklerse (ki bu geçiş sürecinde teorik olarak mümkün), tek yapman gereken kümeye bir satır eklemek.

Relay adresine e-posta gönderimi ve gönderen kaydı hatırlatması

Domain değişikliğinden bağımsız, uzun süredir geçerli iki kural var ve bunları unutmak da kırılmaya sebep oluyor:

• Gönderen kaydı zorunlu: Apple'ın resmi dokümantasyonuna göre relay adresine e-posta gönderebilmek için outbound e-postalarını veya e-posta domain'lerini kaydettirmen ve SPF (Sender Policy Framework) ile bu e-postaları doğrulaman gerekiyor. Bu adım domain değişse de değişmiyor — kayıt yoksa e-posta kullanıcıya iletilmez.
• Günlük 100 e-posta limiti: Her private relay adresinin günlük limiti 100 e-postadır; bu sayıya hem geliştiricinin gönderdiği hem kullanıcının yanıtları dahildir. Toplu bildirim gönderen sistemler (parola sıfırlama, kampanya e-postası) bu limiti test senaryolarında gözden kaçırabilir.

Sık karıştırılan bir ayrıntı: Apple'ın dokümantasyonundaki [email protected] → sales_at_example_com_<something>@icloud.com örneği, kullanıcının relay adresini değil, senin gönderen adresinin kullanıcıya okunabilir hâle getirilmiş biçimini gösteriyor. Yani bu örnek Sign in with Apple relay domain geçişinin konusu değil; örnekteki <something> de birebir kopyalanacak bir değer değil, yer tutucu.

Aynı kullanıcı-farklı domain hesap birleştirme tuzağı

Apple'ın relay kimlik mimarisinin sabit bir kuralı var: aynı kullanıcının relay adresi, tek bir geliştirici takımı yazdığı tüm uygulamalarda aynı kalır; farklı geliştirici takımlarının uygulamalarında ise farklı adres üretilir. Bu mantık domain değişikliğinden etkilenmiyor.

Ancak burada gerçek bir risk var: Apple'ın garantisi "mevcut adresler kesintisiz çalışmaya devam edecek" diyor — yani zaten var olan bir relay adresi domain değiştirmiyor. Değişen şey yalnızca yeni üretilecek adreslerin hangi domain'de olacağı. Sorun, backend'in kullanıcıyı e-posta adresinin tam string'ine göre birincil anahtar olarak eşlediği durumlarda çıkıyor: iki relay domain'inin paralel yaşadığı bir dünyada, e-postayı kimlik anahtarı yapan bir şema aynı kişiyi iki ayrı kayıt olarak görme riskini yapısal olarak taşır.

Doğru yaklaşım, e-posta adresinin kendisini değil, Apple'ın Sign in with Apple akışında verdiği kullanıcı tanımlayıcısını birincil kullanıcı kimliği olarak saklamak: Apple'ın dokümantasyonu ASAuthorizationAppleIDCredential üzerindeki user alanını "kimliği doğrulanmış kullanıcı için bir tanımlayıcı" olarak tarif ediyor. İstemci bu değeri backend'ine iletir, backend de kullanıcıyı bu değerle eşler. E-posta yalnızca iletişim kanalı olarak tutulmalı, kimlik anahtarı olarak değil.

1type AppleUser = {
2  appleUserId: string;
3  appleEmail: string;
4};
5 
6interface UserRepository {
7  findByAppleEmail(email: string): Promise<AppleUser | null>;
8  findByAppleUserId(appleUserId: string): Promise<AppleUser | null>;
9  updateEmail(appleUserId: string, appleEmail: string): Promise<void>;
10}
11 
12// Yanlış: e-posta domain'i değişirse kullanıcı eşleşmesi bozulur
13export async function findUserByAppleEmail(
14  repo: UserRepository,
15  email: string,
16) {
17  return repo.findByAppleEmail(email);
18}
19 
20// Doğru: Apple'ın verdiği kullanıcı tanımlayıcısı birincil anahtar
21export async function findUserByAppleUserId(
22  repo: UserRepository,
23  appleUserId: string,
24) {
25  return repo.findByAppleUserId(appleUserId);
26}
27 
28// E-posta yalnızca güncel iletişim kanalı olarak senkron tutulur
29export async function syncAppleContactEmail(
30  repo: UserRepository,
31  appleUserId: string,
32  currentEmail: string,
33) {
34  await repo.updateEmail(appleUserId, currentEmail);
35}

Sandbox ve gerçek cihaz test planı

Geçiş henüz aktif değil — duyuru "later this year" diyor ve 8 Eylül 2026 itibarıyla resmi kaynaklarda bir aktivasyon teyidi yok. Yani şu anda sandbox'ta veya gerçek bir cihazda private.icloud.com uzantılı bir adres üretip üretmediğini test etmen mümkün değil.

Bunun yerine yapabileceğin şey, kodunu spekülatif bir test adımıyla değil, domain-agnostic bir tasarımla geleceğe hazırlamak: yukarıdaki liste/regex yaklaşımını bugünden uygula, mevcut testlerini hem privaterelay.appleid.com hem private.icloud.com örnek adresleriyle çalıştır (ikinci adresi gerçek Apple'dan almadan, kendi test fixture'ında simüle ederek), ve geçiş tarihi netleştiğinde asıl doğrulamayı yapmak üzere Apple Developer News sayfasını izlemeye devam et.

Migration kontrol listesi

Aşağıdaki liste, Apple'ın resmi tavsiyelerinden ve bu yazıda ele alınan risklerden derlenmiştir:

• Allowlist/regex güncelle: private.icloud.com'u ekle, privaterelay.appleid.com'u asla çıkarma — Apple mevcut adreslerin kesintisiz çalışmaya devam edeceğini söylüyor, ikisi paralel yaşayacak.
• Özellik ayrımını koru: Hide My Email (icloud.com) ile Sign in with Apple relay domain'lerini aynı allowlist mantığında karıştırma; artık farklı kaderleri var.
• ESP kurallarını gözden geçir: Suppression list, spam filtresi ve routing kurallarındaki domain enumerasyonlarını domain-agnostic hale getir.
• SPF/gönderen kaydını doğrula: Relay adresine e-posta gönderiyorsan outbound domain kaydı ve SPF doğrulaması hâlâ zorunlu; günlük 100 e-posta limitini test senaryolarına dahil et.
• Kullanıcı eşleme mantığını düzelt: Birincil anahtar olarak e-posta yerine Apple'ın verdiği kullanıcı tanımlayıcısını (user) kullan.
• Apple Developer News'i izlemeye devam et: Geçişin kesin tarihi netleşene kadar id=1ptvdtcm sayfasını takip et; aktivasyon teyidi geldiğinde bu makaleye bir güncelleme eklenecek.

Öncelik sırasına göre kimin ne kadar aciliyetle harekete geçmesi gerektiğini özetleyen tablo:

SSS

Sign in with Apple'ın yeni relay domain'i nedir?

Apple'ın 24 Ağustos 2026 tarihli resmi duyurusuna göre, bu yıl içinde yeni oluşturulan Sign in with Apple e-posta adresleri artık privaterelay.appleid.com yerine `private.icloud.com` domain'inde yayımlanacak. Bu, Haziran 2026'da duyurulan ve Hide My Email'i de aynı domain'e taşımayı öngören daha geniş bir planın revize edilmiş, dar kapsamlı hâlidir.

E-posta doğrulama/allowlist kodu nasıl güncellenmeli?

Apple'ın resmi tavsiyesi, hesap sistemlerinin, e-posta doğrulama mantığının ve allowlist'lerin hem eski (privaterelay.appleid.com) hem yeni (private.icloud.com) domain'i kabul edecek şekilde güncellenmesi yönünde. Pratikte bu, sabit-kodlanmış tek-domain karşılaştırmasının bir suffix listesi veya regex alternatifine dönüştürülmesi anlamına gelir; ESP tarafında ise domain-bazlı filtreleme ve suppression list kurallarının güncellenmesi çağrısı 15 Haziran duyurusunda yapılmıştı.

Eski relay adresleri çalışmaya devam ediyor mu?

Evet. Apple açıkça belirtiyor: privaterelay.appleid.com üzerindeki mevcut adresler kesintisiz çalışmaya ve e-postaları yönlendirmeye devam edecek. Değişiklik yalnızca yeni oluşturulacak adresleri etkiliyor; geriye dönük bir domain iptali veya zorunlu geçiş yok.

Hide My Email adresleri de private.icloud.com'a mı taşınıyor?

Hayır. Apple, 24 Ağustos 2026'daki güncellemede bu kısmından geri adım attı: iCloud+ Hide My Email adresleri icloud.com domain'inde kalmaya devam edecek. Yalnızca Sign in with Apple için üretilen yeni relay adresleri private.icloud.com'a taşınıyor. Haziran'daki ilk duyuruyu okumuşsan bu ayrımı güncellemen gerekiyor.

Geçiş ne zaman tamamlanmış olacak?

Apple henüz kesin bir tarih vermedi; duyuru metni "bu yılın ilerleyen döneminde" (later this year) diyor. 8 Eylül 2026 itibarıyla resmi kaynaklarda net bir aktivasyon tarihi veya geçişin canlıya alındığına dair teyit yok. Takip için Apple Developer News sayfasını izlemen öneriliyor.

Sonuç

Bu geçişte teknik olarak yapılması gereken şey basit: domain kontrolünü tek bir sabit değerden bir listeye genişletmek. Asıl risk, iki ayrı Apple duyurusu arasındaki kapsam farkını (Haziran'ın geniş planı vs. Ağustos'un daraltılmış hâli) karıştırıp yanlış domain'i yanlış özelliğe bağlamak. Backend'ini şimdiden domain-agnostic hale getirirsen, geçişin kesin tarihi ne zaman netleşirse netleşsin senin için sürpriz olmaz.

Sign in with Apple entegrasyonunun diğer güvenlik yüzeylerini de gözden geçirmek istersen iOS Keychain Security rehberine, genel kimlik doğrulama sertleştirmesi için iOS Security Best Practices yazısına, ağ katmanı güvenliği için iOS Network Security Advanced içeriğine bakabilirsin. Kullanıcı izleme ve gizlilik uyumu tarafında iOS Privacy Compliance ATT ve iOS Privacy Manifests yazıları tamamlayıcı nitelikte.

Kaynaklar

• Apple Developer News — Update: New domain for Sign in with Apple — 24 Ağustos 2026 tarihli resmi güncelleme; yeni domain'in private.icloud.com olduğunu ve Hide My Email'in icloud.com'da kalacağını duyuruyor.
• Apple Developer News — New domain for Sign in with Apple and iCloud+ Hide My Email — 15 Haziran 2026 tarihli ilk duyuru (artık "outdated" işaretli).
• Apple Developer Documentation — Communicating using the private email relay service — SPF, gönderen kaydı ve günlük 100 e-posta limiti detayları.
• Apple Developer Documentation — ASAuthorizationAppleIDCredential.user — kimliği doğrulanmış kullanıcı için verilen tanımlayıcı alanı.
• MacRumors — Apple to Unify Sign in With Apple and Hide My Email on One Domain — 15 Haziran 2026 haberi.
• 9to5Mac — Sign in with Apple and Hide My Email are getting a new shared email domain — 15 Haziran 2026 haberi.
• MacRumors — Apple's New Hide My Email Domain Makes It Easier to Block iCloud Aliases — 17 Haziran 2026; @vxdb'nin bloklama uyarısı.
• AppleInsider — Hide My Email no longer changing domains, will keep iCloud.com — 24 Ağustos 2026, revizyonun ayrıntıları.
• Daring Fireball — Apple Rethinks Plan to Merge 'Hide My Email' Domain Name With 'Sign In With Apple' — 24 Ağustos 2026 yorumu.