Hvorfor den mail, du videresendte til dig selv, landede i spam — redaktionel illustration

read receipts

Hvorfor den mail, du videresendte til dig selv, landede i spam

Du gjorde ikke noget forkert. SPF gjorde. Her er mekanikken, som ingen hos din udbyder vil forklare.

·3 min. læsning

Opsæt en automatisk videresendelse fra din gamle konto til din nye, og noget af mailen forsvinder stille og roligt ind i spam — ikke fordi din udbyder er ødelagt, men fordi videresendelse omskriver hvem der sender beskeden uden at omskrive det kryptografiske bevis. SPF tjekker den forkerte server, DMARC-verdikten bliver til fejl, og en legitim mail, som du sendte til dig selv, bliver sat i karantæne. Rettelsen har et navn: ARC, defineret i RFC 8617 tilbage i 2019.

Hvorfor får videresendelse min mail til at fejle SPF?

Fordi SPF tjekker den sidste server, som relayede beskeden, og videresendelse ændrer den server. SPF — Sender Policy Framework — er en DNS-post, som viser hvilke IP-adresser der må sende mail for et domæne. Når bank.com sender dig en kvittering, tjekker den modtagende server: kom dette fra en IP-adresse, som bank.com autoriserede? Ja. Bestået.

Nu videresender du denne kvittering fra Gmail til din nye adresse. Googles servere relayer den videre. Den endelige modtagende server kører SPF-checket og spørger: er Google autoriseret til at sende for bank.com? Nej, det er det ikke. SPF fejler. Googles egen Workspace-dokumentation forklarer dette klart — videresendt mail fejler SPF, fordi videresendelsesserveren ikke er i det oprindelige domænes SPF-post. Intet blev forfalsket. Checket ser bare på det forkerte hop.

Så hvorfor sender det det til spam?

DMARC. SPF at fejle alene plejer at være overkommeligt; DMARC gjorde det til en vurdering. DMARC bindes SPF og DKIM sammen og fortæller modtagerne hvad de skal gøre når begge fejler: intet, sæt i karantæne, eller afvis. I 2024 havde store afsendere ikke valget — Google og Yahoo begyndte at kræve DMARC fra alle der sender mere end 5.000 mails dagligt til deres brugere.

DKIM, den anden søjle, er en signatur bagt ind i beskeden. I teorien overlever den videresendelse, fordi den signerer indholdet, ikke ruten. I praksis bryder alt der rører ved beskeden den. En mailingliste som tilføjer en "du er tilmeldt, afmeld her"-sigtekrop, en server som omskriver emnelinja, selv en ændring i hvordan en linje bryder — signaturen matcher ikke længere, og DKIM fejler også. Nu er begge søjler nede, DMARC siger fejl, og din egen kvittering er i junk-mappen.

Hvad er ARC og fikser det faktisk dette?

ARC — Authenticated Received Chain, RFC 8617 — lader en ærlig videresender garantere for at mailen bestod autentificering før den rørt den. Videresendelsesserveren stemplet beskeden med en forseglet post som siger "da dette nåede mig, var SPF og DKIM valide — stol på mit ord for det ben du ikke kan verificere." Den endelige modtager, hvis den stoler på den videresender, kan tilsidesætte DMARC-fejlen og levere.

Fangen ligger i "hvis den stoler på". ARC er ikke et kodeord; det er et ry-system. En modtager vejer om ARC-segleren er en kendt, velfungerende operatør. Google stemplet både ARC-headere og respekterer dem fra afsendere som det stoler på, hvilket er hvorfor en Gmail-til-Gmail-videresendelse sædvanligvis overlever mens en videresendelse gennem et antikt universitets-relay ikke gør.

Hvis du selv kører videresendelsen, hjælper to konkrete skridt. Brug Server-Side Redirect / SRS-lignende omskrivning hvis din host tilbyder det, som omskriver envelope-afsenderen så SPF-checker mod din videresender i stedet for det oprindelige domæne. Og foretrækker videresendelse mellem udbydere som begge understøtter ARC. Hvis du konsoliderer konti og ønsker at bestemmelsesstedet bare håndterer autentificeringskaoset for dig, er det præcis den slags rørarbejde en AI-email-platform er bygget til at absorbere.

Hvornår skal jeg stoppe med at give min udbyder skylden?

Når mønsteret er "kun videresendt mail fejler," gør udbyderen sit job korrekt — protokollen er problemet. Her er tegnet: åbn headerne på den manglende besked og se efter Authentication-Results-linjen. Hvis du ser spf=fail sammen med en afsender-IP som tilhører en videresender snarere end den oprindelige afsender, ser SPF på det forkerte hop. Hvis dkim=fail dukker op på mail som gik gennem en liste eller relay som redigerer beskeder, det er en ødelagt signatur, ikke en forfalskning.

Den ubehagelige sandhed er at email-autentificering blev boltet på, lag efter lag, over to årtier på et system som aldrig antog at nogen ville lyve. SPF kom i 2006, DKIM i 2007, DMARC i 2015, ARC i 2019 — hver en patche et hul som den forrige åbnede. Videresendelse er sømmmen hvor alle fire gnider mod hinanden, og dit indbakke er hvor du mærker gnidningen.

daily messages that trigger Google & Yahoo's DMARC requirement (2024)

Kilder

  1. IETF RFC 8617 — Authenticated Received Chain (ARC) specification, 2019
  2. Google Workspace Admin Help — SPF, forwarding and authentication for forwarded mail
  3. Google Email sender guidelines — 2024 bulk sender DMARC requirements and 5,000/day threshold

← Alle artikler