Apple trekt domeinwijziging voor Hide My Email terug

Apple splitst zijn geplande wijziging van e-maildomeinen in tweeën. In juni kondigde het bedrijf aan dat zowel iCloud+ Hide My Email als Sign in with Apple voortaan @private.icloud.com zouden gebruiken. Op 24 augustus liet Apple weten dat Hide My Email-aliases toch op @icloud.com blijven. Nieuwe adressen voor Sign in with Apple worden later in 2026 wel verplaatst van @privaterelay.appleid.com naar @private.icloud.com. Bestaande relay-adressen blijven zonder onderbreking werken. 10

Wat Apple heeft aangepast

Het oorspronkelijke plan was om nieuw aangemaakte adressen van beide privacyfuncties onder te brengen bij @private.icloud.com. Bestaande Hide My Email-adressen met @icloud.com en bestaande Sign in with Apple-adressen met @privaterelay.appleid.com zouden blijven doorsturen. 15

De aangepaste plannen zijn beperkter:

• iCloud+ Hide My Email: nieuwe aliassen blijven eindigen op @icloud.com.
• Sign in with Apple: nieuwe relay-adressen krijgen later in 2026 het domein @private.icloud.com.
• Bestaande Sign in with Apple-adressen: adressen met @privaterelay.appleid.com blijven geldig en blijven e-mails doorsturen.

Apple zegt dat het besluit volgt op “verdere overweging” en feedback uit de community. Het bedrijf heeft niet gezegd dat een specifieke beveiligingsmelding de aanleiding was. 10

Waarom gebruikers bezwaar maakten tegen @private.icloud.com

De kritiek ging niet over het automatisch prijsgeven van de mailbox achter een alias. Het probleem was vooral dat @private.icloud.com meteen zou verraden dat een adres onderdeel is van Apples privacyrelay.

Een website of app kan zo’n domein met een eenvoudige controle herkennen. Vervolgens kan de dienst het adres weigeren, om een ander e-mailadres vragen of het gebruiken als signaal bij fraudedetectie en risicobeoordeling. Daarmee zou Hide My Email bij het aanmaken van accounts veel eenvoudiger te blokkeren zijn. 44

@icloud.com wordt daarentegen ook gebruikt voor gewone iCloud-mailadressen. Een Hide My Email-alias met dat domein valt daardoor minder op bij diensten die gemaskeerde adressen proberen te onderscheiden van reguliere mailboxen. Precies dat verschil vormde de kern van de kritiek: gebruikers vreesden dat de voorgestelde wijziging de praktische privacy en de geloofwaardige ontkenbaarheid van de functie zou verminderen, ook als Apples doorstuurinfrastructuur zelf niet veranderde. 35

Wat ontwikkelaars voor Sign in with Apple moeten doen

Ontwikkelaars kunnen de wijziging het beste behandelen als een overgang tussen relaydomeinen, niet als een volledige vervanging van het oude domein.

Accepteer beide relaydomeinen

Werk accountsystemen, e-mailvalidatie, reguliere expressies, allowlists en domeinspecifieke logica bij zodat zowel nieuwe adressen met @private.icloud.com als bestaande adressen met @privaterelay.appleid.com worden geaccepteerd. Apples eerdere richtlijnen verwezen bij relaydomeinen ook naar @icloud.com. Systemen moeten er daarom niet van uitgaan dat er maar één geldig Apple-relayachtervoegsel bestaat. 810

Maak vooral geen bestaande accounts ongeldig omdat het adres het oudere domein gebruikt. Apple zegt dat adressen met @privaterelay.appleid.com blijven werken en e-mails zonder onderbreking blijven doorsturen. 10

Controleer de configuratie voor uitgaande e-mail

Als een app of website berichten via Apples private-e-mailrelay verstuurt, moeten de gebruikte domeinen en subdomeinen in het Apple-ontwikkelaarsaccount worden geregistreerd. Volgens Apples configuratiehandleiding moeten de geregistreerde e-mailbronnen bovendien een SPF-controle doorstaan. 6

Controleer daarom in elk geval:

• geregistreerde verzenddomeinen en subdomeinen;
• SPF-records in DNS;
• e-mailvalidatie en processen voor accountherstel;
• allowlists en blocklists;
• databasevelden of schema’s die uitgaan van één vast e-maildomein;
• klantenservice- en accountzoektools die gebruikers op basis van hun e-mailachtervoegsel vinden.

Apple beschrijft de relay als een dienst die berichten doorstuurt naar een van de geverifieerde e-mailadressen van de Apple Account van de gebruiker. 3

Hoe recente privacyproblemen de context veranderen

De discussie over de domeinnaam viel samen met afzonderlijke meldingen over zwakke plekken in Apples privacyfuncties. Die incidenten bewijzen niet dat @private.icloud.com zelf een e-mailadres of IP-adres zou prijsgeven. Ze helpen wel verklaren waarom gebruikers extra kritisch waren op een wijziging die privacyaliassen eenvoudiger herkenbaar zou maken.

Kwetsbaarheid in Hide My Email bij spam-bounces

Een gemelde fout in Hide My Email kon het echte adres achter een alias blootleggen wanneer een bericht naar die alias als spam werd geweigerd. Het onderliggende adres kon dan verschijnen in mailtransferlogs aan de kant van de afzender, waardoor de belangrijkste privacybelofte van de functie werd ondermijnd. Apple zei dat het op 3 juli 2026 een oplossing had uitgerold. Tests achteraf meldden dat het probleem niet langer kon worden gereproduceerd. 474954

Een patch wist eerdere blootstelling niet automatisch uit. Mailservers van derden kunnen oude bezorgingslogs bewaren. Daardoor kunnen adressen die vóór de oplossing zichtbaar werden nog steeds voorkomen in systemen waar Apple geen controle over heeft. 4860

Gemelde IP-lekken in Private Relay

Onderzoekers meldden daarnaast dat bepaalde WebKit-gerelateerde verbindingen iCloud Private Relay konden omzeilen, waardoor het echte IP-adres van een gebruiker zichtbaar kon worden. De gemelde routes hadden onder meer te maken met passkeys en WebAuthn, WebTransport en DNS-prefetching. 192023

Een later bericht beschreef een vermoedelijke oplossing in iOS 26.6.1. De beschikbare berichtgeving gaat daarbij over een gemelde patch, niet over een bredere uitleg van Apple over de architectuur of de precieze impact. 18

Deze kwesties werken via andere mechanismen dan de zichtbaarheid van een e-maildomein. De Hide My Email-fout draaide om het lekken van een adres via teruggestuurde e-mail; de Private Relay-meldingen gingen over netwerkverkeer dat buiten de relayroute kon vallen. Geen van beide toont aan dat het voorgestelde domein @private.icloud.com rechtstreeks de identiteit van een gebruiker zou onthullen.

De meest voor de hand liggende uitleg voor Apples ommezwaai

De directe verklaring is verzet vanuit de community tegen de eenvoudigere blokkeerbaarheid. Gebruikers wezen erop dat een speciaal privacydomein websites een makkelijke manier zou geven om aliassen te herkennen en te weigeren. Apple bevestigt zelf dat het besluit volgde op feedback uit de community. 10

De gelijktijdige beveiligingsmeldingen zijn vooral reputatiecontext, geen bewezen oorzaak. Ze maakten het vertrouwen in Apples privacybescherming kwetsbaarder, maar Apple heeft geen verband gelegd tussen die meldingen en de beslissing over de domeinnaam.

Voor gebruikers is het resultaat een compromis: Hide My Email houdt het minder opvallende achtervoegsel @icloud.com, terwijl ontwikkelaars voor Sign in with Apple vanaf later dit jaar rekening moeten houden met zowel @private.icloud.com als het bestaande @privaterelay.appleid.com.