My understanding is that DKIM Oversigning is about signing a blank header, not having 2 headers present. 2 Content-Type headers is not allowed per the spec.
laura > On 4 Mar 2026, at 11:49, Bram via mailop <[email protected]> wrote: > > Adding a data point that might help some of you chasing Microsoft DKIM > failures. > > We recently tracked down an intermittent DKIM fail (550 5.7.515, Spf=Pass, > Dkim=Fail, DMARC=Pass) that affected roughly 50% of a sender's traffic to > Microsoft properties. Gmail had zero issues with the same messages, same key, > same selector. Everything validated fine externally. > > Root cause: a duplicate Content-Transfer-Encoding header in the signed > message. > The sending platform was inserting Content-Transfer-Encoding twice, and the > DKIM h= tag included it twice as well. Per RFC this is technically valid for > oversigning, but Microsoft's DKIM validator chokes on it. Gmail handles it > without complaint. > > But there was a tricky part ... the duplicate header wasn't visible in most > header viewers. You had to look at the raw h= tag in the DKIM signature to > spot that Content-Transfer-Encoding appeared twice. Once we removed the > duplicate, Microsoft passed DKIM immediately. > > This was specific to a sending platform bug (not the MTA itself), but given > how many platforms chain together components that each touch headers, I > suspect this pattern might be hiding in more setups than people realize. > Worth checking if you're seeing inconsistent DKIM failures at Microsoft that > validate fine everywhere else. > > Bram Van Daele Teneo / Engagor.ai > > From: mailop <[email protected] <mailto:[email protected]>> > On Behalf Of Jethro Binks via mailop > Sent: Wednesday, 4 March 2026 10:22 > To: [email protected] <mailto:[email protected]> > Subject: [SPAM DETECTED MAIL] Re: [mailop] Outlook rate limiting, just us? > > Thanks Ken (and Laura), > > So I'm guessing the only thing that has changed is that the requirement > announced last year has finally been implemented for us (or, perhaps as John > suggests, either the 5000 threshold has been changed, or the period over > which it applies). > > Anyway, I configured a minimal DKIM and it has certainly helped with > delivery, so it has got me over that hurdle. > > And while the reporting form may not have helped me, in its current broken > state it won't be any use to me if there is something I actually do have to > report in the future. Is there a reporting form for reporting form problems? > 🙂 > > Jethro. > . . . . . . . . . . . . . . . . . . . . . . . . . > > Jethro R Binks, Network Manager, > > Information Services Directorate, University Of Strathclyde, Glasgow, UK > > > > The University of Strathclyde is a charitable body, registered in Scotland, > number SC015263. > > From: mailop <[email protected] <mailto:[email protected]>> > on behalf of Ken O'Driscoll via mailop <[email protected] > <mailto:[email protected]>> > Sent: 03 March 2026 5:08 PM > To: [email protected] <mailto:[email protected]> <[email protected] > <mailto:[email protected]>> > Subject: Re: [mailop] Outlook rate limiting, just us? > > >> On 3 Mar 2026, at 16:52, Jethro Binks via mailop <[email protected] >> <mailto:[email protected]>> wrote: >> >> All, >> >> We were seeing these temporary deferrals for MS-related consumer domains >> from time to time in the last couple of weeks, after maybe a couple of days >> it would clear up and messages would be delivered onwards. >> >> However starting on 27th Feb we've got something different. Full hard >> rejections with: "550 5.7.515 Access denied, sending domain STRATH.AC.UK >> doesn't meet the required authentication level. The sender's domain in the >> 5322.From address doesn't meet the authentication requirements defined for >> the sender. To learn how to fix this see: >> https://go.microsoft.com/fwlink/p/?linkid=2319303 Spf= Pass , Dkim= Fail , >> DMARC= Pass" >> >> For the particular server of ours that's involved in this (we've been >> sending from its IP for maybe 15 years), we are not doing any DKIM signing >> for Reasons. I had thought (rightly or wrongly) that either of SPF pass or >> DKIM pass was fine, that's certainly been the situation up to now. >> Something's changed somewhere though lately. > > Lack of DKIM is likely the problem, they require all messages to be DKIM > signed > <https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730> > and have been rolling out enforcement since last year. > >> Well, anyway, I thought I'd take one of the suggested routes in the forums >> and report athttps://olcsupport.office.com/. >> >> There's a big banner at the top: "We are aware of an issue that may result >> in certain IP addresses being temporarily rejected at higher rates. We are >> actively investigating the issue. Please continue to submit tickets if you >> are experiencing this problem.". Is that the temporary defer problem? Or >> the permanent reject one? Or some other problem? No idea, so I'll fill the >> form in anyway. > > This message is related to a different issue connected to a different SMTP > response code. > > >> Except, I can't submit it. I get the error: "Website URL must start with >> http:// or https:// and contain a valid domain and top level domain.". I'd >> like to think I'd know my website address >> is "http://www.strath.ac.uk <http://www.strath.ac.uk/>", but apparently MS >> knows better and I'm wrong. > > Maybe they are strictly enforcing the must be a TLD bit and excluding a lot > of working domains. But adding DKIM will make that bounce go away without > having to contact them. > > Ken. > _______________________________________________ > mailop mailing list > [email protected] <mailto:[email protected]> > https://list.mailop.org/listinfo/mailop -- The Delivery Expert Laura Atkins Word to the Wise [email protected] Delivery hints and commentary: http://www.wordtothewise.com/blog
_______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
