Varför kommer inte vidarebefordrad e-post fram?

Varför bortfallet är tyst, och varför diagnosen oftast blir fel

När vidarebefordrad e-post försvinner får du normalt inget felmeddelande. Ingen studs, ingen varning, inget som säger att något gick fel. Mejlet accepterades av din brevlåda hos webbhotellet i steg ett, och när det sedan skulle skickas vidare till Gmail eller Outlook blev det tyst underkänt eller stoppat i skräpposten längre bort i kedjan, utan att någon av parterna får veta det.

Det tysta bortfallet är precis varför felsökningen så ofta landar fel. "Vi får bara lite mejl den här veckan", "Gmail är kinkigt" eller "avsändaren skrev nog fel adress" är alla naturliga gissningar när det enda du har att gå på är en frånvaro. Den faktiska orsaken sitter nästan alltid i hur vidarebefordran hanterar avsändarautentisering, ett samspel mellan SPF, DKIM och DMARC som beskrivs i sin helhet i vår guide om SPF, DKIM och DMARC.

Mekaniken bakom SPF-brottet

När info@sindoman.se vidarebefordras till din Gmail behåller webbhotellet den ursprungliga kuvertavsändaren, alltså adressen som stod som avsändare i det inkommande mejlet. Men själva utskicket till Gmail sker från webbhotellets egen server och IP-adress, inte från avsändarens. Gmails mottagande server ser då ett mejl som påstår sig komma från en viss domän, skickat från en IP-adress som inte finns med i den domänens SPF-post enligt RFC 7208. SPF-kontrollen misslyckas, eftersom den är byggd för att fånga upp just avsändaradresser som skickas från obehöriga servrar. Det här är inte ett fel hos webbhotellet utan hur vidarebefordran alltid har fungerat rent tekniskt, vilket även cPanels egen dokumentation om forwarders utgår från.

SPF-kontrollen är i praktiken garanterad att fela varje gång ett mejl vidarebefordras, och det är i sig ofarligt. DMARC kräver nämligen inte att SPF passerar, bara att minst en av SPF och DKIM gör det och är i linje med avsändardomänen, enligt RFC 7489, avsnitt 4.2. Det är alltså DKIM, inte SPF, som i praktiken avgör om mejlet ändå kommer fram.

Knorren: DKIM är den enda tråden, och det är oftast din egen värd som klipper den

DKIM-signaturen skapas av avsändarens egen server och läggs till i mejlets header innan meddelandet ens når webbhotellet. Signaturen är matematiskt knuten till innehållet, inte till vilken IP-adress som råkar skicka mejlet vidare. Så länge webbhotellet vidarebefordrar meddelandet oförändrat följer DKIM-signaturen med hela vägen till Gmail eller Outlook, fortfarande giltig och fortfarande i linje med avsändarens domän. DMARC-kontrollen passerar då på DKIM ensamt, trots att SPF redan fallit, och det är förklaringen till att de allra flesta vidarebefordrade mejl faktiskt kommer fram.

Bortfallet uppstår först när DKIM också går sönder, och det som oftast river signaturen är varken avsändaren eller mottagaren utan webbhotellet självt. Lägger spamfiltret till en spamfot i brödtexten, sätter det ett [SPAM]-prefix i ämnesraden, eller skriver om meddelandet på MIME-nivå, ändras exakt de bytes som DKIM-signaturen har räknat sin hash över. Signaturen blir ogiltig, DKIM-kontrollen faller, och nu har DMARC ingenting kvar att luta sig mot eftersom SPF redan var trasigt sedan steg ett. Det gör felet dubbelt bakvänt. Funktionen du betalar webbhotellet för, spamfiltret som ska skydda din inkorg, är ofta det som gör att andras mejl till dig försvinner.

Först i det här läget spelar avsändarens DMARC-policy roll, och den avgör hur hårt fallet blir snarare än om det sker. Kör domänen p=reject kastas mejlet tyst så fort både SPF och DKIM har fallit. Kör den i stället p=quarantine hamnar det troligen i mottagarens skräppost i stället för att försvinna helt, och kör den p=none levereras mejlet ändå trots de brutna kontrollerna, bara märkt i loggarna. Du kan aldrig påverka den policyn, den ägs av avsändarens domän, men efter att DKIM väl gått sönder är det den som avgör om posten kastas, karantänsätts eller ändå kommer fram. Andelen domäner som kör p=reject har dessutom ökat sedan Googles och Yahoos krav på massutskick från februari 2024 och Microsofts motsvarande skärpning, vilket gör att fler av de fall där DKIM redan brustit numera kastas helt tyst i stället för att bara flaggas.

Varför SRS inte löser DMARC-problemet

En del webbhotell aktiverar Sender Rewriting Scheme, förkortat SRS, för att reparera SPF-brottet. Tekniken skriver om kuvertavsändaren, MAIL FROM, till en adress under hostens egen domän, vilket får SPF att passera mot hostens IP. Men DMARC kräver alignment enligt RFC 7489, avsnitt 3.1.2, alltså att den domän som klarar SPF-kontrollen ska matcha domänen i mejlets From-fält. Byter SRS kuvertavsändaren till hostens domän matchar den per definition inte längre avsändarens From-domän, så SPF-benet i DMARC faller ändå, oavsett att SPF-kontrollen i sig lyckades.

Det är ingen tillfällighet att SRS inte räcker hela vägen. RFC 7208, SPF-standarden från april 2014, föreslår själv en omskrivning av avsändaradressen som fix för just vidarebefordran, i bilaga D.2, den idé som senare blev SRS. Men RFC 7208 nämner DMARC ingenstans, av det enkla skälet att DMARC-standarden, RFC 7489, publicerades först i mars 2015, nästan ett år senare. SPF:s egen lösning skrevs alltså innan alignment-kravet ens existerade och kunde omöjligt ta höjd för det. SRS löser precis det problem SPF hade 2014. Kvar står, precis som innan SRS aktiverades, DKIM som den enda tråd som avgör om mejlet kommer fram.

Så bekräftar du att det faktiskt är det här

• Testa utan vidarebefordran. Be en avsändare vars mejl försvann skicka samma sak direkt till din slutadress i stället för till info@sindoman.se. Kommer det fram nu är vidarebefordran boven, inte spamfilter eller ett skrivfel.
• Leta efter dkim=fail, inte bara spf=fail. Sök efter raden Authentication-Results i mejlets fullständiga headers, som du når via "Visa original" i Gmail eller meddelandeegenskaper i Outlook. Ett spf=fail där är väntat och normalt vid vidarebefordran och säger ingenting om varför mejlet försvann. Leta i stället efter dkim=fail. Står det där är DKIM-signaturen bruten, och det är den som faktiskt fällde mejlet.
• Kontrollera om meddelandet modifierats på vägen. Har ämnesraden fått ett prefix, till exempel [SPAM], eller har brödtexten fått en extra fot längst ner som inte fanns i originalet? Det är tecknet på att webbhotellets eget spamfilter har skrivit om meddelandet, och det är oftast precis den ändringen som river DKIM-signaturen.
• Kontrollera avsändarens DMARC-policy. Posten är publik i DNS under _dmarc.deras-doman.se. Slå upp den med vårt DNS-uppslagsverktyg och leta efter p=reject eller p=quarantine. Hittar du p=reject vet du hur hårt fallet blev sedan DKIM redan gått sönder, inte varför det gick sönder i första läget.

Lösningarna, rangordnade efter vad som faktiskt fungerar

Ingen av lösningarna nedan är en genväg som lagar vidarebefordran som mekanik. De flesta löser problemet genom att ta bort vidarebefordran som steg, inte genom att reparera den.

Bäst: hämta posten i stället för att vidarebefordra den

Skapa en riktig brevlåda hos webbhotellet i stället för en ren vidarebefordringsregel, och hämta den med IMAP direkt i din Gmail- eller Outlook-klient. Då sker inget extra SMTP-hopp. Mejlet levereras en enda gång, till din egen brevlåda hos hosten, och SPF och DKIM kontrolleras bara mot den ursprungliga avsändaren vid det tillfället.

Ett observandum om Gmail specifikt. Funktionen "Kontrollera e-post från andra konton", som hämtar via POP i Gmails webbgränssnitt, går inte längre att sätta upp för nya konton, och Google stänger den helt i januari 2027. Vi har skrivit mer om vad Gmails POP-avveckling innebär. Bygger du en ny lösning i dag, luta dig mot IMAP i en riktig e-postklient snarare än den inbyggda POP-hämtningen.

Flytta hela brevlådan till mottagarleverantören

Läser du ändå all post i Google Workspace eller Microsoft 365 är den mest robusta lösningen att sluta med uppdelningen helt. Peka domänens MX-poster direkt mot Google eller Microsoft i stället för mot webbhotellet, och låt info@sindoman.se leva som en riktig brevlåda eller ett alias där. Då försvinner mellanhoppet, och all autentisering sker i ett enda steg som mottagarleverantören själv kontrollerar.

Om du ändå måste vidarebefordra

Ibland är vidarebefordran svår att komma runt, till exempel för en delad funktionsadress som flera personer ska nå i sina egna inkorgar. Fråga då supporten rakt ut om två saker. Skriver hotellet om kuvertavsändaren med SRS, och modifierar något filter i kedjan meddelandet med spamfot eller ämnesprefix? Svaren framgår sällan av dokumentationen, och de avgör om DKIM-signaturen överlever hoppet. Räkna ändå med ett visst tapp mot avsändare som kör en strikt DMARC-policy. Det går inte att konfigurera bort helt så länge vidarebefordran finns kvar som mekanik.

Den riktiga lösningen bakom kulisserna heter ARC

Det finns en standard byggd just för att lösa vidarebefordringsproblemet på protokollnivå. Den heter ARC, Authenticated Received Chain. Den vidarebefordrande servern signerar och bevarar resultatet av den ursprungliga autentiseringskontrollen innan mejlet skickas vidare, så att den slutliga mottagaren kan lita på det ursprungliga SPF- och DKIM-utfallet även när SPF bryts på sista hoppet. ARC är byggt just för scenariot ovan, en mellanhand som modifierar meddelandet på vägen och därmed river DKIM-signaturen. Utan ARC har mottagaren inget annat att luta sig mot när både SPF och DKIM har fallit, med ARC kan den fortfarande lita på den ursprungliga autentiseringen. Microsoft dokumenterar hur mottagande administratörer pekar ut betrodda ARC-signerare i sin guide om ARC-konfiguration, och Google beskriver sitt ARC-stöd i dokumentationen för Google Workspace.

Haken är att ARC bara hjälper om den vidarebefordrande servern faktiskt lägger till ARC-headers. När vi gick igenom de svenska webbhotellens egna kunskapsbanker hittade vi ingen som dokumenterar att deras vidarebefordran ARC-signerar. Det utesluter inte att någon gör det, men det betyder att du inte kan räkna med det, och att du inte kan verifiera det utan att fråga. För en vanlig webbhotellskund är IMAP-hämtning eller en fullständig flytt till mottagarleverantören det som faktiskt går att genomföra i dag.

Vad svenska webbhotell själva säger om det här

Flera svenska webbhotell avråder numera uttryckligen, i sina egna kunskapsbanker, från att vidarebefordra e-post till Gmail, Outlook eller Yahoo. Det är ett rimligt besked, men det stannar oftast vid rekommendationen utan att förklara varför vissa avsändare kommer fram och andra inte. Förklaringen ligger sällan hos avsändarens domän i sig. Oftast avgörs det av om värdens eget spamfilter råkar modifiera just det mejlet och därmed river DKIM-signaturen, i kombination med hur strikt avsändarens DMARC-policy råkar vara satt när det väl händer.

Hamnar ditt utgående mejl i stället i mottagarens skräppost, snarare än att försvinna helt, är det ett annat problem med en annan lösning. Läs mer om varför e-post hamnar i skräpposten. Vill du i stället låta flera personer läsa samma inkommande adress utan att bryta autentiseringskedjan är e-postalias ofta ett bättre val, eftersom ett alias levererar direkt till en riktig brevlåda i stället för att skicka vidare ett redan mottaget meddelande.