Defaults.Exposed › Åtgärder › Guides
Gmail "550-5.7.1 Message Blocked" — Avkoda studsen och åtgärda den (2026)
Publicerad 2026-07-08
Siffror från 2026-06-29 · metodik v7. Aggregerade censusdata över 261 miljoner graderade domäner. Se hur vi graderar.
Gmail returnerar 550-5.7.1 när det blockerar ett meddelande av policyskäl snarare än en saknad post: en sändande eller mottagande domäns policy, en IPv6-anslutning utan omvänd DNS, eller misstänkt skräppost. Av de 12,145,313 domänerna som auktoriserar Googles egna servrar i SPF tillämpar bara 18.5% DMARC, enligt Defaults.Exposed-censuset med 261 miljoner domäner.
550-5.7.1 är Gmails äldsta generella avvisning, och fixen beror på meningen efter koden i din studs. Nedan: en avkodningstabell för den exakta formuleringen, sedan fixvägen per variant — policyavvisningar, IPv6-servrar utan omvänd DNS, skräppost eller innehållsblock — plus de liknande koder folk förväxlar den med, inklusive 5.7.26-familjen som Google nu använder för DMARC-policyavvisningen som äldre referenser placerade under 5.7.1.
Vad betyder Gmails 550-5.7.1 egentligen?
I SMTP:s utökade statuskodschema (RFC 3463) betyder varje 5.7.x-kod “permanent misslyckande, policyskäl”. Gmail använder 550-5.7.1 som sin äldre policy-familj: avsändar- eller mottagarpolicyblock, skräppost-ryktes-block, och — varianten som överraskar de flesta administratörer — e-post som anländer via IPv6 från en server utan omvänd DNS (PTR)-post.
Google har omdefinerat varianter med tiden. DMARC-policyavvisningen (“not accepted due to domain’s DMARC policy”) ligger nu under 550-5.7.26 i Googles aktuella referens, men äldre studsmeddelanden i cirkulation kan fortfarande visa det som 5.7.1; innehållssäkerhetsblocket är nu kodat 552 5.7.0. Två andra syskon förväxlas med 5.7.1: 550-5.7.26, autentiseringskravs-familjen (sin egna guide), och 550-5.7.25, saknad PTR-koden på alla IP-versioner. Vad koden är, avkoda texten nedan.
Vilken 550-5.7.1-variant har du?
Matcha formuleringen i ditt icke-leveransrapport (NDR). Google justerar dessa strängar mellan år — matcha innebörden, inte interpunktionen.
| Din studs lyder ungefär… | Vad det betyder | Din fixväg |
|---|---|---|
| ”This message does not meet IPv6 sending guidelines regarding PTR records and authentication.” | Din server levererade via IPv6 utan (eller icke-matchande) omvänd DNS | PTR-post för IPv6-adressen, eller vidarebefordra via din leverantörs smarthost (nedan) |
| “The user or domain that you are sending to (or from) has a policy that prohibited the email that you sent.” | Policyblock — mottagarens, eller din egna domäns | Kontakta den mottagande administratören; om din egna domäns DMARC är den aktiva policyn, se nedan |
| ”This message is likely unsolicited email. To reduce the amount of spam sent to Gmail, this message has been blocked.” | Skräppost/ryktes-block på ditt innehåll, IP eller domän | Postmaster Tools + listhygien + ettpklicksavprenumeration (nedan) |
| “This message is likely suspicious due to the very low reputation of the sending domain” (eller “…sending IP address”) | Ryktes-block — domän eller IP | Samma ryktes-väg (nedan) |
| “Unauthenticated email from yourdomain is not accepted due to domain’s DMARC policy.” — kodad 550-5.7.26 i Googles aktuella referens; äldre studsmeddelanden kan fortfarande visa 5.7.1 | Din egna DMARC-policy bad Gmail att avvisa ett oautentiserat meddelande | Hitta den oautentiserade källan — luckra inte upp policyn först (nedan) |
| “…blocked because its content presents a potential security issue.” — nu kodad 552 5.7.0 | Innehålls-/policyblock (bilagetyp, länkrykte) | Ta bort den flaggade innehållsklassen; kontrollera länkar och bilagor |
| Kod är 550-5.7.25, “the sending IP address doesn’t have a PTR record” | Saknad omvänd DNS på vilken IP-version som helst | Samma rDNS-fix som IPv6-varianten |
| Kod är 550-5.7.26 | Autentiseringskravs-familj, inte 5.7.1 | Se 550-5.7.26-guiden |
| Kod är 421-4.7.0, “Try again later, closing connection.” | Tillfällig uppskov — hastighet eller rykte, inte ett permanent block | Sakta ner, åtgärda autentisering och skräppostfrekvens; det rensas vanligtvis |
Hur åtgärdar du ett 550-5.7.1-studsmeddelande?
- Kör den kostnadsfria sökningen på defaults.exposed — den betygsätter din SPF, DKIM och DMARC som världen ser dem, innan du rör DNS, och visar om DMARC-varianten ens är möjlig för din domän.
- Läs den fullständiga NDR-texten mot avkodningstabellen — meningen, inte koden, identifierar orsaken.
- DMARC-variant: hitta vilken sändande källa som misslyckades med autentisering och åtgärda den källan (nästa avsnitt).
- IPv6/PTR-variant: lägg till matchande omvänd DNS för serverns IPv6-adress, eller vidarebefordra via din leverantörs smarthost.
- Skräppost/policy-variant: Postmaster Tools, skräppostfrekvens under 0,10% (Googles hårda kravtak är 0,30%), listhygien, RFC 8058 ettpklicksavprenumeration.
- Skicka om ett test till en Gmail-postlåda och scanna igen — bekräfta att studsen är borta och att betyget återspeglar det.
Studsen nämner din DMARC-policy — varför det är din policy som fungerar
Googles aktuella referens kodar den här strängen som 550-5.7.26, men äldre studsmeddelanden och tredjepartsdokumentationer visar det fortfarande under 5.7.1 — hur som helst är mekaniken identisk. Det läses bakvänt tills du ser det: Gmail kontrollerade ett meddelande som påstod sig vara från din domän, fann att varken SPF eller DKIM godkändes med anpassning, slog upp din DMARC-post och gjorde exakt vad du bad om — avvisa. Din stängsel höll. Frågan är vad som fastnade i det: en bortglömd legitim avsändare (ett CRM, ett faktureringsverktyg, en nyhetsbrevplattform) eller ett faktiskt förfalskning.
Luckra därför inte upp policyn som steg ett. Hitta den oautentiserade källan. Två fällor förklarar de flesta fall:
- SPF godkänns, men på fel domän. Mottagare utvärderar SPF mot Return-Path (RFC5321.MailFrom)-domänen, inte From-rubriken. Ett SaaS-verktyg som skickar “från” dig godkänns vanligtvis med SPF på sin egna studsdomän, som inte anpassas till din From-domän — så DMARC misslyckas fortfarande. Genomgång: DMARC misslyckas men SPF och DKIM godkänns.
- DKIM godkänns, men med standardsignaturen. Google Workspaces
gappssmtp.com- och Microsoftsonmicrosoft.com-standarder verifieras fine och anpassas till ingenting. Se DKIM godkänns men DMARC misslyckas fortfarande.
Den här varianten är sällsyntare än du tror: 27,640,987 av 261,086,232 domäner — 10.59% — tillämpar en DMARC-policy av quarantine eller reject, enligt Defaults.Exposed-censuset (2026-06-29). De andra 89.41% ser aldrig den här studsen eftersom de inte har något stängsel att hålla. Att åtgärda källan, inte policyn, täcks end-to-end i DMARC-fixguiden.
Studsen nämner IPv6-sändningsriktlinjer — omvänd DNS-fixen
Moderna servrar ansluter ofta till Gmail via IPv6 som standard, och Google kräver att den anslutande IPv6-adressen har en PTR-post som löser sig till ett värdnamn som löser sig tillbaka till samma adress (forward-confirmed omvänd DNS). Miss det, och varje meddelande får 550-5.7.1 oavsett hur ren din SPF är.
Tre fixar, i preferensordning:
- Sätt PTR-posten för din servers IPv6-adress — gjort där IP:n bor (din VPS-värd eller ISP-kontrollpanel, inte din domäns DNS-zon), med en matchande AAAA-post som pekar tillbaka.
- Vidarebefordra via din leverantörs smarthost. Om du inte kan kontrollera rDNS, dirigera utgående e-post via din e-postleverantörs eller ISP:s relä, som redan har korrekt rDNS.
- Föredra IPv4-transport som ett stopgap. Det döljer vanligtvis symptomet eftersom din IPv4-adress har en PTR — en lösning, inte en fix. Sätt IPv6-PTR när du kan.
Studsen säger “likely unsolicited email” — ryktes-vägen
Här kan autentisering vara fine, men Gmails filter litar inte på e-posten. Autentisering är golvet, inte taket — bland de 12,145,313 domänerna som auktoriserar _spf.google.com, låser bara 8.0% ner SPF med en strikt -all, så ett godkänt kontroll säger lite på egen hand. (Fullständig jämförelse: vilken e-postleverantör ger de starkaste SPF-standarderna.)
Ryktes-checklistan:
- Registrera dig i Google Postmaster Tools och titta på skräppostfrekvens-instrumentpanelen — håll den under 0,10%, och låt den aldrig nå taket på 0,30% som Googles bulk-avsändarriktlinjer sätter som ett hårt krav.
- Rensa din lista. Droppa icke-engagerade och allt köpt eller skrapat; skicka bara till folk som bad om det.
- Implementera RFC 8058 ettpklicksavprenumeration på bulk-e-post — krävs av Googles regler, och varje avprenumeration som inte är ett “skräppost”-klick skyddar din frekvens.
- Håll autentisering anpassad (SPF och DKIM på din egna domän) så att rykte ackumuleras till en domän du kontrollerar.
Vanliga frågor
Är 550-5.7.1 detsamma som 550-5.7.26? Nej. 550-5.7.26 är Gmails autentiseringskravs-familj (SPF/DKIM saknas eller misslyckas) — och Googles aktuella referens placerar även DMARC-policyavvisningen där. 550-5.7.1 är den äldre policy-familjen: mottagare- och avsändare-policyblock, IPv6-utan-PTR, skräppost och ryktes-block. Studstexten, inte numret, talar om vilken fix som gäller (per 2026-06-29 och aktuella Google-riktlinjer).
Ska jag ställa tillbaka min DMARC-policy till p=none för att stoppa studsarna? Det stoppar dem genom att riva ner stängslet. Bara 10.59% av de 261,086,232 domänerna i Defaults.Exposed-censuset (2026-06-29) tillämpar DMARC överhuvudtaget; om du är en av dem, behåll det och åtgärda den oautentiserade källan — att luckra upp policyn öppnar exakt-domän-spoofing igen.
Varför blockerar Gmail min e-post när min SPF-post godkänns på varje kontrollant? Kontrollanter testar posten; Gmail testar meddelandet. SPF utvärderas mot Return-Path-domänen, inte den synliga From-adressen, så ett godkännande på en leverantörs studsdomän gör ingenting för din DMARC-anpassning — och ryktes-block ignorerar SPF helt. Den kostnadsfria sökningen visar vilket lager som faktiskt misslyckas.
Betyder 550-5.7.1 att min IP är på en blocklista? Inte nödvändigtvis. Gmail kör sitt egna ryktessystem; du kan vara blockerad av Google medan du inte finns på någon offentlig blocklista. Kontrollera Postmaster Tools för Googles vy — och notera att att åtgärda autentisering förhindrar framtida skada men inte i sig återställer ett dåligt sändningsrykte.
Skicka ägaren rapporten
När studsen är åtgärdad, kör om sökningen och vidarebefordra den graderade rapporten till företagsägaren eller kunden vars e-post studsade. Den visar, på klarspråk, vad som var trasigt, vad du åtgärdade och var domänen nu står mot 261-miljoners-domänbaslinjen — exakt vad de behöver för försäkringsförnyelsen eller klientens säkerhetsenkät som frågar “autentiserar du din e-post?”. En tyst åtgärdad studs är osynligt arbete; en före-och-efter-rapport är bevis.
Kontrollera din domän → · Gmail 550-5.7.26 — fixen i kravordning → · Åtgärda DMARC → · Hur vi graderar → · Enbart aggregerade data. Data lagras och behandlas inom EU.