SPF record

[Ova]

Ik heb al langer terug een SPF record ingesteld in onze DNS, werkte goed,maar iets gaat toch wat scheef.
Naast het mailen vanuit onze mailbox sturen wij ook mail vanuit Exact.

include:_spf.exactonline.nl staat in onze SPF record, maar nu komen e-mailtjes bij 1 iemand niet aan. Nu ben ik er achter gekomen dat Exact ook weer verstuurd vanuit flowmailer.nl, dit zie ik ook terug in de foutmelding van de e-mail welke terug komt.

Nu heb ik ook include:spf.flowmailer in de record gezet, gaat nog niet helemaal goed, maar dat moet ik nog uitzoeken, wellicht is de spf.flowmailer.nl niet goed.

Maar ik twijfel of dat mijn gehele record wel goed is, het volgende heb ik nu;
(om te testen heb ik softfail gebruikt)

NAME: @
TYPE: TXT
VALUE: "v=spf1 a:zimbra.onsdomein.nl include:_spf.exactonline.nl include:spf.flowmailer.net ~all"

Waar ik aan twijfelt is dat ik begint met een a:zimbra.onsdomein.nl
Wij draaien wel met onze eigen mailserver (Zimbra), maar de DNS loopt via onze provider.
Persoonlijk denk ik dat het include:zimbra.onsdomein.nl moet zijn en achter de a moet denk ik staan a:onsdomein.nl

Maar na een tijdje zoeken met Google kom ik dingen tegen als "v=spf1 a mx jouwbedrijf.nl", dit lees ik ook op de site van flowmailer.com/artikel/het-spf-record

Zou het raadzamer zijn om het als volgt door te voeren?
NAME: @
TYPE: TXT
VALUE: "v=spf1 a mx onsdomein.nl include:zimbra.onsdomein.nl include:_spf.exactonline.nl include:spf.flowmailer.net ~all"

Of ga ik hiermee de fout in?

[g0tanks]

Ova schreef op maandag 2 maart 2020 @ 12:29:
Nu heb ik ook include:spf.flowmailer in de record gezet, gaat nog niet helemaal goed, maar dat moet ik nog uitzoeken, wellicht is de spf.flowmailer.nl niet goed.

Een snelle Google search vertelt mij dat het spf.flowmailer.net is: https://flowmailer.com/artikel/het-spf-record

Maar ik zie op het moment van schrijven dat je dat al wel hebt meegenomen in de voorbeeld records.

[ Voor 12% gewijzigd door g0tanks op 02-03-2020 12:34 ]

[TECHcrime]

In _spf.exactonline.nl staat het volgende:
_spf.exactonline.nl. 299 IN TXT "v=spf1 include:spf.flowmailer.net -all"

De flowmailer.net wordt dus al geinclude.

Kan je zien vanaf welk IP-adres de mail komt die niet goed aankomt? In de mailflower.net staat het volgende:
ip4:185.136.64.128/27 (185.136.64.129 - 185.136.64.158)
ip4:185.136.65.128/27 (185.136.65.129 - 185.136.65.158)

Als het dus van bovenstaande IP's afkomt, dan is het al geinclude in je SPF.

De volgorde in je SPF record maakt verder niets uit.

Je value zou dan worden:
v=spf1 a mx include:zimbra.onsdomein.nl include:_spf.exactonline.nl ~all

a: include alle A records in de DNS van de huidige domeinnaam
mx: include alle MX records in de DNS van de huidige domeinnaam
include:zimbra.onsdomein.nl: Include deze externe SPF record
include:_spf.exactonline.nl: Include deze externe SPF record


Daarnaast.. Komt e-mail van onsdomein.nl niet goed aan bij een externe ontvanger, of komt de mail van een externe verzender niet goed aan bij onsdomein.nl?

[ Voor 38% gewijzigd door TECHcrime op 02-03-2020 12:47 ]

[Rensjuh]

Ova schreef op maandag 2 maart 2020 @ 12:29:

Zou het raadzamer zijn om het als volgt door te voeren?
NAME: @
TYPE: TXT
VALUE: "v=spf1 a mx onsdomein.nl include:zimbra.onsdomein.nl include:_spf.exactonline.nl include:spf.flowmailer.net ~all"

Of ga ik hiermee de fout in?

Sowieso moet je dan voor je domein wel a: zetten, dus:
"v=spf1 a mx a:onsdomein.nl include:zimbra.onsdomein.nl include:_spf.exactonline.nl include:spf.flowmailer.net ~all"

Maar aangezien je al "a" in je SPF hebt staan hoef je je eigen domein niet nogmaals aan te geven.

Ook include je het SPF record van een subdomein.
Tenzij dit subdomein geen eigen SPF record heeft is dit niet nodig en dus dubbel.

In principe zou dus het volgende voldoende moeten zijn:
v=spf1 a mx include:_spf.exactonline.nl include:spf.flowmailer.net ~all

Er vanuit gaande dat je MX records naar de zimbra server verwijzen.

Kan het probleem niet ook bij die ene persoon zitten?
Krijgt die een foutmelding in een logging te zien waar vermeld word dat de SPF niet zou kloppen bijv?

[ Voor 26% gewijzigd door Rensjuh op 02-03-2020 12:48 ]

[Jester-NL]

Met @Rensjuh.
Overigens zou ik voor het doorsturen dat Exact doet niet mijn SPF-record aanpassen. Tenzij Exact je verzoekt om die flowmailer.net op te nemen, maar anders mag je gevoegelijk aannemen dat Exact ervoor zorgt dat deze in hun SPF-record is opgenomen.
Het kan dus gewoon met

code:

v=spf1 a mx include:_spf.exactonline.nl ~all

[Rensjuh]

Jester-NL schreef op maandag 2 maart 2020 @ 13:02:
Met @Rensjuh.
Overigens zou ik voor het doorsturen dat Exact doet niet mijn SPF-record aanpassen. Tenzij Exact je verzoekt om die flowmailer.net op te nemen, maar anders mag je gevoegelijk aannemen dat Exact ervoor zorgt dat deze in hun SPF-record is opgenomen.
Het kan dus gewoon met

code:

v=spf1 a mx include:_spf.exactonline.nl ~all

https://mxtoolbox.com/Sup...actonline.nl&run=toolpage

Ah, niet gezien, maar die flowmailer is van/voor Exact.
Staat al in het SPF van _spf.exactonline.nl dus includen is sowieso niet nodig omdat Exact dat inderdaad verzorgt.

[3raser]

Rensjuh schreef op maandag 2 maart 2020 @ 13:05:
[...]


https://mxtoolbox.com/Sup...actonline.nl&run=toolpage

Ah, niet gezien, maar die flowmailer is van/voor Exact.
Staat al in het SPF van _spf.exactonline.nl dus includen is sowieso niet nodig omdat Exact dat inderdaad verzorgt.

Flowmailer (nogmaals) includen is zelfs af te raden aangezien een SPF record een maximum aantal lookups heeft. Als je dus teveel a: en include: in je SPF hebt staan kan het zijn dat je SPF record alsnog niet werkt.

Het SPF record van @Jester-NL lijkt mij de beste optie. Als jullie eigen mailserver een ander IP adres heeft dan wat "a" en "mx" op onsdomein.nl retourneren dan zul je daar nog een extra a:zimbra.onsdomein.nl toe moeten voegen. Om recursive lookups te ontwijken zou je daar ook nog het IP adres van de server kunnen kunnen plaatsen met ip4:88.88.88.88 syntax. Dit verslechterd helaas wel de leesbaarheid van je SPF record.

[Ova]

Oke, het is heel heel stuk helderder geworden, iedereen erg bedankt voor de input.

Ik was ergens de draad kwijt geraakt dat de a verwijst naar de a record, op een gegeven moment zit je zo te denken dat je het overzicht verliest

De 3 mx records verwijzen naar de mailserver van de provider, ik moet onze Zimbra in de SPF record zetten.

"v=spf1 a a:zimbra.onsdomein.nl include:_spf.exactonline.nl ~all"
Met deze record ga ik even testen.

@TECHcrime Onze mail komt niet aan op hun domein, maar hun e-mail komt bij ons tussen de spam.
Dus dan heb ik het gevoel dat er aan hun kant iets fout gaat. Maar de e-mail welke wij versturen vanuit onze Zimbra komen wel aan, alleen de e-mails vanuit Exact weer niet.

Net schoot me in me gedachten dat hun ook 2 andere domeinen hebben, als ik daar heen verstuurd vanuit Exact, dan komt het wel aan. Nu ben ik meer geneigd te denken dat het aan hun kant fout gaat. De SPF records zijn alle hetzelfde van hun, wellicht gaat het scheef in de DMARC/DKIM. In hun SPF staat er iets van Outlook en een IP4 range van de hele webserver van hun provider

Maar goed, onze klant is er van overtuigd dat bij hun alles goed is, de mail komen allemaal bij hun aan.... Tsja, wat kan je daar opzeggen

[Qwerty-273]

Aangezien je contact hebt met de andere kant, wat is de "melding" die zij zien?

Elk fatsoenlijk product zal een logging bij houden met de gemaakte keuzes door de mail gateway. Dus ook waarom iets niet aankomt, als dat puur op je spf zou zitten, dan kan je dat matchen met het IP address wat de ontvangende kant als verzender ziet.

[Rensjuh]

Ova schreef op maandag 2 maart 2020 @ 14:04:
De 3 mx records verwijzen naar de mailserver van de provider, ik moet onze Zimbra in de SPF record zetten.

Dan zou het hiervoor al voldoende moeten zijn om "mx" in je SPF te zetten.
Hiermee worden de MX records van je domein meegenomen, ongeacht of deze naar je eigen domein of een externe server verwijzen.

Je kunt ook de ontvangende partij even in de (Exchange) logs laten kijken?
Mogelijk dat je daar wel iets gevonden krijgt over het hoe/wat/waarom de mails op 2/3 domeinen wel aankomen maar op de 3e niet.
Ongetwijfeld dat er op dat 3e domein iets (lekker vaag, ik weet het) niet goed staat.
Maar daar kun jij niks aan doen als je daar het beheer niet over hebt.

[Ova]

De e-mail komt daar niet aan, dus de klant kan niets zien. De klant weet hoe hij een e-mail kan versturen en daar heb je het mee gehad.

Nu heb ik iemand gesproken die binnenkort langs komt om te kijken met telnet, ik ken dat wel, maar ben er niet thuis in. Volgens hem kunnen we dan een e-mail versturen en kijken waar het mis gaat. Ik ben benieuwd.

De MX ga ik er in ieder geval er bij zetten.

[TECHcrime]

Stuur eens een mailtje naar https://www.mail-tester.com/. Deze geeft je gelijk een mooi overzicht waarom iets niet zou aankomen bij de ontvanger. Probeer dit vanaf al je mail platformen.

[Rensjuh]

Ova schreef op maandag 2 maart 2020 @ 14:18:
De e-mail komt daar niet aan, dus de klant kan niets zien. De klant weet hoe hij een e-mail kan versturen en daar heb je het mee gehad.

Mogelijk word hij al afgevangen voordat hij in de mailbox komt.
Als de Exchange server of mail gateway die er voor zit hem blokkeert moet ie in een log verschijnen.
Een email verdwijnt niet zomaar in het niets... ;-)

[Amendeon]

Ova schreef op maandag 2 maart 2020 @ 14:04:
Oke, het is heel heel stuk helderder geworden, iedereen erg bedankt voor de input.

Ik was ergens de draad kwijt geraakt dat de a verwijst naar de a record, op een gegeven moment zit je zo te denken dat je het overzicht verliest

De 3 mx records verwijzen naar de mailserver van de provider, ik moet onze Zimbra in de SPF record zetten.

"v=spf1 a a:zimbra.onsdomein.nl include:_spf.exactonline.nl ~all"
Met deze record ga ik even testen.

@TECHcrime Onze mail komt niet aan op hun domein, maar hun e-mail komt bij ons tussen de spam.
Dus dan heb ik het gevoel dat er aan hun kant iets fout gaat. Maar de e-mail welke wij versturen vanuit onze Zimbra komen wel aan, alleen de e-mails vanuit Exact weer niet.

Net schoot me in me gedachten dat hun ook 2 andere domeinen hebben, als ik daar heen verstuurd vanuit Exact, dan komt het wel aan. Nu ben ik meer geneigd te denken dat het aan hun kant fout gaat. De SPF records zijn alle hetzelfde van hun, wellicht gaat het scheef in de DMARC/DKIM. In hun SPF staat er iets van Outlook en een IP4 range van de hele webserver van hun provider

Maar goed, onze klant is er van overtuigd dat bij hun alles goed is, de mail komen allemaal bij hun aan.... Tsja, wat kan je daar opzeggen

Je maakt op dit moment ook gebruik van de SPF SoftFail en niet de HardFail (~all ipv -all). Bij de meeste mailservers zal je mail dan alsnog worden afgeleverd (soms in de spam). Ik betwijfel dus of het probleem echt in het SPF record zit. Weet daarbij niet of er gebruik wordt gemaakt van DMARC, wat weer van invloed kan zijn op wat er gebeurd met de mail aan de ontvangende kant.

Het klinkt alsof de ontvangende partij de mail er simpelweg uitfiltert. Kan dan in de quarantaine van bijv. een O365 belanden of de spamfilter die de boel tegenhoud. Als het echt alléén deze klant is, en Exact mailtjes wel naar andere klanten / mailaccounts werkt, kan je al met redelijke zekerheid zeggen dat het probleem aan hun kant ligt.

Hun SPF / DKIM / DMARC record is irrelevant voor mail die jij richting die partij verstuurd. SPF / DKIM / DMARC is alleen voor uitgaande e-mail.

[kodak]

@Amendeon heeft een zeer goede opmerkingen.
SPF/ DKIM / DMARC zijn ontworpen om aanwijzingen te geven. Je kan een ontvanger er niets mee verplichten. Als alle records volgens de standaard zijn, dan nog is het aan de ontvanger (ontvangende mailserver) om zelf te bepalen waarom die je mail wel of niet wenst te accepteren en je daar al dan niet over te berichten.

Je geeft helaas erg weinig informatie, dan gaat het ook voor Tweakers niet makkelijk worden je echt inhoudelijk te helpen. Dat je je bedrijfsnaam/domein niet wil prijsgeven kan ik begrijpen. Maar het zou al helpen als je uit kan leggen wat je gedaan hebt om te testen of je records correct zijn. Dat je uitleg geeft welke foutmelding je terug krijgt. Wat nog beter is is als je kan uitleggen wat de bedoeling met je records is, wat je in die foutmeldingen leest en waarom die naar jou mening goed zou zijn. (Je hebt neem ik aan vooraf uitbedacht wat met je configuratie de bedoeling is en getest voordat je in de praktijk facturen ging verzenden)

Hoe dan ook, een snelle manier is om contact met de mailservice van je klant op te nemen die de facturen/bedrijfsmail niet wenst te accepteren en daar te vragen waarom zij menen dat het niet acceptabel is. Zeker als je het probleem alleen bij hun hebt en niet bij al je andere klanten.

En waarom denk je op basis van hun mail komt bij ons in de spam het aan hun zou liggen? Want hun filter regels hebben te maken met wat ze van jullie willen ontvangen, niet waarom er bij jullie mail van hun spam labels krijgt.

edit:
als jullie domein niet onsdomein.nl is, misschien is het dan handig om geen domeinen van anderen in je voorbeelden te gebruiken en daarvoor de tlds te gebruiken die daarvoor bedoelt zijn zoals .test of .invalid of .example of de speciaal gereserveerde domeinen als example.org example.net of example.com te gebruiken

[ Voor 9% gewijzigd door kodak op 02-03-2020 18:03 . Reden: aanvulling ]

[Saven]

Misschien bluft de klant wel omdat 'ie je facturen niet op tijd wil betalen Daar wel eens aan gedacht?

[kodak]

Saven schreef op maandag 2 maart 2020 @ 18:02:
Misschien bluft de klant wel omdat 'ie je facturen niet op tijd wil betalen Daar wel eens aan gedacht?

Dat is een mogelijkheid, alleen sturen ze volgens de OP wel foutmeldingen terug als de mail niet afgeleverd kan worden. En als de OP dat schrijft zou ik er eerst maar even zeker van zijn dat het echt niet aan de verzender ligt. Helaas geeft de OP niet aan wat er in die meldingen staat?

[Nakebod]

Controleer ook via bijv https://app.dmarcanalyzer.com/dns/spf of je totaal aantal DNS lookups niet meer dan 10 is. (https://sendgrid.com/docs...settings/spf-limitations/)
Zo had ik een domein met 2 includes, die ieder zelf ook weer 3 DNS lookups deden. Daarmee kwam ik al op 8 DNS lookups. En toen moest er een 3e partij bij, en zou ik op 12 uitkomen. En dat geeft problemen.

Helaas heb je zelf weinig controle over het aantal DNS lookups wat externe partijen doen.
Dus daar weer een SPF Flattening service voor genomen die alle lookups omzet naar IP adressen/ranges.

[Ova]

Rensjuh schreef op maandag 2 maart 2020 @ 14:46:
Mogelijk word hij al afgevangen voordat hij in de mailbox komt.
Als de Exchange server of mail gateway die er voor zit hem blokkeert moet ie in een log verschijnen.
Een email verdwijnt niet zomaar in het niets... ;-)

Mogelijk zal hij wel ergens worden geleverd, maar de klant heeft daar niet zoveel verstand van en hij is van mening dat alles aankomt, dus niet zijn pakkie-an.
De e-mail komt in ieder geval terug van "[e-mail]", en dat is waar Exact weer gebruik van maakt.

In een bijgevoegde tekst document staat het volgende:

Reporting-MTA: dns; return.exactonline.nl
Original-Envelope-Id: 9da5b76499664d41b6f432ab119332cf

Final-Recipient: rfc822; administratie@**naam_van_de_klant**.nl
Action: failed
Status: 5.7.1 (Delivery not authorized, filter id 7851501)

@Amendeon schreef op maandag 2 maart 2020 @ 15:35:
Op dit moment heb ik bewust tijdelijk een softfail ingesteld, het is de bedoeling dat dit weer een hardfail wordt.
Dit probleem komt alleen voort bij deze klant en alleen bij 1 domein, de 2 andere geven geen problemen.
Ook als ik vanuit Exact stuurt met een andere domein, dan wordt ook deze niet afgeleverd op die enne domein van de klant, bij de 2 ander weer wel. Mijn gevoel zegt ook dat het ligt aan hun zijde.

@kodak schreef op maandag 2 maart 2020 @ 17:57:
Ik heb niks te verbergen betreft onze domeinnaam, ik dacht dat dit niet echt de bedoeling was. Het domein waar het over gaat is color-graphics.nl en de mailserver zimbra.color-graphics.nl
Ik wil wel meer info geven, dat is niet het probleem, maar toen ik deze post begon dacht ik meer dat het scheef ging in onze SPF, maar gaan der weg blijkt dat het niet zo is. Opzicht is de SPF niet zo moeilijk, de verwijzing naar ons domein was er niet, de "a" is nu toegevoegd. Het is de bedoeling dat Exact uit onze naam kan mailen, dat werkt nu ook goed. Net als ik al schreef, dit probleem komt alleen voort bij 1 klant. Greenhost is volgens mij de provider, ik kan vragen of dat onze klant er geen probleem mee heeft als ik even naar Greenhost gaat bellen.

@Saven schreef op maandag 2 maart 2020 @ 18:02:
Zou een mooie zijn
Nee, ze zijn al best lang klant, betaling is niet altijd geheel op tijd, maar meestal gaat dat gelukkig goed. Wij sturen ook de facturen naar hun via de gewone e-mail vanwege dit probleem.

@kodak schreef op maandag 2 maart 2020 @ 18:06:
OP, is dat wat ik hierboven in de quote hebt gezet?

@Nakebod schreef op maandag 2 maart 2020 @ 18:54:
Oke, dat is niet zo mooi, ik zit op 12. Hier had ik geen weet van. Ik kan een include er uitgooien die er zo al 5 in beslag neemt. Deze is niet echt direct nodig.

[Amendeon]

Ova schreef op maandag 2 maart 2020 @ 23:25:
[...]


Mogelijk zal hij wel ergens worden geleverd, maar de klant heeft daar niet zoveel verstand van en hij is van mening dat alles aankomt, dus niet zijn pakkie-an.
De e-mail komt in ieder geval terug van "[e-mail]", en dat is waar Exact weer gebruik van maakt.

In een bijgevoegde tekst document staat het volgende:

[...]


@Amendeon schreef op maandag 2 maart 2020 @ 15:35:
Op dit moment heb ik bewust tijdelijk een softfail ingesteld, het is de bedoeling dat dit weer een hardfail wordt.
Dit probleem komt alleen voort bij deze klant en alleen bij 1 domein, de 2 andere geven geen problemen.
Ook als ik vanuit Exact stuurt met een andere domein, dan wordt ook deze niet afgeleverd op die enne domein van de klant, bij de 2 ander weer wel. Mijn gevoel zegt ook dat het ligt aan hun zijde.

@kodak schreef op maandag 2 maart 2020 @ 17:57:
Ik heb niks te verbergen betreft onze domeinnaam, ik dacht dat dit niet echt de bedoeling was. Het domein waar het over gaat is color-graphics.nl en de mailserver zimbra.color-graphics.nl
Ik wil wel meer info geven, dat is niet het probleem, maar toen ik deze post begon dacht ik meer dat het scheef ging in onze SPF, maar gaan der weg blijkt dat het niet zo is. Opzicht is de SPF niet zo moeilijk, de verwijzing naar ons domein was er niet, de "a" is nu toegevoegd. Het is de bedoeling dat Exact uit onze naam kan mailen, dat werkt nu ook goed. Net als ik al schreef, dit probleem komt alleen voort bij 1 klant. Greenhost is volgens mij de provider, ik kan vragen of dat onze klant er geen probleem mee heeft als ik even naar Greenhost gaat bellen.

@Saven schreef op maandag 2 maart 2020 @ 18:02:
Zou een mooie zijn
Nee, ze zijn al best lang klant, betaling is niet altijd geheel op tijd, maar meestal gaat dat gelukkig goed. Wij sturen ook de facturen naar hun via de gewone e-mail vanwege dit probleem.

@kodak schreef op maandag 2 maart 2020 @ 18:06:
OP, is dat wat ik hierboven in de quote hebt gezet?

@Nakebod schreef op maandag 2 maart 2020 @ 18:54:
Oke, dat is niet zo mooi, ik zit op 12. Hier had ik geen weet van. Ik kan een include er uitgooien die er zo al 5 in beslag neemt. Deze is niet echt direct nodig.

In dat geval kan er in combinatie met de foutmelding worden gezegd dat de ontvangende partij haar mailserver jouw mail niet accepteert. Jij hebt hier verder ook geen invloed op (zolang je SPF / DKIM e.d. gewoon goed staat).

Het inkorten van je SPF record zou nog kunnen zodat de ontvangende mailserver alle lookups doet. Het kan inderdaad zijn dat na 10 records enkele mailservers dit niet aankunnen.

Ik heb voor de rest niet echt een indicatie wat voor mailomgeving ze hebben, dus dat maakt het wat lastig inschatten wat de vervolgstappen zijn.

De quick 'n dirty oplossing is het mailadres wat vanuit jullie Afas mailt whitelisten op de te ontvangen mailserver. Security wijs is dit echt een afrader echter, want dit betekent dat ongeacht wat er in die mails zit, de filters het zullen negeren.

De andere oplossing vergt een stuk meer werk en is troubleshooten en de filter logs onderzoeken. Als ik het zo hoor is de klant daar niet echt thuis in, dus is dit ook niet echt een praktische oplossing.

Is het een optie voor die partij om in ieder geval voor nu naar een ander domein van de klant te mailen? Dan kunnen jullie in ieder geval al wat

[kodak]

Begin met het beperken van de dns lookups. Dat het enige is wat tests melden wat zeker fout/ongewenst is bij de beperkingen van spf.

[Ova]

Even de schaaf over de DNS lookups gehaald. Ik heb de include van de provider weggehaald (spf.velzart.nl)
Deze was eigenlijk niet echt nodig. Eerder had ik dit vanmorgen al bij een ander domein van ons gedaan (sign-express.nl) Dit gaf een positief resultaat met de test via https://app.dmarcanalyzer.com/dns/spf
Nu heb ik het zojuist ook doorgevoerd bij color-graphics.nl, het resultaat is daar nu ook positief.

[Backspin]

Even een reactie op dit wat oudere topic, omdat ik tegen hetzelfde probleem aanliep:

- Mail sturen vanuit Exact Online
- Werkt naar alle klanten, behalve 1
- Bij mailen naar die klant komt een foutmelding retour: Status: 5.7.1 (Delivery not authorized, filter id [XXXXXX])

Ik heb het probleem voorgelegd aan de support-afdeling van Exact. Wat bleek: het e-mailadres van de klant stond in de systemen van Exact geblokkeerd, waardoor er geen mail naar toe gestuurd kan worden. Ze konden daar geen precieze reden voor geven (een vaag verhaal over hoe hun AI-systeem soms ten onrechte adressen blokkeerde). Na deblokkering werkte het weer.

Die combinatie ("Delivery not authorized, filter id") levert op Google maar 1 hit op, en dat is deze thread. Dus vandaar dat ik de oplossing hier post, mochten in de toekomst mensen op dezelfde query zoeken.

[ Voor 3% gewijzigd door Backspin op 07-09-2020 14:54 ]

[Ova]

@Backspin schreef op maandag 7 september 2020 @ 14:30

Ik had je laatste bericht niet gezien tot nu omdat ik wederom een andere klant hebt met een soortgelijke probleem. "Status: 5.7.1 (Delivery not authorized, filter id [XXXXXX])"
Ik ga nu het probleem voor leggen bij Exact om te kijken of dit kan worden opgelost.

Bedankt voor je reactie

[Toevoeging-1 11:45]
Zojuist gesproken met iemand van Exact, ik had het geluk dat ik iemand sprak die precies wist waar ik het over had
Ze gaan een onderzoek starten en als het goed is hoor ik daar vandaag iets over.
[/Toevoeging-1]


[Toevoeging-2 12:02]
Snelle oplossing. Probleem is opgelost, 2 e-mail adressen waren inderdaad geblokkeerd.
Blokkade is er nu vanaf gehaald.

Bedankt voor de duw in de juiste richting.
[/Toevoeging-2]

[ Voor 39% gewijzigd door Ova op 23-10-2020 12:02 ]

[Ruimzicht]

Hier een zelfde ervaring. SPF, DKIM dmarc geoptimaliseerd maar nog steeds problemen bij één klant(adres). Bleek dus door Exact Online geblokkeerd te worden. Best een vreemd verhaal eigenlijk...

[Oid]

Gebruiken jullie DMARC icm exactonline?
Sinds dat ik dmarc op reject heb ingesteld komen de mails vanuit [e-mail] ipv de eigen ingestelde mail-adres; volgens de support ligt het aan SPF maar dit is al jaren hetzelfde ingesteld en heeft nooit een probleem gegeven.
Enige wat ik dus kan herleiden is DMARC (draaide het al een paar maanden met none en geen probleem ervaren eigenlijk) nu weer teruggezet naar none eens kijken wat het verschil is.

verschil in mijn headers:
voor de wijziging:

code:

Authentication-Results: spf=pass (sender IP is 185.136.64.132)
smtp.mailfrom=flowmailer.exact.com; domein.nl; dkim=pass (signature was
verified) header.d=flowmailer.net;domein.nl; dmarc=fail action=none
header.from=domein.nl;compauth=pass reason=702
Received-SPF: Pass (protection.outlook.com: domain of flowmailer.exact.com

From: "Bedrijfsnaam." <[e-mail]>

na de wijziging:

code:

Authentication-Results: spf=pass (sender IP is 185.136.65.132)
smtp.mailfrom=flowmailer.exact.com; domein.nl; dkim=pass (signature was
verified) header.d=flowmailer.net;domein.nl; dmarc=pass action=none
header.from=exact.com;compauth=pass reason=100
Received-SPF: Pass (protection.outlook.com: domain of flowmailer.exact.com

From: "Bedrijfsnaam." <[e-mail]>

Heeft iemand dit ook ervaren / gebruikt iemand DMARC icm exactonline?

Update 01/12:
Na de DMARC weer op NONE te hebben gezet komen de mails van exactonline weer via de eigen ingestelde mail adres binnen. Eens uitvogelen hoe DMARC goed kunnen neerzetten icm exactonline.

[ Voor 6% gewijzigd door Oid op 01-12-2020 16:33 ]

[SmokingCrop]

Oid schreef op maandag 30 november 2020 @ 21:58:
Gebruiken jullie DMARC icm exactonline?
Sinds dat ik dmarc op reject heb ingesteld komen de mails vanuit [e-mail] ipv de eigen ingestelde mail-adres; volgens de support ligt het aan SPF maar dit is al jaren hetzelfde ingesteld en heeft nooit een probleem gegeven.
Enige wat ik dus kan herleiden is DMARC (draaide het al een paar maanden met none en geen probleem ervaren eigenlijk) nu weer teruggezet naar none eens kijken wat het verschil is.

verschil in mijn headers:
voor de wijziging:

code:

Authentication-Results: spf=pass (sender IP is 185.136.64.132)
smtp.mailfrom=flowmailer.exact.com; domein.nl; dkim=pass (signature was
verified) header.d=flowmailer.net;domein.nl; dmarc=fail action=none
header.from=domein.nl;compauth=pass reason=702
Received-SPF: Pass (protection.outlook.com: domain of flowmailer.exact.com

From: "Bedrijfsnaam." <[e-mail]>

na de wijziging:

code:

Authentication-Results: spf=pass (sender IP is 185.136.65.132)
smtp.mailfrom=flowmailer.exact.com; domein.nl; dkim=pass (signature was
verified) header.d=flowmailer.net;domein.nl; dmarc=pass action=none
header.from=exact.com;compauth=pass reason=100
Received-SPF: Pass (protection.outlook.com: domain of flowmailer.exact.com

From: "Bedrijfsnaam." <[e-mail]>

Heeft iemand dit ook ervaren / gebruikt iemand DMARC icm exactonline?

Update 01/12:
Na de DMARC weer op NONE te hebben gezet komen de mails van exactonline weer via de eigen ingestelde mail adres binnen. Eens uitvogelen hoe DMARC goed kunnen neerzetten icm exactonline.

Er zijn eigenlijk nog twee zaken (minstens 1) die nodig zijn om niet gespoofed te worden na SPF:
1| Een DKIM TXT record om toe te voegen
-> dit zou direct voor DMARC 'alignment' zorgen, aangezien die dan via DKIM zijn validatie kan doen

2| Een aangepaste Return-Path waarbij je dan een CNAME record kan aanmaken die dan terug verwijst naar de locatie waar het al de hele tijd naartoe verwijst bij Exact.

Bijvoorbeeld: Als de return-path bij hen nu ingesteld als [e-mail], dan wordt die return-path dan bv. aangepast naar [e-mail] waarbij exact.domein.be een CNAME is naar flowmailer.exact.com.

Zo ontvangen zij (of flowmailer) nog steeds de "bounces" als een mail niet afgeleverd kan worden, maar kan DMARC wel het correcte domein.be in het Return-Path gebruiken om te verifiëren via SPF.

Zo kan DMARC via SPF dus ook zijn 'alignment' voltooien.


Dit alles hebben we even nagevraagd via de support van Exact en daar kregen we simpelweg het volgende terug: (antwoord van 19/01/2021)
"Ik kan u hierop momenteel geen antwoord voorzien. Het enige wat me moemnteel ondersteuenen zijn SPF records. De informatie hieromtrent kunt u vinden via ons support portaal en dan te zoeken op SPF.
Er wordt wel aangewerkt om DMARC Records in Exact Online zelf op te zetten. De functionaliteit is momenteel in testfase. Ik heb nog geen zicht op wanneer deze beschikbaar is voor al onze klanten."

Wij gaan dus wellicht tot dit opgelost is, exact met een subdomein laten uitsturen die wat minder veilig opgesteld is, maar dan is de rest van het domein waarmee gestuurd wordt toch al veilig..

Vroeger hadden ze dit blijkbaar wel overigens..
Via de Google Cache:
https://webcache.googleus...cd=20&hl=nl&ct=clnk&gl=be

[ Voor 6% gewijzigd door SmokingCrop op 20-01-2021 22:16 ]

[Bonobobob]

Ik zie deze thread nu pas.
Bij ons was er een alignment probleem. Support van Exact kreeg het niet opgelost. Ik heb dan zelf contact opgenomen met Flowmailer. Die hebben het dan voor ons opgelost (november 2020).
We moesten volgende records instellen:
e.our-company.com CNAME web.flowmailer.net.
fm1._domainkey.our-company.com CNAME fm1-410-our-company-com.fmdkim.net.
fm2._domainkey.our-company.com CNAME fm2-410-our-company-com.fmdkim.net.

Bij Flowmailer zelf moesten ze dat dan ook nog goed zetten.

Daarna geen SPF, DKIM of DMARC errors meer in de headers als er mails vanuit Exact Online vertrekken met onze domeinnaam als afzender!

[TomBlijleven]

Modbreak:

Helpen mag, spammen niet.

[ Voor 89% gewijzigd door Equator op 21-02-2021 20:04 ]

[BHQ]

Ova schreef op maandag 2 maart 2020 @ 12:29:
Waar ik aan twijfelt is dat ik begint met een a:zimbra.onsdomein.nl
Wij draaien wel met onze eigen mailserver (Zimbra), maar de DNS loopt via onze provider.
Persoonlijk denk ik dat het include:zimbra.onsdomein.nl moet zijn en achter de a moet denk ik staan a:onsdomein.nl

Een 'include:' wordt alleen gebruikt om te refereren aan een ander SPF-record wat meegenomen moet worden. Dus als er op 'zimbra.onsdomein.nl' geen txt record met daarin een SPF aanwezig is gaat dat niet werken.

Een 'a:' wijst naar een A-record (en daarmee dus het IP-adres achter dat A record). Dus als je 'a:zimbra.onsdomein.nl' toevoegt neem je die host op in het SPF-record. Met 'a:onsdomein.nl' voeg je het A-record van het kale domein/de apex toe (dus als de host waarop de website draait zelf ook mailt, kan dat nuttig zijn).

Als het MX record van 'onsdomein.nl' al naar 'zimbra.onsdomein.nl' wijst kan je in dit geval ook 'mx' gebruiken om die host op te nemen in het SPF-record.

Een SPF-record mag een maximaal aantal DNS-lookups veroorzaken. Alleen 'ip4:' en 'ip6:' dragen hier niet aan bij. Als je een 'include:' gebruikt tellen de lookups daarin (a, mx, andere includes..) ook mee.

Daarnaast, een ~all is in principe open voor interpretatie voor de ontvangende host, een -all is een hardfail (mail van een andere host dan in het SPF-record zou dan in principe niet afgeleverd moeten worden).

[ Voor 11% gewijzigd door BHQ op 17-02-2021 20:16 ]

[gastenboek]

Oud topic I know, maar aangezien ik er zelf via Google op kwam en hier het meeste info vond, toch even een aanvulling opdat anderen er ook van kunnen profiteren:

Zoals anderen liep ik er, na goed zetten van het SPF record (obv instructies van Exact zelf, die prima via Google te vinden zijn), nog tegenaan dat met DMARC niet op p=none, de afzender ineens [e-mail] wordt.

Ik kreeg van de helpdesk van Flowmailer een link doorgestuurd naar een tool om voor Exact Online klanten ook nog een drietal CNAME records te bepalen: https://flowmailer.com/h/exact-cname-generator

[g0tanks]

Dank voor je bijdrage. Ik denk dat er inmiddels genoeg oplossingen zijn aangedragen en het topic rijp is voor een slotje.