We run reputations on all of the valid DKIM signatures on the message, but there may be benefits to having one that matches the header from the ESP perspective... or maybe not.
It ties the reputation of the message more to the client, which may be good or bad depending on the client. If it's only the ESP, then it ties the reputation more to the ESP, which may be good or bad depending on the ESP. Of course, having an ESP one (even as additional to the client one) allows you to get postmaster stats for the ESP iirc, or use our feedback loop... but having it ties your overall ESP reputation to all of your messages. Having both, the one closest matching to the from header domain will be treated as primary, which may help prefer the client reputation over the ESP reputation in some cases, or in cases where you're trying to separate streams (ie, different products under the same domain, or different ESPs or transactional vs marketing). They're all signals in the ML soup, of course, and so the weighting between primary and other changes with the model. I'm not sure you can really game things one way or the other, so signing with both would be my default suggestion... though the ESPs often have more information on how these things work from their perspective with their own testing. For hosting providers, much of the above still applies, though it still depends on how good your abuse handling is. I think you have more chances of abuse being say hijacked accounts or such, so you might want to keep the clients separated. If I was a client, I'd want my own domain to match the header from domain so I could use my reputation on multiple senders or move providers and keep it. Also, of course DKIM signing by ESP or hosting provider ties your reputation together, but so does your IP, network and ASN, so there's already collective reputation going on... so doing so by DKIM just makes it clearer and maybe that much closer to the anti-spam world not relying on IPs so much. If you're a first party (ie, serving just yourself (or just your company)), I'd sign with yourself and match. It's not strictly necessary, ie if you have multiple domains for your company and only want to manage one key, that's probably fine up until you consider DMARC. Brandon On Thu, Nov 14, 2019 at 9:21 AM Paul Smith via mailop <mailop@mailop.org> wrote: > > On 14/11/2019 16:38, Stefan Bauer via mailop wrote: > > Is it bad - in terms of reputation - when domain in dkim-header (d=...) > differs from senders address? > > signing is done correctly and pub-key is present at domain of corse - > specified with d=... > > > like d=mydomain.com > > Sender is Stefan <m...@corp.org> > > I could not find anything in the RFC. > > There's a reason for that. > > DKIM itself has nothing to do with reputation. It's simply a way of proving > that the message was 'authorised' by someone. > > People who use it for reputation could potentially do all sorts of different > things - from just assigning a 'trustworthiness' rating to a signing domain, > or a combination of signing domain & sender or whatever. So, you will > probably get as many answers as people who choose to answer. > > If you use DMARC, then the signing domain is ignored for DMARC's purposes if > it's not associated with the 'From' header address domain. > > Here we do something very simple, and decide to trust signing domains if they > don't send spam, and aren't ISPs, ESPs, or hosting companies (eg a generic > AmazonSES signature), but other people probably do different things. > > That doesn't mean we distrust DKIM signatures from ISPs, ESPs or hosting > companies, just that we ignore them if the signature verifies, because that > tells us nothing useful. > > > > -- > > Paul Smith Computer Services > Tel: 01484 855800 > Vat No: GB 685 6987 53 > > Sign up for news & updates > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
