Defaults.Exposed › Oplossingen › Guides
Gmail "550-5.7.1 Message Blocked" — decodeer de bounce en los het op (2026)
Gepubliceerd 2026-07-08
Cijfers per 2026-06-29 · methodologie v7. Geaggregeerde censusgegevens over 261 miljoen beoordeelde domeinen. Zie hoe wij beoordelen.
Gmail geeft 550-5.7.1 terug wanneer het een bericht blokkeert om policyredenen in plaats van een ontbrekend record: een beleid van de verzendende of ontvangende domein, een IPv6-verbinding zonder reverse DNS, of vermoede spam. Van de 12.145.313 domeinen die Google’s eigen servers in SPF autoriseren, handhaaft slechts 18,5% DMARC, volgens de Defaults.Exposed-census van 261 miljoen domeinen.
550-5.7.1 is Gmail’s oudste catch-all-afwijzing, en de oplossing hangt af van de zin na de code in uw bounce. Hieronder: een decodertabel voor de exacte bewoording, gevolgd door het oplospad per variant — policyafwijzingen, IPv6-servers zonder reverse DNS, spam- of inhoudsblokkades — plus de gelijkende codes waarmee mensen hem verwarren, waaronder de 5.7.26-familie die Google nu gebruikt voor de DMARC-policyafwijzing die oudere naslagwerken onder 5.7.1 indeelden.
Wat betekent Gmail’s 550-5.7.1 eigenlijk?
In het SMTP-schema voor uitgebreide statuscodes (RFC 3463) betekent elke 5.7.x-code “permanente fout, policyredenen”. Gmail gebruikt 550-5.7.1 als zijn legacy-policyfamilie: afzender- of ontvangerpolicyblokkades, spamreputatieblokkades, en — de variant die de meeste beheerders verrast — mail die binnenkomt via IPv6 vanaf een server zonder reverse-DNS-record (PTR).
Google heeft varianten in de loop der tijd hercodeerd. De DMARC-policyafwijzing (“not accepted due to domain’s DMARC policy”) staat in Google’s huidige naslagwerk nu onder 550-5.7.26, hoewel oudere bounces in het wild nog steeds als 5.7.1 kunnen verschijnen; de blokkade voor inhoudsbeveiliging heeft nu code 552 5.7.0. Twee andere verwante codes worden verward met 5.7.1: 550-5.7.26, de authenticatievereisten-familie (eigen gids), en 550-5.7.25, de code voor ontbrekende PTR bij elke IP-versie. Wat de code ook is, decodeer eerst de tekst hieronder.
Welke variant van 550-5.7.1 hebt u?
Vergelijk de bewoording in uw non-delivery report (NDR). Google past deze teksten van jaar tot jaar aan — vergelijk de strekking, niet de interpunctie.
| Uw bounce lijkt op… | Wat het betekent | Uw oplospad |
|---|---|---|
| ”This message does not meet IPv6 sending guidelines regarding PTR records and authentication.” | Uw server leverde af via IPv6 zonder (of met niet-overeenkomende) reverse DNS | PTR-record voor het IPv6-adres, of relay via de smarthost van uw provider (hieronder) |
| “The user or domain that you are sending to (or from) has a policy that prohibited the email that you sent.” | Een policyblokkade — van de ontvanger, of van uw eigen domein | Neem contact op met de ontvangende beheerder; als het beleid van uw eigen DMARC in het spel is, zie hieronder |
| ”This message is likely unsolicited email. To reduce the amount of spam sent to Gmail, this message has been blocked.” | Spam-/reputatieblokkade op uw inhoud, IP of domein | Postmaster Tools + lijsthygiëne + uitschrijven met één klik (hieronder) |
| “This message is likely suspicious due to the very low reputation of the sending domain” (of “…sending IP address”) | Reputatieblokkade — domein of IP | Hetzelfde reputatiepad (hieronder) |
| “Unauthenticated email from yourdomain is not accepted due to domain’s DMARC policy.” — gecodeerd als 550-5.7.26 in Google’s huidige naslagwerk; oudere bounces tonen mogelijk nog 5.7.1 | Uw eigen DMARC-beleid vertelde Gmail een niet-geauthenticeerd bericht te weigeren | Zoek de niet-geauthenticeerde bron — verzwak het beleid niet als eerste stap (hieronder) |
| “…blocked because its content presents a potential security issue.” — nu gecodeerd als 552 5.7.0 | Inhouds-/policyblokkade (bijlagetype, linkreputatie) | Verwijder de gemarkeerde inhoudscategorie; controleer links en bijlagen |
| Code is 550-5.7.25, “the sending IP address doesn’t have a PTR record” | Ontbrekende reverse DNS bij elke IP-versie | Dezelfde rDNS-oplossing als de IPv6-variant |
| Code is 550-5.7.26 | Familie authenticatievereisten, niet 5.7.1 | Zie de gids 550-5.7.26 |
| Code is 421-4.7.0, “Try again later, closing connection.” | Tijdelijk uitstel — snelheid of reputatie, geen permanente blokkade | Vertraag, herstel authenticatie en spampercentage; het verdwijnt meestal vanzelf |
Hoe lost u een 550-5.7.1-bounce op?
- Voer de gratis scan uit op defaults.exposed — die beoordeelt uw SPF, DKIM en DMARC zoals de wereld ze ziet, voordat u aan DNS komt, en laat zien of de DMARC-variant voor uw domein überhaupt mogelijk is.
- Lees de volledige NDR-tekst tegen de decodertabel — de zin, niet de code, wijst de oorzaak aan.
- DMARC-variant: zoek uit welke verzendbron de authenticatie niet doorstond en herstel die bron (volgende sectie).
- IPv6/PTR-variant: voeg bijpassende reverse DNS toe voor het IPv6-adres van de server, of relay via de smarthost van uw provider.
- Spam-/policyvariant: Postmaster Tools, spampercentage onder 0,10% (Google’s harde vereiste plafond is 0,30%), lijsthygiëne, RFC 8058-uitschrijven-met-één-klik.
- Verstuur een testbericht naar een Gmail-postvak en scan opnieuw — bevestig dat de bounce weg is en het cijfer dat weerspiegelt.
De bounce noemt uw DMARC-beleid — waarom dat uw beleid is dat werkt
Google’s huidige naslagwerk codeert deze tekst als 550-5.7.26, maar oudere bounces en documentatie van derden tonen hem nog steeds onder 5.7.1 — de werking is in beide gevallen identiek. Het leest achterstevoren totdat u het doorheeft: Gmail controleerde een bericht dat beweerde van uw domein te komen, ontdekte dat noch SPF noch DKIM slaagde met alignment, zocht uw DMARC-record op en deed precies wat u vroeg — weigeren. Uw hek hield stand. De vraag is wat erin vastzat: een vergeten legitieme afzender (een CRM, een facturatietool, een nieuwsbriefplatform) of een echte spoof.
Verzwak het beleid dus niet als eerste stap. Zoek de niet-geauthenticeerde bron. Twee valkuilen verklaren de meeste gevallen:
- SPF slaagt, maar op het verkeerde domein. Ontvangers evalueren SPF tegen het domein in de Return-Path (RFC5321.MailFrom), niet de From-header. Een SaaS-tool die “namens” u verstuurt, slaagt meestal voor SPF op zijn eigen bounce-domein, dat niet aligneert met uw From-domein — dus DMARC faalt alsnog. Stapsgewijs: DMARC faalt maar SPF en DKIM slagen.
- DKIM slaagt, maar met de standaardhandtekening. De standaardwaarden
gappssmtp.comvan Google Workspace enonmicrosoft.comvan Microsoft verifiëren prima en aligneren met niets. Zie DKIM slaagt maar DMARC faalt nog steeds.
Deze variant komt zeldzamer voor dan u zou denken: 27.640.987 van de 261.086.232 domeinen — 10,59% — handhaven een DMARC-beleid van quarantine of reject, volgens de Defaults.Exposed-census (2026-06-29). De overige 89,41% zien deze bounce nooit, omdat ze geen hek hebben om vast te houden. De bron herstellen, niet het beleid, wordt volledig behandeld in de DMARC-fixgids.
De bounce noemt IPv6-verzendrichtlijnen — de reverse-DNS-oplossing
Moderne servers maken vaak standaard via IPv6 verbinding met Gmail, en Google vereist dat het verbindende IPv6-adres een PTR-record heeft dat naar een hostnaam verwijst die terugverwijst naar hetzelfde adres (forward-confirmed reverse DNS). Mist u dat, dan krijgt elk bericht 550-5.7.1, hoe schoon uw SPF ook is.
Drie oplossingen, in volgorde van voorkeur:
- Stel het PTR-record in voor het IPv6-adres van uw server — geregeld waar het IP-adres leeft (uw VPS-host of ISP-beheerpaneel, niet de DNS-zone van uw domein), met een bijpassend AAAA-record dat terugverwijst.
- Relay via de smarthost van uw provider. Kunt u rDNS niet beheren, route uitgaande mail dan via de relay van uw e-mailprovider of ISP, die al correcte rDNS heeft.
- Geef als tijdelijke oplossing de voorkeur aan IPv4-transport. Dat verbergt meestal het symptoom omdat uw IPv4-adres wél een PTR heeft — een omweg, geen oplossing. Stel de IPv6-PTR in zodra u kunt.
De bounce zegt “likely unsolicited email” — het reputatiepad
Hier kan de authenticatie in orde zijn, maar vertrouwen Gmail’s filters de mail niet. Authenticatie is de vloer, niet het plafond — van de 12.145.313 domeinen die _spf.google.com autoriseren, sluit slechts 8,0% SPF strikt af met een -all, dus een geslaagde controle zegt op zichzelf weinig. (Volledige vergelijking: welke e-mailprovider heeft de sterkste SPF-standaardinstellingen.)
De reputatiechecklist:
- Registreer u bij Google Postmaster Tools en houd het spampercentage-dashboard in de gaten — houd het onder 0,10%, en laat het nooit het plafond van 0,30% bereiken dat Google’s bulkverzenderrichtlijnen als harde vereiste stellen.
- Maak uw lijst schoon. Verwijder niet-betrokkenen en alles wat gekocht of geschraapt is; verstuur alleen naar mensen die erom vroegen.
- Implementeer RFC 8058-uitschrijven-met-één-klik op bulkmail — verplicht volgens Google’s regels, en elke afmelding die geen “spam”-klik is, beschermt uw percentage.
- Houd de authenticatie gealigneerd (SPF en DKIM op uw eigen domein) zodat reputatie zich opbouwt op een domein dat u beheert.
Veelgestelde vragen
Is 550-5.7.1 hetzelfde als 550-5.7.26? Nee. 550-5.7.26 is Gmail’s familie authenticatievereisten (SPF/DKIM ontbrekend of falend) — en Google’s huidige naslagwerk plaatst de DMARC-policyafwijzing daar ook onder. 550-5.7.1 is de oudere policyfamilie: ontvanger- en afzenderpolicyblokkades, IPv6-zonder-PTR, spam- en reputatieblokkades. De bouncetekst, niet het nummer, vertelt u welke oplossing van toepassing is (per 2026-06-29 en huidige Google-richtlijnen).
Moet ik mijn DMARC-beleid terugzetten naar p=none om de bounces te stoppen? Dat stopt ze door het hek af te breken. Slechts 10,59% van de 261.086.232 domeinen in de Defaults.Exposed-census (2026-06-29) handhaaft DMARC überhaupt; bent u daar één van, behoud het dan en herstel de niet-geauthenticeerde bron — het beleid verzwakken opent exact-domeinspoofing opnieuw.
Waarom blokkeert Gmail mijn mail terwijl mijn SPF-record bij elke checker slaagt? Checkers testen het record; Gmail test het bericht. SPF wordt geëvalueerd tegen het Return-Path-domein, niet het zichtbare From-adres, dus een geslaagde controle op het bounce-domein van een leverancier doet niets voor uw DMARC-alignment — en reputatieblokkades negeren SPF volledig. De gratis scan laat zien welke laag daadwerkelijk faalt.
Betekent 550-5.7.1 dat mijn IP op een blacklist staat? Niet noodzakelijk. Gmail draait zijn eigen reputatiesysteem; u kunt door Google geblokkeerd worden terwijl u op geen enkele publieke blocklist staat. Controleer Postmaster Tools voor Google’s beeld — en let op dat het herstellen van authenticatie toekomstige schade voorkomt, maar op zichzelf geen slechte verzendreputatie herstelt.
Stuur de eigenaar het rapport
Zodra de bounce is opgelost, voert u de scan opnieuw uit en stuurt u het beoordeelde rapport door naar de bedrijfseigenaar of klant wiens mail bounce’te. Het laat in gewone taal zien wat er kapot was, wat u hebt gerepareerd en waar het domein nu staat tegenover de baseline van 261 miljoen domeinen — precies wat ze nodig hebben voor de verzekeringsverlenging of beveiligingsvragenlijst van een klant die vraagt “authenticeert u uw e-mail?”. Een stilletjes opgeloste bounce is onzichtbaar werk; een voor-en-na-rapport is bewijs.
Controleer uw domein → · Gmail 550-5.7.26 — de oplossing in volgorde van vereiste → · Repareer DMARC → · Hoe wij beoordelen → · Uitsluitend geaggregeerde gegevens. Gegevens opgeslagen en verwerkt in de EU.