The total density number for the MKT_OP_DBF.M_ORIGIN_NB column don't look very good:
Range cell density: 0.0000034460903826
Total density: 0.0053334921767125
Notice the total density value is 3 magnitudes larger than the range density ... which can indicate a largish number of duplicates. (NOTE: This wide difference between range cell and total density can be referred to as 'skew' - more on this later.)
Do some M_ORIGIN_NB values have a large number of duplicates? What does the following query return:
=====================
select top 30 M_ORIGIN_NB, count(*)
from MKT_OP_DBF
group by M_ORIGIN_NB
order by 2 desc, 1
=====================
The total density can be used to estimate the number of rows expected for a join (eg, TRN_HDR_DBF --> MKT_OP_DBF). The largish total density number, when thrown into the optimizer's calculations, may be causing the optimizer to think that the volume of *possible* joins will be more expensive than a join in the opposite direction (MKT_OP_DBF --> TRN_HDR_DBF) which in turn means (as Jeff's pointed out) that you end up table scanning MKT_OP_DBF (as the outer table) because of no SARGs.
From your description it sounds like you've got the necessary indexes to support a TRN_HDR_DBF --> MKT_OP_DBF join order. (Though it wouldn't hurt to see the complete output from sp_helpindex for both tables just to make sure we're on the same sheet of music.)
------------------------
Without more details (eg, complete stats for both tables, sp_help for both tables - if you decide to post these I'd recommend posting them as a *.txt attachment).
I'm assuming you *know* that a join from TRN_NDR_DBF --> MKT_OP_DBF should be much quicker than what you're currently seeing. If this is the case, I'd probably want to start with:
=====================
exec sp_modifystats MKT_OP_DBF, M_ORIGIN_NB, REMOVE_SKEW_FROM_DENSITY
go
exec sp_recompile MKT_OP_DBF
go
-- run your query again
=====================
By removing the skew from the total density (ie, set total density = range cell density = 0.00000344...) you're telling the optimizer that it can expect a much smaller number of joins for the join order of TRN_HDR_DBF --> MKT_OP_DBF ... and that may be enough for the optimizer to use TRN_HDR_DBF to drive the query.
NOTE: If sp_modifystats/REMOVE_SKEW_FROM_DENSITY provides the desired join order, keep in mind that you'll need to re-issue this command after each update stats command that modifies the stats on the M_ORIGIN_NB column. For example, modify your update stats maintenance job to issue sp_modifystats/REMOVE_SKEW_FROM_DENSITY for those special cases where you know it helps query performance.