Prova appens utskick skarpt mot tre olika mottagardomäner och läs byggverktygets utskickslogg efteråt. Två helt olika fel ser likadana ut från din sida: brevet lämnade aldrig tjänsten, eller brevet skickades men släpptes inte fram. Bara loggen skiljer dem åt, och bara ett av felen har med skräppost att göra.
Två olika fel ser likadana ut i din inkorg
En användare skriver ”jag fick ingen inloggningslänk”. Du provar själv, får länken direkt och hittar inget fel. Det beror på att beskrivningen täcker två situationer som inte har något gemensamt utom symtomet.
I det första fallet skickades brevet aldrig. Utskicket avvisades av tjänsten som skulle ha skickat det, ofta av en fullt avsiktlig anledning. Supabase, som ligger under flera av byggverktygens inloggning, anger att den inbyggda mejltjänsten är avsedd för icke-produktionsbruk och att den utan egen SMTP bara skickar till adresser som tillhör projektets team; övriga adresser faller med felmeddelandet ”Email address not authorized”. Dokumentationen anger också gränsen: ”Currently this value is set to 2 messages per hour”. Två brev i timmen, bara till dig och dina medarbetare. Det är inget fel i appen. Det är en inställning som gör exakt det den ska, tills den första riktiga användaren dyker upp.
I det andra fallet lämnade brevet tjänsten men stoppades eller sorterades bort på mottagarsidan. Då finns en rad i tjänstens logg, men statusen kan vara levererad, studsad eller misslyckad beroende på var kedjan bröts. Skicka inte om innan du har läst den raden: kontrollera avsändaridentiteten, mottagarens svar och eventuell inkorgsregel eller karantän var för sig.
Skillnaden är hela artikeln. Innan du vet vilket av fallen du har finns det ingenting meningsfullt att be byggverktyget rätta.
Avsändaradressen är antingen din egen eller lånad
Många appar börjar med en lånad avsändare: verktygets egen testdomän eller en förvald systemadress. Lovable anger till exempel att mejl från egen domän finns på betalplaner och att gratisplaner använder ”the default Lovable Cloud Auth sender”. Det kan räcka under ett internt prov. När brev senare fastnar hos andra mottagare är den faktiska avsändaradressen och domänstatusen därför två av de första uppgifterna att kontrollera.
Tre mekanismer beskriver hur avsändardomänen autentiseras och kopplas till den synliga avsändaren, och det är värt att veta vad de faktiskt gör — inte för att du ska ställa in dem, utan för att du ska förstå svaret du får.
none, quarantine eller reject.Följden är konkret. Skickar appen med en lånad avsändaradress är den synliga domänen inte din, och det är verktygets autentisering och avsändarrykte som följer brevet. Skickar appen från din egen verifierade domän är det ditt eget domännamn som bär brevet och som du kan följa i loggarna. Det ger kontroll över identiteten, men ingen garanti för placering i inkorgen.
I Lovable ska du inte formulera posterna själv. Tjänsten anger att SPF, DKIM och DMARC läggs till och underhålls automatiskt när domänen kopplas in, och att ändringen normalt slår igenom på några timmar men kan ta upp till 48 timmar. Har du någon som förvaltar domänen är din uppgift att vidarebefordra verktygets poster ordagrant och sedan kontrollera statusen. Använder du ett annat byggverktyg följer du dess exakta domänflöde i stället.
Grundkraven gäller dessutom även dig som skickar tio brev i veckan. Googles avsändarriktlinjer kräver SPF eller DKIM för samtliga avsändare, TLS vid överföringen och att andelen anmäld skräppost hålls under 0,3 procent enligt Postmaster Tools. Först vid minst 5 000 meddelanden per dygn tillkommer kravet på DMARC och på att den synliga avsändardomänen ligger i linje med den kontrollerade. Grundraden är alltså låg — men den finns.
Skicka ett skarpt utskick till tre mottagardomäner
Provet kräver ingen kod. Poängen är att din egen adress inte räcker som test: den kan ligga hos samma leverantör, den kan redan ha tagit emot brev från appen, och den är i flera verktyg uttryckligen tillåten när ingen annan är det.
Skriv resultatet på tre rader: mottagardomän, klockslag, var brevet hamnade, och om länken fungerade. Tre rader räcker för att skilja fallen åt. Landade allt i inkorgen har du ett fungerande utskick för de tre domänerna vid den tidpunkten — inte ett löfte om leverans till alla mottagare för all framtid. Leverans avgörs hos mottagaren, varje gång.
Läs loggen i byggverktyget innan du beställer en fix
Loggen är det som gör dig oberoende av gissningar. I Lovable sköts avsändardomänen under Cloud-fliken och Emails, och där finns både domänens status och en aktivitetslogg med mottagare, status, typ, tidsstämplar och felspår, plus mått på skickade, levererade och studsade brev över de senaste 7, 30 eller 90 dagarna. Använder du ett annat verktyg heter ytan något annat, men de tre uppgifter du är ute efter är desamma: finns raden, vad står det i status, och vilken avsändaradress användes.
Volymer och kostnader är också en orsak
- Kontrollera timgränsen innan du felsöker. Lovable anger att mejlen är begränsade till 100 brev per timme och arbetsyta. Supabase anger 2 brev per timme för standardtjänsten och 30 brev per timme som utgångsläge efter att egen SMTP kopplats in.
- Kontrollera vad volymen kostar. Lovable anger 50 000 transaktionsmejl per månad utan extra kostnad för en betald arbetsyta och 4 krediter per 1 000 brev därutöver. Siffrorna gäller Lovable och kan ändras — läs alltid ditt eget verktygs aktuella villkor innan du planerar ett utskick.
Två frågor att ställa när breven fastnar
När du har dina tre rader och en titt i loggen är beställningen kort. Be inte om en lösning först. Be om de två uppgifter som avgör vilken lösning som är rätt, och säg uttryckligen att ingenting ska ändras under tiden.
Appen skickar [inloggningslänk/bekräftelse/kvitto]. Ändra ingenting förrän du svarat på båda frågorna:
- Vilken avsändaradress skickas det här brevet från, och är den domänen verifierad i vårt konto eller är det verktygets test- eller systemdomän?
- Visa de tre senaste utskicken ur tjänstens logg med mottagare, tidsstämpel, status och eventuellt felmeddelande — ordagrant, utan tolkning.
Jag skickade tre brev [klockslag] till [tre mottagardomäner]. Resultatet var [inkorg/skräppost/inget]. Säg också om någon gräns för antal brev per timme kan ha stoppat något av dem. Om en uppgift inte går att hämta, säg det i stället för att anta.
Svaret placerar felet på ett av två ställen, och du slipper en dyr omväg: att låta modellen skriva om utskickskoden när problemet i själva verket var en avsiktlig gräns eller en lånad avsändaradress. Vill du gå vidare med egen domän är det ett eget, avgränsat steg — och glöm inte att avsändaradressen i appen måste bytas efter verifieringen. När DNS-posterna är på plats upptäcker Lovable verifieringen automatiskt; avsändaradressen i appen ändras däremot inte av det.
Klart när tre brev har landat och du vet varifrån de kom
Arbetet är klart när tre brev till tre olika mottagardomäner har nått inkorgen, när du kan peka på raden i loggen för vart och ett och när du kan svara på frågan vilken avsändaradress appen använder. Lägg de tre raderna i din provlista — utskick är precis den sortens funktion som slutar fungera vid en ändring ingen kopplade till mejl.
Provet är också en förutsättning för sajtens råd om inloggning. Guiden om data och inloggning föreslår engångslänk via mejl som ett av de enklaste sätten att slippa lösenord. Det rådet håller bara så länge brevet kommer fram, och den kontrollen hör hit, inte dit.
Kom ihåg vad som gör det här felet särskilt lömskt: en användare som aldrig fick brevet har ingenting att anmäla. Artikeln om en felrapport som går att använda visar hur du får fram en användbar beskrivning när någon väl hör av sig. Utskicken är den motsatta situationen — här hör ingen av sig, och du måste själv gå och titta.
Skickades brevet över huvud taget? Vilken avsändaradress stod på det? Är den domänen min egen och verifierad? Och när provade jag senast mot en mottagare som inte är jag?