Mail altijd in spambox, ondanks perfecte configuratie?

[Luchtbakker]

Hallo allemaal,

Ik zit met een groot raadsel en hoop dat iemand me kan helpen.

Onlangs ben ik overgestapt van CyberPanel naar cPanel, omdat cPanel een stuk stabieler werkt. In CyberPanel werkte e-mail direct "out of the box" zonder problemen; mails kwamen nooit in de spambox terecht bij ontvangers zoals Gmail en Outlook.

Sinds de overstap naar cPanel is dit volledig veranderd. Geen enkele mail van geen enkel domein komt nog buiten de spambox aan.

Wat heb ik al gecontroleerd?

- DNS-instellingen: DKIM, SPF, DMARC en andere relevante DNS-records zijn gecontroleerd en correct ingesteld.

- Mail-tester.com score: Testresultaat: 10/10, dus technisch gezien zou alles in orde moeten zijn.

Link: https://www.mail-tester.com/test-hhmcfgjdd

- MXToolbox Email Health Check: Geen bijzonderheden gevonden

Blacklist-controle: IP-adres is niet geblokkeerd of vermeld op bekende spam blacklists.
Dit is logisch, want onder CyberPanel werkte alles perfect met hetzelfde IP-adres.

- Gmass: Geen bijzonderheden https://www.gmass.co/anal...ess=[e-mail]

Mijn vraag:

Wat zie ik over het hoofd? Waarom werken e-mails onder cPanel anders dan onder CyberPanel, terwijl alle instellingen identiek lijken? Heeft iemand advies of suggesties om dit probleem op te lossen?

Alvast bedankt!

[ThaStealth]

Mogelijk vergeet je IPv6. Als de server waar jouw server mee kletst alleen een v4 adres heeft dan werkt het wel goed aangezien jouw server dan ook zijn v4 adres doorgeeft, maar als de andere server een v6 adres heeft, net zoals jouw server zal hij via v6 gaan kletsen. En dan zit het IPv6 adres niet in je SPF record waarschijnlijk.
Mail-tester heeft geen v6 en dus lijkt alles te werken.

Je kan dit op meerdere manieren oplossen
- IPv6 uitschakelen op je server c.q. forceren dat mails altijd via v4 mailen
- IPv6 adres in je DNS records opnemen

Je kan dit dubbelchecken door de headers van het mailbericht aan de ontvangende kant te bekijken, in de headers is waarschijnlijk wel te vinden waarom een mail een hoge spam score heeft

[Luchtbakker]

@ThaStealth Een goeie dat je het zegt. Ik heb in mijn Reverse DNS een PTR record van zowel een IPv4 als IPv6 adres, alleen gebruik ik de hele IPv6 niet en is dit ook nergens ingesteld. Ik zal eens de PTR record van de IPv6 verwijderen en kijken wat dit doet.

[BHQ]

Als je geen v6 ingesteld hebt maakt het PTR daarop natuurlijk ook niet uit, maar weet je ook zeker dat dit zo is?

Ben je alleen van software veranderd of ook van server waar het op draait?

Mail-tester kan prima 10/10 zijn, dan nog geeft het geen enkele garantie dat je bij M365 niet in de spam beland.

[Luchtbakker]

BHQ schreef op zaterdag 15 maart 2025 @ 14:49:
Als je geen v6 ingesteld hebt maakt het PTR daarop natuurlijk ook niet uit, maar weet je ook zeker dat dit zo is?

Ben je alleen van software veranderd of ook van server waar het op draait?

Mail-tester kan prima 10/10 zijn, dan nog geeft het geen enkele garantie dat je bij M365 niet in de spam beland.

De server en IP zijn gelijk gebleven. Er zijn geen back-ups meegenomen, dus de DNS records die in cyberpanel stonden, staan nu niet in cpanel. Cpanel maakt zijn eigen records aan.

[BHQ]

-edit, maar reactie volgde alsnog-

Blijft de vraag, hoe weet je zo zeker dat de machine geen IPv6 heeft? (Zijn er nog partijen die servers opleveren zonder dat?)

[ Voor 73% gewijzigd door BHQ op 15-03-2025 15:02 ]

[Luchtbakker]

BHQ schreef op zaterdag 15 maart 2025 @ 14:54:
Dus je stelt je PTR's in binnen Cpanel, niet bij de partij waar je de server afneemt?

Nee. De PTR records staan bij de partij waar ik de server afneem. (de hostname)
Cpanel doet natuurlijk de nameservers, dus bij mijn domainholder heb ik diverse records in moeten stellen voor de hostname:



Vervolgens doet cpanel de rest, zoals hier 1 van de domeinen:



Volgens mij gaat dit gewoon goed?

[Luchtbakker]

BHQ schreef op zaterdag 15 maart 2025 @ 14:54:
Blijft de vraag, hoe weet je zo zeker dat de machine geen IPv6 heeft? (Zijn er nog partijen die servers opleveren zonder dat?)

Ik heb de installatie van almalinux uitgevoerd zonder ipv6 te gebruiken. De provider levert de ipv6 gewoon hoor, maar stond niet direct op mijn prio lijstje die te gebruiken.

[Vorkie]

Post eens een header van zo'n email die in de spam beland?

Helpt misschien wel.

[Luchtbakker]

Vorkie schreef op zaterdag 15 maart 2025 @ 15:09:
Post eens een header van zo'n email die in de spam beland?

Helpt misschien wel.

Tuurlijk

Ik weet overigens dat mijn gegevens erin staan, geen probleem.

code:

Delivered-To: [e-mail]
Received: by 2002:a05:7108:c0b:b0:3ef:929c:79b4 with SMTP id pl11csp1266530gdb;
        Mon, 10 Mar 2025 11:23:44 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IGGQBO5shxKFZ37uRnO9QshwsAlp/bCA/SRIv3hHQqZYDy1kAIicOeytYdYjr6Cv7dFeSxB
X-Received: by 2002:a17:907:2d92:b0:abf:6842:d46 with SMTP id a640c23a62f3a-ac252b5a2a5mr1662310466b.32.1741631023890;
        Mon, 10 Mar 2025 11:23:43 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1741631023; cv=none;
        d=google.com; s=arc-20240605;
        b=NCktvUefcUs/PhC+XcHXV+XDEAV75nLGHbqF0d8imkUordxNk/rJbqipKz+8TWxYPk
         BbTyB+hmIZtsmg5paH3vubXysRNMSukKLAHQqNeJfdrC93V32G8+lUDcnN6t/+bV8eoF
         xwjfNn2esoQODAwlTFLr/HnPGQh3wTYtz69OytMV/SUjpRt1uBeHVH/OAFFQ+4XLkcQS
         xWvZk0G1jMZtWALo2fQIvIMceN1CTTJhaYOLfwHT5KlyoQkXvUtnisMzb9Dok6jnJ1uh
         LLIfjqVVP9BpVYNafzRxauAJ8uQMv5q6ov+hyiHQhm6iFV6LK+k+iEX7WdVs2Ir5U9qv
         LwVQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=content-language:thread-index:mime-version:message-id:date:subject
         :to:from;
        bh=+zVBSWUd/an21DtBd0eKJkFIRYOLB0in0Kr10hIDXls=;
        fh=SOhpoXxo5Oip4HLAJ3gKg3BOzWqEDrdXQc/uJkTg/Ao=;
        b=UequfbxgvC2NIjgzvfqVC6XJZdowCbDHARRpNBxK9vRd5QsV2j9IEu0PP35Fdsyhqe
         DQHdimQQ2MN/1MYN0rr1afZsXL7iG1Bg14AjK6HOIty8QjxDAA04Qxk2kpci6jmY0TiJ
         J+zFhJTAzgj51C1pLntm44XtIkLO3YIA93L76q8CdjoeSrMZek2Emi0sZCeRnEzVKRt4
         jrbmMA5hrqPteCZyFfpYkO+S5iCwgwrL4t+/GWQvvj79myzk+mTouc60bPQZzqCt0SZ/
         QsAOkltB9QUN5Wyf4IFfJR9j8oLfWTjSlX05Y7JN8HawK9GeUuWbkPmabLFGpFdaVXrn
         1h9w==;
        dara=google.com
ARC-Authentication-Results: i=1; mx.google.com;
       spf=pass (google.com: domain of [e-mail] designates 194.163.161.200 as permitted sender) smtp.mailfrom=[e-mail];
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yumbite.nl
Return-Path: <[e-mail]>
Received: from panel.myrisdns.eu (panel.myrisdns.eu. [194.163.161.200])
        by mx.google.com with ESMTPS id a640c23a62f3a-ac239844b99si873882266b.430.2025.03.10.11.23.43
        for <[e-mail]>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Mon, 10 Mar 2025 11:23:43 -0700 (PDT)
Received-SPF: pass (google.com: domain of [e-mail] designates 194.163.161.200 as permitted sender) client-ip=194.163.161.200;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of [e-mail] designates 194.163.161.200 as permitted sender) smtp.mailfrom=[e-mail];
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yumbite.nl
Received: from 222-213-212-87.ftth.glasoperator.nl ([87.212.213.222]:65017 helo=JemiLaptop) by panel.myrisdns.eu with esmtpsa
  (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.1) (envelope-from <[e-mail]>) id 1trhmx-0000000065f-17oe for [e-mail]; Mon, 10 Mar 2025 19:23:43 +0100
From: <[e-mail]>
To: <[e-mail]>
Subject: testje
Date: Mon, 10 Mar 2025 19:23:42 +0100
Message-ID: <001c01db91e9$8e068100$aa138300$@yumbite.nl>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01DB91F1.EFCAE900"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AduR6YsR/E1MiLRVTfuY3irrdNnNvA==
Content-Language: nl
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - panel.myrisdns.eu
X-AntiAbuse: Original Domain - gmail.com
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - yumbite.nl
X-Get-Message-Sender-Via: panel.myrisdns.eu: authenticated_id: [e-mail]
X-Authenticated-Sender: panel.myrisdns.eu: [e-mail]
X-Source: 
X-Source-Args: 
X-Source-Dir: 

------=_NextPart_000_001D_01DB91F1.EFCAE900
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 


------=_NextPart_000_001D_01DB91F1.EFCAE900
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
=09{font-family:"Cambria Math";
=09panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
=09{font-family:Calibri;
=09panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
=09{margin:0cm;
=09font-size:11.0pt;
=09font-family:"Calibri",sans-serif;
=09mso-ligatures:standardcontextual;
=09mso-fareast-language:EN-US;}
span.E-mailStijl17
=09{mso-style-type:personal-compose;
=09font-family:"Calibri",sans-serif;
=09color:windowtext;}
.MsoChpDefault
=09{mso-style-type:export-only;
=09font-size:11.0pt;
=09mso-fareast-language:EN-US;}
@page WordSection1
=09{size:612.0pt 792.0pt;
=09margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
=09{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DNL link=3D"#0563C1" v=
link=3D"#954F72" style=3D'word-wrap:break-word'><div class=3DWordSection1><=
p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></body></html>
------=_NextPart_000_001D_01DB91F1.EFCAE900--

[Vorkie]

Wat ik alleen zie is dat je MX A record verwijst naar die yumbite.nl, en de PTR daarvan panel.x.eu is.

Voor zover ik weet zou dit moeten matchen.

[Luchtbakker]

Vorkie schreef op zaterdag 15 maart 2025 @ 15:24:
Wat ik alleen zie is dat je MX A record verwijst naar die yumbite.nl, en de PTR daarvan panel.x.eu is.

Voor zover ik weet zou dit moeten matchen.

Dit was in geval van Cyberpanel niet het geval. Zou ook raar zijn, want dan zou je voor elke website dat je host een aparte server moeten hebben.

panel.myrisdns.eu is de hostname, en namens de hostname worden de mails verstuurd. In dit geval is Yumbite 1 van de domeinen dat op de server actief is.

Volgens spam-tester.com is het ook goed ingesteld



Of ik heb wat gemist natuurlijk

[Vorkie]

Luchtbakker schreef op zaterdag 15 maart 2025 @ 15:29:
[...]


Dit was in geval van Cyberpanel niet het geval. Zou ook raar zijn, want dan zou je voor elke website dat je host een aparte server moeten hebben.

panel.myrisdns.eu is de hostname, en namens de hostname worden de mails verstuurd. In dit geval is Yumbite 1 van de domeinen dat op de server actief is.

Volgens spam-tester.com is het ook goed ingesteld

[Afbeelding]

Of ik heb wat gemist natuurlijk

Spamfilters kijken vaak naar meerdere dingen - ook de mxrecords van het domein, dan komen ze ineens een servernaam tegen die niet overeenkomt met de PTR.

[sdk1985]

Ik zou het eens zonder expliciet proberen, dus die + uit je spf weghalen.

code:

v=spf1 a mx ip4:194.163.161.200 ~all

Dat en panel.myrisdns.eu zelf werkt niet, die wordt geforward naar

quote: https://panel.myrisdns.eu/cgi-sys/defaultwebpage.cgi

SORRY!
If you are the owner of this website, please contact your hosting provider: [e-mail]
It is possible you have reached this page because

Geen garantie dat het gaat helpen maar dat is wat mij opvalt.

Verder is het heel normaal dat je server aangeeft welke hostname hijzelf heeft. Daarom checken ze ook het a-record van die hostname in het mailtester rapport.

[ Voor 13% gewijzigd door sdk1985 op 15-03-2025 15:44 ]

[Jazzy]

sdk1985 schreef op zaterdag 15 maart 2025 @ 15:42:
Ik zou het eens zonder expliciet proberen, dus die + uit je spf weghalen.

code:

v=spf1 a mx ip4:194.163.161.200 ~all

Waarom adviseer je dat? De + is inderdaad optioneel maar je ziet bij Google toch al een pass?

Als je het SPF-record aan wilt passen, dan zou je a en mx kunnen verwijderen en ~ vervangen door een -. Dan ga ik er van uit dat de server op IP-adres 194.163.161.200 de enige server is die toegestaan wordt om mail te verzenden namens dit domein.

De reden om a en mx te verwijderen is dat ze overbodig zijn, de reden om ~ door - te vervangen is dat je de ontvangende server een positieve bevestiging geeft in plaats van een 'waarschijnlijk klopt het wel'.

En als dat het geval is, zet ook gelijk p=reject in je DMARC record. De overweging is hetzelfde als bij SPF, een policy van none zegt totaal niets, een reject vertelt de ontvangende server dat de mail geweigerd moet worden als die niet compliant is.

Edit: Kijk ik er overheen of mis ik een DKIM-signature in die headers?

[ Voor 26% gewijzigd door Jazzy op 15-03-2025 15:55 ]

[Vorkie]

@Jazzy Ik zie inderdaad ook geen DKIM, goed gezien

[sdk1985]

Jazzy schreef op zaterdag 15 maart 2025 @ 15:50:
[...]

Waarom adviseer je dat? De + is inderdaad optioneel maar je ziet bij Google toch al een pass?

Omdat het functioneel hetzelfde zou moeten zijn, het feitelijk niet hetzelfde is en het 5 seconde kost om het te wijzigen en dus uit te sluiten. Dat is een manier van problemen oplossen, uitsluiten.

Overigens als ik een mail naar gmail stuur:

code:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@x.nl header.s=x header.b=pvx8TtHa;
       spf=pass (google.com: domain of [e-mail] designates x as permitted sender) smtp.mailfrom=[e-mail];
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=x.nl

Dus ik zie in de eerdere post ook geen dkim terwijl hij daar wel zou moeten staan.

[ Voor 34% gewijzigd door sdk1985 op 15-03-2025 16:08 ]

[Jazzy]

sdk1985 schreef op zaterdag 15 maart 2025 @ 16:04:
[...]

Omdat het functioneel hetzelfde zou moeten zijn, het feitelijk niet hetzelfde is en het 5 seconde kost om het te wijzigen en dus uit te sluiten. Dat is een manier van problemen oplossen, uitsluiten.

Gewoon dingen proberen zonder dat je begrijp wat het zou moeten oplossen is een slechte manier van problemen oplossen. Stel dat het ineens even werkt, komt het dan door iets wat eigenlijk niet stuk was of is er een andere factor die ook een rol speelt? Beter zoom je in net zo ver tot je de oorzaak hebt, maak dan een oplossing waarbij je begrijpt hoe die de root cause verhelpt en valideer die.

[Luchtbakker]

Jazzy schreef op zaterdag 15 maart 2025 @ 15:50:
[...]

Waarom adviseer je dat? De + is inderdaad optioneel maar je ziet bij Google toch al een pass?

Als je het SPF-record aan wilt passen, dan zou je a en mx kunnen verwijderen en ~ vervangen door een -. Dan ga ik er van uit dat de server op IP-adres 194.163.161.200 de enige server is die toegestaan wordt om mail te verzenden namens dit domein.

De reden om a en mx te verwijderen is dat ze overbodig zijn, de reden om ~ door - te vervangen is dat je de ontvangende server een positieve bevestiging geeft in plaats van een 'waarschijnlijk klopt het wel'.

En als dat het geval is, zet ook gelijk p=reject in je DMARC record. De overweging is hetzelfde als bij SPF, een policy van none zegt totaal niets, een reject vertelt de ontvangende server dat de mail geweigerd moet worden als die niet compliant is.

Edit: Kijk ik er overheen of mis ik een DKIM-signature in die headers?

Ik heb de dmarc al aangepast, maar dat maakte geen verschil.
@Vorkie

code:

v=DMARC1; p=reject; rua=mailto:[e-mail]; ruf=mailto:[e-mail]; fo=1;

Nu heb ik SPF hiernaar aangepast op jullie advies:

code:

v=spf1 +a +ip4:194.163.161.200 -all

[sdk1985]

Jazzy schreef op zaterdag 15 maart 2025 @ 16:09:
[...]
Gewoon dingen proberen zonder dat je begrijp wat het zou moeten oplossen is een slechte manier van problemen oplossen. Stel dat het ineens even werkt, komt het dan door iets wat eigenlijk niet stuk was of is er een andere factor die ook een rol speelt? Beter zoom je in net zo ver tot je de oorzaak hebt, maak dan een oplossing waarbij je begrijpt hoe die de root cause verhelpt en valideer die.

Volgens mij gaat dit heel erg offtopic, maar dat is toch volstrekte onzin? We weten exact welk probleem hier moet worden opgelost. Dat is namelijk in de topicstart gespecificeerd en samen te vatten als dat bij gmail de mail niet als spam moet binnen komen. Wat er niet duidelijk is, is de oorzaak. Vervolgens is een strategie van uitsluiten van zaken waarvan je niet verwacht dat daar de oorzaak is in mijn ervaring een hele efficiënte. Als er iets is dat ik je kan garanderen in IT is dat het een kwestie van tijd is tot iets niet werkt zoals het zou moeten werken. Stel dat er vannacht een update in de heuristieken van Google is geslopen waarbij hun script niet goed omgaat met +. Juist aan die ene knop draaien gaat je in staat stellen het gebied steeds kleiner te maken waarin de oorzaak ligt. Dan kan je daarna gericht gaan werken aan het hoe/wat/waarom/wie/wanneer.

Verder had je ondertussen toch al het probleem gevonden? Ik snap niet zo goed wat je wilt bereiken met je vragen en reactie op de antwoorden. Het helpt de ts in ieder geval niet.

[ Voor 4% gewijzigd door sdk1985 op 15-03-2025 16:22 ]

[Jazzy]

sdk1985 schreef op zaterdag 15 maart 2025 @ 16:19:
Verder had je ondertussen toch al het probleem gevonden? Ik snap niet zo goed wat je wilt bereiken met je vragen en reactie op de antwoorden. Het helpt de ts in ieder geval niet.

Ik heb in Jazzy in "Mail altijd in spambox, ondanks perfecte..." uitgelegd wat er verandert moet worden EN waarom dat een verschil maakt.

Prima dat we het niet eens zijn, maar ik geloof gewoon sterk in de juiste manier van troubleshooten en gewoon iets proberen is doorgaans niet de beste optie. Verder zijn we er beiden om de TS te helpen, dus maak je niet al te druk over een paar kritische vragen.

[Jazzy]

Luchtbakker schreef op zaterdag 15 maart 2025 @ 16:13:
[...]


Ik heb de dmarc al aangepast, maar dat maakte geen verschil.
@Vorkie

code:

v=DMARC1; p=reject; rua=mailto:[e-mail]; ruf=mailto:[e-mail]; fo=1;

Nu heb ik SPF hiernaar aangepast op jullie advies:

code:

v=spf1 +a +ip4:194.163.161.200 -all

Die SPF zou eigenlijk v=spf1 ip4:194.163.161.200 -all moeten zijn. De + kan weg omdat die optioneel is en voor verwarring kan zorgen, de a kan weg omdat je al een expliciet IP-adres hebt opgegeven. Probleem nog niet opgelost, maar je configuratie is in ieder geval een stukje perfecter dan die al was.

Dank voor je testmailtje. Bij Microsoft krijg je een Spam Confidence Level (SCL) van 5, bij de meeste mensen zal dat inderdaad resulteren in een mailtje in de Junkmail folder. Zie verder geen enkel issue:

code:

X-MS-Exchange-Organization-SCL: 5
X-Forefront-Antispam-Report:
CIP:194.163.161.200;CTRY:DE;LANG:nl;SCL:5;SRV:;IPV:NLI;SFV:SPM;H:panel.myrisdns.eu;PTR:panel.myrisdns.eu;CAT:SPM;SFS:(13230040)(8096899003);DIR:INB;
X-Microsoft-Antispam: BCL:0;ARA:13230040|8096899003;
X-Microsoft-Antispam-Mailbox-Delivery:
ucf:0;jmr:0;auth:0;dest:J;OFR:SpamFilterAuthJ;ENG:(910005)(944506478)(944626604)(4710137)(4715020)(920097)(930097)(3100021)(140003)(1310096);RF:JunkEmail;

Je ziet dat je een aantal spam-rules triggert maar Microsoft vertelt er uiteraard niet bij waarom.

Enige wat ik me kan bedenken is dat je IP-adres op dit moment geen reputatie heeft. Je zou eens kunnen kijken of je hem ergens kunt submitten om die wel te krijgen, in plaats van te wachten tot je die opbouwt omdat dat met een laag volume een eeuwigheid kan duren.

[Luchtbakker]

Jazzy schreef op zaterdag 15 maart 2025 @ 16:35:
[...]
Die SPF zou eigenlijk v=spf1 ip4:194.163.161.200 -all moeten zijn. De + kan weg omdat die optioneel is en voor verwarring kan zorgen, de a kan weg omdat je al een expliciet IP-adres hebt opgegeven. Probleem nog niet opgelost, maar je configuratie is in ieder geval een stukje perfecter dan die al was.

Ik heb het aangepast , maar zie zo nog even geen verschil.

[sdk1985]

Luchtbakker schreef op zaterdag 15 maart 2025 @ 16:42:
[...]


Ik heb het aangepast , maar zie zo nog even geen verschil.

Volgens mij is de vraag die je nu moet proberen te beantwoorden;

waarom zitten er in de Authentication-Results geen dkim vermelding. Want die kreeg ik wel in het mailtje dat ik zojuist naar een gmail adres stuurde.

Ik kreeg namelijk dit:

code:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@x.nl header.s=x header.b=pvx8TtHa;
       spf=pass (google.com: domain of [e-mail] designates x as permitted sender) smtp.mailfrom=[e-mail];
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=x.nl

Daarna een heel stuk over DKIM, bij jouw voorbeeld ontbreekt dat volledig. Opvallend genoeg stond bij mail-tester wel dat je DKIM werkt.

[ Voor 30% gewijzigd door sdk1985 op 15-03-2025 16:46 ]

[Luchtbakker]

@sdk1985 ik durf niet te zeggen. De records staan wel ingesteld, en volgens mail-tester worden ze ook meegeleverd en zijn ze geldig.

[Jazzy]

Luchtbakker schreef op zaterdag 15 maart 2025 @ 17:11:
@sdk1985 ik durf niet te zeggen. De records staan wel ingesteld, en volgens mail-tester worden ze ook meegeleverd en zijn ze geldig.

Zag ze bij Microsoft trouwens ook gewoon terugkomen in de headers, met een goed resultaat. Wel bijzonder inderdaad dat ze bij jouw test ontbreken en @sdk1985 ze wel ziet.

Maar het lijkt er dus niet op dat DKIM, SPF od DMARC direct een oorzaak is. En met het aanscherpen van SPF en DMARC heb je ook alles wel zo'n beetje kunnen doen wat door de spamfilters nog als extra gewicht kan tellen.

Blijft voor mij het gebrek aan reputatie van je IP-adres over als enige optie. Tenzij iemand anders nog een ander idee heeft.

[Luchtbakker]

Jazzy schreef op zaterdag 15 maart 2025 @ 17:27:
[...]


Blijft voor mij het gebrek aan reputatie van je IP-adres over als enige optie. Tenzij iemand anders nog een ander idee heeft.

Het gekke is dat tot 2 weken geleden (tijdens Cyberpanel) de e-mails wel gewoon keurig doorkwamen. Ik zou dan zeggen dat het geen reputatie aan het IP adres is, al is dat ook het enige wat ik mij nog zo kan bedenken.

[sdk1985]

Luchtbakker schreef op zaterdag 15 maart 2025 @ 17:11:
@sdk1985 ik durf niet te zeggen. De records staan wel ingesteld, en volgens mail-tester worden ze ook meegeleverd en zijn ze geldig.

Op basis van wat ik nu heb gelezen verwacht ik dat er 2 oorzaken zijn

1) voor gmail heb je echt die dkim nodig
2) voor alles van microsoft heb je een bepaald volume nodig, dat volume zul je nu vermoedelijk niet halen. Tevens hoeven bij laag volume slechts een paar mensen iets te junken en je hebt weer een issue.

Puntje 1 zou ik even bij cpanel neerleggen en vragen of die kunnen verklaren waarom je naar gmail geen dkim meestuurt. Ik kwam bijvoorbeeld dit tegen: https://support.cpanel.ne...s-third-party-DNS-servers

Puntje 2 kun je weinig aan doen behalve via een mail relay gaan verzenden.SDNS rapporteert pas vanaf 100 berichten per dag: https://sendersupport.olc...utlook.com/snds/data.aspx. Ik denk dat je dat niet haalt? Microsoft is uberhaupt problematisch omdat die veel lastiger zijn dan gmail. Die gebruiken heuristieken die soms letterlijk nergens op slaan. Je kunt zelfs geblackholed worden tot het punt dat je niet eens bounces terug krijgt.

[ Voor 14% gewijzigd door sdk1985 op 15-03-2025 17:38 ]

[Luchtbakker]

sdk1985 schreef op zaterdag 15 maart 2025 @ 17:37:
[...]


Puntje 1 zou ik even bij cpanel neerleggen en vragen of die kunnen verklaren waarom je naar gmail geen dkim meestuurt. Ik kwam bijvoorbeeld dit tegen: https://support.cpanel.ne...s-third-party-DNS-servers

Dit artikel gaat over DKIM als je een externe DNS server gebruikt. In dit geval gebruik ik gewoon de powerdns service dat cpanel zelf installeert.

[Luchtbakker]

Ik heb zojuist een 2e installatie gehad op een nieuwe server, met 2 nieuwe domeinen ter test, en daar heb ik exact de zelfde problemen. Het lijkt dus iets binnen cpanel te zijn.

[jurroen]

Probeer het eens zonder die originele received-from. Dat kan problemen geven.

[Luchtbakker]

jurroen schreef op zaterdag 15 maart 2025 @ 23:40:
Probeer het eens zonder die originele received-from. Dat kan problemen geven.

Ik zie zo even geen mogelijkheid deze te verwijderen. Het enige wat ik vandaag weer zie in een nieuwe mail is dat alles passed is.

code:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@byaesnas.com header.s=default header.b=Qs3BynIG;
       spf=pass (google.com: domain of [e-mail] designates 194.163.161.200 as permitted sender) smtp.mailfrom=[e-mail];
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=byaesnas.com
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=byaesnas.com; s=default; h=Content-Transfer-Encoding:Content-Type: Message-ID:Subject:To:From:Date:MIME-Version:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=P6moefL1ldEQtG2TCfgBY4Z1N3s7/D0uf9SA7eu2bVo=; b=Qs3BynIGmI8wTQAXF+zJcM34Gh lBLmI07T6+kqWSEVnbiNggyhARWWrBJbSiw9tx1j4X1i8crerVyDpyzJlyeF55R//fLTo7Qh19vj/ mOIaLlDkbq5jfa064nJ4izxUDcm78kQybYIhxYlb8ueRqMhi5MdJedRn+xtOzjN9VmfVaLQq2YO4J JCVlYBE4FF9nO86YQY3p54/rNnS2gz3vylP9joad441Ap9PdS/xqFCZAtCwnuKIRP8qAeYSlxRn0d oEr3Ihk+QPH4rtHDqDmwVf2SeKAUBMwj6vxte86V/wXnOj4O4wQbyoeGmn2JvMXXRDJZBHfPtNumc APAOdJFg==;

[jurroen]

Luchtbakker schreef op zondag 16 maart 2025 @ 12:20:
[...]


Ik zie zo even geen mogelijkheid deze te verwijderen. Het enige wat ik vandaag weer zie in een nieuwe mail is dat alles passed is.

Kijk, dat is al vooruitgang!

Voor de deliverability hoef je de originele IPs er niet meer uit te halen. Maar het is wel aan te raden voor de privacy van je klanten (ik ga er voor het gemak vanuit dat je die hebt, omdat cPanel best wel overkill, complex en prijzig is voor single users).

Vroeger was het geloof ik een vinkje ergens in WHM (vermoedelijk in het Exim stuk) maar lijkt erop dat je het nu zelf in Exim moet gooien: https://support.cpanel.ne...hide-local-ip-during-smtp

Kan het helaas niet voor je testen omdat ik al jaren geen cPanel of Exim meer gebruik.

Oh en last but not least, als je de gebruikers van je server kent en vertrouwt kun je ook de username wel uit de headers halen.

[ Voor 6% gewijzigd door jurroen op 16-03-2025 15:15 ]