E-post havner i søppelpost? Slik finner bedriften årsaken
En e-post som havner i mottakerens søppelpost, kan se ut som et lite irritasjonsmoment. For en bedrift kan det bety at et tilbud eller et viktig svar ikke blir lest. Feilsøkingen begynner med å skille mellom tre ulike situasjoner: Meldingen ble avvist og kom tilbake, den ble levert til søppelpost, eller avsenderen vet rett og slett ikke om den kom frem.
1. Finn ut hvor meldingen stoppet
Be om tidspunkt, mottakertjeneste og om avsenderen fikk en returmelding. En returmelding med feilkode er et annet spor enn en melding som faktisk ligger i mottakerens søppelpost. Test gjerne med én vanlig melding fra den samme avsenderkontoen til en mottaker dere samarbeider med. Ikke send mange nesten like tester på rad.
Hvis problemet bare gjelder meldinger fra nettsidens kontaktskjema, er det en egen sendekjede. Bruk da sjekklisten vår for kontaktskjema som ikke leverer henvendelser. Hvis feilen oppstod etter bytte av e-postleverandør, kontroller også migreringspunktene for e-post.
2. Kartlegg alle som sender på vegne av domenet
Bedriften sender sjelden bare fra én postboks. Nettside, fakturasystem, nyhetsbrev, skanner og andre tjenester kan bruke samme avsenderdomene. Skriv ned hver legitim sendekilde før dere endrer DNS. Et oppsett som fungerer for de ansattes vanlige e-post, kan likevel feile for en tredjepartstjeneste.
3. Kontroller SPF, DKIM og DMARC på en faktisk melding
Disse tre mekanismene svarer på ulike spørsmål. SPF angir hvilke servere som kan sende for domenet brukt i den tekniske avsenderadressen. DKIM lar mottakeren kontrollere en digital signatur på meldingen. DMARC knytter kontrollen til domenet mottakeren ser i Fra-feltet og angir en policy for meldinger som ikke består kontrollen. Et SPF-treff alene sier derfor ikke alltid at domenet i det synlige Fra-feltet er riktig bekreftet.
Be e-postleverandøren kontrollere mottakerens autentiseringsresultat for en konkret testmelding: bestod SPF, bestod DKIM, og var minst én av dem riktig justert mot Fra-domenet for DMARC? Microsoft forklarer samspillet mellom SPF, DKIM og DMARC. Google beskriver sine avsenderkrav og anbefalinger. Krav kan variere med mottakertjeneste og sendemengde.
Ikke legg til tilfeldige SPF-oppføringer eller sett en streng DMARC-policy før alle legitime sendekilder er kartlagt og testet. Da kan dere ellers stenge ute egne meldinger. Endringer bør gjøres i riktig DNS-sone av den som forvalter domenet, og resultatet må testes på nytt etterpå.
4. Se videre enn DNS
Bestått autentisering er nødvendig, men ingen garanti for at meldingen havner i innboksen. Mottakerens filtre kan også vurdere avsenderhistorikk, sendemønster og innhold. Sjekk om problemet gjelder alle mottakere, bare én tjeneste eller bare én type melding. Skill vanlige samtaler fra masseutsendelser; de kan ha ulike krav og ulikt omdømme.
Ta vare på en avgrenset, anonymisert feilkode og tidspunkt når dere ber om teknisk hjelp. Del ikke hele meldinger, kundeadresser eller komplette meldingshoder i åpne kanaler. Det gir støttepersonell et spor å følge uten unødvendig eksponering.
En kort beslutningsrekkefølge
- Avklart leveringsstatus: avvist, søppelpost eller ukjent?
- Finnes det flere sendekilder for samme domene?
- Hva viser autentiseringsresultatet for én konkret melding?
- Gjelder problemet bestemte mottakere eller bestemte meldingstyper?
- Er endringen testet etter at DNS eller sendetjeneste ble rettet?
Trenger dere hjelp til å skille DNS-feil fra problemer hos sendetjenesten eller mottakeren, kan dere lese mer om datahjelp hos Trønder Data. Begynn med leveringssporet, ikke med å gjette hvilken post i DNS som bør endres.