550 5.7.26 “This message does not have authentication information”: de oplossing voor Gmail

Weigert Gmail je mail met dit SMTP-antwoord, dan loop je tegen de handhaving van Gmail voor bulkverzenders aan:

550-5.7.26 This message does not have authentication information or fails to
550-5.7.26 pass authentication checks (SPF or DKIM). To best protect our users
550-5.7.26 from spam, the message has been blocked. Please visit
550 5.7.26 https://support.google.com/mail/answer/81126 for more information.

Dit is een weigering vanwege authenticatie; reputatie, content en filters per gebruiker spelen er geen rol in. De verzendersregels van Gmail (van kracht sinds februari 2024 en strenger gehandhaafd sinds november 2025) eisen dat elke verzender slaagt voor SPF of DKIM, en dat verzenders van ongeveer 5.000 of meer berichten per dag naar persoonlijke Gmail-accounts slagen voor SPF en DKIM, het From-domein in alignment brengen met een van beide en een DMARC-record publiceren. Faalt de authenticatie, dan weigert Gmail het bericht al tijdens de SMTP-sessie.

Wat 550 5.7.26 echt betekent

De fout heeft drie mogelijke oorzaken, op volgorde van hoe vaak ze voorkomen:

1. Noch SPF noch DKIM is in alignment met het zichtbare From:-domein.
2. De eigen DMARC-policy van je domein (p=quarantine of p=reject) zegt Gmail dat mail die faalt geweigerd moet worden. Een ontbrekend DMARC-record heeft een eigen code, 4.7.40 of 5.7.40, in de foutenlijst van Gmail.
3. SPF en DKIM slagen allebei, maar het domein in de From:-header komt niet overeen met het geauthenticeerde domein (mislukte alignment).

Gmail telt een geslaagde SPF op alleen het Return-Path-/bouncedomein niet mee. Is je bouncedomein bounces.esp.com en je From hello@yourdomain.com, dan slaagt SPF maar is het niet in alignment, dus moet je vertrouwen op DKIM ondertekend door yourdomain.com.

Stap 1: bekijk de headers van het originele bericht

Stuur jezelf een test vanaf hetzelfde verzendplatform naar een Gmail-account dat het bericht wel nog accepteert (of een Workspace-account waarin je de spammap kunt lezen). Open het bericht → drie puntjes → Origineel weergeven.

Zoek de header Authentication-Results::

Authentication-Results: mx.google.com;
       dkim=pass header.i=@esp.com;
       spf=pass smtp.mailfrom=bounces.esp.com;
       dmarc=fail (p=NONE) header.from=yourdomain.com

In dit voorbeeld slaagt DKIM voor esp.com, maar de From is yourdomain.com, en daarom faalt DMARC. De oplossing is DKIM-ondertekening voor yourdomain.com instellen in je ESP, niet SPF aanpassen.

Stap 2: zet DKIM-alignment recht

DKIM-alignment is de makkelijkste winst. Bijna elke grote ESP (Mailchimp, HubSpot, SendGrid, Brevo, Klaviyo, ActiveCampaign, Customer.io, Resend, Postmark) ondersteunt DKIM op je eigen domein. Je voegt een CNAME- of TXT-record dat zij je geven toe op selector._domainkey.yourdomain.com en zet daarna DKIM-ondertekening aan in hun dashboard.

Na propagatie (een paar minuten tot een paar uur) hoort de header Authentication-Results dkim=pass header.i=@yourdomain.com te tonen, en slaagt DMARC via DKIM, ook als SPF niet in alignment is.

Controleer het met onze DKIM-lookup.

Stap 3: publiceer een DMARC-record (ook als het p=none is)

De regels voor bulkverzenders van Gmail eisen dat er een DMARC-record bestaat. p=none is genoeg om aan deze eis te voldoen terwijl je nog aan het monitoren bent. Het minimale record dat voldoet is:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Voeg het toe als TXT-record op _dmarc.yourdomain.com. Maak er een met onze DMARC-generator.

Stap 4: controleer of SPF niet ongemerkt kapot is

Ook als DKIM het werk doet, wil je dat SPF in orde is. Veelvoorkomende problemen:

• Meer dan 10 DNS-lookups in het SPF-record (geeft permerror)
• Twee SPF-records op hetzelfde domein (er mag er maar één zijn)
• Een -all (hard fail) waar je ~all bedoelde (alleen van belang als je ESP niet in de include-lijst staat)

Controleer het met onze SPF-lookup. Zit je boven de limiet van 10 lookups, maak het record dan plat met delegatie naar subdomeinen of een dienst voor SPF-macro's.

Stap 5: meld je aan bij Google Postmaster Tools en lees het uit

Krijg je 550 5.7.26, meld het From-domein dan aan bij Google Postmaster Tools. Na 24 tot 48 uur verkeer laat het zien:

• Slagingspercentage van authenticatie (doel: >99%)
• Domeinreputatie
• IP-reputatie
• Spampercentage (de harde grens van Gmail is 0,3%; mik op minder dan 0,1%)

Is de grafiek voor authenticatie iets anders dan bijna 100% groen, dan hebben je oplossingen nog niet volledig effect.

Stap 6: test opnieuw vanaf een nieuwe verbinding

De retry-wachtrijen van ESP's kunnen 30 minuten nodig hebben om leeg te lopen. Pauzeer en hervat de campagne, of stuur een nieuw testbericht nadat DKIM en DMARC zijn gepropageerd. De bounce hoort meteen te verdwijnen zodra de authenticatie slaagt. Gmail "onthoudt" de eerdere mislukking niet tegen je IP.

Waarom je na alle oplossingen toch nog 550 5.7.26 kunt krijgen

Een paar minder voor de hand liggende oorzaken die we in support tegenkomen:

• Subdomein komt niet overeen. Is je From hello@mail.yourdomain.com maar is DKIM ingesteld op yourdomain.com, dan is de alignment standaard relaxed en hoort hij toch te slagen, maar sommige ESP's publiceren strikte alignment in DMARC (adkim=s). Zet het op adkim=r.
• Verouderde DNS-cache. Gmail cachet DNS urenlang. Wacht na het publiceren van DKIM minstens 4 uur voordat je aanneemt dat de oplossing niet werkt.
• Verkeerde selector. Sommige ESP's wisselen hun selectors (bijvoorbeeld s1, s2). Heb je het oude TXT-record verwijderd voordat het nieuwe actief was, dan zie je DKIM-fouten tot je het opnieuw toevoegt.

Veelgestelde vragen

Is 550 5.7.26 hetzelfde als 550-5.7.1 van Gmail? Nee. 550-5.7.1 Our system has detected... is een blokkade op content/reputatie. 550-5.7.26 is puur een bounce vanwege handhaving van authenticatie, en de oplossing is technisch (DKIM/SPF/DMARC), niet inhoudelijk.

Blokkeert Gmail na een 550 5.7.26 mijn hele IP? Nee. Deze bounce wordt per bericht en per verzender beoordeeld. Op zichzelf schaadt hij je IP-reputatie niet. Maar steeds opnieuw proberen met kapotte authenticatie verspilt verbindingen en kan je uiteindelijk afremmen via 421-throttling.

Heb ik een handhavende DMARC-policy (p=quarantine of p=reject) nodig om dit op te lossen? Nee. Gmail eist een gepubliceerd DMARC-record. p=none is genoeg voor de check voor bulkverzenders. Ga pas naar handhaving als je DMARC-aggregaatrapporten er schoon uitzien.

Blijf de regels van Gmail voor

Gmail verscherpt deze eisen elke 12 tot 18 maanden. MailVitals bewaakt je SPF, DKIM, DMARC en alignment doorlopend en waarschuwt je zodra een record verschuift.

Bronnen

• Gmail SMTP errors and codes (Google Workspace Help), de drie teksten van 550 5.7.26 (niet-geauthenticeerde verzender, SPF hard fail, DMARC-policy) en de aparte 5.7.40 voor een ontbrekend DMARC-record.
• Email sender guidelines (Gmail Help), SPF of DKIM voor alle verzenders, SPF, DKIM, DMARC en From-alignment voor bulkverzenders, en DKIM-sleutels van minstens 1024 bits.
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), de huidige DMARC-standaard (mei 2026, ter vervanging van RFC 7489), inclusief identifier alignment en de modi adkim/aspf.
• RFC 7208: Sender Policy Framework (SPF), de limiet van 10 DNS-lookups en de permerror die ontstaat als je die overschrijdt.