Hoe controleer ik mijn MX-, SPF-, DKIM- en DMARC-records?

Hoe controleer ik een MX-record?

Voer dig MX uit met uw domeinnaam en +short en vergelijk de prioriteiten en hostnamen met de waarden die uw provider u gaf. Het antwoord toont één regel per record: de prioriteit, een spatie en de host. Voor Proton Mail verwacht u 10 mail.protonmail.ch. en 20 mailsec.protonmail.ch.; voor Fastmail 10 in1-smtp.messagingengine.com. en 20 in2-smtp.messagingengine.com.; voor Mailbox.org vier mxext-hosts.

Hier komen twee problemen aan het licht. Een record van de vorige provider dat nog in de lijst staat, maakt aflevering onvoorspelbaar, dus verwijder het. En een leeg antwoord betekent geen MX: afzenders vallen dan terug op het adresrecord van de domeinnaam, zoals RFC 5321 beschrijft. Wat elke regel betekent, wordt uitgelegd in wat een MX-record is.

Hoe controleer ik een SPF-record?

Vraag de TXT-records op in de root van de domeinnaam en controleer dat precies één regel met v=spf1 begint. De root bevat ook andere TXT-records, zoals het eigendomsbewijs van uw e-mailprovider, dus lees de hele lijst. Twee regels die met v=spf1 beginnen zijn een fout: RFC 7208 geeft een permanente fout terug als een domeinnaam meer dan één SPF-record heeft.

Tel dan de opzoekingen. Elke include, a, mx, ptr en exists, plus de redirect-modifier, telt mee voor de limiet van 10, en een include telt ook mee wat erin genest is. Een record boven de limiet mislukt voor elke afzender. Het aanmaken van het record wordt beschreven in hoe u een SPF-record aanmaakt.

Hoe controleer ik DKIM als ik de selector niet ken?

Gebruik de selector van uw provider: u kunt selectors niet uit DNS opvragen, dus neem ze uit het DKIM-scherm van de provider. DNS staat geen lijst toe van de namen onder _domainkey. De selectors zijn protonmail, protonmail2 en protonmail3 bij Proton Mail, fm1, fm2 en fm3 bij Fastmail, en MBO0001 tot MBO0004 bij Mailbox.org.

De opzoeknaam is selector._domainkey.yourdomain. Een provider die CNAME-records gebruikt, zoals deze drie, antwoordt met een CNAME naar zijn eigen host. Een provider die de sleutel rechtstreeks publiceert, antwoordt met een TXT-record dat v=DKIM1 en p= gevolgd door de publieke sleutel bevat. Een lege p= betekent dat de sleutel is ingetrokken. De sterkste test is een echt bericht, want een record dat bestaat kan nog ongebruikt zijn: stuur een e-mail naar een andere provider en lees dkim=pass in de volledige headers.

Hoe controleer ik een DMARC-record?

Vraag het TXT-record op bij _dmarc.yourdomain en controleer één regel die met v=DMARC1 begint en een p=-beleid bevat. Als p ontbreekt, behandelen ontvangers het beleid als none. Als de regel geen rua heeft, worden er geen aggregate rapporten geproduceerd en vertelt de monitoringfase van de uitrol van DMARC u niets. Records in de oudere stijl dragen mogelijk nog een pct-tag, die RFC 9989 heeft verwijderd.

Een subdomein zonder eigen record valt via de DNS tree walk onder het beleid van de bovenliggende domeinnaam, met hoogstens acht query's. Een opzoeking van een naam zonder record geeft niets terug, wat hetzelfde is als geen DMARC.

Waarom toont mijn opzoeking nog steeds de oude waarde?

Een cache bewaart het oude antwoord totdat de TTL verloopt, en een ontbrekend record kan ook worden gecachet. De tijd die een wijziging nodig heeft om zich te verspreiden is ongeveer de oude TTL van het record op het moment dat u het wijzigde. Richtlijnen van leveranciers noemen voor een gebruikelijke MX-wijziging een tot vier uur, en in het ergste geval 24 tot 48 uur. RFC 2308 voegt toe dat negatieve antwoorden worden gecachet met de TTL uit het SOA-record van de zone, dus een record dat u net hebt aangemaakt kan bij sommige resolvers afwezig lijken.

Om de caches over te slaan, vraagt u de gezaghebbende nameserver: zoek hem op met dig NS en herhaal dan de query met @ en zijn naam, zoals in het codeblok hierboven. Als de gezaghebbende server de nieuwe waarde toont en uw resolver niet, wacht dan. Als geen van beide dat doet, is het record niet opgeslagen of is de hostnaam fout, meestal doordat de DNS-editor de domeinnaam een tweede keer heeft toegevoegd.

Als e-mail nog steeds niet aankomt nadat de records goed lijken, ga dan naar waarom e-mail niet aankomt op een eigen domeinnaam.

Welke online hulpmiddelen kunnen e-mailrecords controleren?

Elke online DNS-opzoeking of controle van mailauthenticatie die de openbare DNS bevraagt, geeft hetzelfde antwoord als dig, met een vriendelijkere weergave. Gebruik er een die de ruwe recordtekst toont, zodat u hem teken voor teken kunt vergelijken met de waarde van uw provider. Plak er geen privégegevens in: de domeinnaam is alles wat het nodig heeft.

Volgens de telling van Postelva van 12 november 2026 vraagt een volledige Proton Mail-installatie 8 records (1 verificatie-TXT, 2 MX, 1 SPF, 3 DKIM, 1 DMARC) en 6 opzoekingen, omdat de twee MX-records één query delen en de verificatie- en SPF-records de root-TXT-query delen. Bewaar de zes opdrachten eenmalig en voer ze na elke wijziging opnieuw uit. Dezelfde records worden vergeleken in SPF vs DKIM vs DMARC.

Een citeerbare regel: vraag na elke DNS-wijziging de vier recordtypen op en stuur een testbericht; een record is pas correct als de opzoeking en het bericht overeenkomen.