Kort svar: Kontroller først, om ordrestatussen skal udløse mailen, og om mailtypen er aktiveret under WooCommerce → Indstillinger → E-mails. I WooCommerce 10.9 eller nyere følger du testordren i
transactional-emails-loggen. På ældre versioner findes denne core-log ikke; brug i stedet mailtransportens eller udbyderens log. En lokal “Sent” betyder aflevering til mailsystemet, ikke levering til indbakken.
Fagligt gennemgået: 28. august 2026
Kontrolgrundlag: WordPress 7.1, WooCommerce 11.0.1 og PHP 8.4.23 på isoleret staging samt aktuel produktdokumentation. Den konkrete mailtransport og DNS-opsætning skal kontrolleres i butikkens eget miljø.
Mailfejl bliver ofte behandlet som ét problem, men WooCommerce, WordPress, mailserveren og modtagerens system er fire forskellige led. En mail kan mangle, fordi ordren stadig afventer betaling. Den kan være deaktiveret, fejle ved wp_mail(), blive accepteret af SMTP og senere afvist eller ende i spam. Først når du ved, hvilket led der stoppede, kan du rette det sikkert.
På denne side
| Hændelse | Typisk modtager | Forudsætning, der skal kontrolleres |
|---|---|---|
| Ny ordre | Butikkens valgte administratorrecipient | Mailtypen er aktiv, og ordren er oprettet |
| Behandler ordre | Kunden | Betaling er registreret, og status skifter som forventet |
| Ordre på hold | Kunden | Gateway-/ordreforløbet bruger On hold |
| Mislykket ordre | Administrator og/eller kunde efter opsætning | Ordren skifter fra relevant tidligere status til Failed |
| Færdig ordre | Kunden | Ordren markeres Completed |
Udvidelser kan tilføje egne mails og betingelser. Brug derfor det præcise interne mail-ID eller navn i loggen frem for at antage, at alle “ordremails” har samme trigger.
transactional-emails; på ældre versioner går du videre til mailtransportens, SMTP-løsningens eller udbyderens log.| Fund | Hvad betyder det? | Kontrol | Næste skridt |
|---|---|---|---|
| Ordren står Afventer betaling | Betalingsmailen er muligvis ikke trigget | Gateway og ordrestatus | Løs betaling/callback først |
Disabled | Mailtypen er slået fra | E-mailindstilling | Aktivér kun den rigtige type |
Skipped | En betingelse, fx modtager, mangler | Logdetalje og ordredata | Ret den manglende betingelse |
Failed | WordPress/mailtransport returnerede fejl | Fejltekst og transportlog | Ret transport/credentials |
Sent, men ingen modtagelse | WooCommerce afleverede mailen | SMTP/provider delivery event | Undersøg bounce, spam og autentificering |
| Ingen logpost | Trigger blev ikke kørt, logging skjuler niveauet eller fatal error | Logindstilling, status og fatal log | Ret trigger/konflikt |
En ubetalt ordre i “Afventer betaling” udløser ikke de samme kundemails som en betalt ordre i “Behandler”. Ændr ikke status for at teste mails, medmindre du bruger en isoleret testordre og ved, hvilke lager-, regnskabs- og integrationshændelser statusændringen udløser.
Hvis mange mails mangler, segmenter efter mailtype og status. En enkelt manglende “Ny ordre” til administrator og alle manglende kundekvitteringer er ikke samme fejl.
Bekræft, at mailen er aktiveret, at administratorrecipient er korrekt, og at afsenderadressen bruger butikkens eget domæne. Gem ikke en tilfældig ændring; tag screenshot af den oprindelige opsætning med adresser anonymiseret.
Brug “Send igen” på en testordre kun som supplement. En gensendt mail beviser transporten, men ikke at den oprindelige ordretrigger virker.
transactional-emails-loggen i WooCommerce 10.9+Core-loggen transactional-emails kræver WooCommerce 10.9 eller nyere. Filtrer på ordre-ID og mailtype. Logklassifikationen giver retningen:
Hvis INFO/NOTICE ikke vises, kontroller logniveauet. Slå ikke omfattende debuglogging til permanent; mailsystemer kan behandle persondata.
På WooCommerce-versioner ældre end 10.9 er en manglende transactional-emails-kilde forventet og ikke bevis på, at triggeren fejlede. Brug ordrestatus og ordrenoter til at fastslå den forventede trigger, og følg derefter samme UTC-tidspunkt i den eksisterende SMTP-/mailtransport- eller udbyderlog. Hvis der ikke findes en sådan log, kan en midlertidig, privatlivssikker mail-logning afprøves på staging. Installer ikke en tilfældig logger på live alene for at producere et screenshot, og opgradér først WooCommerce efter backup og kompatibilitetstest.
“Sent” er ikke lig med leveret til indbakken. Find mailen i SMTP-/providerloggen ved tidspunkt eller message-ID. Klassificér den som accepteret, leveret, midlertidigt forsinket, bounced eller afvist. Kontroller SPF, DKIM, DMARC, afsenderdomæne og modtagerens spam-/karantænelog uden at offentliggøre adresser.
Hostious har en intern forklaring af SPF, DKIM og DMARC. DNS-autentificering forbedrer ikke en mail, som WooCommerce aldrig forsøgte at sende.
Hvis mailudvidelsen sender asynkront, kontroller WooCommerce → Status → Planlagte handlinger og pluginets egen kø. Find det konkrete ordre-ID eller hook. Kør ikke hele køen manuelt; du kan udsende gamle mails eller belaste shoppen. Brug guiden til forfaldne handlinger ved en voksende backlog.
Brug WooCommerce, standardtema og den valgte mailtransport. Opret nye testordrer; gamle ordrer kan indeholde gemte recipient-/template-data. Tilføj maildesign, ordrestatus- og checkoutudvidelser igen enkeltvis, og sammenlign logklassifikationen.
Mailtransportens hændelser skal læses i kronologisk rækkefølge. “Accepted” betyder normalt kun, at næste mailserver tog imod beskeden. “Delivered” er stærkere, men kan stadig ende i spam eller karantæne. En “soft bounce” kan blive genforsøgt, mens en permanent afvisning kræver rettelse af adresse, autentificering eller policy.
Sammenlign mindst to testmodtagerdomæner, hvis kun enkelte kunder mangler mail. Hvis alle mails til ét domæne afvises, er global WooCommerce-konflikttest sjældent første valg.
Mail- og ordredatasæt indeholder personoplysninger. Del kun message-ID, status, UTC-tid og redigeret fejltekst med de parter, der skal fejlsøge. Slå midlertidig verbose logging fra efter testen, og følg butikkens retentionpolitik. Screenshots skal bruge en dedikeret testadresse og må ikke vise andre ordrelinjer i baggrunden.
En testordre skifter til “Behandler” kl. 08.32. transactional-emails viser den forventede kundemail som Sent, og mailtransporten registrerer samme Message-ID som accepteret få sekunder senere. Modtagerens server afviser derefter beskeden med en permanent policyfejl. WooCommerce har i dette forløb både udløst og afleveret mailen korrekt; en plugin-konflikttest vil derfor være et sidespor.
Næste kontrol er afsenderdomæne, SPF/DKIM/DMARC-resultat og den konkrete afvisningskode. Når den er rettet, oprettes en ny testordre. Brug ikke bare “send igen” på den gamle ordre, hvis målet er at kontrollere triggeren fra start til slut.
Det omvendte forløb er en ordre, der står “Behandler”, men slet ikke har en post for den forventede mailtype. Kontrollér først, om mailen er aktiveret og har en gyldig recipient. Findes begge dele, sammenlignes statusovergangen med en ny testordre og loggen omkring triggeren. Her er DNS ikke første kontrol, fordi WooCommerce endnu ikke har afleveret noget til mailtransporten.
En mail kan blive genereret, men være tom, mangle ordrelinjer eller have ødelagt layout. Det er ikke samme problem som manglende levering. Hvis transporten viser “Delivered”, åbnes den modtagne testmail og dens rå headers, mens template-overrides og mailcustomizer testes på staging. Kontrollér både HTML- og tekstversion, fordi nogle modtagere eller systemer bruger tekstalternativet.
Gem en kopi af den nuværende templateoverride før ændring. Hvis standardmailen indeholder de korrekte data, men den tilpassede ikke gør, ligger fejlen i skabelonen eller dens hooks – ikke i SMTP.
Sent i core-loggen og en leveret event i mailtransporten; på ældre versioner dokumenteres overdragelsen i den eksisterende transport-/udbyderlog.Gendan tidligere mailtype-, afsender- eller SMTP-indstilling. Hvis en DNS-ændring indgår, gem den tidligere record og TTL, og rollback kun efter en valideret plan. Gensend ikke alle gamle ordrer efter rollback; udvælg testordren eller en godkendt kundeliste.
Mailtransporten skal have message-ID og deliveryevent. Hosting skal have wp_mail()-/PHP-fejl og tidspunkt. Pluginudvikleren skal have trigger, ordrestatus og stagingreproduktion. Se mail hosting hos Hostious for domænebaseret maildrift.
Sender sitet stadig med PHP mail, er der ingen godkendt afsender bag beskederne. Send i stedet via SMTP fra en rigtig postkasse på eget domæne — se email hosting.
Tre mulige led: mailen blev aldrig trigget (forkert ordrestatus), aldrig sendt (wp_mail/transport fejler) eller afvist hos modtageren (SPF/DKIM mangler). Find ud af hvilket led, før du ændrer noget.
Send via en SMTP-forbindelse eller mailtjeneste i stedet for serverens standard-PHP-mail, og sæt SPF, DKIM og DMARC på domænet. Det løser langt de fleste leveringsproblemer.
Så er transporten ok, og problemet ligger i mailtypen eller modtagelsen: tjek at kundemailen er aktiveret i WooCommerce → E-mails, og om kundens mailudbyder afviser på grund af manglende autentifikation.
Gem den relevante mailindstilling med adresser skjult, ordrenoten, transportens leveringsstatus og – på WooCommerce 10.9 eller nyere – et anonymiseret udsnit af transactional-emails-loggen. På ældre versioner bruges mailtransportens egen log eller en midlertidig, dataminimeret logkilde. Kobl signalerne sammen med ordre-ID, mailtype, UTC-tidspunkt og Message-ID.
Efter rettelsen skal testen bruge samme ordreflow som den oprindelige fejl. En generel “send testmail”-knap beviser kun, at transporten kan sende noget; den beviser ikke, at en bestemt WooCommerce-trigger bliver udløst. Dokumentér både ordrestatusændringen, den valgte mailtype, transportens accept og præcis én levering til en kontrolleret testpostkasse.