SPF i praksis: kartlegg alle avsendere

Modul 4: Leveringsdyktighet: SPF, DKIM og DMARC i praksis · Lesetid: 12 minutter

Læringsmål: Etter denne leksjonen kan du finne alle tjenester som sender e-post på vegne av domenet ditt, samle dem i ett SPF-record, telle oppslagene rekursivt opp til grensen på ti, og velge bevisst mellom ~all og -all.

Nøkkelbegreper: oversikt over avsendere, envelope sender (Return-Path), ett SPF-record, include, redirect, grense på 10 DNS-oppslag (RFC 7208 avsnitt 4.6.4), tomme oppslag (void lookups, maksimalt 2), rekursiv telling, permerror, flattening, SPF for underdomener, SPF på et domene som ikke sender e-post, ~all og -all

Kort oppfriskning

Et SPF-record er et TXT-record på domenet ditt som begynner med v=spf1 og lister opp hvilke servere som får sende e-post på vegne av domenet ditt. Oppbyggingen, tegnene + - ~ ? og de tre vanligste feilene (to records, +all, mer enn ti oppslag) står i DNS-kurset, leksjon 4.3. Les den først hvis SPF er nytt for deg. Denne leksjonen handler om den vanskelige delen: i praksis vet nesten ingen nøyaktig hvem som sender e-post på vegne av domenet sitt.

Steg 1: oversikten

SPF fungerer bare hvis alle avsendere er med. Glemmer du en, havner e-posten i spam eller blir avvist så snart du strammer inn DMARC. Gå derfor gjennom denne listen. Hos en gjennomsnittlig liten bedrift finner du fort fem eller seks:

To gode måter å finne dem på:

1. Les headerne. Send en e-post til deg selv fra hvert system (en faktura, en passordtilbakestilling, et testnyhetsbrev) og se i headerne etter Return-Path og Authentication-Results (leksjon 1.5). Der ser du via hvilket domene og hvilken server den kom.
2. DMARC-rapporter. Sett DMARC til p=none med en rapportadresse (leksjon 4.4). Etter noen uker ser du i rapportene (leksjon 4.5) hver server som har sendt e-post på vegne av domenet ditt, også de du hadde glemt. Det er den mest pålitelige oversikten.

Ikke alle tjenester hører hjemme i SPF-en din

Her går det ofte galt. SPF ser på envelope sender (Return-Path), ikke på Fra-adressen. Mange nyhetsbrev- og utsendingstjenester sender med et Return-Path på sitt eget domene, for eksempel bounce-123@mail.mailer.example. Mottakeren kontrollerer da SPF-recordet til mailer.example, ikke ditt eget. En include av den tjenesten i ditt record gjør da ingenting, bortsett fra å koste et oppslag.

Det tjenesten faktisk trenger for å komme gjennom DMARC, er en DKIM-signatur med ditt domene (leksjon 4.3), eller et eget Return-Path-underdomene fra deg (for eksempel bounce.example.com som CNAME til tjenesten). Les derfor i veiledningen til tjenesten hva den krever. Sier den "sett include: i SPF-en din", gjør det. Sier den bare "lag disse CNAME-recordene for DKIM og bounce-domenet", trenger du ikke endre hovedrecordet. Modul 7 går nærmere inn på dette.

Steg 2: ett record, og riktig telling

Alle avsendere går i ett record. Si at oversikten din gir dette: mailserveren til hostingleverandøren din, Microsoft 365 for noen ansatte, regnskapsprogrammet ditt og en helpdesk. Da blir recordet for eksempel:

example.com.  3600  IN  TXT  "v=spf1 a mx include:spf.hosting.example include:spf.protection.outlook.com include:_spf.boekhoud.example include:mail.helpdesk.example ~all"

Hvor mange oppslag er det? Tell hver a, mx, include, exists, ptr og redirect, og tell deretter også alt som står i recordene bak hver include:

Ved 11 gir mottakeren en permerror: hele SPF-recordet teller da ikke, for ingen avsendere. E-posten fra din egen mailserver blir altså vurdert dårligere fordi helpdesken koster tre oppslag. Og det lumske er: recordet ditt kan være 9 i dag og 11 i morgen, uten at du endrer noe, fordi en tjeneste utvider sitt eget record.

I tillegg: maksimalt to tomme oppslag

RFC 7208 nevner også void lookups: oppslag som ikke gir noe resultat (navnet finnes ikke, eller har ikke noe SPF- eller adresserecord). Mer enn to av disse fører også til permerror. Dette skjer særlig med gamle includeer fra tjenester du ikke lenger bruker, og som har fjernet recordet sitt, eller med en a: til en server som ikke lenger finnes. Rydd altså opp.

Steg 3: tilbake under ti

Er du over ti, finnes det fire løsninger, fra best til minst bra:

1. Fjern det som ikke trengs. Tjenester du ikke lenger bruker. Tjenester som sender med eget Return-Path (se over) og derfor ikke hører hjemme i SPF-en din. a hvis nettstedet ditt ikke sender e-post selv. mx hvis MX-en din peker til en tjeneste som allerede står i recordet ditt med en include.
2. Bruk et underdomene. La en tjeneste sende fra nieuws.example.com eller factuur.example.com. Det underdomenet får et eget SPF-record med bare den tjenesten, og teller ikke med i de ti på hoveddomenet ditt. Justering i DMARC (leksjon 4.4) fungerer som standard også for underdomener.
3. Bruk ip4: og ip6: for dine egne faste servere. De koster ikke noe oppslag. Gjør dette bare for adresser du selv administrerer og som ikke endrer seg.
4. Flattening (erstatt alle includes med IP-adressene som ligger bak dem akkurat nå). Det bringer antallet ned til 0, men recordet stemmer ikke lenger så snart en tjeneste endrer adressene sine, og store tjenester gjør det jevnlig. Gjør dette bare med et verktøy som oppdaterer det automatisk, og helst ikke i det hele tatt.

redirect eller include?

redirect= betyr: bruk SPF-recordet til det andre domenet i stedet for dette recordet. Det koster ett oppslag, akkurat som en include. Det er nyttig hvis du har mange domener som skal ha nøyaktig samme policy: v=spf1 redirect=_spf.example.com på hvert domene, og det faktiske recordet ett sted. Et record med redirect= kan ikke ha all, for da blir redirecten ignorert. Gmail bruker det selv: gmail.com har v=spf1 redirect=_spf.google.com.

Steg 4: ~all eller -all?

Anbefalingen fra dette kurset, lik den i DNS-kurset:

• Begynn med ~all (softfail). E-post fra en server som ikke står i recordet ditt, blir sett på som mistenkelig, men som regel ikke avvist umiddelbart. Glemmer du en avsender, blir skaden begrenset.
• Gå over til -all (fail) når du er sikker på at alle avsendere er med, for eksempel etter at du har sett på DMARC-rapporter i noen uker og det ikke lenger finnes ukjente kilder.

Med DMARC i tillegg er forskjellen mindre enn man ofte tror. DMARC avgjør på grunnlag av "SPF eller DKIM bestått og justert". En softfail er for DMARC rett og slett "ikke bestått". Den egentlige beskyttelsen kommer altså fra en streng DMARC-policy, ikke fra -all. Noen mottakere avviser allerede ved -all, før DMARC-vurderingen; det er en grunn til å velge -all først når recordet ditt virkelig er fullstendig.

Et domene som aldri sender e-post

Har du domener som aldri sender e-post (et gammelt merkenavn, et skrivefeildomene)? Beskytt dem mot misbruk med:

example.org.         IN  TXT  "v=spf1 -all"
_dmarc.example.org.  IN  TXT  "v=DMARC1; p=reject"
example.org.         IN  MX   0 .

Her er -all riktig med en gang: det er ingen som skal få sende e-post. Den siste linjen er en null MX (RFC 7505): "dette domenet mottar ikke e-post". example.com selv er satt opp nøyaktig slik.

I praksis: slik ser det ut i et kontrollpanel

Hos en hostingpakke fra WebOké står som standard v=spf1 a mx include:webawere.nl ~all. Legger du til en tjeneste, tilpasser du det recordet (i DirectAdmin: DNS Management, blyanten bak SPF-recordet, feltet Include Domain; i Min side: SPF-hjelpen på fanen DNS). La include:webawere.nl stå så lenge e-posten eller nettstedet ditt går gjennom de serverne. Hos andre leverandører heter standardincluden noe annet, men prinsippet er likt: legg til, ikke lag et nytt record.

Oppsummering

• Lag først en oversikt over alle avsendere; DMARC-rapporter og headere hjelper med det.
• En tjeneste med eget Return-Path hører ikke hjemme i SPF-en din; den trenger DKIM med ditt domene.
• Tell rekursivt: hver include, a, mx, exists, ptr og redirect, også inni includes. Over ti, eller mer enn to tomme oppslag, gir permerror.
• Kom tilbake under ti ved å rydde opp og bruke underdomener; flattening bare med automatisk vedlikehold.
• Begynn med ~all, gå til -all når du er sikker. Domener som aldri sender e-post: -all, DMARC reject og null MX.

Quiz

Oppgave

Oppgave Z4.2: La SPF-en til domenet ditt bli talt opp rekursivt. Fyll inn ditt eget domene (eller sidn.nl hvis du ikke har et eget domene). Tell selv først hvor mange DNS-oppslag SPF-recordet koster, inkludert alt inni includene, og fyll inn tallet, sammen med slutten av recordet (~all, -all, ?all eller +all). Programmet teller etter i sanntid, inkludert tomme oppslag, og viser treet.

Oppgave O4.2: Oversikt over avsendere. Lag med tabellen fra denne leksjonen en liste over alle systemer som sender e-post på vegne av domenet ditt. Noter for hvert: via hvilken server eller tjeneste, om det bør være med i SPF-en din (eget Return-Path eller ikke), og om det signerer med DKIM og ditt domene. Send en testmail til deg selv fra minst to systemer og noter fra headerne Return-Path-domenet og DKIM-domenet (d=).

Les mer

Stegene i disse artiklene gjelder for kontrollpanelene til WebOké; hos andre leverandører fungerer det på tilsvarende måte.

• Gratis DNS-kurs 4.3: SPF: hvem kan sende e-post på vegne av domenet ditt?
• DirectAdmin-veiledning 5.7: SPF stille inn og utvide
• Hvordan fungerer SPF-recorden i DNS?
• Legge til eller endre en SPF-post i DirectAdmin
• WebOké-veiledning 5.5: DNS-hjelpere: MX, SPF, DMARC, CAA og SRV
• RFC 7208 (SPF), avsnitt 4.6.4 (grenser) og 6.1 (redirect); RFC 7505 (null MX)