Gmail afviser dine mails: hvad 550 5.7.26 og de andre fejlkoder betyder, og hvordan du retter dem

Hvorfor Gmail afviser flere mails end før

Siden 1. februar 2024 har Google krævet, at alle, der sender til private Gmail-konti, godkender deres mail med SPF eller DKIM, har gyldig DNS og omvendt DNS for den sendende IP-adresse, bruger TLS, følger standarden for mailformatet (RFC 5322) og holder den rapporterede spamrate under 0,3 %. Massesendere skal mere: SPF og DKIM, en DMARC-post (p=none er nok), et afsenderdomæne i From:-feltet der er alignet med SPF eller DKIM, og afmelding med ét klik i markedsføringsmails. Google regner dig som massesender, når du har sendt tæt på 5.000 beskeder på 24 timer til private Gmail-konti, og al mail fra samme primære domæne tæller med, også fra underdomæner. Er du først massesender, forbliver du det.

I en periode endte mail, der brød reglerne, mest i spamfilteret. Googles FAQ for afsendere siger, at Gmail fra november 2025 gradvist skærper håndhævelsen over for mail, der ikke lever op til kravene, med både midlertidige og permanente afvisninger. Google oplyser ingen præcis dato, og stramningen sker gradvist, så et domæne, der fungerede fint sidste måned, kan begynde at få afvisninger i denne måned.

Reglerne gælder mail til private Gmail-konti (gmail.com og googlemail.com). De gælder ikke mail til Google Workspace-konti. Det fritager ikke afsendere på Microsoft 365 eller Workspace: sender din virksomhed til private Gmail-adresser, gælder reglerne for jer.

Sådan læser du afvisningen

En afvisning fra Gmail har to tal foran teksten. Det første er SMTP-svarkoden på tre cifre: 421 og 451 betyder "prøv igen senere", 550 betyder "nej". Det andet er den udvidede statuskode, for eksempel 5.7.26. En kode, der starter med 4, er midlertidig: Gmail begrænser modtagelsen, og din server prøver igen. En kode, der starter med 5, er permanent: beskeden er afvist, og afsenderen får en fejlmeddelelse retur.

De midlertidige koder fortjener lige så meget opmærksomhed som de permanente. En 4.7.x-kode er Gmails varsel om en 5.7.x-kode, hvis intet ændres. De fleste godkendelseskoder findes i par, en midlertidig og en permanent, med samme årsag og samme løsning.

Teksten i afvisningen nævner som regel det domæne og den IP-adresse, der fejlede. Notér begge. De er den hurtigste vej til synderen.

550 5.7.26: tre forskellige beskeder, tre årsager

5.7.26 er den kode, folk søger mest på, og den dækker over tre forskellige problemer. Læs teksten efter koden for at se, hvilket du har.

Den første siger, at afsenderen ikke er godkendt: hverken SPF eller DKIM bestod. Det er grundkravet til alle afsendere, store som små. Tjenesten, der sendte beskeden, står ikke i din SPF-post og signerer ikke med DKIM for dit domæne. Løsningen er at godkende tjenesten: slå DKIM-signering med dit eget domæne til i tjenestens indstillinger (den giver dig en eller flere DNS-poster, du skal oprette), og tilføj dens SPF-include, hvis den sender med dit domæne som konvolutafsender. Den midlertidige udgave er 4.7.26 med samme ordlyd om manglende godkendelse.

Den anden siger, at MAIL FROM-domænet har en SPF-post med hård afvisning (-all), og at den sendende IP-adresse ikke står i den. Her adlyder Gmail blot din egen post. Enten tilhører IP-adressen en tjeneste, I bruger, og som er glemt, eller også sender noget med jeres konvolutdomæne, som ikke burde. Sammenlign IP-adressen i afvisningen med din SPF-post. Er tjenesten legitim, så tilføj den. At ændre -all til ~all skjuler symptomet; at tilføje afsenderen løser problemet.

Den tredje siger, at mailen ikke modtages på grund af domænets DMARC-politik. Den er anderledes: beskeden fejlede DMARC, og domæneejeren har bedt modtagerne om at afvise den slags mail. Er domænet dit, og var mailen ægte, har du en legitim afsender, der ikke er alignet (se afsnittet om alignment nedenfor). Var mailen ikke jeres, gør DMARC præcis sit arbejde: nogen forsøgte at sende som jeres domæne, og Gmail afviste dem. Her findes også en midlertidig tvilling: 4.7.26, hvor DMARC-politikken gælder, men en midlertidig DNS-fejl forhindrede godkendelsen. Den peger på jeres DNS: tjek at navneserverne svarer stabilt, og at signaturerne er gyldige, hvis I bruger DNSSEC.

5.7.27 og 4.7.27: SPF bestod ikke

Disse koder siger, at beskeden fejlede SPF, og at Gmail kræver SPF af massesendere. Årsagerne er de sædvanlige. En ny tjeneste står ikke i posten. Posten har mere end 10 DNS-opslag, så hele tjekket fejler, selv når afsenderen står der. Der er to SPF-poster på samme domæne, hvilket er ugyldigt. Eller tjenesten sender med sit eget konvolutdomæne, så jeres post slet ikke bliver tjekket.

Kør dit domæne gennem den gratis SPF Surveyor på monitordmarc.eu/tools/spf-surveyor. Den tegner include-træet og tæller opslagene, så du med det samme kan se, om en tjeneste mangler, eller om posten er vokset over grænsen. Er du over 10, så fjern først includes for tjenester, I ikke bruger længere, før du overvejer at "flade" posten ud.

5.7.30 og 4.7.30: DKIM bestod ikke

Disse siger, at beskeden fejlede DKIM. Enten signerer tjenesten slet ikke, den signerer med en nøgle, hvis offentlige del ikke er oprettet i jeres DNS, eller den oprettede nøgle passer ikke længere efter et nøgleskift. Google kræver DKIM-nøgler på mindst 1024 bit og anbefaler 2048.

Find selektoren i DKIM-Signature-headeren i en testmail (værdien s=) og slå den op med den gratis DKIM Inspector på monitordmarc.eu/tools/dkim-inspector. Er der intet oprettet på den selektor, er tjenestens DNS-poster aldrig blevet tilføjet, eller de er tilføjet under et forkert navn. Bruger I Microsoft 365, skal DKIM for jeres eget domæne slås til i Defender-portalen, og det kræver to CNAME-poster (selector1 og selector2); indtil da bliver mail fra jeres eget domæne ikke signeret med jeres domæne.

4.7.32 og 5.7.32: From: er ikke alignet

Disse siger, at From:-adressen ikke er alignet med det domæne, der bestod SPF eller DKIM. Alignment er kernen i DMARC. Det er ikke nok, at SPF bestod for et eller andet domæne; det skal bestå for domænet i From:-feltet, som modtageren ser, eller for dets overordnede organisationsdomæne.

Det klassiske eksempel: jeres nyhedsbrevsværktøj sender fra nyhed@jeresbutik.dk, SPF består for værktøjets eget returdomæne, og DKIM er signeret med værktøjets domæne. Alt består, intet er alignet. Løsningen er værktøjets indstilling for "eget domæne" eller "domæneverificering", som får det til at signere DKIM med jeres domæne og helst også bruge en returadresse på jeres domæne. Alignet DKIM er den mest robuste af de to, fordi den overlever videresendelse, og det gør SPF ikke. Google kræver i dag én alignet metode af massesendere, anbefaler begge og skriver, at begge sandsynligvis bliver et krav på sigt.

Googles tabel angiver 5.7.32 med svarkoden 421 i stedet for 550. Behandl den som samme problem som 4.7.32, og ret den på samme måde.

4.7.31: ingen DMARC-post

Denne kode står i Googles FAQ for afsendere: den betyder, at det sendende domæne ikke har en DMARC-post, eller at posten ikke har en politik. For massesendere er en DMARC-post et krav, og en overvågningspolitik med p=none er nok til at opfylde det.

En minimal post er en TXT-post på _dmarc.ditdomæne med v=DMARC1; p=none; og en rua-adresse, som modtagerne sender deres rapporter til. Den gratis DMARC Wizard på monitordmarc.eu/tools/dmarc-wizard bygger en til dig, og DMARC Inspector på monitordmarc.eu/tools/dmarc-inspector tjekker det, du har oprettet, tag for tag. Bliv ikke på p=none for evigt, men spring heller ikke for hurtigt videre: rapporterne er netop det, der viser dig de afsendere, du har glemt.

Koderne, der ikke handler om godkendelse

4.7.23 og 5.7.25 betyder, at den sendende IP-adresse ikke har en PTR-post (omvendt DNS), eller at PTR-navnet ikke peger tilbage på samme IP. Det sættes af den, der ejer IP-adressen: jeres hostingfirma, internetudbyder eller mailudbyder. Kører I jeres egen mailserver, så bed dem sætte den; bruger I en stor udbyder, er det næsten aldrig årsagen.

4.7.29 og 5.7.29 betyder, at beskeden ikke blev sendt over TLS. Moderne udbydere gør det som standard. Det rammer mest gamle servere, printere og scannere, der sender mail direkte, og hjemmelavede scripts.

4.7.24 og 5.7.24 siger, at SPF-posten har et eller flere "mistænkelige" elementer. Google definerer ikke, hvad der tæller som mistænkeligt. Det betaler sig at gennemgå posten for syntaksfejl, mekanismer ingen kan forklare og meget brede IP-intervaller, og at fjerne alt, der ikke er brug for.

4.7.28 og 5.7.28 handler om hastighed: Gmail har set en usædvanlig mængde mail fra jeres IP-adresse. Googles råd ved 4.7.28 er konkret: stop med at sende i mindst 10 minutter, genoptag på én forbindelse, og tilføj forbindelser én ad gangen. Google advarer også mod pludselige spring og nævner, at selv en fordobling af mængden kan udløse begrænsninger. Godt at vide før Black Friday: skru op for kampagnemængden over flere dage, ikke i én udsendelse.

Sådan finder du afsenderen, der fejler

Start med afvisningen. Den nævner IP-adressen og som regel domænet. Slå op, hvem der ejer IP-adressen (et omvendt DNS-opslag eller WHOIS nævner som regel udbyderen), og så har du ofte svaret på et minut: fakturasystemet, webshopplatformen, et CRM, et helpdeskværktøj, en scanner på kontoret.

Kommer afvisningerne retur til en anden, så bed om den fulde tekst, eller send en test fra det mistænkte system til en privat Gmail-adresse. I Gmail viser "Vis original" på beskeden, om SPF, DKIM og DMARC bestod, og headeren Authentication-Results viser, hvilket domæne hver af dem blev tjekket mod. Så ved du ikke kun, hvad der fejlede, men også for hvilket domæne, og det er det, du skal bruge for at rette alignment.

Det fulde billede får du fra jeres DMARC-rapporter (aggregate reports). Store mailudbydere, også Gmail, sender som regel én om dagen til rua-adressen i jeres DMARC-post, med hver IP-adresse, der har sendt mail som jeres domæne, og om den bestod. En glemt afsender dukker op der flere dage før den første afvisning når frem til dig. Det gratis værktøj XML-to-Human på monitordmarc.eu/tools/xml-to-human gør en rapportfil til en læsbar tabel med navnene på de sendende kilder.

En kort rækkefølge før travlheden

Først: sørg for at kende alle tjenester, der sender som jeres domæne: mailplatform, nyhedsbrevsværktøj, webshop, fakturering, CRM, helpdesk. Dernæst: slå DKIM med jeres eget domæne til i hver af dem. Tjek så, at SPF indeholder dem, der bruger jeres konvolutdomæne, og holder sig under 10 opslag. Opret en DMARC-post med en rua-adresse, hvis I ikke har en, og start på p=none. Læs rapporterne i et par uger, ret det, der dukker op, og bevæg jer derefter mod quarantine og reject. Hold til sidst øje med Google Postmaster Tools, der viser jeres domænes spamrate og har et overblik over, om I lever op til afsenderkravene.

Det svære er ikke den første rettelse. Det er at opdage, når noget ændrer sig: en kollega tager et nyt værktøj i brug, en udbyder skifter nøgle, nogen redigerer SPF-posten og skubber den op på 11 opslag. MonitorBase tjekker jeres domæner hver dag, giver besked, når SPF, DKIM eller DMARC ændrer sig eller begynder at fejle, og læser jeres DMARC-rapporter for jer, fra 16 €/måned ekskl. moms på Basic-planen. Tjenesten drives fra Danmark, alle data gemmes og behandles i Paris, og der er ingen amerikanske underdatabehandlere.

Tjek dit domæne nu

Kør det gratis domænetjek på monitordmarc.eu. Det tjekker SPF, DKIM, DMARC, MX, sortlister og mere i ét hug og fortæller, hvad du skal rette. Ingen konto, ingen e-mailadresse.

Kilder

Google, Email sender guidelines FAQ, support.google.com/mail/answer/14229414 (set 20. oktober 2026): skærpet håndhævelse fra november 2025, definitionen af massesender, hvem reglerne gælder for, alignment, koden 4.7.31 og overblikket over afsenderkrav i Postmaster Tools.

Google, Gmail SMTP errors and codes, support.google.com/mail/answer/3726730 (set 20. oktober 2026): ordlyden af alle koder i denne guide, herunder de tre varianter af 5.7.26 og svarkoden 421 ved 5.7.32.

Google, Email sender guidelines, support.google.com/mail/answer/81126 (set 20. oktober 2026): krav til alle afsendere siden 1. februar 2024, krav til massesendere, DKIM-nøglelængde og rådene om hastighedsbegrænsning.

Microsoft Learn, Set up DKIM to sign mail from your Microsoft 365 domain, learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure (opdateret 3. juli 2026, set 20. oktober 2026).

Gratis værktøjer, der hjælper

• SPF Surveyor: Visualisér hele SPF-include-træet og tæl DNS-opslag mod grænsen på 10.
• DKIM Inspector: Find publicerede DKIM-nøgler på tværs af almindelige selectors og analysér nøglestyrke.