I am not convinced that "because that's the way the .exe is set up" will stand up to scrutiny as adequate justification.
Be that as it may,
a) Did you regenerate the module file mkl95_blas.mod by running the compiler on the sources for MKL95_BLAS, with "/iface:mixed" in effect? If not, the module file will not contain any information on the interface other than that in the default calling convention (or whichever convention was used when it was last generated). Do note that the regeneration will help only with MKL routines with Fortran 95 interfaces. You may still have trouble with the F77 MKL routines that have character arguments.
b) Did you consider adding !DEC$ ATTRIBUTES statements for each of your routines, rather than for the MKL routines? If the number of your routines is less than the number of MKL routines called, as is likely, you might save some effort by making such changes and building your DLL without specifying "/iface:mixed".
a) I tried this by including blas.90 in my project and setting /iface:nomixed for this source file only. It did not have any effect, i.e. it still used mixed.
b) My dll has about 300 entry points using mixed length passing. Not all of them pass strings though. I was looking for somthing simple like your suggestion (a). However it looks like I may have to alter my entry definitions.
The simpler thing we did was to add:
!DEC$ ATTRIBUTES DEFAULT :: dgemm etc for the specific names.
But now that I am doing the better thing of having a USE BLAS95_MKL and calling the generic names I get a compiler error with !DEC$ ATTRIBUTES DEFAULT :: gemm