Apple låter Hide My Email stanna på @icloud.com

Apple delar nu upp den planerade förändringen av sina privata e-postadresser. Efter att i juni ha meddelat att både iCloud+ Hide My Email och Sign in with Apple skulle börja använda @private.icloud.com, meddelade företaget den 24 augusti att Hide My Email-alias även fortsättningsvis ska använda @icloud.com. Nya adresser från Sign in with Apple ska däremot flyttas från @privaterelay.appleid.com till @private.icloud.com senare under 2026. Befintliga adresser fortsätter att fungera och vidarebefordra e-post utan avbrott. 10

Det här ändrar Apple

Apples ursprungliga plan var att samla nya adresser från de två integritetsfunktionerna under domänen @private.icloud.com. Befintliga Hide My Email-adresser på @icloud.com och befintliga Sign in with Apple-adresser på @privaterelay.appleid.com skulle fortfarande ha fungerat. 15

Den reviderade planen är mer begränsad:

• iCloud+ Hide My Email: Nya alias fortsätter att använda @icloud.com.
• Sign in with Apple: Nya vidarebefordringsadresser ska använda @private.icloud.com senare under 2026.
• Befintliga Sign in with Apple-adresser: Adresser på @privaterelay.appleid.com förblir giltiga och fortsätter att vidarebefordra e-post.

Apple hänvisar till ”ytterligare överväganden” och feedback från användarcommunityn. Företaget har inte sagt att något särskilt säkerhetslarm låg bakom beslutet. 10

Därför reagerade användarna på den nya domänen

Problemet var inte att ett domänbyte automatiskt skulle avslöja vilken inkorg som finns bakom ett alias. Invändningen var att @private.icloud.com tydligt skulle signalera att adressen är en Apple-genererad vidarebefordringsadress.

En webbplats eller app skulle kunna upptäcka domänen med en enkel kontroll och därefter neka adressen, kräva en annan e-postadress eller använda informationen i bedömningar av bedrägeririsk. På så sätt skulle Hide My Email bli betydligt enklare att blockera vid registrering. 44

@icloud.com används däremot även för vanliga iCloud-adresser. Ett Hide My Email-alias med den ändelsen är därför svårare för en tjänst att skilja från en traditionell e-postadress. Det var kärnan i kritiken: användarna befarade att den föreslagna förändringen skulle försämra funktionens praktiska integritet och möjligheten att inte omedelbart avslöja att adressen är maskerad, även om Apples vidarebefordringssystem i sig inte förändrades. 35

Vad utvecklare behöver göra

Utvecklare som använder Sign in with Apple bör se förändringen som en övergång mellan två vidarebefordringsdomäner – inte som att den gamla plötsligt försvinner.

Acceptera båda domänerna

Uppdatera kontosystem, regler för e-postvalidering, reguljära uttryck, tillåtelselistor och annan domänspecifik logik så att nya adresser på @private.icloud.com accepteras tillsammans med befintliga adresser på @privaterelay.appleid.com. Apples tidigare vägledning nämnde även @icloud.com i samband med hantering av vidarebefordringsdomäner. System bör därför inte utgå från att det bara finns en giltig Apple-domän. 810

Det viktigaste är att inte flytta eller ogiltigförklara befintliga användare enbart för att deras adress använder den äldre domänen. Apple säger att adresser på @privaterelay.appleid.com fortsätter att fungera och vidarebefordra e-post utan avbrott. 10

Kontrollera den utgående e-posten

Om en app eller webbplats skickar meddelanden via Apples privata e-postrelä måste utvecklaren registrera de domäner och underdomäner som används för utgående e-post i Apples utvecklarkonto. Apple kräver också att de registrerade e-postkällorna klarar en SPF-kontroll. 6

Det innebär att team bör gå igenom:

• registrerade avsändardomäner och underdomäner,
• SPF-poster i DNS,
• flöden för e-postvalidering och kontoåterställning,
• tillåtelse- och blocklistor,
• databasfält och scheman som förutsätter en viss e-postdomän,
• support- och kontosökningsverktyg som matchar användare utifrån domänsuffix.

Apples dokumentation beskriver relät som en tjänst som vidarebefordrar meddelanden till en av de verifierade e-postadresserna på användarens Apple-konto. 3

Säkerhetsproblemen ger viktig bakgrund – men bevisar inte orsaken

Domändebatten kom samtidigt som separata rapporter om svagheter i Apples integritetstjänster. Dessa händelser visar inte att @private.icloud.com i sig skulle läcka en e-postadress eller IP-adress. De hjälper däremot till att förklara varför användarna granskade en förändring som kunde göra privata alias enklare att känna igen.

En sårbarhet i Hide My Email kunde avslöja den riktiga adressen

En rapporterad brist i Hide My Email kunde avslöja adressen bakom ett alias när ett meddelande till aliaset avvisades som skräppost. Den riktiga adressen kunde då dyka upp i avsändarens e-postloggar, vilket underminerade funktionens centrala integritetslöfte. Apple uppgav att en korrigering infördes den 3 juli 2026, och senare tester visade att problemet inte längre gick att återskapa. 474954

En uppdatering raderar dock inte nödvändigtvis historiska uppgifter. E-postsystem hos tredje part kan ha sparat äldre leveransloggar, vilket innebär att adresser som exponerades före korrigeringen fortfarande kan finnas kvar utanför Apples kontroll. 4860

Rapporter om IP-läckor i Private Relay

Säkerhetsforskare rapporterade också att viss trafik kopplad till WebKit kunde kringgå iCloud Private Relay och avslöja användarens riktiga IP-adress. De rapporterade vägarna omfattade WebAuthn-förfrågningar kopplade till passkeys, WebTransport och DNS-förladdning. 192023

En senare rapport beskrev en möjlig korrigering i iOS 26.6.1. Underlaget gäller dock en rapporterad åtgärd, inte en bredare förklaring från Apple om arkitekturen eller konsekvenserna. 18

Det rör sig om andra mekanismer än synligheten hos en e-postdomän. Hide My Email-problemet handlade om att en avvisad e-post kunde avslöja adressen bakom aliaset, medan Private Relay-rapporterna gällde nätverkstrafik som kunde ta en annan väg än relät. Inget av detta visar att den föreslagna domänen @private.icloud.com direkt skulle avslöja användarens identitet.

Den mest rimliga tolkningen av Apples helomvändning

Den tydligaste förklaringen är användarnas oro för att Hide My Email skulle bli lättare att blockera. En särskild integritetsdomän skulle ge webbplatser ett enkelt sätt att identifiera och neka alias. Apples eget meddelande bekräftar att beslutet ändrades efter feedback från communityn. 10

De samtidiga säkerhetsrapporterna bör främst ses som bakgrund och förtroendekontext – inte som en bevisad orsak. De gjorde tilliten till Apples integritetsskydd mer skör, men Apple har inte kopplat rapporterna till domänbeslutet.

För användarna blir resultatet en kompromiss: Hide My Email behåller den mindre iögonfallande ändelsen @icloud.com, medan utvecklare för Sign in with Apple måste förbereda sina system för @private.icloud.com och samtidigt fortsätta stödja den äldre relädomänen.