Hvad tjekket kigger på
Recorden. Findes der en SPF-record, og er der kun én? To records er ikke dobbelt beskyttelse. Modtageren behandler det som en fejl, og så gælder ingen af dem.
De ti opslag. Hver include, a, mx, exists og redirect koster et DNS-opslag, og det samme gør dem, der gemmer sig inde i leverandørernes egne includes. Kommer det samlede tal over ti, giver SPF en fejl, og så tæller den ikke med. Vi følger hele kæden ned, ikke bare det første led.
DKIM og DMARC. SPF beskytter kun den tekniske afsenderadresse, ikke den, brugeren ser i sit mailprogram. Det er DMARC, der binder de to sammen. Derfor viser resultatet alle tre.
Hvorfor grænsen rammer så mange
Hver tjeneste, der sender for jer, beder om sin egen include. Mailen, nyhedsbrevet, CRM’et og supportsystemet. Hver af dem kan pege videre på flere, og I kan ikke se det i jeres egen record. Fejlen gemmer sig som regel et par niveauer nede hos en leverandørs leverandør, og den opstår ofte først, når nogen tilføjer en ny tjeneste.
Hvad I gør ved fundene
- Hav én record. Er der to, så slå dem sammen til én.
- Fjern includes fra tjenester, I ikke bruger længere. De koster opslag og giver en afsender adgang, I har glemt.
- Er I over ti, så flyt masseudsendelser som nyhedsbreve til et subdomæne med sin egen SPF, for eksempel
nyhed.jeresdomæne.dk. Det holder hoveddomænets record kort. - Undgå at skrive leverandørernes IP-adresser direkte ind for at spare opslag. Listen passer, indtil de skifter adresser, og det får I ikke besked om.
- Slut recorden med
-alleller~all. Aldrig+all, som tillader alle servere i verden at sende i jeres navn.
Skal nogen tage forløbet for jer, er det den opgave, vi løser under stop mailspoofing.