Varför mejlet du vidarebefordrade till dig själv hamnade i skräpposten

Ställ in en automatisk vidarebefordring från ditt gamla konto till det nya, och en del av mejlen försvinner tyst in i skräpposten — inte för att din leverantör är bruten, utan för att vidarebefordring skriver om vem som skickar meddelandet utan att skriva om det kryptografiska beviset. SPF kontrollerar fel server, DMARC-domen blir misslyckat, och ett legitimt mejl som du skickade till dig själv blir karantänerat. Lösningen har ett namn: ARC, definierad i RFC 8617 redan 2019.

Varför gör vidarebefordring att mitt mejl misslyckas SPF?

För att SPF kontrollerar den sista servern som vidarebefordrade meddelandet, och vidarebefordring ändrar den servern. SPF — Sender Policy Framework — är en DNS-post som listar vilka IP-adresser som är tillåtna att skicka mejl för en domän. När bank.com skickar dig ett kvitto kontrollerar den mottagande servern: kom detta från en IP-adress som bank.com godkänt? Ja. Godkänt.

Vidarebefordra nu det kvittot från din Gmail till din nya adress. Googles servrar vidarebefordrar det. Den slutliga mottagande servern kör SPF-kontrollen och frågar: är Google godkänt att skicka för bank.com? Nej, det är det inte. SPF misslyckas. Googles egen Workspace-dokumentation förklarar detta klart — vidarebefordrade meddelanden misslyckas SPF eftersom vidarebefordringservern inte finns i den ursprungliga domänens SPF-post. Ingenting förfalskades. Kontrollen tittar bara på fel hopp.

Så varför hamnar det i skräpposten?

DMARC. SPF-misslyckande allena var tidigare överlevbart; DMARC gjorde det till ett avgörande. DMARC binder samman SPF och DKIM och talar om för mottagare vad de ska göra när båda misslyckas: ingenting, karantän eller avvisning. År 2024 hade stora avsändare inget val — Google och Yahoo började kräva DMARC på alla som skickade mer än 5 000 meddelanden per dag till sina användare.

DKIM, den andra pelaren, är en signatur som är inbakad i meddelandet. I teorin överlevs vidarebefordring eftersom det signerar innehållet, inte vägen. I praktiken bryter allt som rör meddelandet det. En e-postlista som lägger till en sidfot "du är prenumererad, avsluta prenumeration här", en server som skriver om ämnesraden, till och med en förändring i hur en rad radbryter — signaturen stämmer inte längre, och DKIM misslyckas också. Nu är båda pelarna nere, DMARC säger misslyckat, och ditt eget kvitto är i skräpmappen.

Vad är ARC och fixar det faktiskt detta?

ARC — Authenticated Received Chain, RFC 8617 — låter en ärlig vidarebefordare garantera att mejlet passerade autentisering innan det rörde vid det. Vidarebefordringservern stämplar meddelandet med en förseglar post som säger "när detta nådde mig var SPF och DKIM giltiga — lita på mitt ord för det hopp du inte kan verifiera." Den slutliga mottagaren, om den litar på denna vidarebefordare, kan åsidosätta DMARC-misslyckandet och leverera.

Fångsten ligger i "om den litar på". ARC är inte ett lösenord; det är ett ryktessystem. En mottagare väger huruvida ARC-förseglarens tätning är en känd, väl betingad operatör. Google både stämplar ARC-rubriker och respekterar dem från avsändare som det litar på, vilket är varför en Gmail-till-Gmail vidarebefordring vanligtvis överlevs medan en vidarebefordring genom någon arkaisk universitetets relä inte gör det.

Om du kör vidarebefordringen själv hjälper två konkreta drag. Använd Server-Side Redirect / SRS-omskrivning om din värd erbjuder det, vilket skriver om kuvertavsändaren så att SPF-kontrollen går mot din vidarebefordare istället för den ursprungliga domänen. Och föredra vidarebefordring mellan leverantörer som båda stöder ARC. Om du konsoliderar konton och vill att destinationen bara ska hantera autentiseringskaoset åt dig, det är exakt den typ av ledningar som en AI-mejlplattform är byggd för att absorbera.

När ska jag sluta skylla på min leverantör?

När mönstret är "bara vidarebefordrat mejl misslyckas" gör leverantören sitt jobb korrekt — protokollet är problemet. Här är signalen: öppna det saknade meddelandet rubriker och leta efter raden Authentication-Results. Om du ser spf=fail tillsammans med en avsändar-IP som tillhör en vidarebefordare snarare än den ursprungliga avsändaren, det är SPF som kontrollerar fel hopp. Om dkim=fail dyker upp på mejl som gick genom en lista eller en relä som redigerar meddelanden, det är en förstörd signatur, inte en förfalskning.

Den obehagliga sanningen är att e-postautentisering bultas på, lager efter lager, under två decennier på ett system som aldrig antog att någon skulle ljuga. SPF kom 2006, DKIM 2007, DMARC 2015, ARC 2019 — var och en lappade ett hål som den tidigare öppnade. Vidarebefordring är sömen där alla fyra gnuggar mot varandra, och din inkorg är där du känner friktionen.

@@END@@