Mail server werkt niet
Ik ben bezig om een mailserver op te zetten op mijn VPS, maar dit wil niet helemaal lukken. Voorheen kon ik e-mails sturen naar mijn Outlook mailadres (kwamen wel in de map "Ongewenst"), maar tegenwoordig komen deze e-mails niet meer aan. Ik heb verder geprobeerd maar de e-mails komen wel aan op mijn quicknet.nl en een Microsoft Exchange account wat ik heb, van werk.
Ik heb al een en het ander uitgezocht met DNS-records en Reverse DNS. Maar ik kom er echt niet uit.
DNS records:
Reverse DNS (deze wordt geaccepteerd op mxtoolbox.com):
Postfix configuratie:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
# See /usr/share/postfix/main.cf.dist for a commented, more complete version
# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h
readme_directory = no
# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = www.domein.nl
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = $myhostname, domein.nl, localhost, localhost.localdomain, localhost
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all
# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h
readme_directory = no
# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = www.domein.nl
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = $myhostname, domein.nl, localhost, localhost.localdomain, localhost
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all
Resultaat van mxtoolbox.com:
Ik hoor graag van jullie!
Gewijzigd op 11/04/2017 20:04:24 door Marthijn Buijs
Dat Microsoft ze weigert, is een ander punt.
Dat zul je met nader moeten uitzoeken.
- vinden ze je server niet lief
- vinden ze dat je spf zegt dat de mail niet van die server hoort te komen
- bevat je mail op andere manieren inhoud die op spam lijken.
- klopt het ontvangende mail adres?
Gewijzigd op 11/04/2017 18:05:40 door Ben van Velzen
Ik heb besloten om het versturen van e-mail te proberen met behulp van een externe SMTP-dienst. Het goede nieuws is dat het versturen naar Gmail.com-adressen prima gaat. Het slechte nieuws is dat het versturen naar Outlook.com-adressen er nog toe leidt dat de e-mails bij de map "Ongewenst" komen.
De externe SMTP-dienst is Mailjet, hiervoor moest ik nog een SPF en DKIM configuratie in mijn DNS wijzigen. De wijzingen werden als correct gezien volgens Mailjet.
Maar zoals ik al zei, bij Outlook.com-adressen komen de e-mails in de map "Ongewenst". Iemand een idee hoe dit op te lossen?
Gewijzigd op 17/04/2017 15:37:05 door Ben van Velzen
Heb zojuist een e-mail gestuurd naar [email protected] via de web interface van Outlook maar ik ontvang geen e-mail terug dat de e-mail niet afgeleverd is.
Gewijzigd op 17/04/2017 15:37:37 door Marthijn Buijs
Want met een tool die ik heb geïnstalleerd op mijn laptop kan ik e-mails versturen met mijn eigen SMTP en de Connection Log kan ik inzien. E-mails kwamen verder niet in ongewenst.
Hierna probeerde ik het via PHPMailer, en raad eens, het komt niet in de map "Ongewenst".
Zou het ermee te maken kunnen hebben dat ik mijn MX-record verwijderd heb en dit nog moest worden uitgevoerd door de DNS?
Mailjet gaf de SPF waarde aan die ik moest instellen, dit heb ik gedaan en werd als correct gezien door Mailjet, heb het hierna niet aangepast.
Ik heb enkel 2 A-records (1 wildcard) en 2 TXT-records (SPF en DKIM). Geen MX-record.
SPF waarde:
Code (php)
1
v=spf1 include:spf.mailjet.com mx a ip4:84.22.96.218 ~all
84.22.96.218 is het IP-adres van mijn server.
als phpMailer wel gewoon goed aankomt, heeft het te maken met de headers van de mail zoals je die voorheen verstuurde.
phpMailer zorgt dat dat allemaal op de juiste manier staat :)
Verdiep je even in DomainKeys zoals Ben aangaf, dit scheelt een hele hoop.
Microsoft is inderdaad niet heel hebberig op inkomende mail van 'nieuwe' servers wellicht heb je een ip of de domeinnaam van de server zelf dat al eens een slechte reputatie heeft opgelopen in het verleden. Dit heeft tijd nodig (heel veel tijd) om te herstellen.
Ik ben zelf ooit eens een pagina van outlook.com tegengekomen waar je een mail ergens heen moet sturen en krijg je resultaten te zien.
Vanaf daar kon ik niet veel mee verder aangezien ik geen eigenaar was van '[email protected]'
Overigens in een van je screenshots staat dat de domeinnaam zelf (zonder www niet bestaat)
Dit soort problemen kunnen aan veel dingen liggen, lengte en inhoud van bericht, historische gegevens, dns, spf record, domainkey enz enz
Heel veel succes! als je de pagina van outlook nog eens tegenkom, post m hier ff ;-] ik geloof iets van webmasters outlook.com of iets dergelijks
Nu bleek dat wanneer ik een e-mail verstuurde met als e-mailadres "[email protected]" deze in de "Ongewenst" map belandde. Maar wanneer ik het e-mailadres veranderde in bijvoorbeeld "[email protected]" (zonder streepje), kwam deze wel fatsoenlijk binnen.
Gewijzigd op 19/04/2017 16:16:44 door Lord Gaga