Userbase

Hoi,


Heb eens een dom vraagje.

Mail ik vanaf een Exchange mailbox naar een mailbox op een Vimexx mail krijg ik de melding dat het PTR record niet correct ingesteld is.
Maar ook weer niet naar alle mailboxen van de servers die ik gebruik.

Wat mis ik bij de DNS instellingen van mijn domein op Exchange

Als je zelf je mailserver host, dan moet dat (in regel) vanop een fixed IP gebeuren. De provider achter dat fixed IP moet het PTR-record instellen.
Ik heb dat indertijd aangevraagd bij zowel Telenet als edpnet en dat ging vlot.

PTR record is zowiezo op niveau van dns, dus staat an sich los van exchange.

in principe zou dat moeten betekenen dat het IP-adres van (een van) je mailservers géén reverse dns heeft (of niet overeenkomt met de hostname)

Sinna schreef: 16 feb 2024, 23:09 Als je zelf je mailserver host, dan moet dat (in regel) vanop een fixed IP gebeuren. De provider achter dat fixed IP moet het PTR-record instellen.

Neen hoor, gewoon het MX record naar MS Exchange en de mailbox worden daar gebruikt.

Toegevoegd na 2 minuten 52 seconden:

Splitter schreef: 16 feb 2024, 23:10 PTR record is zowiezo op niveau van dns, dus staat an sich los van exchange.

in principe zou dat moeten betekenen dat het IP-adres van (een van) je mailservers géén reverse dns heeft (of niet overeenkomt met de hostname)

Dus dan moet ik terug met de hoster contact opnemen.
Heb je daar ergens een goed artikel waar je mij naar kan verwijzen?
Thanx

Het wordt nergens expliciet verplicht dat de PTR moet matchen voor het afleveren van email, het is een keuze om emails te weigeren obv iprev fail, net zoals het een keuze is om PTR aan te bieden of niet.

Maar goed, hier is materiaal dat je kan gebruiken:

https://datatracker.ietf.org/doc/html/r ... ection-2.1
> "Make sure your PTR and A records match."

Wiki inzake deze RFC bepaling, inclusief implicaties naar email toe: https://en.wikipedia.org/wiki/Forward-c ... everse_DNS

RFC die uitlegt hoe iprev rol kan spelen bij de authenticatie van email berichten: https://datatracker.ietf.org/doc/html/rfc8601#section-3

Leuk in theorie, in de praktijk moet het matchen of je mails worden gereject of krijgen een hogere spam classificatie.

Aanbieden of niet.
Als Vimexx mails weigert snap ik dat niet.
Ik ga met Vimexx ook nog eens contact opnemen.

zoek eerst even uit of de mailservers in kwestie uberhaupt een PTR record hebben (géén record hebben is nog steeds iets heel anders dan een niet-matchend record hebben)

het is afaik verplicht om een PTR record te hebben dat terug kan leiden naar je mailserver (met de aanrader dat het een matchende hostname is).

dus:

1.2.3.4 mag een forward hebben van "mijn.mail.server", en een reverse van "dit.is.een.mailserver" zolang "dit.is.een.mailserver" maar het ip van 1.2.3.4 teruggeeft.
moest de reverse echter "mijn.mail.server" zijn, zou dat nog beter zijn.

als je mailserver "mijn.mail.server" zou gebruiken, en dat zou niet te vinden zijn in dns: fail
als je mailserver "mijn.mail.server" zou gebruiken, maar het zou niet resolven naar het ip van je mailserver: fail
als je mailserver "mijn.mail.server" zou gebruiken, en geen reverse hebben: fail
als je mailserver "mijn.mail.server" zou gebruiken, en een niet-matchende reverse zou hebben ("dit.is.een.mailserver"): accept, maar hogere spam classificatie
als je mailserver "mijn.mail.server" zou gebruiken, en als reverse ook "mijn.mail.server" zou hebben, dewelke beide het ip van de mailserver zijn: perfect

je kan een aantal tests doen op deze sites, om zo al een vroege conclusie te maken:

- mxtoolbox.com
- mail-tester.com
- dnsviz.net
- dnschecker.org

Splitter schreef: 17 feb 2024, 19:43 het is afaik verplicht om een PTR record te hebben dat terug kan leiden naar je mailserver (met de aanrader dat het een matchende hostname is).

Kan je aanhalen waar staat dat een PTR, en meer specifiek FCrDNS dan, verplicht is?

Ik dacht dat het een best practice was. In de praktijk kan email zonder FCrDNS idd niet altijd afgeleverd worden, niet omwille van technische beperkingen, wel nav policy (wat ook betekent dat het wel afgeleverd kan worden als die policy niet gehanteerd wordt). Ik verwijs naar de RFC 1912 hierboven gelinkt, waar staat "there should be a matching PTR record," waar men dus should gebruikt ipv must.

Reden: geen kwestie van wie gelijk heeft, wel de implicatie hiervan naar de vraag van OP toe, alsook zijn verzoek voor "een goed artikel waar je mij naar kan verwijzen". Als het inderdaad verplicht is heeft hij een aanzienlijk makkelijkere case bij zijn provider, dan bij een best practice.

in RFC1912 zou ik de 'should' persoonlijk interpreteren als een 'must' (volgens mij is de should gebruikt als 'zou moeten hebben'),
maar dat heeft weinig belang gezien die enkel informatief is.

RFC8601 geeft voor 'iprev' wel aan dat het wel verplicht is om een PTR te hebben én dat die matcht, maar geeft eveneens aan dat die methode afgeraden is, omdat dit vaak niet gerespecteerd zou worden.

en ter verificatie heb ik het ook nog eens aan chat gpt gevraagd... en ik lijk effectief mis te zitten, er zou geen enkele RFC zeggen dat een PTR record (al dan niet matchend) verplicht is, voor geen enkel type record.
zou nochtans gezworen hebben van wel - maar het zal, zoals je zegt, dus 'best practice' zijn, en over de jaren heen in mijn hoofd een verplichting geworden zijn.

ben persoonlijk wel benieuwd naar de exacte melding dat OP krijgt, en over welke IPs het gaat (gewoon, omdat ik zo'n meldingen nog nooit heb meegemaakt in die 20-wat jaar dat ik mijn eigen mailservertje draai)

Iirc doet gmail sinds kort verhoogd moeilijk als de PTRs niet of niet juist ingesteld staan.
Deel van hun spambestrijding en mailbeveiliging.

Blijft toch vreemd.
Op alle servers die ik gebruik bij verschillende hosters, zit een PTR.
Maar als je de mail op Exchange hebt zitten kan dat toch nooit overeenkomen met die van de webserver.

550 5.7.363 Remote server returned sender verification failed -> 550 Verification failed for <[email protected]>;Sender verify failed

En toch staat erbij dat Office365 geen PTR-records kan maken of beheren.
Dus de DNS moet extern.
Zal mijn eens wat verdiepen in die ganse materie

svermassen schreef: 18 feb 2024, 19:18 Maar als je de mail op Exchange hebt zitten kan dat toch nooit overeenkomen met die van de webserver.

Zelf weinig ervaring met Exchange, maar waarom zou dat niet kunnen?

De PTR record is vooral administratief kan (en mag in principe) gelijk welke FQDN zijn. Het mag dus ook gerust een naam zijn die dan weer resolvet naar ergens compleet anders. Je kan ook meerdere PTR records hebben voor hetzelfde IP.

svermassen schreef: 18 feb 2024, 19:18 En toch staat erbij dat Office365 geen PTR-records kan maken of beheren.
Dus de DNS moet extern.
Zal mijn eens wat verdiepen in die ganse materie

Het aanmaken van die PTR moet door de provider gebeuren die het (vast) IP-adres aan jou uitgedeeld heeft: op Office365 heeft dat dus geen zin.
Zoals eerder gemeld maken noch Telenet noch edpnet daar problemen rond (in de veronderstelling dat het een vast IP-adres is), geen ervaring met Proximus hieromtrent.

svermassen schreef: 18 feb 2024, 19:18 550 5.7.363 Remote server returned sender verification failed -> 550 Verification failed

hmmm... even getest:
o365, geldige spf record, A record & rDNS matchen (mail-db9pr02cu00204.inbound.protection.outlook.com) voor de mailserver,
A records lijken in orde (de usual gigantische lijst van o365 mailservers)
zou er mss een nieuwe server binnen de o365 cluster zijn die niet goed geconfigureerd is ? maar dan zouden meerdere klanten dat moeten ervaren?

heb je toevallig zo'n geweigerd voorbeeld met het effectieve IP van de versturende mailserver ?

also: belangrijk: de gefaalde mails zijn toch niet toevallig verstuurd via een of ander scriptje op de webserver?
want dat zou het natuurlijk ook helemaal anders maken (zeker als je gewoon een mailto scriptje gebruikt ipv smtp bv)


Edit: door even naar je site te surfen heb ik gezien dat je DA gebruikt, toevallig met hetzelfde domein als waarmee je vanaf outlook mails stuurt ?
if so kan deze thread je de oplossing bieden: https://forum.directadmin.com/threads/c ... ain.62305/
(in het kort: *.protection.outlook.com whitelisten + bij de MX records van het domein in DA zorgen dat de mail handling NIET door DA maar door O365 gedaan wordt)

als ik me niet vergis krijg je dus die foutmelding wel en lijkt het alsof er een PTR record mis is met het domein, maar feitelijk komt dat van DA die die fout ziet,
door simpelweg een configuratie instelling waarbij DA denkt dat die verantwoordelijk zou moeten zijn voor de mails (en dus boos is dat de mail van 0365 en niet matcht)

Thanx voor de tips.
Ik ga eens wat verder uitpluizen.

Edit: ik heb wat gekeken naar de dns, dus hswsolutions.eu is het maildomein.
Wat mis ik hier dan nog?

Www.mail-tester.com gebruiken, voor mij nog steeds de meest eenvoudige referentie om uit te pluizen wat er nog ontbreekt om goed te zijn. Onze klanten halen daar allemaal tussen de 9 en 9.8 als score, en ik geef toe dat dat toch minder straightforward was als het lijkt.

Ja, die ken ik goed genoeg.
En ik haal daar 10/10.
Daarmee dat ik er geen hol meer van snap

Edit: correctie, inderdaad 10/10, maar wel met opmerkingen i.v.m. het PTR record.

Uw IP-adres 40.107.22.137 wordt geassocieerd met het domein mail-am6eur05on2137.outbound.protection.outlook.com.
Echter lijkt het erop dat uw bericht wordt verzonden vanaf EUR05-AM6-obe.outbound.protection.outlook.com.

De melding zegt dat er een andere outbound gebruikt om de mails te verzenden dan verwacht.
En nu moet ik bij MS iemand aan de gang krijgen om dat te fixen?

Dat is normaal en quasi met alle M365 sending hosts hoor ... ik haal ook meestal 10/10 als DKIM ook actief is. Als je het enkel met vimexx hebt lijkt het me eerder daar een issue te zijn dan elders. Nu als alles goed staat is blocken enkel en alleen omdat het PTR niet overeenkomt een faux-pas qua security imho.