Gmail had een grote storing waardoor berichten niet werden ontvangen

Gmail heeft dinsdagavond een omvangrijke storing gehad, waardoor berichten die naar Gmail.com-adressen werden verstuurd, niet afgeleverd werden. Het was de tweede grote storing in een week.

De storing begon dinsdagavond rond 21:42 uur en was woensdag iets voor 01:00 uur verholpen. Gebruikers meldden dinsdagavond dat ze wel toegang tot Gmail hadden. Berichten die naar Gmail.com-adressen werden verstuurd, kregen echter een bounce-notificatie dat het e-mailaccount dat ze probeerden te bereiken, niet bestond.

De problemen deden zich wereldwijd voor. Google zelf spreekt van een 'aanzienlijke hoeveelheid' gebruikers die er last van hadden. Niet bekend is of de storing alle gebruikers trof. De laatste keer dat Google zelf bekendmaakte hoeveel Gmail-gebruikers er in totaal waren, was in 2018; toen had de webmaildienst 1,5 miljard actieve accounts.

Het is de tweede keer in een week dat Gmail een storing heeft. Maandag betrof het probleem dat gebruikers door een authenticatiestoring niet konden inloggen bij Gmail en andere Google-diensten, zoals YouTube en GSuite.

Door Olaf van Miltenburg

Nieuwscoördinator

16-12-2020 • 07:34

108

Submitter: BretClit

Reacties (108)

108
104
58
16
1
26
Wijzig sortering
cfr. Protonmail wil dit zeggen dat elke andere mail provider die mails wou verzenden naar gmail, niet automatisch de mails opnieuw gaat proberen verzenden.
Because Gmail is sending a permanent failure, our mail servers will not automatically retry sending these messages (this is standard practice at all email services for handling permanent failures).
Ik kan mij voorstellen dat dit nog voor problemen gaat zorgen bij mensen die verwachten dat de mail later wel zal aankomen.
Ik kreeg op LinkedIn zojuist het bericht dat mijn e-mail adres (Gmail dus) niet bereikbaar was en werd ook geforceerd uitgelogd met de vraag om te verifiëren met een alternatief adres. Kon dit wel overslaan, maar toch vind ik het een bijzonder neveneffect van zo’n storing.. en dat op basis van een verkeerde fout-reply vanuit Google.
Hoezo een verkeerde fout-reply? Er is een storing en de mail kan niet bij Gmail ontvangen of verwerkt worden, terwijl er wel verbinding gemaakt kan worden met de Gmail mailservers op poorten 25 (SMTP) en 587 (SMTPS).
Gmail geeft een foutcode terug dat ze de mail niet kunnen verwerken en dus het bericht weigeren. Daarmee wordt de verzender geinformeerd dat er iets mis is.
Als ze geen foutcode teruggeven terwijl ze de mail niet kunnen verwerken, is er een veel groter probleem, namelijk een ontvanger die de mail niet ontvangt, terwijl de verzender denkt dat de mail keurig is afgeleverd.

De door Gmail gegenereerde foutcode voldoet precies aan de SMTP specificaties.
De door Gmail gegenereerde foutcode voldoet juist niet:
550-5.1.1 The email account that you tried to reach does not exist. Please try double-checking the recipient's email address for typos or unnecessary spaces. Learn more at https://support.google.com/mail/?p=NoSuchUser
Dit moet enkel en alleen gebeuren als het adres daadwerkelijk niet meer bestaat.

Wat gebeurt er nu bij de meest goed geconfigureerde emailsystemen? De bounces worden direct omgezet in een hard bounce. Een hard bounce is een adres waar je in principe nooit meer naar mag versturen. Dit is wat verzenders ook moeten doen volgens de RFC richtlijnen.

Verzenders moeten dit nu ongedaan maken voor de periode waarin het probleem is opgetreden. En dat gaat lang niet zo makkelijk.

Als Gmail de mail tijdelijk niet kan verwerken, moet Gmail een transient (4xx error) doorgeven.

Edit: ter verduidelijking, met verzender bedoel ik hier dus de verantwoordelijken achter de verstuurde mail. De verzender kan een eigen MTA hebben of gebruik maken van een Email Service Provider.

[Reactie gewijzigd door Aurora op 26 juli 2024 05:33]

Verzendende diensten moeten helemaal niets ongedaan maken. Google heeft gemeld: dit adres bestaat niet (om wat voor reden dan ook). Dan is een hard fail gewoon de enige juiste optie. Je moet die mail niet blijven hersturen omdat er geen enkele verwachting is dat die ooit gaat afgeleverd worden.

Het is nu aan de personen die de mail verstuurd hebben om actie te ondernemen en de mail opnieuw aan te bieden en opnieuw te versturen. Want wat je niet moet doen als verzendende dienst is zelf een lijst gaan aanleggen van email adressen waarvan een andere dienst zegt dat ze niet bestaan, omdat je die lijst nooit up to date kunt houden zonder zelf opnieuw te proberen.

Google beslist natuurlijk zelf niet zomaar van "vandaag gaan we deze fout sturen gedurende 2,5u". Iemand heeft een fout gemaakt, de mail server krijgt verkeerde informatie binnen (misschien verkeerde database geconfigureerd) en neemt actie op de informatie dat het heeft. Namelijk dat de gebruiker niet bekend is en stuurt daar een correct antwoord op terug. De server zelf weet niet dat dit een probleem van voorbijgaande aard is.
Verzendende diensten moeten helemaal niets ongedaan maken.
Dat heb ik ook niet gezegd. Ik spreek enkel over verzenders, die verantwoordelijk zijn voor de verstuurde berichten. Een verzender kan ook zijn eigen MTA hebben. Als we het hebben over "verzendende diensten", dus een ESP, zoals Sendgrid of SparkPost, dan denk ik dat deze hun klanten moet verwitiggen van de problemen bij Google.
Het is nu aan de personen die de mail verstuurd hebben om actie te ondernemen en de mail opnieuw aan te bieden en opnieuw te versturen.
De actie is in ieder geval de vermoedelijke false-positives terugplaatsen als zijnde actief. Email opnieuw sturen gaat erg lastig als het om transactionele email gaat. Dus mail die de gebruiker zelf triggert, zoals een wachtwoord vergeten mailtje.
Oef, een user does not exist error wijst toch wel op een serieus probleem. Daar heeft iemand op de verkeerde knopjes gedrukt....
Of dat heeft weer te maken met dat authenticatie probleem.

Authenticatie systemen checken niet enkel je credentials maar ook de identiteit.
Het is goed mogelijk dat ze bij het vorige incident een workarround hebben geimplementeerd die nu andere neveneffecten genereerd, (zoals identiteiten die niet gevonden kunnen worden -> dan kan de mailbox ook niet gevonden worden)

Het ziet er allesinds niet goed uit, kans is groot dat deze saga nog niet voorbij is.
Ik heb mijn MX records al aangepast zo dat ik een backup mail server heb, zo dat ik geen mails verlies.

MX 20 wijst nu naar een transip forwarder in het geval MX10 plat is.

Maar ik ben niet zo zeker of dit mij gaat helpen in dit geval, want de mx record resolved wel naar een werkend adres...(mail server antwoord), dus mail word weggesmeten omdat de recipient niet bestaat, ik kan beter mx10 en mx20 even omswitchen tot ik zeker ben dat gmail hun probleem definitief opgelost heeft.

[Reactie gewijzigd door sebastienbo op 26 juli 2024 05:33]

Maar dat fallback MX record gaat alleen werken als het primaire MX record echt offline is.

Als je primaire MX record echt een "550-5.1.1 user does not exist" terugstuurt, heb je aan het fallback MX record nog steeds niets, want de verzonden mail is dan al actief geweigerd.
Een fallback MX record is alleen handig als je primaire record volledig onbereikbaar is op poort 25 of 587, de verzendende partij zal dan proberen om de mail op het fallback MX record af te leveren.
Een fallback MX record is alleen handig als je primaire record volledig onbereikbaar is op poort 25 of 587, de verzendende partij zal dan proberen om de mail op het fallback MX record af te leveren.
Een fallback is alleen relevant bij een niet bereikbare poort 25. MX record documenteert de receiving mail servers voor een domein tbv mail relay naar dat domein. Poort 587 is voor mail submission naar een willekurige geadressseerde door een domain user, daar speelt het MX record geen rol in.
Dat had ik toch in mijn bericht geplaatst ??

"Maar ik ben niet zo zeker of dit mij gaat helpen in dit geval, want de mx record resolved wel naar een werkend adres...(mail server antwoord), dus mail word weggesmeten omdat de recipient niet bestaat"

vandaar dat ik mijn mx records omgewisseld heb.

" ik kan beter mx10 en mx20 even omswitchen tot ik zeker ben dat gmail hun probleem definitief opgelost heeft."

Primary is nu transip die een store & forward functie heeft op mijn @catchall

[Reactie gewijzigd door sebastienbo op 26 juli 2024 05:33]

Bij dit soort problemen zeg ik altijd dat niet iemand op de verkeerde knopjes heeft gedrukt, want één mens zou niet zulke problemen moeten kunnen veroorzaken. Dan zit er iets in het systeem fout.
De door Gmail gegenereerde foutcode voldoet precies aan de SMTP specificaties.
Als je dat zegt heb je ze nog nooit gelezen...
4yz Transient Negative Completion reply
The command was not accepted, and the requested action did not
occur. However, the error condition is temporary, and the action
may be requested again. The sender should return to the beginning
of the command sequence (if any). It is difficult to assign a
meaning to "transient" when two different sites (receiver- and
sender-SMTP agents) must agree on the interpretation. Each reply
in this category might have a different time value, but the SMTP
client SHOULD try again. A rule of thumb to determine whether a
reply fits into the 4yz or the 5yz category (see below) is that
replies are 4yz if they can be successful if repeated without any
change in command form or in properties of the sender or receiver
(that is, the command is repeated identically and the receiver
does not put up a new implementation).

5yz Permanent Negative Completion reply
The command was not accepted and the requested action did not
occur. The SMTP client SHOULD NOT repeat the exact request (in
the same sequence). Even some "permanent" error conditions can be
corrected, so the human user may want to direct the SMTP client to
reinitiate the command sequence by direct action at some point in
the future (e.g., after the spelling has been changed, or the user
has altered the account status).
Er is bewust in SMTP een onderscheid tussen transient failures (4xx) en permanent failures (5xx). Daarmee weet de verzendende partij of hij de mail moet bewaren voor latere bezorging, of meteen mag bouncen.

Een permanent failure geven voor een transient probleem zoals wat hier speelde is een bijzonder grove fout aan de kant van Gmail. Een 5xx code mag je alleen geven als buiten kijf staat dat de gevraagde actie niet zal kunnen slagen, ook niet bij opnieuw proberen. In alle andere gevallen dient de server een 4xx te geven of desnoods simpelweg te disconnecten, zelfde effect.
Dit is een storing, dus ook de teruggekoppelde foutmelding is onderdeel van de storing. Ja, een 4xx was netter EN beter geweest.

Maar stel nou dat de authentication laag van Gmail door een fout bij alle gebruikers aangaf dat de gebruiker niet bestaat. Hoe moet het mail platform dan weten dat dat een fout is? De 5xx melding is vanuit het perspectief van de mai omgeving gewoon correct.

Da's nou net het nadeel van een storing.. Dat doet niet altijd wat je verwacht of hoopt.
Maakt toch niets uit voor mijn stelling dat het een bijzonder grove fout is van Gmail? Hun interne afhandeling is hun zaak.

Transient backend failure moet een transient frontend failure opleveren. Is geen probleem van anderen, die SHOULD NOT de transactie retryen.

[Reactie gewijzigd door curry684 op 26 juli 2024 05:33]

Vanuit de mailserver gezien is er toch correct gehandeld? Server zag geen gebruiker in het autorisatie systeem en heeft vandaar uit de 550-5.1.1 melding gegenereerd. Adres bestaat niet en dat klopte dus voor de mail server.
Bij een onbekende of tijdelijke storing hoort een e-mail server een tijdelijke foutcode te gebruiken.

Een permanente weigering hoort eigenlijk alleen plaats te vinden als helemaal goed gaat, maar de mailbox simpelweg niet bestaat of om andere redenen permanent geen e-mail meer mag ontvangen.
Een 4xx had idd op zijn plaats geweest ipv een 5xx. Nu worden zenders opgezadeld met het probleem.
This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

VALIDADDRESS@gmail.com
host gmail-smtp-in.l.google.com [173.194.79.26]
SMTP error from remote mail server after RCPT TO:<VALIDADDRESS@gmail.com>:
550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 https://support.google.com/mail/?p=NoSuchUser mb3si15379ejb.126 - gsmtp
Dit is een voorbeeld van zo'n retour e-mail. Daar is echt niet uit op te maken dat er een tijdelijk storing is. Dit is gewoon een permanente fout waaruit je kunt opmaken dat het e-mailadres niet bestaat.

Mijn maildienst kreeg honderden van deze mails te verwerken. Heel vervelend omdat er soms automatisch actie wordt ondernomen op basis van adressen die niet meer bestaan. Je wilt namelijk niet te boek staan als spammer en sommige maildiensten gaan je wel zo zien als je veel mail stuurt naar niet-bestaande adressen.
Veel bulk mail services, mailchimp ed, versturen na een "adres bestaat niet" melding geen mails meer naar dat adres om te voorkomen dat ze op spam-lijsten terecht komen. Ook zo'n neven-effect waar je niet direct aan denkt
Als verzender van e-mail heb je weinig keus. Stuur je te vaak naar Gmail adressen die niet bestaan dan gaat je score bij gmail omlaag en beland je vaker in de spam. Het “schoonhouden” van je adressen is erg belangrijk. (Geld overigens ook voor andere grote e-mail providers.)
Ik krijg die melding ook (altijd) maar omdat mijn mail geen plaatjes inlaadt, en dus de track-pixel geen reactie geeft.
Zal wel meevallen, aangezien er een reply terugkomt. Tenzij het verstuurd wordt door een proces wat niet gemonitord wordt.
Maar dan moet je dat bounce bericht wel goed lezen. En dat gebeurd vaak niet. Heb al vaak gezien dat mensen met een vraag koemn waarom hun mail niet verstuurd is terwijl in de bounce gewoon de reden wordt opgegeven. Of een bericht krijgen waarin zwart op wit staat dat de mail niet verstuurd is en toch vragen: is deze verstuurd?
Wat een prachtig vak hebben wij toch he? Ik ga me steeds meer voelen als Roy uit IT crowd.
Is dat niet met iedere foutmelding, niet lezen, wegklikken en zeggen dat het niet werkt :p
NDR DSN is geen reply.
Hoe kom je daar nou weer bij?
Een systeem-gegenereerd bericht beschouw ik niet als een reply.
Dat is dan jouw mening.
Ik was gisteren een paar bestellingen aan het doen op dat tijdstip. Ik vond het al vreemd dat ik geen bevestiging kreeg per mail. En zoals het er nu naar uit ziet ga ik die dus ook niet meer krijgen. Ik heb zonder account besteld, dus kan ook niet inloggen.
Dat probleem had ik ook. Gelukkig heeft de website waar ik had besteld [licentieverkoop.nl] een chat. Daar werd ik meteen geholpen, en had de medewerker al gezien dat de emails niet aankwamen. Hopelijk kun je ook op deze manier je bestelling bevestigd krijgen.
Ik ben er nog niet achteraan gegaan, maar heb natuurlijk nog altijd het bewijs van mijn bankafschrift... zal wel goedkomen. Dank voor de tip.
Bij een fatsoenlijke geconfigureerde mail server én een verzender die op de hoogte is van de problemen bij Google, zouden hun klanten/ontvangers kunnen verwittigen.

Ik vermoed echter dat dit slechts bij een klein aantal verzenders zal gebeuren. Een hoop wordt niet gemonitord. Het proces dat van een adres een 'hard-bounce' maakt is lang en breed verwerkt als zodanig. De SMTP terugkoppeling van Gmail was dan ook:
550-5.1.1 The email account that you tried to reach does not exist. Please try double-checking the recipient's email address for typos or unnecessary spaces
Je krijgt een boodschap dat je mail niet aankwam, zie niet hoe mensen gaan denken dat die toch magisch nog zal aankomen.
Ook mooi dat dat ook in het artikel staat.
Kreeg inderdaad diezelfde mail (heb tegenwoordig een protonmail account).
Gmail heeft al langer last van dit probleem, dit is niet beperkt tot die paar uurtjes die jullie noemen in het artikel.

Ik krijg al sinds de storing van alle Google diensten op maandag klachten van klanten binnen die proberen te mailen maar bounces van Gmail krijgen, allemaal een 550 5.1.1 User Unknown berichten, terwijl de adressen gegarandeerd wel al bestaan (eerdere corresponentie aanwezig).
Zijn die berichten "weg" of niet? Of zijn ze gebuffered en later alsnog afgeleverd?
Volgens een email die ik van Protonmail heb gekregen hierover, worden de verzonden berichten niet opnieuw verstuurd

"Because Gmail is sending a permanent failure, our mail servers will not automatically retry sending these messages (this is standard practice at all email services for handling permanent failures)."
Zo lang het maar duidelijk is en de berichten niet in de "void" zijn terechtgekomen.
Vraag me wel af hoe automatische mails worden afgehandeld, bijv. een bestelbevestiging of betaalmail. Zouden bedrijven door hebben dat hun mail nooit zal aankomen?
Mijn vrouw kreeg ieg een bericht van LinkedIn in hun App dat haar (Gmail) email adres niet bestond. LinkedIn monitort het dus.
Normaal krijg je die bounce dus op het adres waar je mee verstuurd, dus als dat geen kansloze noreply@ is dan is er weinig aan de hand en krijg je daar melding van binnen.
Lekker onzeker inderdaad.

Net in die periode wat bestellingen gedaan en dus inderdaad geen bevestiging gekregen.

Dan moet je een klantenservice lastig vallen, of ze je bestelling wel hebben en of ze de bevestiging alsnog willen sturen.

Nou ja, het is wat het is..........
De berichten zijn geweigerd door de mailserver, met notificatie daarvan aan de zender.

Geweigerd betekent dat er niks later afgeleverd gaat worden.
Erger nog. Allerlei mailing lijsten gooien je er automatisch vanaf. En andere mail verzenders (zoals Amazons SES) zullen tijdelijk weigeren e-mail naar zo’n adres te versturen om hun reputatie als verzender te waarborgen. (Al acht ik het bij Amazon wel waarschijnlijk dat daar iemand ingrijpt om dit in dit geval te voorkomen.)
Die spam lijsten, die worden ook beheerd, dus als de personen achter die lijsten op de hoogte zijn van problemen met de Google mail server(s), dan zullen ze daar ook wel rekening mee houden.

De meest bekende (en daarmee de belangrijkste/meest invloedrijke) anti-spam lijsten geven je een optie om je mail server te de-listen. En als zij zien dat er ineens wel een heleboel dezelfde soort berichten worden geweigerd door 1 globaal opererende mail server (error messages worden bijna nooit ge-encrypt), dan voelen zij ook wel op hun theewater aan dat er iets goed mis gaat.

Dat zal het opnieuw verzenden door mailing lijsten hen geen (of slechts zeer tijdelijke) reputatie-schade opleveren.
dit was maandagavond al aan de gang.
Yep, ik kreeg dinsdagochtend al tickets binnen van klanten die maandagavond na Rutte's nieuwe regels weer allemaal nieuwsbrieven moesten versturen (zoals bijv. sportscholen of sportclubs) maar al hun leden met gmail adressen bouncen. Natuurlijk geven ze gelijk ons systeem de schuld 8)7

Heeft de hele dag aangehouden nog. Dus echt niet beperkt tot die enkele paar uurtjes op dinsdagavond.

[Reactie gewijzigd door chris_vanr op 26 juli 2024 05:33]

Inderdaad, ik kreeg even na middernacht in de nacht van maandag op dinsdag ook meerdere mails aan mijn moeder's Gmail adres terug met de mededeling dat het adres niet bestaat.

Staat ook in het storingsoverzicht van Gmail:
https://www.google.com/ap...8e60fdfb3c0f64fc9b81752e1

[Reactie gewijzigd door Wild Chocolate op 26 juli 2024 05:33]

Ik gebruik Gmail als recovery mail adres van veel diensten. Hoe lossen jullie dat op? Zijn er veiligere en meer stabielere alternatieven?
Kijk eens naar protonmail, misschien voldoet dat aan je eisen. Is veilig en gericht op privacy.
Maar is het ook stabieler? Of mis je dan weer email omdat ze ergens worden geblokkeerd? Want protonmail klinkt dan wel super veilig maar het klinkt ook als een dienst die van de ene op de andere dag verdwenen kan zijn.
Zelf gebruik ik het al jaren met veel tevredenheid, heb nog niet gehad dat verzonden mail niet aankomt. Het artikel waar jij naar refereert heeft betrekking op Rusland, waar toegang tot Protonmail is geblokkeerd.

Dat het van de ene op andere dag van de aardbodem verdwijnt lijkt mij sterk, daar heeft google het patent op met het stopzetten van producten. Verder zijn ze druk bezig met het uitrollen van nieuwe producten.
In de meer dan 15 jaar dat ik gmail gebruik is dit de eerste serieuze storing die ik meemaak. En als dromer kun je best geloven dat protonmail niet zomaar verdwijnt. Je hebt ook daar geen bevestiging of contractuel overeenkomst waarin ze dat beloven.
Beetje jammer dat je mij gelijk als dromer neerzet... Geldt je betoog ook niet voor gmail? Of heb jij daar wel een contactuele overeenkomst met ze afgesloten waarbij ze dat beloven?
Ik wel in ieder geval, want ik betaal voor gSuite.
Fijn voor jou en Google. Maar heb je daarbij een contractuele overeenkomst met ze afgesloten waarbij ze beloven hun gSuite diensten niet stop te zetten in de toekomst?

Zo betaal ik voor ProtonMail en ProtonVPN, maar daar ging de vraag van K-aroq en mijn reactie daarop niet.
Ja er zijn nu twee storingen in een week maar over het algemeen is Gmail dacht ik toch vrij stabiel?
Kan ik ook zeggen van de mailserver die ik in eigen beheer (en on-premise) heb. Gebeurt ook meestal 1 of 2 keer per jaar dat deze op een of andere spamlijst terechtkomt.

Meestal nadat er iemand op bezoek is geweest met een laptop (om samen met 1 van de kids van mijn baas huiswerk te maken. Alhoewel deze zijn gescheiden van het normale netwerk via VLAN, mijn statische IP adres is dan al wel aangemerkt als spammer bij 1 (of meerdere) spam lijst.

Voor een kleine mail-server als de mijne neemt het delisten over het algemeen genomen zo'n 24 uur in beslag. Niet het de-listen zelf, maar dat de anti-spam organisaties je daadwerkelijk van hun black-list verwijderen.

Dat gezegd hebbende, Heb wel 1 keer bijna 3 weken moeten wachten voor de verwijdering een feit was bij een spamlijst die vooral de Noord-Amerikaanse markt bedient. Alhoewel ik daar nooit mail naar toe stuur, trof me dat niet heel erg, behalve een (iets) lagere reputatie score.

Deze mail server draait al ruim 15 jaar (waarvan ruim 10 jaar onder mijn beheer) en blijkbaar dus net zo stabiel als GMail, op de occasionele spamlijst vermelding na.
2 storingen in een week, waar vermoedelijk de meeste mensen geen last van hebben gehad, en jij vindt de dienst niet meer stabiel? Je hebt te maken met een ICT dienst en elke ICT dienst kun je 1 ding met zekerheid zeggen, namelijk "je zult te maken hebben met storingen".

Ook de voorgestelde Protonmail van @patviev zal een storing krijgen. Google er maar eens op en je zult zien dat deze ook aantal keren down is geweest door storing.
Niet echt, elke diesnt ligt er af en toe uit. Denk dat het nu redelijk lang geleden was dat gmail zo'n problemen had dit valt dus echt wel mee.
Anoniem: 414757 16 december 2020 07:46
Ik hoop dat ze snel aangeven waar deze problemen vandaan komen. Het is fijn om te weten dat dit opgelost is en natuurlijk ook hoe dit gedaan is.

Ik kan me voorstellen dat bedrijven die betalen voor deze diensten erg op hun hoede zijn nu. Als dit doorslaat naar hun kan een bedrijf als Randstad bijvoorbeeld erg veel geld kosten als hun medewerkers hun systemen niet kunnen gebruiken.
Elke dienst, elk bedrijf, elke organisatie, alles kan worden en zal worden getroffen door een storing.

Van een keer mail niet afleveren hoef je niet direct een dienst te wantrouwen. Gmail is verder gewoon een betrouwbare dienst.
Bij mij werkt het nog steeds niet. Komt nog steeds geen mail binnen.
Misschien probeert iemand je een JunkieVirus te sturen en worden de e-mails daarom tegengehouden?
Hierbij de volledige mail die ik heb ontvangen van ProtonMail.

Dear ProtonMail user,

Starting at around 4:30PM New York (10:30PM Zurich), Gmail suffered a global outage.
A catastrophic failure at Gmail is causing emails sent to Gmail to permanently fail and bounce back. The error message from Gmail is the following:

550-5.1.1 The email account that you tried to reach does not exist.

This is a global issue, and it impacts all email providers trying to send email to Gmail, not just ProtonMail.

Because Gmail is sending a permanent failure, our mail servers will not automatically retry sending these messages (this is standard practice at all email services for handling permanent failures).
We are closely monitoring the situation. At this time, little can be done until Google fixes the problem. We recommend attempting to resend the messages to Gmail users when Google has fixed the problem. You can find the latest status from Google's status page:

https://www.google.com/ap...8fadee664c68c240ff9f529ab

Best Regards,
The ProtonMail Team
Wij hadden hier om 21:12 al last van de storing.

Mail van Fastmail naar gmail lukte niet. Van die gmail naar Fastmail wel weer. Van die gmail naar een andere gmail ook niet maar de andere kant op weer wel. Er was geen touw aan vast te knopen waarna ik zelf de conclusie trok dat het iets in Gmail moest zijn tot frustratie van mn vrouw.
Ik had dit probleem eerder op de dag ook al dat er mail bounced met de 'mailbox bestaat niet' , ik dacht eerst dat het een probleem was bij m'n domeinnaam provider maar dit verklaart meer.
Ik dacht dat de storing alleen om @gmail.com adressen ging? Naar jij hebt het over een eigen domeinnaam?
Ik zei, ik dacht in eerste instantie dat het aan mijn domein lag, maar was dus Gmail. Maar het probleem speelde al eerder en langer dan alleen deze grote storing

Op dit item kan niet meer gereageerd worden.