Kontrollera e-post blacklist: Det verktygen inte berättar

Kör din avsändande IP genom en uppslagning mot flera listor så får du en tabell med gröna och röda rader. Den tabellen svarar på en smal fråga: finns den här adressen just nu på någon av de publika DNS-blocklistorna? Att kontrollera e-post blacklist säger alltså inget om Gmail, Outlook eller en företagsgateway kommer att ta emot nästa meddelande. Att behandla de två frågorna som samma är precis där de flesta incidenttidslinjer börjar gå fel.

Den här guiden går igenom vad en kontroll faktiskt frågar, hur du kör en själv med dig, vilka svarskoder som betyder ren och vilka som betyder att din fråga blev avvisad, och hur du kopplar ihop allt med övervakning så att du slutar göra det för hand klockan två på natten.

En blacklist-kontroll är en DNS-fråga, inget mer

Varje DNS-blocklista (DNSBL) fungerar på samma sätt. Du vänder på oktetterna i IPv4-adressen, lägger till listans zon och frågar efter en A-post. RFC 5782 beskriver konventionen: för 192.0.2.99 mot bad.example.com blir frågan 99.2.0.192.bad.example.com. Står adressen på listan får du ett svar i intervallet 127.0.0.0/8. Gör den inte det får du inget svar alls.

Den mekanismen är hela grejen. Webbverktygen där du klistrar in en IP kör dussintals sådana uppslagningar parallellt och formaterar svaren åt dig.

# Står 203.0.113.25 på Spamhaus ZEN?
dig +short 25.113.0.203.zen.spamhaus.org A

# En domänbaserad lista fungerar likadant, fast utan omvändning:
dig +short example.com.dbl.spamhaus.org A

Tomt svar betyder inte listad. Ett svar i 127.x.x.x betyder listad, och de sista oktetterna visar vilken underlista som träffade. Kör det från en maskin du kontrollerar, mot din egen resolver, så kan du skripta det, logga det och larma på det.

Kontrollera adressen din post faktiskt lämnar ifrån, inte den din webbplats använder

Det första misstaget är att slå upp fel IP. Din marknadssajt, ditt API och din utgående mailrelay är oftast tre olika adresser. Den som spelar roll är IP:n i Received-headern på ett meddelande som faktiskt kom fram till en brevlåda.

Skickar du via en ESP på delad infrastruktur är den IP:n inte din, och listningen är inte din heller. Skickar du från en dedikerad IP är den helt din, inklusive allt den förra användaren av adressintervallet gjorde.

Hämta avsändande IP från ett levererat meddelande, inte från en inställning i en dashboard. Kontrollera sedan tre saker var för sig: den avsändande IP:n, envelope- och From-domänen, och varje domän som finns i dina länkar, inklusive spårnings- och avregistreringsvärdar. URI-baserade listor som URIBL och SURBL bedömer länkarna i meddelandets brödtext, så en ren IP skyddar inte ett meddelande som pekar på en listad domän.

Ett rent svar från en publik resolver kan vara ett avslag i förklädnad

Det här är felläget som de generiska kontrollsidorna aldrig nämner. Spamhaus besvarar inte frågor som kommer via publika eller öppna resolvers, och signalerar det med en returkod i stället för en listning. Spamhaus dokumenterar 127.255.255.254 som en felkod, inte som ett rykteresultat, och säger att den aldrig ska användas för att avvisa post.

Det ger två konsekvenser. Tolkar ditt skript vilket 127.x-svar som helst som listad, larmar en avvisad fråga från en moln-resolver om en listning som inte finns. Tolkar det i stället ett svar utan användbart innehåll som ren, missar du tyst riktiga listningar, eftersom avslaget också kan se ut som ett tomt svar eller NXDOMAIN.

Lösningen är att köra uppslagningar från en värd med egen rekursiv resolver och korrekt omvänd DNS, eller att använda den kostnadsfria frågetjänst som Spamhaus hänvisar publika mirror-användare till. Validera sedan zonen innan du litar på den. RFC 5782 kräver att IPv4-listor har en post för 127.0.0.2 och ingen för 127.0.0.1, så du kan testa din uppsättning så här:

dig +short 2.0.0.127.zen.spamhaus.org A   # måste ge ett 127.x-svar
dig +short 1.0.0.127.zen.spamhaus.org A   # måste ge inget svar

Ger båda tomt svar är din resolver-väg trasig eller avvisad. Åtgärda det innan du läser något resultat därifrån.

De flesta leveransincidenter är inte blocklistincidenter

När vi går igenom en studsrapport är första frågan alltid vad den mottagande servern faktiskt skrev, innan vi kör någon uppslagning. En listning ger ett specifikt avslag. Ett rykteproblem hos en brevlådeleverantör ger ett annat, och ingen publik lista visar det.

Googles avsändardokumentation är tydlig med det. Ett 550 5.7.1-svar kan betyda att den avsändande IP:n står på en avstängd lista, ofta på grund av dåligt rykte på delad IP, medan 5.7.26 pekar på misslyckad autentisering. För massutskick kräver Google SPF, DKIM och DMARC, giltiga framåt- och bakåtuppslagningar för avsändande IP, TLS och en skräppostfrekvens under 0,30 % i Postmaster Tools. Gmails avsändarkrav anger 0,10 % som rekommenderat mål.

Läs det som en ordningsföljd. Nämner studsmeddelandet en DNSBL-zon har du ett listningsproblem. Talar det om rykte, autentisering eller hastighetsbegränsning kommer en blocklistuppslagning att visa ren, och du har slösat en timme på att bekräfta det.

• Nämner en DNSBL-zon eller URL: du står på just den listan. Kör uppslagningen och använd listans egen sida för borttagning.

• 550 5.7.1 med formuleringen om IP-rykte: leverantörens rykte, ofta på delad IP. Kontrollera Postmaster Tools och trenden för volym och klagomål.

• 5.7.26: autentiseringen misslyckades. Kontrollera SPF-, DKIM- och DMARC-anpassningen.

• 4.7.28 eller formulering om hastighet: du skickar för snabbt för ditt nuvarande rykte. Dra ner takten och bygg upp den igen.

Sluta använda en engångskontroll i webbläsaren som övervakning

En enskild uppslagning visar läget i det ögonblick du trycker på enter. Listningar är ofta tillfälliga, och många dyker upp efter en topp som du själv orsakade: en kall import, en blast för ny inhämtning av tillstånd, ett komprometterat formulär som någon använde för att skicka skräppost vidare.

Verktygen som tar betalt för att "ta bort dig från 100 blocklistor" säljer en tjänst för ett problem som de flesta av de listorna inte har. Många av listorna i en typisk kontroll med flera uppslagningar påverkar de stora brevlådeleverantörerna försumbart, och borttagningen är oftast gratis och självbetjänt på operatörens egen sida. Att jaga varje röd rad slösar tid som borde gå till de två eller tre listor som dina mottagare faktiskt använder.

Rangordna listorna efter den trafik du skickar. Titta på vilka mottagare som syns i dina studsar, ta reda på vilka listor just de mottagarna offentligt använder, och bevaka dem. Resten är brus som du kan gå igenom en gång i månaden.

Gör kontrollen till ett schemalagt jobb med ett larmtröskelvärde

Här är den minimala versionen som håller. Den körs från en värd med en riktig resolver, validerar zonen först och skiljer mellan tre utfall: listad, inte listad och frågan avvisad.

import socket

def dnsbl(ip: str, zone: str) -> str:
    rev = ".".join(reversed(ip.split(".")))
    try:
        answer = socket.gethostbyname(f"{rev}.{zone}")
    except socket.gaierror:
        return "not_listed"
    if answer.startswith("127.255.255."):
        return "refused"   # felkod, inte ett rykteresultat
    return f"listed:{answer}"

# Kontrollera zonen innan du litar på den (RFC 5782-testposter)
assert dnsbl("127.0.0.2", "zen.spamhaus.org").startswith("listed")
assert dnsbl("127.0.0.1", "zen.spamhaus.org") == "not_listed"

Kör det var 15:e till 60:e minut per avsändande IP och per avsändande domän, logga varje resultat med tidsstämpel, och larma bara vid övergången från not_listed till listed. Larma separat på refused, eftersom det betyder att din övervakning är blind, inte att ditt rykte har ändrats.

Komplettera med de signaler som blocklistor brukar ligga efter. Klagomålsfrekvens från Postmaster-dashboarden, studsfrekvens per mottagande domän och fördröjningsfrekvens per timme rör sig innan en listning dyker upp, och de är siffrorna som avgör om du ska pausa ett utskick. Om du redan skickar loggar och mätvärden till en övervakningsstack är uppslagningsresultatet bara ytterligare en tidsserie.

Fyra verktyg passar det här arbetsflödet, beroende på var smärtan sitter.

Postmark är en tjänst för enbart transaktionsmail, så dina lösenordsåterställningar delar inte sändningsväg med någon annans nyhetsbrev. Om dina listningar hela tiden kan spåras till en granne på delad infrastruktur är det strukturella svaret att skilja transaktionella utskick från marknadsföringsutskick.

Resend är det utvecklarförsta alternativet om du vill ha ett rent API och en liten yta att instrumentera. Värt det när ditt team ändå kommer att skripta sina egna leverabilitetskontroller.

SendGrid har längst meritlista vid stora volymer och erbjuder dedikerade IP-adresser, vilket betyder att ryktet, och exponeringen mot blocklistor, är ditt ensamt. Hoppa över det om du inte kan bemanna den uppvärmning och övervakning som dedikerade IP-adresser kräver.

Better Stack är biten för schemalagda jobb: uptime-liknande kontroller, larm och jourroutning för uppslagningsskriptet ovan, så att en ny listning når en människa i stället för en loggfil.

När du är listad, åtgärda orsaken innan du begär borttagning

Att ta bort en listning utan grundorsak köper dig några dagar. Operatören av en lista som ser samma adress återkomma med samma beteende listar den igen, och vissa operatörer eskalerar upprepade listningar.

Arbeta i den här ordningen:

1. Stoppa eller dra ner utskicken från den listade IP:n. Mer dålig trafik förlänger listningen och ger nya.

2. Läs listoperatörens listningspost. Många anger beviset: en träff i en spamfälla, en topp, en rapport om missbruk av relä.

3. Hitta källan. Kontrollera formulärens endpoints för öppet relämissbruk, titta på nyliga listimporter, och granska alla nya integrationer som börjat skicka under den senaste veckan.

4. Åtgärda orsaken och använd sedan operatörens egen process för borttagning. Vissa listor löper ut automatiskt efter en lugn period.

5. Återuppta i lägre volym, först till dina mest engagerade mottagare, och bevaka klagomålsfrekvens och fördröjningar under en vecka.

Saknad omvänd DNS är en återkommande bidragande orsak. Google räknar giltiga PTR-poster bland sina avsändarkrav, och en avsändande IP utan sådan post ses av många mottagare som lågt betrodd innan innehållet ens har bedömts.

Bygg livscykelflödet kring signalen, inte listan

Om din produkt skickar aktiveringsmail, faktureringsmail eller säkerhetsmail är en listning en tillgänglighetsincident för de flödena. Behandla den så: skicka transaktionsmail via en väg som är isolerad från marknadsföringsvolymen, och gör triggerlagret medvetet om leveransläget, så att ett fastnat aktiveringsmail faller tillbaka på en prompt i appen.

Customer.io är det händelsedrivna lagret som folk brukar kombinera med en separat leverantör för utskick, just av det här skälet: beteendeutlösare och meddelandelogik ligger på ett ställe och leveransen på ett annat, och du kan byta eller dela upp leveransen utan att skriva om flödena. Avvägningen är ett system till att hålla observerbart.

Den separationen är den del som är värd att kopiera även om du väljer andra leverantörer. En händelse på blocklistan ska ändra vart ett meddelande går, inte om din livscykellogik fungerar.

Det här sätter vi på plats den här veckan

Tre saker, i ordning efter avkastning. För det första en schemalagd uppslagning med zonvalidering och ett separat tillstånd refused, som körs från en värd med egen resolver. För det andra en uppdelning av dina studsar per mottagande domän, så att du vet vilka listor som spelar roll för din trafik. För det tredje en skriven runbook som börjar med studsmeddelandets text och slutar med borttagningssteget, så att den som har jour inte behöver improvisera.

Vilken av dina avsändande domäner skulle du inte märka om den var listad i en dag?