Fejl 550 5.7.26 fra Gmail – sådan løser du den

Du sender en helt almindelig mail til en kunde med en Gmail-adresse, og få sekunder efter ligger der en returmail i din indbakke. Måske er det ikke engang dig selv, der sender – det kan være kontaktformularen på hjemmesiden, webshoppens ordrebekræftelser eller nyhedsbrevet, der pludselig ikke kommer frem. I returmailen står der noget i stil med:

550-5.7.26 This mail has been blocked because the sender is unauthenticated.
550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.

Eller i en lidt anden udgave:

550 5.7.26 Unauthenticated email from firma.dk is not accepted due to domain's DMARC policy.

Begge betyder det samme: Gmail kan ikke se, at mailen faktisk kommer fra en server, der har lov til at sende på vegne af dit domæne.

Hvorfor sker det?

Siden februar 2024 kræver Google, at alle afsendere til Gmail-adresser autentificerer deres mails med enten SPF eller DKIM. Sender du mere end 5.000 mails om dagen til Gmail, skal du desuden have DMARC, og afsenderdomænet i Fra-feltet skal matche det domæne, der er godkendt med SPF eller DKIM.

I praksis ser vi især fejlen hos små virksomheder i disse situationer:

Et eksternt system sender som jeres domæne. Hjemmesiden, webshoppen, bookingsystemet eller CRM'et sender mails fra fx info@firma.dk, men systemets server står ikke i jeres SPF-post, og der er ingen DKIM-signatur.
SPF-posten er forkert. Der er to SPF-poster på domænet, en tastefejl, eller posten kræver mere end 10 DNS-opslag. Så fejler SPF helt.
DKIM er aldrig slået til. Mange starter med Microsoft 365 eller et webhotel uden at aktivere DKIM.
Domænet har DMARC med p=quarantine eller p=reject, og en afsender, der ikke er sat korrekt op, bliver derfor afvist i stedet for bare at havne i spam.

Fejlen ligger altså næsten altid hos afsenderens domæne – ikke hos modtageren.

Sådan løser du det

Trin 1: Find ud af, hvem der sender

Kig i returmailen. Den indeholder ofte den oprindelige mails header, hvor du kan se, hvilken server der har forsøgt at levere den (linjerne der starter med Received:). Kom fejlen fra en mail, du selv har skrevet i Outlook, er det jeres mailsystem. Kom den fra en ordrebekræftelse eller en formular, er det det system.

Har du selv en Gmail-adresse, kan du sende en testmail dertil fra det system, der driller. Åbn mailen i Gmail i en browser, klik på de tre prikker øverst til højre i mailen og vælg Vis original. Øverst står resultatet for SPF, DKIM og DMARC som PASS eller FAIL. Det fortæller dig præcist, hvad der mangler.

Trin 2: Tjek jeres SPF-post

Åbn PowerShell og slå jeres domæne op:

Resolve-DnsName firma.dk -Type TXT | Where-Object { $_.Strings -like "v=spf1*" }

Kontrollér at:

Der kun er én post, der starter med v=spf1. To SPF-poster gør begge ugyldige.
Alle systemer, der sender som jeres domæne, er med. Bruger I Microsoft 365, skal include:spf.protection.outlook.com være med. Eksterne systemer oplyser selv, hvilken include: de skal have – find det i deres hjælp eller kontrolpanel.
Posten slutter med -all eller ~all.

Et eksempel på en korrekt post for en virksomhed, der bruger Microsoft 365 og et nyhedsbrevssystem, kunne se sådan ud (det sidste include er kun et eksempel):

v=spf1 include:spf.protection.outlook.com include:_spf.nyhedsbrevssystem.dk -all

Ændringen laves hos den, der har jeres DNS – typisk webhotellet eller domæneudbyderen.

Trin 3: Slå DKIM til

SPF alene er skrøbeligt, fordi det fejler, når mails videresendes. DKIM er en digital signatur, som følger mailen hele vejen. Slå det til i jeres mailsystem, og gør det samme i de eksterne systemer, der sender som jeres domæne – de fleste nyhedsbrevs- og webshopsystemer kan signere med jeres eget domæne, når I lægger et par CNAME-poster i DNS.

Bruger I Microsoft 365, aktiverer du DKIM i Defender-portalen under Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM. Driller det, har vi skrevet om det i Når selector2 i Microsoft 365 DKIM driller.

Trin 4: Tjek jeres DMARC-politik

Resolve-DnsName _dmarc.firma.dk -Type TXT

Står der p=reject eller p=quarantine, skal alle jeres afsendere bestå SPF eller DKIM med jeres eget domæne, ellers afvises de med 5.7.26. Løsningen er at rette afsenderen (trin 2 og 3) – ikke at slække på DMARC. Har I slet ingen DMARC-post, så se vores guide Sådan opsætter du SPF, DKIM og DMARC korrekt.

Trin 5: Test igen

DNS-ændringer kan tage fra få minutter til et par timer om at slå igennem. Send derefter en ny testmail til en Gmail-adresse og tjek Vis original igen. Når der står PASS ved SPF eller DKIM (og ved DMARC, hvis I har det), er problemet løst.

Mails, der allerede er afvist, bliver ikke sendt igen af sig selv. De skal sendes på ny.

Problemer?

SPF fejler stadig med "permerror": Posten har for mange DNS-opslag (over 10). Fjern include: for systemer, I ikke længere bruger, og undgå mekanismerne a, mx og ptr, hvis de ikke er nødvendige.
Kontaktformularen på hjemmesiden fejler: Mange formularer sender med PHP's indbyggede mailfunktion direkte fra webserveren. Sæt i stedet formularen til at sende via SMTP med en rigtig postkasse, så mailen går gennem jeres mailsystem.
Kun nogle mails afvises: Typisk er det én bestemt afsender – fx en printer eller et system, der sender via en anden server. Find den i trin 1.
Lignende fejlkoder: Gmail bruger også 5.7.27 (SPF fejlede), 5.7.30 (DKIM fejlede), 5.7.32 (Fra-adressen matcher ikke det godkendte domæne) og 5.7.25 (afsenderserveren mangler en PTR-post). Starter koden med 4 i stedet for 5, er mailen ikke afvist, men forsinket – årsagen og løsningen er den samme.

Kort sagt

Fejlen 550 5.7.26 betyder, at Gmail ikke kan bekræfte, at afsenderen har lov til at sende på vegne af jeres domæne. Find ud af, hvilket system der sender, sørg for at det står i jeres SPF-post, og slå DKIM til overalt, hvor det er muligt. Så kommer mailene frem igen.

Vil du have nogen til at gennemgå jeres domæne, hjælper Todo-IT gerne.