Een zakelijke e-mail versturen en vervolgens ontdekken dat deze in de spammap terechtkomt, is frustrerend. Zeker wanneer offertes, facturen, contactformulieren of belangrijke klantberichten niet aankomen.
Een van de eerste technische onderdelen die je dan moet controleren is de e-mailauthenticatie van je domeinnaam. Door SPF, DKIM en DMARC in te stellen laat je ontvangende mailservers controleren welke systemen namens jouw domein mogen mailen, of een bericht onderweg is gewijzigd en wat er moet gebeuren wanneer authenticatie niet klopt.
Deze drie technieken werken samen:
SPF → welke servers mogen namens het domein verzenden?
DKIM → is het bericht digitaal ondertekend en onderweg intact gebleven?
DMARC → klopt de afzender met SPF/DKIM en wat moet de ontvanger doen bij fouten?
SPF, DKIM en DMARC zijn geen magische garantie dat iedere e-mail altijd in de inbox belandt. Ze vormen wel een essentieel onderdeel van betrouwbare zakelijke e-mail en helpen misbruik van je domeinnaam tegen te gaan.
Google adviseert alle afzenders SPF, DKIM en DMARC te configureren. Voor grotere afzenders zijn strengere authenticatie-eisen van toepassing.
Waarom komen zakelijke e-mails in de spam?
Een mailprovider zoals Gmail, Outlook of Yahoo kijkt naar veel meer dan alleen de tekst van je bericht.
Bij de beoordeling kunnen onder andere meespelen:
SPF;
DKIM;
DMARC;
reputatie van het verzendende IP-adres;
reputatie van het domein;
reverse DNS;
verzendvolume;
spamklachten;
bouncepercentage;
inhoud van het bericht;
verzendpatroon;
beveiligde TLS-verbinding;
kwaliteit van de adressenlijst.
Je kunt dus uitstekende DNS-records hebben en alsnog problemen met afleverbaarheid ervaren.
Andersom geldt hetzelfde: wanneer belangrijke authenticatie ontbreekt, kan een ontvangende mailserver minder vertrouwen hebben in een bericht.
Google geeft aan dat niet-geauthenticeerde berichten kunnen worden gemarkeerd als spam of zelfs kunnen worden geweigerd.
Wat is SPF?
SPF staat voor Sender Policy Framework.
Met SPF publiceer je via DNS welke mailservers of diensten gemachtigd zijn om namens een domein e-mail te versturen.
Stel dat een bedrijf mail verstuurt via:
de eigen mailserver;
Microsoft 365;
een nieuwsbriefdienst;
een facturatiesysteem.
Dan moeten de relevante verzendende systemen op de juiste manier worden meegenomen in de SPF-configuratie.
Een ontvangende mailserver kan vervolgens controleren of de server waarvan het bericht afkomstig is volgens het SPF-beleid gemachtigd is.
Hoe ziet een SPF-record eruit?
Een SPF-record wordt als TXT-record in DNS gepubliceerd.
Een vereenvoudigd voorbeeld:
v=spf1 ip4:203.0.113.10 include:_spf.example.net -all
Dit voorbeeld betekent in hoofdlijnen:
v=spf1→ dit is een SPF-record;ip4:→ het opgegeven IPv4-adres mag verzenden;include:→ een andere opgegeven mailinfrastructuur wordt meegenomen;-all→ overige bronnen zijn niet toegestaan volgens dit beleid.
Dit is alleen een voorbeeld. Een SPF-record moet altijd aansluiten op de werkelijke mailinfrastructuur van het domein.
Kopieer daarom nooit blind een SPF-record van een ander domein.
Welke systemen moeten in SPF staan?
Inventariseer eerst alle diensten die namens je domeinnaam e-mail kunnen versturen.
Denk bijvoorbeeld aan:
eigen mailserver;
hostingserver;
Microsoft 365;
Google Workspace;
nieuwsbriefsoftware;
webshop;
CRM;
facturatieprogramma;
ticketsysteem;
websiteformulieren;
externe SMTP-provider.
Een veelgemaakte fout is dat alleen de normale mailbox wordt opgenomen.
De nieuwsbriefsoftware of webshop verzendt vervolgens vanaf een andere infrastructuur en slaagt niet voor SPF.
Google adviseert expliciet dat de SPF-configuratie alle afzenders van het domein bevat. Ontbrekende externe verzenddiensten kunnen ertoe leiden dat berichten als spam worden behandeld.
Kun je meerdere SPF-records toevoegen?
Voor dezelfde hostnaam moet je niet simpelweg meerdere afzonderlijke SPF-beleidsregels naast elkaar publiceren.
Stel bijvoorbeeld dat je al hebt:
v=spf1 include:provider-a.example -all
en vervolgens voor een tweede dienst nog een apart SPF-record toevoegt:
v=spf1 include:provider-b.example -all
Dan heb je geen nette gecombineerde configuratie.
De verzendende bronnen horen in één correcte SPF-policy te worden verwerkt, bijvoorbeeld conceptueel:
v=spf1 include:provider-a.example include:provider-b.example -all
Welke waarden werkelijk nodig zijn moet je altijd controleren bij de gebruikte e-mailproviders.
Wat betekent ~all of -all bij SPF?
Aan het einde van SPF-records zie je vaak verschillende kwalificaties.
-all
Hiermee geef je duidelijk aan dat niet-gemachtigde verzenders niet volgens het SPF-beleid zijn toegestaan.
~all
Dit wordt vaak als een minder strenge softfail gebruikt.
Welke instelling passend is hangt af van je mailomgeving en de fase waarin je de configuratie uitvoert.
Een streng beleid instellen zonder eerst alle legitieme verzenders te inventariseren kan ervoor zorgen dat geldige e-mail niet correct authenticeert.
Wat is DKIM?
DKIM staat voor DomainKeys Identified Mail.
Bij DKIM wordt uitgaande e-mail cryptografisch ondertekend.
De verzendende mailserver gebruikt daarvoor een privésleutel.
De bijbehorende publieke sleutel staat in DNS.
Een ontvangende mailserver kan daardoor controleren:
of het bericht met de juiste DKIM-sleutel is ondertekend;
welk domein verantwoordelijk is voor die handtekening;
of relevante onderdelen van het bericht na ondertekening zijn gewijzigd.
DKIM controleert dus iets anders dan SPF.
SPF kijkt vooral naar de verzendende infrastructuur. DKIM voegt een digitale handtekening aan het bericht toe.
Hoe ziet een DKIM-record eruit?
DKIM gebruikt meestal een zogenaamde selector.
Een DNS-naam kan bijvoorbeeld zijn:
selector1._domainkey.example.nl
Daaronder staat een TXT-record met de publieke sleutel.
Een sterk vereenvoudigde weergave:
v=DKIM1; k=rsa; p=PUBLIC_KEY
De daadwerkelijke p=-waarde bevat een veel langere publieke sleutel.
De private sleutel hoort niet in DNS te staan en moet geheim blijven op het verzendende systeem.
Wat is een DKIM-selector?
Een selector maakt het mogelijk om verschillende DKIM-sleutels voor één domeinnaam te gebruiken.
Je kunt bijvoorbeeld selectors tegenkomen zoals:
default;selector1;selector2;google;mail;een provider-specifieke waarde.
Een e-mail bevat informatie over welke selector voor de handtekening is gebruikt.
De ontvangende server weet daarmee welk DNS-record moet worden opgevraagd.
Hoe lang moet een DKIM-sleutel zijn?
De gebruikte e-mailprovider bepaalt vaak welke DKIM-sleutel wordt gegenereerd.
Google vereist voor mail naar persoonlijke Gmail-accounts minimaal 1024-bit DKIM-sleutels en adviseert 2048-bit wanneer de provider dit ondersteunt.
Wanneer je provider 2048-bit DKIM ondersteunt, heeft dat daarom doorgaans de voorkeur.
Wat is DMARC?
DMARC staat voor Domain-based Message Authentication, Reporting and Conformance.
DMARC bouwt voort op SPF en DKIM.
Het belangrijke verschil is dat DMARC ook kijkt naar de relatie tussen de zichtbare afzender in het From:-veld en het domein dat via SPF of DKIM wordt geauthenticeerd.
Dat wordt alignment genoemd.
Daarnaast kan de domeineigenaar via DMARC aangeven wat ontvangers zouden moeten doen met berichten die de controle niet doorstaan.
DMARC.org beschrijft DMARC als een protocol voor authenticatie, beleid en rapportage dat voortbouwt op SPF en DKIM en daarbij de zichtbare From-domeinnaam betrekt.
Waarom is DMARC alignment belangrijk?
Stel dat iemand een bericht ontvangt met:
Van: administratie@bedrijf.nl
Voor de ontvanger lijkt het bericht dus afkomstig van bedrijf.nl.
Maar technisch kan een ander domein worden gebruikt voor SPF of DKIM.
DMARC controleert of de relevante domeinen voldoende met elkaar overeenkomen.
Voor Gmail-bulkafzenders moet het domein in de zichtbare From-header afgestemd zijn op minimaal het SPF- of het DKIM-domein. Google adviseert uiteindelijk alignment met beide.
Dit maakt het moeilijker om simpelweg een willekeurig zichtbaar afzenderadres te gebruiken en daarmee betrouwbare authenticatie voor een ander domein te misbruiken.
Hoe ziet een DMARC-record eruit?
DMARC wordt gepubliceerd als een TXT-record.
De hostnaam is doorgaans:
_dmarc.example.nl
Een eenvoudige beginconfiguratie kan bijvoorbeeld zijn:
v=DMARC1; p=none; rua=mailto:dmarc@example.nl
De onderdelen betekenen:
v=DMARC1→ DMARC-versie;p=none→ alleen monitoren, geen streng afdwingbeleid;rua=→ adres waar aggregate DMARC-rapporten naartoe kunnen worden gestuurd.
Gebruik geen voorbeeldadres letterlijk voor een live domein.
DMARC p=none, quarantine of reject
DMARC kent verschillende beleidsniveaus.
p=none
p=none is vooral bedoeld om te monitoren.
Berichten die de controle niet halen worden door jouw DMARC-policy niet automatisch opgedragen om in quarantaine te gaan of geweigerd te worden.
Dit is vaak een verstandige eerste stap wanneer je nog niet precies weet welke systemen namens het domein mailen.
DMARC.org adviseert een geleidelijke implementatie: eerst SPF en DKIM goed instellen, daarna alignment controleren, starten met p=none, rapportages analyseren en vervolgens het beleid aanscherpen.
p=quarantine
Met:
p=quarantine
geef je ontvangende servers aan dat niet-conforme berichten verdacht moeten worden behandeld.
Dat kan bijvoorbeeld betekenen dat ze eerder richting spam of quarantaine gaan.
p=reject
Met:
p=reject
vraag je ontvangende servers om berichten die niet door het DMARC-beleid komen te weigeren.
Dit biedt een sterkere bescherming tegen bepaalde vormen van domeinspoofing, maar moet pas worden ingevoerd wanneer je zeker weet dat je legitieme mailstromen correct zijn geconfigureerd.
Anders kun je ook geldige bedrijfscommunicatie blokkeren.
Waarom niet direct DMARC p=reject instellen?
Stel dat je bedrijf e-mail verstuurt vanuit vijf verschillende systemen.
Vier zijn correct ingericht.
Het vijfde systeem is een oud facturatiepakket dat niemand tijdens de inventarisatie heeft meegenomen.
Wanneer je direct een streng DMARC-beleid activeert, kunnen berichten vanuit dat systeem problemen krijgen.
Daarom is een gecontroleerde overgang verstandiger:
Stap 1 → inventariseren
Stap 2 → SPF correct instellen
Stap 3 → DKIM activeren
Stap 4 → DMARC p=none
Stap 5 → rapportages analyseren
Stap 6 → fouten oplossen
Stap 7 → eventueel p=quarantine
Stap 8 → eventueel p=reject
Dit verkleint het risico dat legitieme mail onbedoeld wordt geraakt.
SPF, DKIM en DMARC instellen: stappenplan
Voor een zakelijke omgeving kun je onderstaande volgorde gebruiken.
Stap 1. Inventariseer alle verzenders
Maak een overzicht van alles wat e-mail verstuurt met jouw domeinnaam.
Denk niet alleen aan medewerkers.
Controleer ook:
websites;
contactformulieren;
WooCommerce;
CRM;
boekhouding;
nieuwsbriefsoftware;
helpdesk;
monitoring;
servers;
automatische notificaties.
Dit is vaak de belangrijkste stap.
Als je een verzender vergeet, kun je een technisch correct record maken dat functioneel toch onvolledig is.
Stap 2. Controleer het bestaande SPF-record
Controleer wat momenteel in DNS staat.
Bepaal vervolgens:
welke bronnen nog worden gebruikt;
welke bronnen ontbreken;
welke oude diensten verwijderd kunnen worden;
of er dubbele SPF-records aanwezig zijn.
Pas daarna het record aan.
Stap 3. Activeer DKIM bij iedere mailprovider
Veel mailproviders genereren zelf de benodigde DKIM-records.
Je krijgt vervolgens één of meerdere DNS-records die je bij het domein moet plaatsen.
Na toevoeging moet DKIM vaak nog in het beheerpaneel van de maildienst worden geactiveerd of geverifieerd.
Stap 4. Controleer SPF en DKIM
Verstuur testberichten naar verschillende providers en controleer de headers.
Je wilt bijvoorbeeld resultaten zien als:
SPF: PASS
DKIM: PASS
Dat alleen is nog niet voldoende voor DMARC: ook alignment moet kloppen.
Stap 5. Publiceer DMARC met monitoring
Wanneer SPF en DKIM functioneren, kun je DMARC toevoegen.
Bij een eerste implementatie wordt vaak begonnen met:
p=none
Hiermee kun je informatie verzamelen zonder onmiddellijk een streng beleid af te dwingen.
Stap 6. Analyseer DMARC-rapportages
DMARC aggregate reports kunnen laten zien welke infrastructuren e-mail namens het domein verzenden en welke authenticatieresultaten daarbij optreden.
Daarmee kun je onverwachte bronnen ontdekken.
Bijvoorbeeld:
oud mailsysteem;
vergeten website;
externe nieuwsbriefdienst;
softwarepakket;
ongeautoriseerde verzender.
Stap 7. Los mislukte authenticatie op
Controleer per geldige verzender waarom SPF, DKIM of alignment niet klopt.
Pas pas daarna het beleid verder aan.
Stap 8. Verhoog eventueel het DMARC-beleid
Wanneer je legitieme verzendstromen goed in beeld hebt, kun je overwegen van:
p=none
naar:
p=quarantine
en uiteindelijk eventueel:
p=reject
te gaan.
Een strengere policy is geen doel op zichzelf. Het moet passen bij een correct ingerichte e-mailomgeving.
Gmail-eisen voor SPF, DKIM en DMARC
De eisen van grote mailproviders zijn de afgelopen jaren strenger geworden.
Google vereist voor alle afzenders naar Gmail minimaal SPF óf DKIM.
Voor afzenders die ongeveer 5.000 of meer berichten per dag naar persoonlijke Gmail-adressen sturen gelden uitgebreidere eisen, waaronder:
SPF;
DKIM;
DMARC;
alignment van het From-domein met SPF of DKIM;
geldige forward en reverse DNS;
TLS;
lage spampercentages.
Sinds november 2025 heeft Gmail de handhaving tegen niet-conforme bulkmail verder aangescherpt.
Ook wanneer je lang geen 5.000 berichten per dag verstuurt is correcte authenticatie verstandig.
Yahoo stelt eveneens eisen aan bulkmail
Yahoo vereist bij reguliere afzenders minimaal SPF of DKIM.
Voor bulkafzenders gelden onder andere:
SPF én DKIM;
geldige DMARC-policy;
DMARC moet slagen;
alignment met SPF of DKIM;
geldig forward en reverse DNS;
laag spampercentage;
eenvoudige afmelding bij marketingmail.
Yahoo adviseert bij een eerste DMARC-configuratie bovendien het gebruik van rua voor rapportage en monitoring.
Outlook en SPF, DKIM en DMARC
Microsoft heeft de eisen voor grote afzenders naar Outlook.com, Hotmail en Live eveneens aangescherpt.
Voor domeinen die meer dan 5.000 berichten per dag verzenden vereist Outlook SPF, DKIM en DMARC. Microsoft noemt voor DMARC minimaal p=none, met alignment via SPF of DKIM.
Dit laat zien dat SPF, DKIM en DMARC steeds meer onderdeel zijn geworden van de normale technische basis voor professionele e-mail.
SPF, DKIM en DMARC staan goed, maar mail gaat nog steeds naar spam
Dit komt regelmatig voor.
Authenticatie is belangrijk, maar het is geen volledige spamvrij-garantie.
Wanneer alle drie op PASS staan, controleer dan ook andere onderdelen.
Reverse DNS / PTR-record
Een verzendende mailserver hoort een passende reverse DNS-configuratie te hebben.
Google en Yahoo noemen geldige forward en reverse DNS expliciet in hun verzendrichtlijnen.
IP-reputatie
Een IP-adres dat in het verleden veel ongewenste mail heeft verstuurd kan een slechte reputatie hebben.
Dit kan bijvoorbeeld een rol spelen bij slecht beheerde gedeelde mailservers.
Domeinreputatie
Ook het domein zelf bouwt een reputatie op.
Plotseling enorme hoeveelheden mail versturen vanaf een nieuw of nauwelijks gebruikt domein kan anders worden beoordeeld dan stabiel zakelijk mailverkeer.
Spamklachten
Wanneer veel ontvangers berichten als spam markeren, kan dat de afleverbaarheid schaden.
Google en Yahoo hanteren voor hun richtlijnen een spampercentage van minder dan 0,3%.
Mailinglijsten
Stuur marketingmail alleen naar ontvangers die deze berichten daadwerkelijk verwachten en zorg dat afmelden eenvoudig is.
Voor bulk- en marketingmail gelden bij grote providers aanvullende afmeldvereisten.
Inhoud en links
Ook de inhoud van e-mail kan invloed hebben.
Controleer onder andere:
verdachte links;
misleidende onderwerpregels;
kapotte HTML;
ongebruikelijke bijlagen;
URL’s naar domeinen met slechte reputatie.
SPF DKIM DMARC controleren
Na het aanpassen van DNS is het belangrijk te testen of de instellingen daadwerkelijk functioneren.
Controleer niet alleen of het record in DNS zichtbaar is.
Verstuur een echte e-mail en bekijk de authenticatieresultaten in de headers.
Je wilt uiteindelijk controleren:
SPF = PASS;
DKIM = PASS;
DMARC = PASS;
From-domein correct;
SPF/DKIM alignment correct;
PTR/reverse DNS correct;
TLS actief.
Let ook op dat DNS-wijzigingen niet altijd onmiddellijk overal zichtbaar zijn door caching en TTL.
Interne link: lees hiervoor ook ons artikel over DNS propagation.
Veelgemaakte SPF-fouten
Een oude mailprovider blijft in SPF staan
Dit veroorzaakt niet altijd direct afleverproblemen, maar maakt het beleid onnodig ruim.
Verwijder verzendbronnen die aantoonbaar niet meer gebruikt worden.
Nieuwe mailprovider ontbreekt
Je stapt bijvoorbeeld over naar een andere maildienst, maar vergeet SPF aan te passen.
Meerdere SPF-records
Losse SPF-policies naast elkaar kunnen authenticatieproblemen veroorzaken.
Blind een record kopiëren
Het SPF-record van een andere organisatie zegt niets over jouw verzendinfrastructuur.
Website vergeten
Een contactformulier kan via een andere server mail versturen dan de normale mailbox.
Controleer ook de website.
Veelgemaakte DKIM-fouten
Record verkeerd gekopieerd
Een lange DKIM-sleutel kan bij handmatig invoeren verkeerd worden overgenomen.
Verkeerde selector
Wanneer de mailserver selector1 gebruikt maar DNS alleen selector2 bevat, kan de juiste sleutel niet gevonden worden.
DKIM wel in DNS, maar niet geactiveerd
Bij sommige providers moet DKIM na het toevoegen van DNS nog apart worden ingeschakeld.
Oude sleutel na migratie
Bij een overstap naar een nieuwe mailprovider kan oude DKIM-configuratie achterblijven.
Veelgemaakte DMARC-fouten
Direct p=reject instellen
Zonder inventarisatie kan dit legitieme e-mail raken.
Geen alignment
SPF en DKIM kunnen technisch afzonderlijk slagen terwijl DMARC alsnog niet slaagt omdat het zichtbare From-domein niet voldoende overeenkomt.
Rapportages niet bekijken
Een p=none-record publiceren en vervolgens maanden niets met de gegevens doen levert weinig op.
Vergeten externe systemen
Een CRM of boekhoudpakket kan namens het domein e-mail verzenden zonder dat dit in de oorspronkelijke inventarisatie is meegenomen.
Beschermt DMARC tegen spoofing?
DMARC helpt vooral tegen het ongeautoriseerd gebruiken van jouw domein in de zichtbare From-header wanneer ontvangende providers de policy toepassen.
Dat is belangrijk bij e-mail spoofing en phishing.
Zonder goede authenticatie kan een aanvaller proberen een bericht te laten lijken alsof het afkomstig is van:
facturen@jouwbedrijf.nl
Met correct ingestelde SPF, DKIM en DMARC krijgen ontvangende mailservers meer informatie waarmee zij kunnen bepalen of het bericht werkelijk door een geautoriseerde infrastructuur is verzonden.
DMARC is specifiek ontworpen om voort te bouwen op SPF en DKIM en domeineigenaren een beleid voor niet-conforme berichten te laten publiceren.
SPF, DKIM en DMARC na een servermigratie
Na een verhuizing van hosting of mailserver moeten deze records opnieuw worden gecontroleerd.
Dit wordt regelmatig vergeten.
Bijvoorbeeld:
Oude server: 192.0.2.10
Nieuwe server: 192.0.2.50
Wanneer SPF uitsluitend het oude IP-adres toestaat, kan mail vanaf de nieuwe server niet correct door de SPF-controle komen.
Controleer bij een migratie daarom minimaal:
SPF;
DKIM;
DMARC;
MX;
A/AAAA van mailhost;
PTR/reverse DNS;
hostname;
TLS-certificaat;
SMTP-configuratie.
Interne link: lees ook Website verhuizen naar andere hosting voor meer informatie over een complete hostingmigratie.
SPF, DKIM en DMARC voor WordPress
WordPress-websites versturen regelmatig automatische e-mail.
Denk aan:
contactformulieren;
wachtwoordherstel;
nieuwe accounts;
bestellingsbevestigingen;
formulieren;
notificaties.
Een veelgemaakte fout is WordPress rechtstreeks via een slecht geconfigureerde lokale mailfunctie laten versturen.
Voor zakelijke websites kan het verstandiger zijn om mail via een correct geauthenticeerde SMTP- of e-mailprovider te verzenden.
Daarbij moeten SPF en DKIM aansluiten op die verzenddienst en moet DMARC-alignment worden gecontroleerd.
SPF, DKIM en DMARC voor WooCommerce
Bij WooCommerce wordt betrouwbare e-mail nog belangrijker.
Klanten verwachten bijvoorbeeld:
orderbevestiging;
betaalinformatie;
verzendinformatie;
wachtwoordherstel;
accountmails.
Wanneer dergelijke berichten structureel in spam terechtkomen, leidt dat tot extra klantvragen en een slechte gebruikerservaring.
Controleer daarom na het configureren van WooCommerce niet alleen of een testmail technisch wordt verstuurd, maar ook of de authenticatie correct is.
Professionele e-mailauthenticatie via Sanum
Problemen met zakelijke e-mail beginnen vaak bij DNS, maar kunnen ook te maken hebben met de mailserver, hostingomgeving, verzendreputatie of een verkeerde combinatie van verschillende externe diensten.
Sanum kan helpen bij het controleren en configureren van onder andere:
SPF;
DKIM;
DMARC;
DNS;
MX-records;
reverse DNS/PTR;
mailserverconfiguratie;
WordPress-mail;
WooCommerce-mail;
servermigraties;
zakelijke e-mail.
Daarbij kijken we niet alleen of er ergens een TXT-record aanwezig is, maar of de verschillende onderdelen ook daadwerkelijk met elkaar samenwerken.
Komt zakelijke e-mail regelmatig in spam terecht of wil je SPF, DKIM en DMARC correct laten instellen? Neem contact op met Sanum voor controle van je domein, DNS en e-mailconfiguratie.
Veelgestelde vragen over SPF, DKIM en DMARC
Wat is het verschil tussen SPF, DKIM en DMARC?
SPF controleert of een verzendende server gemachtigd is. DKIM voegt een cryptografische handtekening toe aan e-mail. DMARC gebruikt SPF en DKIM en controleert daarnaast de relatie met het zichtbare From-domein.
Moet ik SPF, DKIM en DMARC alle drie instellen?
Voor professionele zakelijke e-mail is het verstandig alle drie correct te configureren. Grote providers stellen voor bulkafzenders inmiddels expliciete SPF-, DKIM- en DMARC-eisen.
Voorkomt SPF dat mijn e-mail in spam terechtkomt?
Niet volledig. SPF is één onderdeel van de beoordeling. Ook DKIM, DMARC, reputatie, spamklachten, reverse DNS en verzendgedrag spelen mee.
Wat is een goed DMARC-record om mee te beginnen?
Een eerste implementatie begint vaak met p=none en rapportage, nadat SPF en DKIM zijn ingericht. Analyseer vervolgens de resultaten voordat je overstapt naar een strenger beleid.
Is p=reject beter dan p=none?
p=reject biedt een strenger beleid voor niet-conforme berichten, maar is alleen verstandig wanneer alle legitieme verzendbronnen correct zijn ingericht. Anders kun je geldige mail raken.
Hoe controleer ik of DKIM werkt?
Verstuur een e-mail en controleer de volledige headers. Daarin moet bij een correct geauthenticeerd bericht een succesvolle DKIM-verificatie zichtbaar zijn.
Waarom faalt DMARC terwijl SPF en DKIM slagen?
DMARC kijkt ook naar alignment. Het domein dat voor SPF of DKIM wordt gebruikt moet voldoende overeenkomen met het domein in de zichtbare From-header.
Moet SPF worden aangepast wanneer ik van server verhuis?
Wanneer het verzendende IP-adres of de mailprovider verandert, moet SPF opnieuw worden gecontroleerd. Mogelijk moeten ook DKIM, PTR en andere mailinstellingen worden aangepast.
Heb ik DMARC nodig als ik maar weinig e-mails verstuur?
Ook kleinere verzenders kunnen profiteren van DMARC voor domeinbescherming en inzicht in verzendbronnen. De specifieke verplichte bulkvereisten van providers gelden pas boven hun ingestelde verzenddrempels.
Kunnen SPF, DKIM en DMARC voorkomen dat iemand mijn domeinnaam misbruikt?
Ze verkleinen de mogelijkheden voor succesvolle e-mailspoofing en geven ontvangende servers middelen om ongeautoriseerde berichten te herkennen en volgens het DMARC-beleid te behandelen.
