Hoe de foutmelding 'Reverse DNS komt niet overeen met de SMTP-banner' te verhelpen

Als u uw eigen mailserver beheert, zult u tijdens een e-mailbezorgbaarheidstest waarschijnlijk de foutmelding 'Reverse DNS komt niet overeen met de SMTP-banner' tegenkomen. Deze waarschuwing is niet cosmetisch. Als u deze negeert, schaadt u direct het vertrouwen in e-mail, neemt spamfiltering toe en kunnen grote providers zoals Gmail en Outlook uw berichten volledig weigeren.

Reverse DNS fungeert als de identiteitskaart van uw server, terwijl de SMTP-banner fungeert als de handdruk. Wanneer deze twee identificatiegegevens niet overeenkomen, behandelen ontvangende servers uw e-mail als verdacht. Deze discrepantie duidt op slechte serverhygiëne en is een veelvoorkomend kenmerk van spam-infrastructuur.

Wat betekent "Reverse DNS komt niet overeen met de SMTP-banner"?

"Reverse DNS komt niet overeen met de SMTP-banner" betekent dat de hostnaam die aan uw verzendende IP-adres is gekoppeld (reverse DNS of PTR-record) niet overeenkomt met de hostnaam die uw mailserver vermeldt in zijn SMTP-begroeting (HELO/EHLO). Wanneer deze niet overeenkomen, beschouwen ontvangende mailservers de verbinding als onbetrouwbaar en kunnen ze uw e-mails markeren of blokkeren.
Zie dit als een verificatieproces tussen twee servers.

Omgekeerde DNS

Standaard DNS zet een domeinnaam om in een IP-adres. Omgekeerde DNS doet het tegenovergestelde: het kijkt naar een IP-adres en vraagt: "Welke naam is hieraan gekoppeld?" Een PTR-record regelt dit.

SMTP-banner (HELO/EHLO)

Wanneer uw server een verbinding met een andere server tot stand brengt, stelt hij zich voor met een begroeting die een SMTP-banner wordt genoemd. Deze begroeting bevat een hostnaam (bijvoorbeeld mail.example.com).

De vergelijking

Wanneer uw e-mail aankomt, bekijkt de ontvangende server uw IP-adres en controleert het PTR-record. Als het PTR-record server1.isp-provider.net aangeeft, maar uw SMTP-banner mail.uwdomein.com aangeeft, is er sprake van een discrepantie.

Een kort voorbeeld:

• IP-adres: 1.2.3.4
• SMTP-banner: mail.business.com
• PTR-record (omgekeerde DNS): 1-2-3-4.dynamic.cloudhost.com
• Resultaat: Fout! De identiteiten komen niet overeen.

Waarom deze fout belangrijk is voor de afleverbaarheid van e-mails

Ontvangende mailservers gebruiken deze controle als een snelle manier om spammers op te sporen.

1. Spamfiltertriggers

Spammers maken vaak gebruik van niet-geconfigureerde servers of botnets. Een generieke of niet-overeenkomende hostnaam is een van de eerste dingen die een spamfilter signaleert.

2. Reputatie en vertrouwen

Grote internetproviders geven prioriteit aan Forward-Confirmed Reverse DNS. Dit betekent dat uw IP-adres naar een naam verwijst en dat die naam terugverwijst naar hetzelfde IP-adres. Als u dit niet heeft, daalt uw 'vertrouwensscore' aanzienlijk.

3. Authenticatiesignalen

Hoewel technisch gezien losstaand van SPF, DKIM en DMARC, maakt rDNS deel uit van het 'totaalplaatje' van de serverstatus. Als uw basisverbinding rommelig is, is uw DMARC-beleid mogelijk niet voldoende om uw reputatie te redden.

Veelvoorkomende oorzaken van de mismatch

Hier zijn enkele veelvoorkomende oorzaken van mismatch.

Standaard cloudhostnamen

Je gebruikt een VPS en hebt het standaard PTR-record dat door de provider is toegewezen niet gewijzigd.

De MTA-configuratie vergeten

Je hebt je DNS-records bijgewerkt, maar bent vergeten de daadwerkelijke instellingen in je e-mailsoftware bij te werken.

Gedeelde hosting

Je bevindt je op een gedeeld IP-adres waarbij de provider de PTR heeft ingesteld op zijn eigen primaire domein, niet op dat van jou.

Kwesties rond intellectueel eigendom

U hebt geen toestemming om het PTR-record te wijzigen, omdat het IP-adres wordt beheerd door een internetprovider die u geen controle heeft gegeven.

Hoe u uw huidige waarden kunt controleren

Voordat u begint met het wijzigen van instellingen, moet u eerst kijken wat de rest van de wereld ziet.

1. Controleer het PTR-record

Voer een snel terminalcommando uit om te zien welke hostnaam aan uw IP is gekoppeld:

• Mac/Linux: dig -x [uw_IP-adres]
• Windows: nslookup [uw_IP-adres]

2. Controleer de SMTP-banner

Gebruik Telnet of OpenSSL om te zien hoe uw server anderen begroet. De eerste regel van het antwoord toont de hostnaam van uw SMTP-banner.

3. Gebruik een gecentraliseerde tool

Handmatig controleren is prima, maar tools zoals PowerDMARC's DNS Record Lookup kunnen u laten zien hoe uw PTR- en A-records er wereldwijd uitzien, zodat u zeker weet dat er geen "DNS-vertraging" is die u valse resultaten geeft.

Hoe u de foutmelding 'Reverse DNS komt niet overeen met de SMTP-banner' stap voor stap kunt oplossen

Hier zijn enkele belangrijke stappen die u moet nemen om de fout te verhelpen.

Stap 1: Identificeer het verzendende IP-adres

Controleer het exacte openbare IP-adres dat uw mailserver gebruikt om e-mail te verzenden. Als u achter een firewall, NAT of proxy zit, kan dit afwijken van het IP-adres van uw lokale server.

Stap 2: Corrigeer het PTR-record

Dit is het deel waar de meeste mensen op vastlopen. Je kunt dit meestal niet wijzigen in het DNS-paneel van je domein. Je moet dit doen via het bedrijf dat eigenaar is van het IP-adres.

• Cloud VPS: Ga naar het dashboard van uw provider (sectie Netwerken/Statisch IP-adres) en zoek naar 'Reverse DNS' of 'PTR'.
• Speciaal/lokaal: Mogelijk moet u een supportticket openen bij uw internetprovider.
• Het doel: stel de PTR in op een volledig gekwalificeerde domeinnaam.

Stap 3: Werk de SMTP-banner (HELO/EHLO) bij

Zorg er nu voor dat uw server zijn naam kent. Veel mailservers gebruiken een standaard bannersjabloon voor de SMTP-begroeting, dus u moet uw Mail Transfer Agent zo configureren dat deze dezelfde FQDN vermeldt die u in stap 2 hebt ingesteld.

• Postfix: Bewerk /etc/postfix/main.cf en werk myhostname = mail.example.com bij.
• Exim: Werk de primary_hostname in uw configuratiebestand bij.
• Start de service opnieuw op nadat u wijzigingen hebt aangebracht!

Stap 4: Controleer of de Forward DNS overeenkomt

De hostnaam die u in stap 2 en 3 hebt gebruikt, moet ook een A-record die terugverwijst naar uw IP-adres. Wanneer de PTR naar de naam verwijst en de naam naar het IP-adres verwijst, bereikt u Forward-Confirmed Reverse DNS (FCrDNS).

Best practices om reverse DNS-fouten te voorkomen

Volg deze aanwijzingen om reverse DNS-fouten te voorkomen.

Eén IP per hostnaam

Houd indien mogelijk uw naamgevingsconventie voor e-mail consistent (bijvoorbeeld mail1.domein.com).

Vermijd generieke naamgeving

Laat uw rDNS nooit staan op static.123.45.clients.provider.com.

Regelmatige audits

Gebruik geautomatiseerde tools om uw infrastructuur te monitoren. PowerDMARCbiedt bijvoorbeeld realtime monitoring die u waarschuwt als uw records niet meer kloppen of als uw IP op een zwarte lijst terechtkomt.

Afstemmen met authenticatie

Zorg ervoor dat uw reverse DNS-hostnaam is opgenomen in uw SPF-record om 'soft' fouten te voorkomen.

Hoe deze fout verband houdt met DMARC en e-mailverificatie

Terwijl DMARC zich richt op de integriteit van het bericht, richten Reverse DNS en de SMTP-banner zich op de integriteit van de verbinding. Zie het als twee beveiligingslagen: één voor het pakket en één voor de bezorgwagen.
Hieronder leest u hoe een mismatch uw bredere authenticatiestrategie ondermijnt:

Prioriteit van evaluatie

De meeste ontvangende servers voeren een 'handshake'-controle uit voordat ze zelfs maar naar uw DMARC- of DKIM-records kijken. Als uw rDNS en banner niet overeenkomen, kan uw e-mail worden afgeremd of geweigerd bij de gateway voordat uw DMARC 'Reject'-beleid zelfs maar de kans krijgt om te bewijzen dat het bericht legitiem is.

Het signaal 'professionaliteit'

Beveiligingsfilters gebruiken rDNS-afstemming als een proxy voor de gezondheid van de server. Een mismatch duidt op een slecht geconfigureerde of gekaapte server, wat typisch is voor botnets, wat kan leiden tot een lagere reputatiescore, ongeacht hoe perfect uw SPF-records zijn.

FCrDNS-naleving

Grote internetproviders vereisen vaak Forward-Confirmed Reverse DNS als basis voor vertrouwen. Als uw SMTP-banner niet synchroon loopt met uw PTR- en A-records, slaagt u niet voor deze verificatie, waardoor uw DMARC-geconformeerde e-mails verdacht overkomen.

Onzichtbare mislukkingen

Zonder een platform als PowerDMARC blijven deze hiaten in de infrastructuur vaak onopgemerkt. Hoewel standaard DNS-controles kunnen aantonen dat uw records 'actief' zijn, geven ze niet altijd aan hoe de gateway van een ontvanger de discrepantie tussen uw banner en uw IP interpreteert.

Hoe PowerDMARC rDNS en SMTP-afstemming automatiseert

Het handmatig controleren van terminalcommando's en het inloggen op verschillende VPS-dashboards kan tijdrovend zijn en vatbaar voor menselijke fouten. PowerDMARC biedt een gecentraliseerde reeks tools die zijn ontworpen om ervoor te zorgen dat de "handshake" van uw server altijd geldig is en vertrouwd wordt door wereldwijde ISP's.

1. Real-time PTR- en FCrDNS-validatie

Onze DNS Record Lookup-tool gaat verder dan alleen basiscontroles. Het verifieert FCrDNS door tegelijkertijd uw PTR-record te controleren en ervoor te zorgen dat de resulterende hostnaam terugverwijst naar uw verzendende IP. Dit helpt u bij het identificeren van "half geconfigureerde" instellingen waarbij een PTR bestaat, maar niet goed is afgestemd op een A-record.

2. Proactieve monitoring en waarschuwingen

DNS-drift komt voor, cloudproviders resetten soms records of IP-reeksen worden opnieuw toegewezen. Reputatiemonitoringservices volgen uw infrastructuur 24/7. Als uw rDNS-afstemming wordt verbroken of het IP-adres van uw server plotseling op een zwarte lijst verschijnt als gevolg van een configuratiefout, ontvangt u een waarschuwing voordat uw deliverability-percentages beginnen te dalen.

3. Holistisch dashboard voor leverbaarheid

Terwijl rDNS de verbindingslaag afhandelt, koppelt PowerDMARC deze gegevens aan uw SPF-, DKIM- en DMARC-prestaties. Door uw geaggregeerde RUA-rapporten te bekijken, kunt u zien of specifieke IP-adressen te maken hebben met hoge afwijzingspercentages van Gmail of Outlook, waardoor u leveringsproblemen kunt herleiden tot niet-overeenkomende SMTP-banners.

Definitieve checklist

• PTR-record komt overeen met de SMTP-banner.
• SMTP-banner komt overeen met de Forward DNS (A-record).
• IP-reputatie is gezond (staat niet op zwarte lijsten).
• SPF, DKIM en DMARC zijn volledig geconfigureerd en op elkaar afgestemd.

Samenvattend

Uiteindelijk draait het bij e-mail allemaal om vertrouwen. Als uw IP-adres en uw serverbegroeting niet overeenkomen, zult u moeite hebben om in de inbox terecht te komen. Het afstemmen van uw records is niet alleen een 'best practice', het is een noodzaak als u wilt dat uw e-mails daadwerkelijk worden gelezen.
Dit soort infrastructuurfouten kunnen lastig op te sporen zijn. PowerDMARC maakt het u gemakkelijker door uw instellingen te controleren en u duidelijke rapporten te geven over wat wel en niet werkt. Het spoort deze configuratieproblemen op voordat ze een nachtmerrie voor de afleverbaarheid worden.
Bekijk de gratis proefversie van PowerDMARC en zie precies hoe uw servers eruitzien voor de rest van de wereld.

Veelgestelde Vragen

Kan ik een PTR-record in mijn domeinregistrar aanpassen?
Nee. PTR-records zijn gekoppeld aan het IP-adres. U moet contact opnemen met uw host of uw internetprovider.
Zal DMARC hierdoor mislukken?
Niet noodzakelijk, maar u kunt toch geblokkeerd worden. Veel filters controleren de banner "handshake" voordat ze zelfs maar naar uw DMARC-records kijken.
Waarom is de fout nog steeds aanwezig nadat ik deze heb verholpen?
DNS-propagatie. Het kan tot 24 uur duren voordat nieuwe records zich over het internet verspreiden.
Wat als ik meerdere domeinen op één IP heb?
Geen zorgen, dit komt heel vaak voor. U hebt niet voor elk domein een andere banner nodig. Kies gewoon één 'hoofdnaam' voor uw server en zorg ervoor dat uw PTR, SMTP-banner en A-record allemaal naar die ene naam verwijzen. Zolang ze met elkaar overeenkomen, zullen de andere domeinen die vanaf dat IP-adres verzenden, geen problemen ondervinden.

• Over
• Laatste berichten

Yunes Tarada

Expert domein- en e-mailbeveiliging bij PowerDMARC

Yunes is teamleider Operations bij PowerDMARC en heeft expertise in e-mailauthenticatie en -beveiliging. Hij is een door Microsoft gecertificeerde Azure Administrator Associate en beschikt over certificeringen, zoals CompTIA A+ en vele andere.

Laatste berichten van Yunes Tarada (Bekijk alle berichten)

• Geverifieerd merkcertificaat versus algemeen merkcertificaat: het juiste certificaat kiezen - 10 maart 2026
• Spam Confidence Level (SCL) -1 Bypass: wat het betekent en hoe u ermee omgaat - 4 maart 2026
• "Voldoet niet aan DMARC-verificatie en heeft een DMARC-beleid van weigeren": wat dit betekent en hoe u dit kunt oplossen - 26 februari 2026