SPF: wie mag mailen namens jouw domein?

Module 4: Records voor e-mail · Leestijd: 10 minuten

Leerdoel: Na deze les kun je een SPF-record lezen, een dienst correct toevoegen en de drie bekendste SPF-fouten vermijden: twee records, +all en meer dan tien opzoekingen.

Kernbegrippen: SPF, v=spf1, mechanisme (a, mx, ip4, ip6, include), kwalificatie (+ - ~ ?), all, één SPF-record, limiet van 10 DNS-opzoekingen, envelope-afzender (Return-Path)

Het probleem: iedereen kan jouw naam gebruiken

E-mail is in de jaren tachtig bedacht voor een klein, vriendelijk internet. Iedere mailserver kan een mail versturen met als afzender info@example.com, ook als die server helemaal niets met example.com te maken heeft. Oplichters maken daar dankbaar gebruik van.

SPF (Sender Policy Framework, RFC 7208) is een eerste stap om dat te voorkomen. In een SPF-record zet je welke servers mail mogen versturen namens jouw domein. Een ontvangende mailserver kijkt bij elke binnenkomende mail: komt deze mail van een server die op de lijst staat?

Zie het als een gastenlijst bij een deur. De portier (de ontvangende mailserver) vraagt de lijst op bij jouw domein en kijkt of de bezoeker (de verzendende server) erop staat.

Hoe ziet een SPF-record eruit?

Een SPF-record is een TXT-record op je domeinnaam dat begint met v=spf1:

example.com.  3600  IN  TXT  "v=spf1 mx ip4:192.0.2.25 include:spf.mailer.example ~all"

Je leest het van links naar rechts. De ontvanger loopt de onderdelen een voor een af en stopt bij het eerste dat past.

Het einde: ~all, -all, ?all of +all

Voor elk onderdeel kan een teken staan dat zegt wat er gebeurt als het past. Bij all (dat altijd past) maakt dat teken het verschil:

Staat er geen teken, dan geldt +. mx betekent dus +mx.

Welke kies je? ~all is een veilige standaard. -all is strenger en goed als je zeker weet dat al je verzenders in het record staan. Gebruik je DMARC (les 4.5), dan bepaalt het DMARC-beleid uiteindelijk wat er gebeurt; veel beheerders kiezen dan ~all.

Fout 1: twee SPF-records

Er mag per domein maar één SPF-record zijn. Vindt de ontvanger er twee, dan is het resultaat een fout (permerror) en telt je SPF helemaal niet. Dat is erger dan geen SPF.

Dit gaat in de praktijk vaak mis. Een nieuwsbriefdienst of Microsoft 365 zegt "voeg dit SPF-record toe", en dan staat er ineens een tweede v=spf1-record naast het oude. De oplossing: voeg de nieuwe dienst toe aan het bestaande record.

Fout:

"v=spf1 mx include:spf.oldhost.example ~all"
"v=spf1 include:spf.protection.outlook.com -all"

Goed:

"v=spf1 mx include:spf.oldhost.example include:spf.protection.outlook.com ~all"

Let op: haal bij het samenvoegen niet de servers weg die je nog gebruikt. Mailt je website via de server van je hostingbedrijf, dan moet die er blijven in staan, ook als je gewone mail naar Microsoft 365 gaat. Een hostingpakket heeft vaak al een standaard-SPF met een include van het hostingbedrijf (bij WebOké is dat bijvoorbeeld include:webawere.nl); laat die staan zolang je website of formulieren via die server mailen.

Fout 2: +all of een te ruim record

+all aan het eind, of een enorme reeks als ip4:0.0.0.0/0, betekent dat iedereen mag. Dan beschermt je SPF niets meer, en spamfilters zien dat als een slecht teken.

Fout 3: meer dan tien opzoekingen

Om een SPF-record te controleren moet de ontvanger soms extra DNS-vragen stellen. Elke include, a, mx, exists, ptr en redirect kost een opzoeking, en een include telt ook alle opzoekingen in het record waar hij naar verwijst. Volgens RFC 7208 mag het totaal niet boven de tien uitkomen. Gaat het erover, dan is het resultaat permerror en faalt SPF.

ip4 en ip6 kosten geen opzoeking. all ook niet.

Daarnaast mogen maximaal twee opzoekingen "leeg" terugkomen (een naam die niet bestaat of geen antwoord heeft). Een include naar een dienst die je allang niet meer gebruikt en die zijn record heeft weggehaald, kan dus ook problemen geven.

Gebruik je veel diensten, tel dan na met een SPF-controletool (les 8.3) en haal diensten weg die je niet meer gebruikt.

Wat SPF niet doet

SPF controleert de envelope-afzender: het technische afzenderadres (Return-Path) dat mailservers onderling gebruiken. Dat is niet altijd hetzelfde adres als het "Van:"-adres dat jij in je mailprogramma ziet. Een nieuwsbriefdienst verstuurt vaak met een eigen Return-Path. SPF alleen houdt dus niet elke vervalste afzender tegen. Daarvoor zijn DKIM (les 4.4) en DMARC (les 4.5) er.

SPF breekt ook bij doorsturen: stuur je mail automatisch door naar een ander adres, dan komt de mail bij de eindontvanger binnen van een server die niet in jouw SPF staat.

Waarom het ertoe doet

Grote mailproviders zijn strenger geworden. Sinds februari 2024 eisen Gmail en Yahoo dat iedereen die mail stuurt minstens SPF of DKIM heeft, en dat wie veel mail verstuurt (meer dan zo'n 5.000 per dag) SPF, DKIM én DMARC heeft. Microsoft stelt sinds mei 2025 dezelfde eis voor Outlook.com, Hotmail en Live.com. Ook als je weinig mail verstuurt, helpt een goed SPF-record tegen de spammap.

In de praktijk: zo ziet het eruit in een paneel

In dit voorbeeld gebruiken we DirectAdmin. In DNS Beheer klik je op het potlood achter het TXT-record dat met v=spf1 begint. DirectAdmin opent een SPF-hulp: bij Inclusief Domein vul je het domein van de dienst in (zonder include:), bij Modus kies je SoftFail (~all) of Mislukt (-all). Onderaan zie je het hele record. Mijn WebOké heeft een vergelijkbare SPF-hulp op het tabblad DNS.

Andere panelen hebben niet altijd zo'n hulp. Dan bewerk je het TXT-record als gewone tekst; de inhoud is precies hetzelfde.

Samenvatting

• SPF is een TXT-record met v=spf1 dat zegt welke servers namens je domein mogen mailen.
• Precies één SPF-record per domein. Nieuwe dienst? Vul het bestaande record aan.
• Eindig met ~all of -all, nooit met +all.
• Maximaal tien DNS-opzoekingen (include, a, mx, exists, ptr, redirect), ip4/ip6 tellen niet mee.
• SPF kijkt naar de envelope-afzender; voor echte bescherming heb je ook DKIM en DMARC nodig.

Quiz

Opdracht

Opzoeken (Z4.3): Zoek het SPF-record van google.com op (of van je eigen domein). Plak het volledige record, en vul in waar het mee eindigt (~all, -all, ?all of +all). Bij je eigen domein controleert de opdracht ook of je precies één SPF-record hebt.

Zelf instellen (O4.3): In de oefenzone gebruik je een nepdienst; bij je echte domein gebruik je de echte include die je mailprovider opgeeft (bijvoorbeeld include:_spf.google.com). Maak in je oefenzone <code>.dnspractice.eu een SPF-record dat toestaat: de MX-servers van de zone (mx), het adres 192.0.2.25 en de oefendienst _spf.mailsuite-demo.dnspractice.eu. Andere servers zijn verdacht of niet toegestaan, dus het record eindigt op ~all of -all.3 en O4.3.

Verder lezen

De stappen in deze artikelen gelden voor de panelen van WebOké; in andere panelen werkt het vergelijkbaar.

• DirectAdmin handleiding 5.7: SPF instellen en aanvullen
• Hoe werkt het SPF-record in de DNS?
• SPF-record toevoegen of wijzigen in DirectAdmin
• WebOké handleiding 5.5: DNS-hulpjes: MX, SPF, DMARC, CAA en SRV
• RFC 7208 (SPF), met name paragraaf 4.6.4 (limiet van tien opzoekingen en twee lege opzoekingen)