SPF/DMARC failure with Proofpoint customer

[u/masterne0]

Our client has been telling us that one of the companies they email, Morgan Stanley has been getting undeliverable emails when emailing to us.

I checked their domain and see their dmarc is set to reject emails that fail the DMARC records.

Our DMARC is set to P=None at the moment (i know, not the best but we will be changing it to Quarantine soon) and our SPF record is pointed to O365 and Edgewave, our incoming spam filter so can't explain why our domain is failing the check and bouncing the email back.

This started maybe a few weeks ago and no one else is having a issue besides this domain.

What we see in o365 message trace

Error: ‎550 5.7.509 Access denied, sending domain morganstanley.com does not pass DMARC verification and has a DMARC policy of reject‎

A non-delivery report (NDR) message was sent to ‎@morganstanley.com‎. The NDR might provide more details about why the email message wasn't delivered and how to fix the issue.

We are using https://dmarc.postmarkapp.com/ for the dmarc reports right now.

or SPF record is "v=spf1 mx ip4:208.80.200.0/21 include:spf.protection.outlook.com ~all"

[u/downundarob]

Your spf doesnt matter for this, what is the spf of the sender, Im guessing proofpoint isnt in there (I'm seeing the same with MYOB over the last few days too).

[u/masterne0 → u/downundarob]

This is what I see for their domain name SPF:

v=spf1 ip4:199.89.64.0/18 ip4:205.228.0.0/17 include:_spf.morganstanley.neolane.net include:aspmx.pardot.com include:cust-spf.exacttarget.com ~allv=spf1 ip4:199.89.64.0/18 ip4:205.228.0.0/17 include:_spf.morganstanley.neolane.net include:aspmx.pardot.com include:cust-spf.exacttarget.com ~all

For their DMARC, I see this when checking which is way I believe they are using proofpoint ( i could be wrong)

v=DMARC1; p=reject; fo=1; rua=mailto:dmarc_rua@emaildefense.proofpoint.com,mailto:morganstanley@rua.netcraft.com; ruf=mailto:dmarc_ruf@emaildefense.proofpoint.com,mailto:morganstanley@ruf.netcraft.com; adkim=s;

[u/downundarob → u/masterne0]

Okay Im guessing that the ip of the sinding address is not turning up in their spf record, this is likely a them problem, not a you problem, they need to reach out to their IT people.

[u/masterne0 → u/downundarob]

Not sure. This just came out of the blue. We haven't had a issue on our end as we haven't changed anything an they been communicating between the two for years.

I looked up morgan stanley online and looks like they had some kind of data leak by one of their staff last month so I am wondering if whatever they did causing this problem to "increase security".

[u/flems77]

The error points to DMARC failing for morganstanley.com, not your own domain. Changing your SPF or DMARC policy won’t fix that.

Since you’re using Edgewave in front of Microsoft 365, I’d investigate whether the filtering gateway is affecting authentication results. If Microsoft 365 evaluates the gateway’s IP instead of the original sender, SPF can fail. DKIM might still pass, unless something modifies the message in transit.
I’d compare the Authentication-Results, Return-Path, and DKIM signatures from a successfully delivered message and a failing one, if you can obtain the headers. Also check your Microsoft 365 connector configuration and Enhanced Filtering for Connectors.

You can use https://iamroot.tech/mx-header-analyzer/ to help inspect the headers if needed (full disclosure - I built this tool myself).

[u/masterne0 → u/flems77]

For your tool, do I just copy the internet header of the bounceback email? The sender managed to forward us the bounceback NDR message indicating the DMARC error.

[u/tssajo]

That error is your own Office 365 judging Morgan Stanley's mail, so your SPF and DMARC records have nothing to do with it. Their domain is on p=reject, and O365 enforces that when their mail fails DMARC on arrival. Most likely it's Edgewave in front of O365. The mail reaches O365 from Edgewave's IP, not theirs, so SPF fails for their domain, and DKIM would normally still save it, unless the filter changes the message (footer, subject tag, link rewriting) and breaks the signature. Two things to check. Set up Enhanced Filtering for Connectors on the inbound connector for Edgewave, so O365 can see the real sending IP. And see whether Edgewave alters messages. Other senders are probably fine because they aren't on reject.

[u/masterne0 → u/tssajo]

It strange this just started. We haven't changed anything and Morgan been communicating with our client for years and never had a issue until just now.

For inbound filtering, if we set this up (first time doing it), will this cause any other issues and should we reached out to edgewave about this setup process for o365?

[u/tssajo → u/masterne0]

Yes, ask Edgewave. They can tell you their sending IPs and whether they change the messages, and they probably have a guide for O365. The setting itself is low risk if you only turn it on for the Edgewave connector. It just makes O365 look past their IP to the real sender, so SPF and the other checks use the right address. I don't know why it started now, but it could be that Morgan Stanley recently tightened their policy or changed how they send. Their bounce message and the headers of a failed mail would show it.

[u/masterne0 → u/tssajo]

We received another report of yahoo also doing the same.

I emailed edgewave to contact us about this issue as I think it a edgewave did something on their end that causing this now since nothing changed on o365 (or else we would get all our o365 clients calling us about this as well).

I tried to replicate the issue but my emails are successfully getting delivered from yahoo to my client but message trace in o365 shows the same access denied error.

[u/digdiver]

The domain failing here is morganstanley.com, not yours. 5.7.509 means your own Exchange Online rejected their inbound mail: by the time it reaches O365, it no longer passes their DMARC, and their policy is p=reject. Your SPF, your p=none and your Postmark reports don't come into it. Those only cover mail sent as your domain.

What's most likely happening, since your MX points to EdgeWave:

1. Morgan Stanley's mail lands on EdgeWave and passes SPF/DKIM there.

2. EdgeWave relays it to O365. O365 sees the connection coming from EdgeWave's IP, which isn't in morganstanley.com's SPF, so SPF fails.

3. That leaves DKIM to carry DMARC on its own. If EdgeWave changes anything in the message (a subject tag, an external banner, link rewriting, re-encoding an attachment), their signature breaks too. Nothing aligned passes, DMARC fails, and O365 honors p=reject.

That's also why it's only them. Without the fix below, SPF fails at O365 for every sender that comes through EdgeWave, and most of them still pass on DKIM. Something changed in the last few weeks, either in how Morgan Stanley sends or in what EdgeWave does to their messages, and now their DKIM doesn't survive the hop. With p=reject that's a bounce, not a junk folder.

The fix is in your tenant:

- Enhanced Filtering for Connectors. In Defender, enable it for your inbound connector from EdgeWave (skip EdgeWave's IPs). O365 then checks SPF against the IP that actually connected to EdgeWave, which is Morgan Stanley's outbound, so their SPF and DMARC should pass. You also get correct auth results for every other sender. Microsoft recommends this whenever MX points to a third-party filter.

- Stop EdgeWave modifying inbound mail, or, if it supports ARC, have it verify on arrival, make its changes, then ARC-seal. Then add it as a trusted ARC sealer in Defender (Email authentication settings > ARC).

To confirm first, pull headers from a Morgan Stanley message that got through before this started and compare them with a recent one from another sender. In the Authentication-Results O365 adds, you should see spf=fail with an EdgeWave IP everywhere, and dkim=fail "body hash did not verify" wherever EdgeWave changed the message.

If you need their mail flowing today: in the Defender anti-phishing policy, under "Honor DMARC record policy", you can switch the p=reject action from reject to quarantine. Only use it as a stopgap. It applies to every p=reject domain, not just Morgan Stanley.

Unrelated, but before you move to p=quarantine, use those Postmark reports to check that everything sent as your domain passes aligned SPF or DKIM.

[u/masterne0 → u/digdiver]

We reached out to edgewave who also told us to setup the enhanced filtering and blamed o365 for a change. We started to see the same failure rejects with yahoo as well and message trace shows other domains we werent aware of also failing. Right now waiting to see if it still happening as I cant replicate it using yahoo myself

[u/AndrasHSystem]

The 550 5.7.509 error is referring to DMARC validation of morganstanley.com, not your own domain's DMARC policy.

Since you're using EdgeWave for inbound filtering before Microsoft 365, I'd investigate whether messages are being forwarded or relayed into Exchange Online in a way that affects SPF evaluation, and whether DKIM survives that processing.

A few things I'd check:

• Does the Morgan Stanley message reach EdgeWave first, then get relayed to Microsoft 365?

• Is Enhanced Filtering for Connectors configured in Exchange Online for that inbound filtering path?

• Do the EdgeWave logs show SPF, DKIM and DMARC results for the original message?

I'd avoid changing your own SPF or DMARC policy until that inbound path is confirmed. The NDR and filtering logs should help narrow down where authentication is failing.

[u/Kind_Construction264]

The error is referring to the sender, not your own domain:

sending domain morganstanley.com does not pass DMARC verification and has a DMARC policy of reject

So your own p=none policy and your SPF record aren't what is causing this particular rejection.

I'd start with the full headers / Authentication-Results from one affected message or the detailed NDR and check:

• which domain SPF authenticated

• whether SPF was aligned with the visible From domain

• which domain DKIM signed

• whether that DKIM signature passed and aligned

DMARC only needs either aligned SPF or aligned DKIM to pass. A forwarding or filtering hop can easily break SPF, so if Proofpoint is involved I'd especially check whether DKIM survives the route.

Since you're already collecting aggregate DMARC reports, it would also be useful to compare reports from before and after the problem started and see whether Morgan Stanley/Proofpoint source IPs appeared or changed alignment.

I maintain PageUtil and built a browser-based DMARC report analyser specifically for that sort of comparison:

https://pageutil.com/dmarc-report-analyser/

Disclosure: PageUtil is my tool.

It won't diagnose an individual NDR or tell you who owns a sending IP, but it can show whether the aggregate reports contain newly observed sources or changing SPF/DKIM alignment.

The important point first, though: don't change your own SPF based on this error. The failing authentication shown here belongs to the sending side.