Mails om nye ordrer nåede ikke frem til en administrators Gmail-indbakke. De landede ikke i spam, de kom simpelthen ikke frem, og det frustrerende var, at WordPress’ egen wp_mail() -funktion konsekvent meldte succes ved hvert forsøg. Det udelukkede de sædvanlige mistænkte: et fejlagtigt kald af mailfunktionen, en plugin-konflikt eller et servernedbrud.
Hvorfor “den siger, den har sendt” ikke betyder “den er kommet frem”
wp_mail() der returnerer true , bekræfter kun, at beskeden blev overdraget til serverens lokale mailsystem til levering. Den siger intet om, hvad der sker efter overdragelsen, herunder om den modtagende mailserver (her Gmail) faktisk accepterede beskeden eller kasserede den i stilhed.
Headeren, der skjulte det egentlige problem
Den egentlige årsag lå i beskedens headere: WooCommerces konfigurerede afsenderadresse var en @gmail.com -adresse, mens selve beskeden fysisk blev sendt af hostingserverens eget mailsystem, ikke af Googles. Gmails SPF-poster (Sender Policy Framework) giver kun Googles egen infrastruktur lov til at sende mails, der påstår at komme fra en @gmail.com -adresse. En besked, der påstår at være fra Gmail, men kommer fra en uvedkommende server, dumper tjekket direkte, og Gmails spamforsvar opfatter et fejlet SPF-tjek på en besked, der udgiver sig for at være en af deres egne adresser, som et stærkt tegn på forfalskning, især når modtageren også er en Gmail-adresse.
Resultatet: beskeden blev i stilhed smidt væk eller filtreret som spam, længe før den nåede en indbakke, hvilket netop er grunden til, at den aldrig dukkede op, heller ikke i spam.
Rettelsen på én linje
Butikkens eget domæne havde allerede en gyldig SPF-post, der godkendte hostingudbyderens mailservere; den blev bare ikke brugt, fordi afsenderadressen pegede på Gmail. At ændre WooCommerces afsenderadresse til et domæne, som den afsendende server faktisk er godkendt til (orders@[storedomain].com), løste det med det samme: en testordremail landede i indbakken inden for et minut, uden nyt plugin, uden SMTP-relay og uden DNS-ændringer.
Det vigtigste
- “Funktionen meldte succes” og “mailen blev leveret” er to forskellige påstande; fejlfinding af levering kræver, at man tjekker autentificering, ikke kun afsenderkaldet.
- At bruge en Gmail-adresse som afsender, når beskeden ikke faktisk kommer fra Googles servere, er en næsten sikker måde at dumpe SPF og blive filtreret fra i stilhed.
- Tjek domænets eksisterende SPF-post, før du griber efter et nyt SMTP-plugin; ofte findes godkendelsen allerede og bliver bare ikke brugt.
Læs også: hvad vedligeholdelse af en hjemmeside reelt dækker, en 403-fejl, der kom og gik, forårsaget af cache-TTL.
Støder du på en lignende begrænsning i din egen WooCommerce- eller WordPress-admin? Lad os tale — ArtinTech Solution bygger netop den slags skræddersyede værktøjer til webshops.