Vad är en catch-all-adress? Så fungerar den, varför verifieringstjänster inte kan bekräfta den och hur du säkert mejlar till den

En catch-all-adress är en adress på en domän vars e-postserver tar emot alla meddelanden, oavsett vad som står före @. Servern säger aldrig om en brevlåda finns, så en verifieringstjänst svarar ”catch-all” i stället för giltig eller ogiltig. I Sponas egna kontroller hamnade 14,25 % av 40 000 adresser i den gruppen.

Den här guiden utgår från B2B-avsändarens perspektiv. Den visar vad servern gör under en verifieringskontroll, varför företag ställer in den så och vad varje verifieringstjänst kallar resultatet. Den visar också vad som hände när en kund skickade 1 200 mejl till catch-all-adresser. Hur du själv sätter upp en catch-all-brevlåda besvaras kort i FAQ-delen.

Get thousands of leads in 4 minutes.

Stop stitching tools together.
Start with verified sales data, delivered in minutes.

SCALE SALES NOW

No contracts · No setup · No onboarding

Catch-all e-post: en catch-all-adress tar emot post till alla adresser

Två grupper använder begreppet, och de menar två olika saker.

För en e-postadministratör är en catch-all en brevlåda. Proton beskriver det som möjligheten att ”ta emot all e-post som skickas till sin domän”, även till adresser som ingen har skapat. Hos Namecheap heter det att all e-post till din domän ”som ännu inte är upplagd som e-postkonto eller e-postalias” hamnar där.

Riktiga brevlådor behåller sin egen post. Proton påpekar att e-post till en befintlig adress ”inte levereras till catch-all-adressen”.

För en avsändare är en catch-all ett verifieringsresultat. NeverBounce sammanfattar det på en rad: accept-all ”är en inställning på mottagarens e-postserver, inte ett omdöme om den enskilda adressen”. Adressen du kontrollerade kan tillhöra en riktig person, vara ett stavfel eller gå till någon som slutade för två år sedan. Servern sa ingenting åt något håll.

Stavningen varierar: catchall, catch-all, accept-all. Verifieringstjänster säger också ”accept all” och webbhotell säger ”wildcard”. Alla beskriver samma beteende hos servern.

Ett missförstånd orsakar mest skada. Många hör catch-all och tänker ”död adress”. Statusen säger att domänen tar emot allt. Den säger ingenting om huruvida personen finns kvar.

Så svarar en catch-all-domän på verifieringstjänstens SMTP-kontroll

En verifieringstjänst kontrollerar en adress genom att påbörja en leverans och avbryta innan något meddelande skickas. Den ansluter till domänens e-postserver, anger en mottagare och läser svaret; svaren definieras i RFC 5321, SMTP-standarden. När servern godtar mottagaren ”returnerar den svaret 250 OK”. När mottagaren är ”känd för att inte vara en levererbar adress” svarar den 550.

På en vanlig domän avgör svaret frågan. 250 betyder att brevlådan finns. 550 betyder att den inte gör det.

En catch-all-domän svarar 250 på allt. Verifieringstjänsten kan inte skilja en riktig brevlåda från en påhittad, så den gör en andra kontroll.

Hunters metod är att fråga servern om den tar emot e-post till en adress ”som garanterat inte finns”. Blir svaret ja, märks hela domänen som accept-all. Varje adress på domänen ärver sedan etiketten.

Standarden förutsåg det här: en server ”FÅR INTE returnera en 250-kod” på ett verifieringskommando om den inte faktiskt har verifierat adressen. Kan den inte det, ”BÖR kod 252 returneras” i stället. Regeln gäller kommandot VRFY. En catch-all-server svarar redan i mottagarsteget, och där betyder 250 att den tar emot meddelandet, inte att någon läser brevlådan.

Ytterligare en klausul blir viktig längre fram. En server som har tagit emot ett meddelande men sedan inte kan leverera det ”MÅSTE skapa ett meddelande om olevererbar e-post” och skicka tillbaka det. Ja-svaret vid dörren kan alltså bli ett nej efter utskicket.

Därför sätter företag upp catch-all-adresser

Hjälpsidorna hos de webbhotell som erbjuder funktionen anger två skäl. En e-postmigrering kan lägga till ett tredje.

Stavfel: one.coms exempel är en avsändare som skriver ”daivd@domain.com” i stället för david@. Utan catch-all avvisar servern meddelandet. Med catch-all hamnar det i en brevlåda som någon håller koll på.

Medarbetare som har slutat: i Google Workspace kan en administratör styra meddelanden till ”obefintliga eller felaktiga e-postadresser” till en catch-all-brevlåda. Routningsalternativet heter ”All inactive and unrecognized accounts”. Post till den som har slutat fortsätter då att nå företaget. Det är en routningsregel som en administratör ställer in, inte en standardinställning: en domän hos Google är inte catch-all om ingen har slagit på funktionen.

Migreringar: Microsoft 365 gör tvärtom. Med Directory-Based Edge Blocking kan en tenant ”avvisa meddelanden till ogiltiga mottagare vid tjänstens nätverksgräns”; svaret är ”550 5.4.1 Recipient address rejected: Access denied”. Microsoft säger åt administratörer att låta en domän stå som ”Internal relay” bara tills katalogen innehåller alla giltiga mottagare. Fram till dess kan nätverksgränsen ta emot okända mottagare, och en verifieringstjänsts kontroll kan tolka det som catch-all.

Hos Websupport är catch-all en inkorg som tar emot all e-post till adresser som inte är upplagda, och den slås på under E-post > Översikt och sedan Catch-All. Ändå rekommenderar Websupport inte funktionen, eftersom den bidrar till att mer skräppost når fram.

Spam är priset. one.com varnar alla som slår på funktionen: ”de flesta mejl som du fångar upp kommer att vara spam”.

Verifiering av catch-all: vad varje verifieringstjänst svarar

Vid e-postverifiering betyder ”catch-all” att tjänsten hittade en e-postserver som tar emot alla mottagare och därför inte kunde testa din adress.

Alla verifieringstjänster slår i samma vägg. ZeroBounce skriver att catch-all-adresser ”är omöjliga att validera utan att mejla dem” och sedan se om de studsar. MailerCheck håller med: ”det finns inget sätt att veta om de är giltiga eller ogiltiga”. Det som skiljer är etiketten, och vad leverantören gör sedan.

Etiketterna kommer från varje leverantörs egna hjälpsidor och produktsidor. Priserna för de djupare kontrollerna finns i guiden om rensning av e-postlistor, inte här.

Unknown är ett annat resultat. NeverBounce definierar det som att servern inte gav ”ett definitivt svar i tid”, ofta på grund av greylisting eller en säkerhetsgateway. En catch-all-server svarade, en server med unknown gjorde det inte.

Kontrollera en unknown igen i morgon, så kan du få ett definitivt svar. Kontrollera en catch-all igen, så får du ännu ett 250.

Hur vanliga catch-all-adresser är: Sponas 40 000 B2B-kontroller

Spona kontrollerade 10 000 unika kandidatadresser i vart och ett av fyra länder innan något skickades. Siffrorna är Sponas data, och andelen som kom tillbaka som catch-all låg mellan 12 % i Storbritannien och 16 % i Tyskland.

Andelen räknas mot alla unika kandidatadresser som kontrollerades. En adress är godkänd, catch-all eller avvisad av annat skäl, aldrig två av dem. Spona har inte mätt någon uppdelning på roll eller bransch, och de här fyra länderna är de enda som Spona har mätt. Sammantaget i alla fyra länderna kom ungefär var sjunde kontrollerad adress tillbaka utan besked.

Andra publicerade andelar beskriver andra populationer. ZeroBounce fann att ”mer än 9 %” av alla e-postadresser som det kontrollerat var catch-all, av mer än 11 miljarder behandlade adresser. MailerChecks siffra är 8,6 % av allt det har verifierat, men per kundlista stiger medianen till 15,25 %. Hunter räknar domäner i stället för adresser: ”38 % av e-postdomänerna” i ett urval på 2 572 adresser var accept-all.

Ingen av dem går att jämföra med Sponas tabell. Var och en räknar något annat på en annan lista. Det de har gemensamt är riktningen: en betydande minoritet av vilken lista du än kontrollerar.

Är catch-all-adresser riskabla för cold email? Vad en kund såg

Ja, och risken går att mäta. Sponas löpande benchmark sätter baslinjen och utesluter catch-all-adresser enligt regel: ”Hård studs är permanenta leveransfel delat med försökta utskick till den verifierade delmängden, exklusive catch-all-adresser”. På 20 000 sådana utskick var andelen hårda studsar 1,525 %.

En kund skickade ändå till catch-all-adresser och rapporterade utfallet. Under ungefär tre månader gav kundens 1 200 utskick 86 hårda studsar, som Spona loggade som en separat kohort. Det är 7,17 %. Sådana rapporter behåller sin egen nämnare för utskick och ingår aldrig i benchmarken.

Sida vid sida är kohortens andel ungefär 4,7 gånger benchmarkens.

Två förbehåll hör till den skillnaden. Siffran 7,17 % kommer från en enda kunds 1 200 utskick: det är ingen branschsiffra, och den förutsäger inte din. De två kohorterna skiljer sig också åt i mer än catch-all-etiketten, så skillnaden jämför utfall och mäter ingen orsak.

Hunter gjorde ett eget test: en kampanj till 100 accept-all-adresser och 100 giltiga adresser. Resultatet: ”Studsfrekvensen var 27 %” för accept-all-gruppen och 1 % för kontrollgruppen. Annan lista, annan avsändare, samma riktning.

Mekanismen är klausulen ur RFC 5321 ovan. En catch-all-server tar emot varje meddelande vid dörren och försöker sedan leverera det internt. När ingen brevlåda matchar måste den skicka meddelandet om olevererbar e-post. ZeroBounces varning följer av det: ”Obefintliga catch-all-adresser kommer till slut att studsa” och skada ditt avsändarrykte.

Hunter listar tre möjliga utfall för ett meddelande till en accept-all-domän: ”levererat, omdirigerat till en catch-all-inkorg eller studsar senare”. Vilket det blir får du veta först efter utskicket.

Var gränsen går: Twilio skriver att en studsfrekvens ”över 2 %” betyder att det är dags att agera, och att sunda utskicksprogram ligger under 1 %. Ett catch-all-segment som studsar som den kohorten drar hela kampanjens andel mot den gränsen när det läggs in i en verifierad kampanj.

Så kontrollerar du catch-all-adresser utöver SMTP-kontrollen

Inget verktyg kan bekräfta en brevlåda bakom en catch-all-server. Servern berättar inte, och inget annat kan svara åt den. Det de bättre verktygen gör är att uppskatta, på tre sätt.

Konfidenspoäng: Hunter sätter en poäng på sina resultat med etiketten Accept all, byggd på ”antalet källor och hur färska de är” där adressen hittades. Rådet är att behandla en poäng på ”85-100 %” som giltig, även om adressen fortfarande är något mer benägen att studsa. En poäng är en sannolikhet byggd på belägg från webben, inte ett svar från servern.

Djupare kontroller: MillionVerifier uppger att en djupare ping omvandlar ”upp till 40 %” av catch-all-adresserna till Valid eller Invalid, medan resten förblir Risky. Det är leverantörens siffra för dess egen metod, på dess egna listor. Behandla varje återvinningsgrad på samma sätt tills du har testat den på din egen lista.

Belägg utanför e-postservern: ett namn som passar företagets adressmönster, en profil hos den arbetsgivaren, ett nyligt omnämnande på företagets webbplats. Vart och ett ökar chansen att brevlådan finns. Guiden om validering av B2B-data går igenom det flödet, och inget av det ändrar serverns svar.

Det enda test som fungerar är det som kostar dig något. Att skicka ett meddelande och se om det studsar är det enda sättet, som ZeroBounce säger. Men att inget studsar kan bara betyda en catch-all-inkorg, som enligt Hunter sannolikt inte läses. Hunter påpekar att metoden väcker ”etiska frågor”, eftersom du spammar andra företag för att ta reda på det, och varje studs belastar din domäns historik.

Så mejlar du säkert till en catch-all-adress: sex steg

1. Håll ett separat segment. Catch-all-adresser ligger aldrig i samma lista som verifierade. Checklistan för datahygien håller dem i ett eget segment vid varje utskick.
2. Begränsa andelen. Hunters råd är att begränsa accept-all-adresser till en liten andel av dina kampanjer, 2 % till 5 % av utskicken. Vid den andelen skulle ett segment som studsar som kundkohorten lägga till högst några tiondels procentenheter.
3. Rangordna efter belägg. Skicka först till adresserna med hög konfidenspoäng, ett matchande namnmönster eller ett nyligt offentligt omnämnande. Spara de rena gissningarna till sist, eller hoppa över dem.
4. Skicka i små omgångar och bevaka. NeverBounce råder dig att skicka ”i små omgångar” och hålla koll på vilka som studsar tillbaka. Om din leverantör kräver en studsfrekvens ”under 4 %”, säger NeverBounce att du ska skicka selektivt i stället för att stryka adresserna.
5. Stoppa vid första studsen från en domän. En hård studs från en catch-all-domän visar att sorteringen misslyckades för det namnet. Spärra adressen direkt och pausa resten av domänen tills du har ett bättre namn.
6. Använd identiteten i en annan kanal. En catch-all-status säger ingenting om personen, så namn, företag och roll kan fortfarande vara användbara. Ett samtal eller ett LinkedIn-meddelande studsar inte. En andra kontakt på företaget kan hjälpa, men på samma domän är den personens adress också catch-all.

Så hanterar Spona catch-all-adresser, och var det brister

Spona hittar leads utifrån en chattbeskrivning av din idealkund, verifierar varje adress och levererar en poängsatt lista på ungefär 4 minuter. Catch-all-adresser går igenom samma SMTP-kontroll som allt annat. Vad som händer sedan styrs av sex regler.

Där det passar: du betalar per lead, och en catch-all-adress räknas aldrig in i antalet verifierade e-postadresser. En lead i Standard Search med enbart e-post kostar 3 till 7 krediter. Med planernas kreditpriser blir det 0,024 till 0,07 dollar.

Varje ny söksession har också en engångskostnad på 1 000 krediter.

För catch-all-poster är det regel 3 som är användbar. Spona behåller personens post, och berikning kan lägga till ett mobilnummer för 35 krediter. Det är 0,28 till 0,35 dollar, och samtalet flyttar till telefonen. Varje sökning börjar med ett gratis urval, och Free-planen har 3 000 engångskrediter.

Där det brister: Spona kan inte heller bekräfta en catch-all-brevlåda; exporten av catch-all saknar avsiktligt påståenden om brevlåda eller studsfrekvens. Spona säljer ingen resolver och ingen konfidenspoäng för de posterna, vilket Hunter och MillionVerifier gör.

Landstabellen omfattar bara USA, Storbritannien, Tyskland och Frankrike, utan uppdelning på roll eller bransch. Kohorten med 1 200 utskick är en enda kunds rapport, loggad för att den kunden skickade in den. Spona skickar inte din e-post och ser därför catch-all-studsar bara när en kund rapporterar dem.

Get thousands of leads in 4 minutes.

Stop stitching tools together.
Start with verified sales data, delivered in minutes.

SCALE SALES NOW

No contracts · No setup · No onboarding

Vanliga frågor om catch-all-adresser (FAQ)

Hur sätter jag upp en catch-all-adress?

I e-postleverantörens administrationsinställningar, inte i ett e-postprogram. Proton tillåter det på ”alla betalda Proton-planer” under Settings, All settings, Organization, Domain names och sedan Set catch-all. Google Workspace använder en routningsregel för ”All inactive and unrecognized accounts” som ”kan ta upp till 24 timmar” att börja gälla. Microsoft 365 gör tvärtom och avvisar okända mottagare redan vid nätverksgränsen.

Vad är en catch-all-domän?

En catch-all-domän är en domän vars e-postserver tar emot e-post till alla adresser, även adresser som inte finns. Verifieringstjänster upptäcker den genom att testa en påhittad adress: ett 250 på den märker domänen. Varje adress på domänen får sedan statusen catch-all, så statusen beskriver domänen, inte personen.

Är en catch-all-adress ogiltig?

Nej. Ogiltig betyder att servern avvisade adressen med 550. Catch-all betyder att servern tog emot den tillsammans med allt annat, så adressen kan mycket väl tillhöra en riktig person. I Sponas kontroller är godkänd, catch-all och avvisad av annat skäl separata kategorier, och varje adress hamnar i bara en av dem.

Studsar catch-all-adresser?

Vissa gör det, efter att servern har tagit emot dem: den tar emot meddelandet, hittar ingen matchande brevlåda och skickar tillbaka ett meddelande om olevererbar e-post. En kunds 1 200 utskick till catch-all-adresser gav 86 hårda studsar. I Hunters test hade 100 accept-all-adresser en studsfrekvens på 27 %. Ingen av siffrorna förutsäger hur din lista beter sig.

Ska jag ta bort catch-all-adresser från min lista?

Inte automatiskt. Hunters hållning är att accept-all-adresser ”inte bör kasseras automatiskt”, och att ingen heller bör behandla dem som helt giltiga. Håll dem i ett eget segment, mejla de bäst underbyggda i små omgångar och flytta resten till telefon eller LinkedIn. MailerCheck beskriver en vanlig respitperiod på 3 till 6 månader utan öppningar eller klick innan borttagning.