Scannen via SMTP2Go naar e-mail werkt niet meer Office365

[Gb1974]

Wie heeft er op het moment ook veel problemen met scannen van MFP printers naar e-mail via de dienst SMTP2Go met Office 365 (Exchange Online)?

Het heeft vanaf begin dit jaar goed gewerkt en nu ineens niet meer.
Alle berichten blijven op Processed staan en er staat "smtp;451 delivery delayed".

Meer mensen die dit probleem hebben?
SMTP2Go geeft aan dat het iets is bij Microsoft en dat men met Microsoft aan een oplossing wil werken.

Of zijn er op dit moment betere manieren om zonder kosten of zonder al te veel kosten te scannen via MFP's naar e-mail?

[F_J_K]

Gokje: de authenticatie-methode werkt niet meer want verouderd.

Alternatieve methode is scan2mail via ouder smtp server (icm spf etc).

[Gb1974]

Volgens mij heeft dat niet wat met authenticatie te maken.
SMTP2Go verzend direct (vanuit de printer) via internet en wordt dan weer net als een e-mail van iemand van buiten bij de gebruiker weer binnen gehaald.
De juiste instellingen staan ook in de DNS van SMTP2Go (Cname records).

Het enige wat ik me voor kan stellen dat de mail niet binnen gehaald kan worden aangezien deze de zelfde domeinnaam heeft als Office 365. Ik weet niet of je SMTP2Go ook toe kunt voegen aan de SFP regel en of dat kan helpen.

[mrmrmr]

@Gb1974 Ik weet niet wat SMTP2Go is, maar je kunt niet zomaar emails laten versturen door een derde partij zonder dat toe te staan in DNS settings. Met name SPF moet worden ingesteld op je domein zodat de servers van deze derde partij wordt toegestaan mail te versturen met jouw domein in het afzenderadres.

Als de derde partij een eigen domein gebruikt zijn DNS mail settings voor hen.

[F_J_K]

Je gebruikt dus de smtp-server van SMTP2Go en ook afzender mailadres SMTP2Go? Als jouw afzender-adres zijn jouw spf-records nodig

[Gb1974]

F_J_K schreef op donderdag 28 augustus 2025 @ 23:26:
Je gebruikt dus de smtp-server van SMTP2Go en ook afzender mailadres SMTP2Go? Als jouw afzender-adres zijn jouw spf-records nodig

Ik gebruik niet een smtp2go afzender adres maar met eigen domein. Het heeft vanaf ongeveer begin maartgoed gewerkt tot nu.

Er zijn in de dns instellingen 3 cname records van smtp2go opgenomen. Dat is I.p.v. toevoegen aan de sfp regel.

[ Voor 13% gewijzigd door Gb1974 op 28-08-2025 23:39 ]

[mrmrmr]

Gb1974 schreef op donderdag 28 augustus 2025 @ 23:33:
Ik gebruik niet een smtp2go afzender adres maar met eigen domein. Het heeft vanaf ongeveer begin maartgoed gewerkt tot nu.

Dat is je probleem. Je moet de uitgaande mail servers van SMTP2Go toevoegen aan SPF van je eigen domein.

[Gb1974]

Is allemaal ingesteld en correct volgens de handleiding van smtp2go.
Sfp cname, dkim en nog 1.
https://dmarcdkim.com/set...n-step-by-step-guide-2024

[Qwerty-273]

Het ontwerp van SMTP2Go zorgt er voor dat je juist niet aan je SPF record van je eigen (mail) domein hoeft aan te passen. Ze gebruiken VERP (zie links hieronder). Office 365 / Exchange Online ondersteunt geen VERP (als zendende partij) en het zou heel goed kunnen dat er iets is veranderd in de anti-spam filtering waardoor ook ontvangen niet meer lekker werkt (doordat VERP niet juist wordt begrepen).

https://support.smtp2go.c...F-DKIM-and-DMARC-Overview
https://support.smtp2go.c...able-Envelope-Return-Path
https://www.smtp2go.com/blog/sender-domain-update/

Aangezien je wel de smtp hosts van SMTP2Go gebruikt in deze opstelling, kan het ook heel goed zijn dat deze op een of andere manier zijn geblacklist of gegreylist aan de kant van Microsoft. Bijvoorbeeld doordat voldoende ontvangers spam melden, of vanwege een grote storm van mails (een aantal MFP's die maar blijven sturen), het volume mails plots erg gestegen is van de verzendende smtp host, etc.

[ Voor 23% gewijzigd door Qwerty-273 op 29-08-2025 00:20 ]

[mrmrmr]

Stuur eens een testbericht via deze dienst naar een verificatie site. Dan zie je wat er fout gaat.

De SPF record opvragen.

Mail versturen en laten testen.

[i-chat]

voor mij klinkt het alsof je dit ook lokaal op zou kunnen lossen.

deze printers ondersteunen allemaal smtp over port 25, enige dat je dus wilt is een smtp-reley server lokaal met verouderde authenticatie protocols aan de lanzeide (zodat de printers het snappen) en een instelling dat je alleen vanaf het lokale netwerk (of subnet) kunt versturen. de relay instellingen zijn dan weer zo dat het MS365 als smarthost kan gebruiken configuratie is wat lastiger omdat MS alleen cert-based authenticatie accepteert voor smarthosts zonder fixed IP.
als alternatief kun je natuurlijk ook een hosted smarthost setup kiezen maar dan zou ik wel gaan voor eentje die spf en dmarc ondersteunt. zodat je een volwaardige authorisatie kunt toepassen.

[Question Mark]

Gb1974 schreef op donderdag 28 augustus 2025 @ 21:17:
Wie heeft er op het moment ook veel problemen met scannen van MFP printers naar e-mail via de dienst SMTP2Go met Office 365 (Exchange Online)?

Wat is de reden dat je deze dienst uberhaubt inzet? Waarom gebruik je niet de relay-functie van M365?

How to set up a multifunction device or application to send email using Microsoft 365 or Office 365

[JRBonenberg]

Hmmm, toevallig dat ik dit topic zie. Kreeg gister een melding van een klant met een webshop waarbij voor het versturen van mail vanaf de webshop ook gebruik gemaakt wordt van SMTP2GO.

Zelfde soort klachten als jij ervaart: mail komt in spam terecht, of twee dagen later aan.
Heb er nog niet verder naar kunnen kijken, maar dat zij niet de enige zijn doet mij vermoeden dat er bij Microsoft 365 wat aanpassingen zijn waardoor SMTP2GO hinder ondervind.

[mrmrmr]

Als mail van een printer wordt onderschept op basis van format, dan is het versturen via het eigen domein gevaarlijk. Vooral bij versturen naar veel externe ontvangers is er een risico dat het als spam wordt gezien (terecht of onterecht).

Ter bescherming van het eigen domein is het daarom het overwegen waard een apart domein of dienst te gebruiken voor mailings.

Microsoft blokkeert mail servers waar weinig verkeer vandaan komt. Ook al heb je alles correct en veilig geconfigureerd (PTR, SPF, DMARC, DKIM, etc). Het risico van hosten bij een hoster die "vieze" klanten heeft vergroot dat.

Ook goed om je te realiseren: aangezien Microsoft monopolist is, heeft het veel macht over welke mail wel of niet wordt bezorgd. Doordat mail aan de deur wordt geweigerd hebben veel ondernemingen niet eens door dat ze mail niet ontvangen. Ze lopen wellicht klanten mis.

smtp;451 delivery delayed wijst overigens op greylisting op de mailserver van de ontvanger. Dat betekent dat een mail niet direct wordt bezorgd, maar dat een nieuwe poging na zoveel tijd (soms 15 minuten, soms langer) nodig is. Een mail server doet dat, maar een spammer doet dat vaak niet, daardoor werkt deze methode als een grove spamfilter.

[Gb1974]

Het werkt in mijn geval weer.
Ik had gisteravond alle ip adressen van smtp2go op de whitelist van Office 365 gezet. Vandaag zijn alle mails alsnog binnen gekomen.
Of dat het geweest is of dat smtp2go wat veranderd is blijft gissen.

https://support.smtp2go.c...resses-With-Microsoft-365

[ Voor 18% gewijzigd door Gb1974 op 29-08-2025 19:12 ]

[nelizmastr]

i-chat schreef op vrijdag 29 augustus 2025 @ 09:46:
voor mij klinkt het alsof je dit ook lokaal op zou kunnen lossen.

deze printers ondersteunen allemaal smtp over port 25, enige dat je dus wilt is een smtp-reley server lokaal met verouderde authenticatie protocols aan de lanzeide (zodat de printers het snappen) en een instelling dat je alleen vanaf het lokale netwerk (of subnet) kunt versturen. de relay instellingen zijn dan weer zo dat het MS365 als smarthost kan gebruiken configuratie is wat lastiger omdat MS alleen cert-based authenticatie accepteert voor smarthosts zonder fixed IP.
als alternatief kun je natuurlijk ook een hosted smarthost setup kiezen maar dan zou ik wel gaan voor eentje die spf en dmarc ondersteunt. zodat je een volwaardige authorisatie kunt toepassen.

Als je mails van de MFP’s alleen voor ontvangers binnen je eigen domein(en) van je MS365 tenant bestemd zijn kun je ook de native functionaliteit van Exchange gebruiken, de ingebouwde SMTP relay via een connector. Je moet dan scopen op vertrouwde IP-adressen, die opnemen in SPF en dan je MFP’s zonder authenticatie over poort 25 naar je MS365 MX record laten wijzen. Kost verder geen lokale inrichting van een server.

[i-chat]

nelizmastr schreef op vrijdag 29 augustus 2025 @ 21:53:
[...]


Als je mails van de MFP’s alleen voor ontvangers binnen je eigen domein(en) van je MS365 tenant bestemd zijn kun je ook de native functionaliteit van Exchange gebruiken,

Zo niet dan doe je mijns inziens iets niet goed, want scans die bedoeld zijn voor buiten je organisatie kun je ook gewoon vanuit je mailbox forwarden of de betreffende mail als bijlage toevoegen aan je corespondentie

Workstations buiten je lokale netwerk die scans moeten ontvangen zouden sws via een vpn verbonden zijn dus dat hele smpt2go lijkt overbodig

de ingebouwde SMTP relay via een connector. Je moet dan scopen op vertrouwde IP-adressen, die opnemen in SPF en dan je MFP’s zonder authenticatie over poort 25 naar je MS365 MX record laten wijzen. Kost verder geen lokale inrichting van een server.

[nelizmastr]

i-chat schreef op zaterdag 30 augustus 2025 @ 11:55:
[...]

Zo niet dan doe je mijns inziens iets niet goed, want scans die bedoeld zijn voor buiten je organisatie kun je ook gewoon vanuit je mailbox forwarden of de betreffende mail als bijlage toevoegen aan je corespondentie

[...]

Ik zie idd ook geen andere use case, maar ik heb mensen dingen zien bedenken.....

[Question Mark]

Gb1974 schreef op vrijdag 29 augustus 2025 @ 19:11:
Het werkt in mijn geval weer.
Ik had gisteravond alle ip adressen van smtp2go op de whitelist van Office 365 gezet. Vandaag zijn alle mails alsnog binnen gekomen.
Of dat het geweest is of dat smtp2go wat veranderd is blijft gissen.

https://support.smtp2go.c...resses-With-Microsoft-365

Fijn om te horen. Maar... wat is nu reden dat je deze extra dienst gebruikt? Je MFP's kun je ook "gewoon" rechtstreeks via M365 laten communiceren zónder deze dienst. Wat is je usecase voor deze dienst nu.

Maak je het nu niet nodeloos complex en kostbaarder?

[Qwerty-273]

nelizmastr schreef op vrijdag 29 augustus 2025 @ 21:53:
Als je mails van de MFP’s alleen voor ontvangers binnen je eigen domein(en) van je MS365 tenant bestemd zijn kun je ook de native functionaliteit van Exchange gebruiken, de ingebouwde SMTP relay via een connector. Je moet dan scopen op vertrouwde IP-adressen, die opnemen in SPF en dan je MFP’s zonder authenticatie over poort 25 naar je MS365 MX record laten wijzen. Kost verder geen lokale inrichting van een server.

Als mail beheerder heb ik toch nog altijd de voorkeur om hiervoor een subdomain te gebruiken. Juist om te voorkomen dat er mogelijk iets naar extern wordt gestuurd onder het eigen bedrijfsdomein en daarmee je hardbevochten reputatie naar de malle miezen helpt.

Zelfde straatje als een marketingmailer die je als dienst afneemt. Dan hoef je namelijk ook niet je bedrijfs spf aan te vullen met ips waar je minder controle op het mailverkeer hebt.

Dus ...@mfp.[bedrijf.tld] ipv ...@[bedrijf.tld] en met restricties in de mfp oplossing dat je alleen naar @[bedrijf.tld] mag mailen (of eigenlijk bij voorkeur alleen naar de ingelogde gebruiker - maar dan zit je al met een deftiger oplossing op je mfp's).

[nelizmastr]

Qwerty-273 schreef op maandag 1 september 2025 @ 17:00:
[...]
Dus ...@mfp.[bedrijf.tld] ipv ...@[bedrijf.tld] en met restricties in de mfp oplossing dat je alleen naar @[bedrijf.tld] mag mailen (of eigenlijk bij voorkeur alleen naar de ingelogde gebruiker - maar dan zit je al met een deftiger oplossing op je mfp's).

Dat is inderdaad een prima oplossing. Die ga ik onthouden