Can't receive emails from one domain

We have one client that cannot email us as of a couple of weeks ago.  As far as we know, nothing's changed on either end. They also don't have issues emailing others.

The undeliverable email they receive simply states:

This is an automatically generated Delivery Status Notification.

Delivery to the following recipients failed.

We're still on Exchange 2003 & they're using Hosted Exchange with Office 365.

I'd checked our spam server & found that not only do we have their domain whitlisted, but its showing a spam score of zero because of it.  Additionally, due to some false positive issues, we aren't setup to outright reject spam any longer so it should still come through.

The header of the undeliverable message is:

Received: from ( by ( with Microsoft SMTP
 Server (TLS) id via Mailbox Transport; Tue, 16 Jun 2015 17:19:17
Received: from ( by ( with Microsoft SMTP
 Server (TLS) id; Tue, 16 Jun 2015 17:19:15 +0000
Received: from (2a01:111:f400:7c0c::141) by (2a01:111:e400:4821::17) with Microsoft
 SMTP Server (TLS) id via Frontend Transport; Tue, 16 Jun 2015
 17:19:14 +0000
Authentication-Results: spf=none (sender IP is x.x.x.x);; dkim=none (message not signed)
 header.d=none;; dmarc=none action=none;
Received-SPF: None ( does not
 designate permitted sender hosts)
Received: from (x.x.x.x) by ( with Microsoft SMTP
 Server id via Frontend Transport; Tue, 16 Jun 2015 17:19:13 +0000
From: <>
To: <>
Date: Tue, 16 Jun 2015 10:19:14 -0700
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
X-DSNContext: 7ce717b1 - 1158 - 00000002 - 00000000
Message-ID: <>
Subject: Delivery Status Notification (Failure)
Return-Path: <>
X-MS-Exchange-Organization-Network-Message-Id: d8c0b642-2a55-47d7-efac-08d2766fb39d
X-EOPAttributedMessage: 0
X-MS-Exchange-Organization-MessageDirectionality: Incoming
X-Forefront-Antispam-Report: CIP:x.x.x.x;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(6009001)(2970300002)(428002)(189002)(199003)(319900001)(53416004)(189998001)(450100001)(46102003)(19580395003)(105586002)(86152002)(110136002)(5001960100002)(78352002)(87836001)(2351001)(89962001)(50986999)(960300001)(19580405001)(84326002)(77096005)(107886002)(101416001)(5001920100001)(229853001)(1476001)(77156002)(5000100001)(62966003)(5003600100002)(25786006)(42382002)(564344004)(92566002)(83832001)(106466001)(118246001)(54356999)(7059030);DIR:INB;SFP:;SCL:1;SRVR:CO1PR05MB314;;FPR:;SPF:None;MLV:sfv;MX:0;A:0;LANG:en;
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB314;
X-MS-Exchange-Organization-AVStamp-Service: 1.0
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(5008015)(5006022)(520003)(3002001);SRVR:CO1PR05MB314;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB314;
X-MS-Exchange-Organization-SCL: 1
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jun 2015 17:19:13.8488
X-MS-Exchange-CrossTenant-Id: b31bef44-96df-443b-b020-c94f9b805344
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB314
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Transport-EndToEndLatency: 00:00:04.0354830

Thanks in advanced for any thoughts or suggestions!
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Will SzymkowskiSenior Solution ArchitectCommented:
Authentication-Results: spf=none (sender IP is x.x.x.x);; dkim=none (message not signed)
  header.d=none;; dmarc=none action=none;
 Received-SPF: None ( does not
  designate permitted sender hosts)

Based on the header information it is failing due to an incorrectly configured SPF record.

blugirlAuthor Commented:
Thanks Will.  Is that on our end or theirs?
Will SzymkowskiSenior Solution ArchitectCommented:
This would be the Senders SPF record. The IP address is not configured properly which is causing it to bounce back for this domain.

Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

Just an add on.... The block is happening at your mail server because of the way you have it configured to handle the SPF check. They should fix their SPF record though.
blugirlAuthor Commented:
Thanks winthropj.  I've already gave them a heads-up, so hopefully their SPF will be adjusted shortly.  Just curious though, where would I find this on our server?
Will SzymkowskiSenior Solution ArchitectCommented:
SPF checks are done againts External DNS not on the Exchange server itself.

blugirlAuthor Commented:
Thanks Will.  If I understand winthropj correctly, is there a setting on our Exchange server that would require the sender to have an SPF record configured? I'm not sure why more folks wouldn't also be having issues receiving emails from them.

I was starting to get clued unto the SPF issue yesterday, but originally thought it was because we didn't have one.  So I had SiteGround add one since they're managing our DNS.  So if this scenario was reversed, it would be the External DNS info that SiteGround manages that you're referring to, correct?
Will SzymkowskiSenior Solution ArchitectCommented:
Depending on how the recipent is interpreting your SPF record is why it is failing. Make sure that your SPF record is configured properly. The recipients probably blocking the mail due to there SPF record requirements, and because the senders does not match it is not allowing the email to get through.

This is what I think is happening,.

Will  - I think its his server checking the SPF record.

The SPF check is configure in Edge Transport under Anti-Spam.
There are three options. Reject, Delete, Stamp Header with info and allow.
Will SzymkowskiSenior Solution ArchitectCommented:
Yes this would either be on a smart host or on the Edge server. I did not read that he is using an Edge server.

Will SzymkowskiSenior Solution ArchitectCommented:
Ahh the entire time i was thinking about Exchange 2010. Totally forgot it was for 2003. However it does still relate to your SPF record for the failed message.

blugirlAuthor Commented:
Will, just to clarify, they're sending the email to us that's getting bounced back to them.  We can send them emails just fine.  So are we thinking that it's our SPF record that's incorrect and/or missing or theirs?
Will SzymkowskiSenior Solution ArchitectCommented:
It is the Senders SPF record that is misconfigured, and it would be how your Exchange server or appliance (smart host) is interpreting the SPF record if it is improperly configured.

Theirs. The SPF record is a DNS record that states which servers are OK to send mail for a particular domain. Your server takes the domain of the email address and then does a DNS lookup to verify that the server sending the message is OK for that domain.

It looks like they don't even have an SPF record. The other piece though is your server is configured to reject the message if the SPF check fails which in this case it does.

You may be able to whitelist their domain. I can't remember off the top of my head where that is done. The other option is to change the action associated with the Sender ID check in exchange.
blugirlAuthor Commented:
Thanks for your patience & feedback Will & Wintropj.  I'm definitely learning a lot through this process & things are starting to make more sense...but another question though...

They feel pretty confident that they're settings & SPF record should be fine since they're using hosted Exchange with Microsoft.  They also provided their SPF info below:

SPF record lookup and validation for:
SPF records are published in DNS as TXT records.

The TXT records found for your domain are:
v=spf1 -all

Checking to see if there is a valid SPF record.

Found v=spf1 record for
v=spf1 -all

Is there any info I can provide them to help point them in the right direction if it is indeed an issue on their end?
blugirlAuthor Commented:
Wintropj, thanks for the link to the article.  I found that under Global Settings > Message Delivery > Sender ID Filtering tab that it's set to the default option of Accept.  But I'm not certain I'm looking in the right location to verify if the filter's been enabled (see Figure 5 from article link).

I looked under Administrative Groups > Anaheim Hills > Servers > our server name > Protocols > SMTP > Default SMTP Virtual Server, but don't see those options.  Am I in the right location?

SMTP Virtual Server
Go to and check their domain.  Last time I was there you could do the DNS check right from the home page.  

You won't find filtering on the SMTP server as its for outgoing.  That header was stamp on the way into your mail server so if the sender ID setting us accept there must be another server or appliance that the mail hits first.  You can check your own domain at that same site and see where your mx record points. It could also be 3rd party software on exchange box that's doing an SPf check.
blugirlAuthor Commented:
Winthropj, ok...that makes sense.  Since we're checking what they're sending us to ensure their domain isn't being spoofed, the part of that article that I'm checking is what the Sender ID Filter is set for under Message Delivery properties, correct?  If it's set for "Accept" & we're completely bypassing the spam filter for this domain, why would it still get rejected?
Hmmmm. Might be up the wrong tree.  We know the message was rejected and that the SPF checked failed but it's only been assumed that the reject was because of that. Just because it's stamped in the header doesn't mean that's why it was rejected.   I'm going to look over the header again and see  if anything jumps out.
Did you find any resolution to this?  I thinking the Forefront logs must have something.
blugirlAuthor Commented:
Sorry for the extended delay on reporting back. I've been slammed & was going to throw in the towel & have a consultant come in to assist.  But this week we had a 3rd client that received undeliverable notice but at least theirs returned error code 5.2.1.

After reviewing this post I confirmed that we were receiving Event ID 9667 & followed their suggestion:

1. Change the Registry value of Named Props Quota to 16384 by going to following location in registry

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-00000000-0000-0000-0000-00000000

2. Increase the Registry value of NonMAPI Named Props Quota to 16384

3. Dismounted and remount the store

We can now successfully receive emails from the original client that had reported the issue.  Now to test with the other 2.

Thanks again for all the help!  Although it wasn't quite the right path, I do appreciate the feedback & still learned something.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
blugirlAuthor Commented:
After receiving an undeliverable notification with error code 5.2.1, it provided more information for the cause of the issue which was different than the original path we were headed down.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.