Sändningsgränsen på ditt webbhotell: vad som händer med mejlen ovanför taket

Siffran för hur många mejl ditt webbhotell släpper ut per timme är sällan hemlig. Den står i supportwikin och tar tio sekunder att googla fram. Det som avgör om du märker något är i stället vad som händer med mejl nummer 1001. Där gör de tre stora kontrollpanelerna tre helt olika saker. Meddelandet kan studsa tillbaka till dig, ligga kvar i kö och gå iväg nästa timme, kastas tyst, eller rapporteras till din e-postklient som fel lösenord. Sista ledet i kedjan, WordPress, är dessutom byggt så att felet aldrig når din skärm.

Vi har inte skickat skarpa testutskick mot någon av gränserna nedan. Vi har läst det värdarna och panelerna själva publicerar, hämtat 14 september 2026, och lagt uppgifterna bredvid varandra. Det räcker för att visa något som är mer användbart än siffrorna i sig, nämligen att de inte går att jämföra rakt av.

Ovanför taket gör panelerna tre olika saker

Nästan alla svenska delade webbhotell körs på en kontrollpanel, alltså den administrationsprogramvara (control panel) som leverantören bygger sin tjänst ovanpå. I praktiken betyder det cPanel, Plesk eller DirectAdmin. Sändningsgränsen (sending limit) sätter värden själv, men mekaniken ovanför gränsen kommer från panelen. Den är tre olika historier.

cPanel skickar, köar och kastar

cPanel gör tre saker i tur och ordning när en domän passerar sitt tak. cPanels egen kunskapsbasartikel om sändningsgränser (mail limiting) räknar upp reglerna i ett räkneexempel där timtaket är satt till 100 och köprocenten till 200.

"The mail server sends the first 100 outgoing messages ... queues the next 100 ... discards any additional outgoing messages from the domain. In the following hour, the mail server attempts to send all queued outgoing messages."

Märk ordet discards. Det är varken en studs eller ett felmeddelande, det är ett meddelande som upphör att existera. Hur stor kudden mellan att köas och att kastas är styrs av inställningen email_send_limits_defer_cutoff, som i standardläge står på 125. Ligger servern kvar på förvalet köas alltså bara de mejl som hamnar mellan 100 och 125 procent av taket. Allt därutöver försvinner.

Nästan varje engelsk felsökningstråd blandar ihop två saker som hör hemma i skilda mekanismer. Felsträngen R=enforce_mail_permissions: Domain example.com has exceeded the max defers and failures per hour ... Message discarded. ser ut att handla om sändningsgränsen men hör till en annan mekanism, kvoten för misslyckade och uppskjutna leveranser. Får du den strängen har du alltså inte nödvändigtvis slagit i taket, du har skickat till för många adresser som inte tar emot.

Plesk bryr sig mindre om siffran än om hierarkin

Hos Plesk är det intressanta inte var taket ligger utan vem som äger det. Gränserna är staplade i nivåer, från abonnemang ner till domän och vidare till enskild brevlåda. En nivå högre upp trumfar alltid nivån under. Plesks dokumentation skriver det rakt ut.

"if the limit for a subscription is reached, no domains of this subscription can send mail, even when some of the domains have not yet reached their individual limit."

Så långt är det bara logik. Den detalj som gör Plesk verkligt förrädisk står några rader längre ner i samma dokument. Vi har inte sett den beskriven på svenska någonstans. Vilken PHP-hanterare (PHP handler) webbplatsen kör avgör vilket tak skriptets mejl räknas mot. Körs PHP som mod_php under Apache bokförs mejlet på domänen. Körs det som CGI eller FastCGI bokförs det på abonnemanget, men inte på domänen.

Konsekvensen är obehagligt konkret. Du öppnar panelen, tittar på domänens räknare, ser noll skickade mejl och drar slutsatsen att gränsen omöjligt kan vara problemet. Samtidigt ligger abonnemanget över sitt tak och blockerar varenda domän under sig. Felet du får tillbaka lyder 5.7.0 Your message could not be sent. The limit on the number of allowed outgoing messages was exceeded.

DirectAdmin rapporterar taket som fel lösenord

DirectAdmin räknar inte per timme utan per dygn, vilket i sig ändrar hela felbilden. Ett timtak återställer sig medan du hämtar kaffe. Ett dygnstak gör det inte. En butik som slår i det på förmiddagen skickar inga orderbekräftelser resten av dagen. DirectAdmins dokumentation beskriver det som "a daily limit for the maximum number of total sends all accounts and scripts under this User can send".

Och så det starkaste enskilda fyndet i hela materialet, hämtat ur samma dokument.

"Update Exim to the latest version, which can support smtp-time blocking, so that if a limit is reached, the smtp-auth send will return an invalid password error."

Läs den meningen en gång till. När dygnstaket är nått svarar servern inte att gränsen är nådd, den svarar att lösenordet är fel. Symtomet du möter blir alltså att Outlook eller Apple Mail plötsligt börjar tjata om lösenordet till en brevlåda som fungerade i morse. Det felet felsöks nästan alltid åt fel håll, med nya lösenord, ominstallerade konton och samtal till supporten om kontot kan vara kapat. Kommer tjatet mitt i ett utskick är sändningsgränsen den första förklaringen att pröva, inte den sista.

Varför WordPress aldrig berättar det

Ingen av mekanismerna ovan syns i WordPress. Det beror inte på en bugg utan på hur kedjan är byggd.

Det börjar hos PHP. Manualen för mail() är ovanligt ärlig om vad returvärdet betyder, eller snarare inte betyder. Funktionen "returns true if the mail was successfully accepted for delivery", och sedan följer varningen direkt. "It is important to note that just because the mail was accepted for delivery, it does NOT mean the mail will actually reach the intended destination." Sant betyder att den lokala mejlservern tagit emot meddelandet. Inget mer.

WordPress väljer uttryckligen den transporten. I kärnans wp-includes/pluggable.php står raden $phpmailer->isMail();, alltså instruktionen att lämna över till PHP:s inbyggda funktion i stället för att tala SMTP själv. Går något fel körs do_action( 'wp_mail_failed', ... ) följt av return false;. Ingen kö, ingen omkörning, ingen notis i adminpanelen. Har inget tillägg kopplat in sig på den kroken händer bokstavligen ingenting.

I samma fil ligger en kodkommentar som är svår att läsa som något annat än ett erkännande.

"default to wordpress@$sitename. Some hosts will block outgoing mail from this address if it doesn't exist, but there's no easy alternative."

WordPress vet alltså att avsändaradressen kärnan väljer kan blockeras av webbhotellet, och skriver det i sin egen källkod. Håll isär det här från den vanligare felklassen, mejl som kommer fram men hamnar i skräpkorgen. Det som beskrivs ovan är motsatsen. Mejlet lämnar aldrig servern, och därför finns det ingenting att leta efter i mottagarens spamfilter.

WooCommerce har ingen omkörningskö

Frågan dyker upp varje gång, så vi kan stänga den. WooCommerce försöker inte igen.

Metoden send_transactional_email() i class-wc-emails.php fångar bara Exception, och wp_mail() kastar aldrig någon exception vid fel. Den returnerar false. Felet passerar alltså rakt förbi den enda plats där det hade kunnat fångas upp.

Det finns en DeferredEmailQueue, och namnet lurar lätt. Den är en fördröjningskö, inte en omkörningskö. Vad den gör är att lägga varje mejl som ett eget jobb i Action Scheduler när sidladdningen avslutas, så att kunden slipper vänta på utskicket medan kassan laddar. Den finns sedan WooCommerce 10.8 och ligger bakom en funktionsflagga, deferred_transactional_emails, vilket betyder att den inte är aktiv i alla installationer. Det som gör den farlig att luta sig mot kommer i nästa steg. Action Scheduler markerar jobbet som slutfört även när mejlet aldrig lämnade servern. Loggen ser ren ut. Kunden fick ingen orderbekräftelse. Samma sorts tysta fel gör att WooCommerce beter sig oberäkneligt på billiga webbhotell, fast här finns inte ens en felsida att gå efter.

De svenska siffrorna, och varför de inte går att jämföra

Så här beskriver de svenska värdarna själva sina gränser. Varje rad är hämtad från leverantörens egen publika sida den 14 september 2026, och kolumnen längst till höger återger deras egen beskrivning av vad som händer ovanför taket.

Titta på tredje kolumnen i stället för på den andra. Där står sju olika nämnare, nämligen konto, domän, adress, inloggning, mottagare, kundförhållande och paket. Loopias 200 per konto är i praktiken strängare än Websupports 300 per adress, som i sin tur ligger långt under samma värds 2 000 per domän. Har du fem brevlådor på en domän betyder de två siffrorna helt olika saker för dig. En rak rankning efter siffra säger därför ingenting. Det är precis en sådan rankning de engelska affiliatelistorna över "email sending limits by host" bygger hela sin existens på.

Att flera värdar inte publicerar någon siffra alls är ingen skampåle. Flera av dem hör till de högst betygsatta i våra jämförelser, och en gräns som sätts från fall till fall kan mycket väl vara generösare än en publicerad. Effekten för dig är ändå densamma. Vill du veta vad som gäller innan du trycker på skicka får du fråga. Förberedelsen blir din uppgift i stället för värdens. PRO ISP förtjänar en egen anmärkning, eftersom deras rad lätt läses fel. De döljer ingenting. Tvärtom publicerar de de mest detaljerade siffrorna i hela tabellen, men de gör det på norska, eftersom proisp.se numera leder vidare till den norska sajten.

Miss Hostings 300 är en annan sorts siffra

Miss Hostings tal står inte i kunskapsbasen utan i § 7.4 i de allmänna villkoren. Vi gick igenom hjälpavsnittet på både svenska och engelska, tretton artiklar vardera, utan att hitta något om sändningsgränser. I villkoren står att bolaget "äger Miss Hosting rätt att stänga av Kund omgående. Miss Hostings riktlinjer är 300 e-postmeddelanden per timme från våra IP-adresser".

Det är inte ett tekniskt tak som studsar enskilda mejl. Det är en avtalsrisk. Skillnaden spelar roll i praktiken, för ett tekniskt tak drabbar ett utskick medan en avstängningsrätt kan drabba hela kontot. Den distinktionen görs inte i någon jämförelse vi har sett.

Oderland förklarar kön, inte bara siffran

En värd sticker ut på ett sätt som förtjänar att sägas rakt ut. Oderland är den enda svenska leverantör vi hittar som förklarar själva kömekaniken i stället för att bara publicera ett tal.

"Om du därför till exempel skickar ut 1000 mail första timmen, varav 500 mail ligger kvar i kön, kommer du bara kunna skicka 500 mail timmen därpå."

Den meningen är värd mer än siffran den beskriver. Vad den säger är att gränsen mäter kön, inte utskicket, och att oleverbara adresser ligger kvar där i flera dygn innan servern ger upp. En dålig mottagarlista sänker alltså inte bara timme ett. Den äter upp timme två också, och timme tre, medan du sitter och undrar varför utskicket går trögare för varje omgång.

Åldern på siffrorna är en del av svaret

Datumen i tabellen är inte kosmetik. Ungefär hälften av uppgifterna ligger två till fyra år tillbaka i tiden. Två av värdarna daterar inte sina sidor alls. Vi hämtade allt den 14 september 2026, men en publicerad siffra kan ha ändrats utan att sidan daterats om. Läs tabellen som en karta över hur värdarna beskriver sina gränser, inte som en mätning av vad servrarna gör i dag.

Rådet alla ger kan flytta dig till ett hårdare tak

Standardrådet i varje WordPress-guide är att sluta lita på PHP:s mail() och i stället koppla in ett SMTP-tillägg. Vi ger det rådet själva i vår genomgång av varför WordPress-mejlen hamnar i skräpkorgen. Rådet står sig. Autentiseringen blir bättre och leveransen blir bättre. Men bytet gör en sak till. Simply.com illustrerar den ovanligt tydligt eftersom de driver två SMTP-servrar med rakt motsatta regler.

• smtp.simply.com är klientvägen och är i deras dokumentation märkt "Får inte användas av Simply.com-webbservrar". Den avvisar vid 300 utgående per minut per avsändare, per avsändardomän och per inloggning, samt vid 1 000 per timme per inloggning.
• websmtp.simply.com är skriptvägen och är märkt "Får endast användas från Simply.com-webbservrar". Om den skriver de "Ingen begränsning på antal mejl."

Pekar du SMTP-tillägget mot den första av de två går du alltså från ingen publicerad gräns till ett hårt tak. Du gör det stick i stäv med värdens egen anvisning. Hos One.com lutar det åt andra hållet, där ligger klientvägen på 250 per timme medan skriptvägen får 60 per minut. Samma åtgärd ger med andra ord motsatt effekt beroende på vilken värd du sitter hos.

Poängen är att bytet också byter vilken räknare dina mejl bokförs mot. Den är värd att kontrollera före bytet i stället för efteråt.

Fyra frågor till supporten

"Vad tillåter min plan" ger dig ett tal utan sammanhang. Tabellen ovan visar varför ett tal inte räcker. Fyra frågor gör jobbet i stället.

1. Vilken siffra gäller för mitt paket?
2. Per vad räknas den, per konto, per domän, per adress eller per inloggning?
3. Vad händer med de meddelanden som hamnar ovanför gränsen? Studsar de, köas de till nästa period, eller kastas de?
4. Gäller samma tak för skript som för e-postklienten?

Den fjärde är den ingen ställer, och ofta den som avgör. Den skiljer mejlen som din webbplats skickar från dem du själv skriver i Outlook. Som Plesks regel om PHP-hanteraren och Simply.coms två servrar visar kan de två vägarna räknas mot helt olika tak hos en och samma leverantör.

Om du faktiskt ska skicka mycket

Vanlig korrespondens och massutskick är inte samma trafik. Flera värdar säger det själva. Wopsa skriver rakt ut att deras mejlservrar "inte [är] byggda för att användas för nyhetsbrev/massmailutskick". Inleed löser det genom att sälja nyhetsbrev som en separat produkt vid sidan av webbhotellet. Den produkten har dessutom en egen uppsättning DNS-poster, alltså egen SPF, DKIM och DMARC, vilket är samma sak som att säga att utskicken går ut genom en annan dörr än webbhotellets vanliga mejlserver. Båda säger i praktiken samma sak. Webbhotellets mejlserver finns där för att din sajt ska kunna skicka lösenordsåterställningar och orderbekräftelser, inte för att skjuta iväg tusen nyhetsbrev på en förmiddag.

Ska du göra ett riktigt utskick behöver du alltså en annan sorts tjänst, inte ett högre tak på den du redan har. Ska du bara få WooCommerce att sluta tappa orderbekräftelser är det tre saker som gäller. Ta reda på vilken nämnare din värd räknar mot, kontrollera om skript och e-postklient delar tak, och sluta läsa tystnad som en bekräftelse på att mejlet gick fram. Blanda för övrigt inte ihop det här med lagringsutrymmet. Det taket handlar om inkommande mejl som äter av din diskkvot, medan allt ovan handlar om utgående sändning. De två gränserna träffas oberoende av varandra och kräver var sin felsökning.