MX-controle:
reageert uw mailserver wel?

Typ uw domein hierboven in. We vragen de MX-records op, sorteren ze op prioriteit, lossen elke hostnaam op naar IPv4 en IPv6, laten de FCrDNS-rondgang lopen voor elk adres, herkennen de mailprovider aan het patroon, en maken vervolgens vanaf ons probe-netwerk verbinding met elke server op poort 25 — waarbij we de SMTP-banner lezen en STARTTLS testen. Gratis, geen registratie, in enkele seconden klaar.

Lager getal = wordt als eerste geprobeerd. Afzenders werken de lijst pas verder af als de hosts met een betere prioriteit niet antwoorden. Gelijke prioriteiten zijn geen fout — het is round-robin load balancing, en grote providers gebruiken het (Googles klassieke set heeft twee hosts op 5 en twee op 10). Het probleem bij een opzet met meerdere lagen zit niet in de getallen — de backup-laag draait vaak oudere software met losere filtering, en precies daarom mikken spammers erop.

Forward-confirmed reverse DNS: het IP-adres van uw mailserver moet een PTR-record hebben, en de naam in die PTR moet weer teruglossen naar hetzelfde IP-adres. Het is goedkoop bewijs dat wie het IP-adres beheert, ook de naam beheert — spamkanonnen op gekaapte adresreeksen krijgen dat meestal niet voor elkaar. Googles richtlijnen voor afzenders maken een geldige, kloppende PTR een harde eis om bij Gmail af te leveren, en de meeste filters wegen het mee. En voordat u dit wegzet als „alleen uitgaand”: uw MX-host verstuurt ook — elke bounce, elke afwezigheidsmelding, elke doorstuurmail. Een kapotte rondgang op de inkomende machine drukt in stilte op dat alles.

Eén MX-record met preference 0 en de root als host — 0 . — vastgelegd in RFC 7505. Het is de standaardmanier om te verklaren: „dit domein accepteert geen mail.” Afzenders zien het en sturen binnen seconden een permanente bounce, in plaats van terug te vallen op de impliciete MX-regel en uw webserver dagenlang te bestoken met nieuwe pogingen. Het is het juiste record voor geparkeerde domeinen en domeinen die alleen een website hebben — gecombineerd met v=spf1 -all en een DMARC-reject-beleid, zodat ook niemand namens het domein kan verzenden.

Verrassend genoeg wel. De impliciete MX-regel uit RFC 5321 zegt dat afzenders, als er geen MX bestaat, het A/AAAA-record van het domein behandelen als een MX met preference 0 — de mail wordt dus bezorgd bij wat er ook antwoordt op het IP-adres van uw webserver. Als daar toevallig een MTA draait, stroomt de mail gewoon door; sommigen draaien jarenlang productie-e-mail op dit toeval. Het is kwetsbaar — verplaats de website en de mail is weg — en zelden opzettelijk. Publiceer expliciete MX-records voor echte mail, of 0 . als er geen mail bedoeld is.

Nee — en dat is een veelvoorkomend misverstand. MX beantwoordt de vraag „waar gaat mail naar dit domein heen”; uw uitgaande reputatie zit in het verzendende IP-adres, SPF, DKIM en DMARC, die onze bijbehorende tools stuk voor stuk beoordelen. Twee uitzonderingen: als u self-hosted, is de MX-machine zelf de verzendende machine, dus tellen de FCrDNS en TLS-hygiëne daarvan dubbel mee; en sommige ontvangers controleren of een domein dat mail verstuurt, ook mail kan ontvangen — een kapotte MX-set faalt die test in stilte.

De probe opent een TCP-verbinding naar elke MX-host op poort 25, leest de begroetingsbanner, stuurt EHLO, en controleert of STARTTLS wordt aangeboden — en onderhandelt het vervolgens, waarbij de TLS-versie en het certificaat worden vastgelegd. Er wordt geen mail verstuurd: het gesprek stopt vóór MAIL FROM. U kunt dit niet vanaf een thuisverbinding doen, omdat consumenten-ISP's uitgaand verkeer op poort 25 blokkeren om botnet-spam tegen te gaan. Eén kanttekening om te kennen: STARTTLS op poort 25 is opportunistisch — een aanvaller die zich tussen de verbinding plaatst, kan het aanbod eruit filteren. MTA-STS is het slot; onze TLS-versiecontrole loopt elke protocolversie na die uw server zal spreken.