This message wasn’t delivered to anyone because there are too many recipients. The limit is 100. More hybrid fun!

If you are living the Exchange Online Hybrid dream like so many, you often run into oddities around message flow.  One encountered recently was a nagging NDR an Exchange Online user would get when sending to an old-school Distribution List.


This message wasn’t delivered to anyone because there are too many recipients. The limit is 100. This message has 198 recipients.


Action: failed
Status: 5.5.3
X-Supplementary-Info: < #5.5.3 smtp;550 5.5.3 RESOLVER.ADR.RecipLimit; too
many recipients>

Now the first thought is some Exchange Online limitation, but the NDR was actually generated by an on-premises server and, as we all know, DLs count as one recipient right? Besides, I wasn’t aware of any limit anywhere in Exchange of 100 – except the pickup directory for the transport service.

Regardless, due diligence required some checking and the sender ( who was part of the list) had the standard recipient limits in place:

And if you didn’t already know, 500 is the default in Exchange Online and that can not be modified.

The other members of the group were all on-prem, so I checked their recipient limits and, as expected, those were set to the default of “unlimited”.

Hmm, Did someone mess with the on-prem org limits? Didn’t make sense since this was the only user reporting this. But being the good scout, I checked anyway and that value was set much higher than 100.

So where the heck was that coming from?

Checked receive connector limits, looked through SMTP protocol logs. No smoking gun.

Then it occurred to me, was it possible that the remote mailbox for the 365 sender was the culprit?

Sure enough, there it was:

Set-Remotemailbox doesn’t let you change that attribute, so I cleared it with ADUC and the birds sang once again.

Reconstructing this, I can only assume that the on-prem mailbox had this value set for some reason and during the move to Exchange Online, it was preserved for the remote mailbox.

The interesting piece to remember is that the DL was expanded in Exchange Online and because majority of the list members were still on-prem, the recipient limits came into play on the on-prem object.

Good times!




Outlook ate my Attachments!

Fixed! If you are seeing this issue, close and re-open Outlook! 

Kinda stumbled upon this the other day when sending a text file through Outlook. The recipient informed me it wasn’t received. Oh jeez, did I just think I sent that?

So I sent it again and even included a pic of it attached to ease my embarrassment. Nope, the recipient was still not getting it- just the email itself.

I checked my sent items and sure enough, no paper clip icon. So I ran a bunch of tests sending different sized text files,  and as you can see from the results (with my clever subject lines – sigh), some went through, some did not.

Message tracking in Office 365 revealed nothing unusual.

I wondered if it was just me, so I did a little searching and found someone reporting the same issue in the TechEd Forums:

At this point, it appears to affect only text attachments over 4MB using Microsoft Office 365 Pro Plus C2R Outlook  8431.2079 and above, but not Outlook on the Web ( OWA) or whatever it’s called now. Your experience may be different.

As you can see, I’m using the latest and greatest version!

I have also reported this issue, so hopefully it will get fixed soon.

In the meantime, compress that text attachment to below 4MB, upload to OneDrive or a shared drive.

Abs of Steel and My DKIM Body Hash Won’t Verify. Help Me Dr. Phil!

If you are applying an *inbound* disclaimer with a mail flow rule in Office 365, you may be surprised to see a DKIM body hash failure in the header of the message. ( and if you have never noticed this, well, that’s understandable!)



Message sent from Gmail with disclaimer rule:


Authentication-Results spf=pass (sender IP is;; dkim=pass (signature was verified);; dmarc=pass action=none;; dkim=fail (body hash did not verify);





Message sent from Gmail w/o disclaimer rule:


Authentication-Results spf=pass (sender IP is;; dkim=pass (signature was verified);; dmarc=pass action=none;; dkim=pass (signature was verified);


This brings up some interesting questions. Is the DKIM check *after* mail flow rules are processed? And does this mean I have lost the ability to check for DKIM failures for those messages?

Thankfully, no on both. I have confirmed that you can ignore the failure and have been assured that mail flow rules are evaluated after DKIM verification.

As you can see in my examples, in both cases, the first DKIM check passes and just as importantly, DMARC passes and that is what you should be hanging your hat on.

Stay safe out there!

Selectors: The Magic Sauce of DKIM

One question I see a lot is “How can I let 3rd party vendors send as our organization using DKIM?” It’s a lot easier than you think.

The trick is in the selector. Per RFC 6376 To support multiple concurrent public keys per signing domain, the
key namespace is subdivided using “selectors”.  

Implementing this is pretty straight-forward, so let’s get started.


Suppose you have your existing DKIM infrastructure handled by Office 365/ EOP.

When sending a message through Office 365/EOP, the header of the message is stamped with the required DKIM fields.

Check out the sample header in the received message below. Note the s=selector1. This tells the receiving server to check :

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qwJgpoXgR3MRDrSVO91kT+tYSpE//LjikNGicqlKjU0=; b=FnK8HjJFfEKHMq5EoIGJVzty4w+v7uE0UmQVFrVYr348e4tqfE66U/pZanlNfS7guhj2T5g5sqva7w1Wc1/+NOlC6CEBMrQiuFVDo0Akk8narhX9r9xs99Yniv…


In your organization’s external DNS, you have a CNAME record of that selector:    canonical name =

Following the DNS pointer…

In the Office 365 DNS is something like this text record with the public signing key:       text =


The receiving server can now run it’s calculations against the message knowing the public signing key.

So you can see where we are going with this.

If you want a 3rd party vendor authorized to send as your company and apply a DKIM key to each message, you have a few options:

Create a unique selector CNAME – different from the one you use for messages coming from your organization – in external DNS that points to the 3rd party vendor’s DNS which contains the public DKIM signing key. This is similar to what Office 365 tenants do.


Use a unique selector and create the DNS text record that has the public DKIM signing key provided by the vendor. Remember: They are generating the messages, so the 3rd party vendor has the private key, you do not!


Each method will work and it’s really up to you. Note that if you decide to create the text record in your DNS with the public key signing key, it will break DKIM for those messages if the 3rd party vendor decides to change the private signing key that they hold.

I think it goes without saying that the one thing you don’t want to do is provide “your” private signing key to a 3rd party vendor and have them sign messages using your “regular” selector – the one you use for messages that actually do come from your domain. At least I wouldn’t recommend that.

Once this is all setup, then it’s up to the 3rd party to set the selector correctly in the message header. So, if EOP is stamping “selector1” on all outbound messages, the 3rd party vendor can use anything allowed by RFC except selector1.

As an example, headers received from the vendor, sending as you, may stamp it with:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=contosoBULK

Receiving servers will now check the text record: and depending on how you set it up, obtain the public signing key or get redirected by CNAME to another DNS.

This also works great for subdomains – i.e. have the 3rd party send as and setup the DKIM records for that specific SMTP domain.

There is no real limit to the number of selectors one domain can support, just ensure they are unique to each sender and are configured properly so receiving systems can correctly access the DKIM public signing key.

With the advent of so many cloud services, I suspect just about every organization has at least one 3rd party sending as their SMTP domain, so get your DKIM ( and SPF records!) right. I hope this helps understand that process a little bit better.

For more info about DMARC/SPF and DKIM:

The Trinity of Email Protection: Lessons Learned using DMARC, DKIM and SPF in Office 365

The Trinity of Email Protection: Lessons Learned using DMARC, DKIM and SPF in Office 365

I am a big fan of DMARC and its ability to easily determine which messages sent as, and from, your SMTP domains are using authenticated and authorized servers. The A in DMARC actually stands for “authentication”, but it’s really a little of both.

Regardless, it’s something I highly recommend and if you are using Office365/EOP, there is really no reason you should not be using it, after all it’s already enabled. In fact, if you choose not to set up any of the email protection trinity, EOP will absolutely mark any message sent from the internet as your domain to your domain as SPAM.

Since you are reading this, I assume you are using it or wanting to use it. To that end, here are some tips and lessons learned from my own experiences:

  1. Start small.  Your first DMARC record in DNS ( should do nothing but report. At its very minimum, it should look like this: “v=DMARC1; p=none;;”  All this does is tell recipient servers that they should send DMARC failure reports to ( This could be a mail-enabled Public Folder).  The p=none does not affect the way messages are delivered. With p=none, you are not suggesting to a recipients mail server that they change the way they handle the messages that fail DMARC checks.  I would recommend you always use p=none, unless you have no 3rd party vendors that send mail as your SMTP domain. In that case, p=quarantine is probably worthwhile once you have vetted out your DMARC policy sufficiently. I would never use p=reject  – unlike a few ISPs out there.
  2. Get your SPF records in order. If you have 3rd party vendors that send as you, this is especially important. It doesn’t take much to exceed the 10 Lookup Max on SPF records. Heck, if you are using EOP, requires three lookups alone! Exceeding that amount can cause failures because recipient domains may ignore your SPF completely.
  3. Don’t forget DKIM! SPF seems to get all the attention, but setting up DKIM could not be easier in Office 365. You can even configure it in the portal now under the Protection menu in EAC. And once setup, there is nothing cooler than seeing that DKIM-Signature in the headers.
  4. There are options if you simply can not get those SPF lookups below 10. The SPF RFC supports macros. Mind. Blown. No really. Imagine a SPF record of “ IN TXT “v=spf1 include:%{i}._ip.{%h}._ehlo.{%d} –all”.  Ok, I am not aware of anyone that does this, but it’s a possibility. Another option is not use SPF records and depend on the DKIM record. This is great if you have no or cooperative 3rd party vendors that send as your domain. DKIM is not limited to that pesky 10 max record lookup and as mentioned above, DMARC messages need to pass either the DKIM or SPF and, not both. If you support multiple SMTP domains, you may want to also consider setting up distinct SPF records for each zone rather then using the include option to keep each domain under that 10 limit.
  5. Don’t forget the alignment requirement! As mentioned above, DMARC will check the sender’s valid SPF or DKIM records in DNS. If one or both of those exist and pass, then alignment must pass as well. This is the magic sauce in DMARC. Alignment simply means the header FROM: matches the Domain “from” (i.e. the MAIL FROM: /Return-PATH) of the message. This is an important consideration because even if the message passes the SPF or DKIM check, it can still fail DMARC if for some reason you have processes that set the FROM: in the header to a completely different domain from the RETURN-PATH or MAIL FROM:. I have seen it happen!
  6. Leverage DMARC inbound. The value-add for DMARC is pretty obvious for messages sent out from your org. But the really cool part is using it inbound to stop those endless spoofing attempts without the need for clunky transport rules. You can create nifty rules to check for failures as illustrated in a previous blog post. This is another reason you want those SPF records to be below 10 lookups. If they exceed allowed amount, you may find that your inbound rules do not correctly detect the dmarc=fail or dmarc=pass.
  7. Whitelisting is your friend. If you are going to create inbound DMARC rules, it is very important to remember that SPF lists mail servers that are authorized to send messages on behalf of your SMTP domain. That’s not necessarily the same list of IPs that will sending as your domain directly to internal users. If you are using WorkDay, SalesForce or any of the multitude of SAAS cloud vendors, you can be pretty darn sure they are sending spoofed messages to your domain, but not to external recipients as you,  so they wont be listed in your SPF. Any whitelisting rules MUST be above the DMARC rule. Seems obvious, but don’t overlook it!
  8. Add a check for dmarc=temperror in your inbound transport rule. If the domain in the Mail FROM: doesn’t exist, you may see a spf=temperror or dmarc=temperror in the Authentication-Results header of the message. If your rule isn’t testing on that, it could slip past your defenses. I have actually seen a number of these from images spun up in 3rd party hosted solutions. I prefer to tag these as FAILs, but that is up to you if you want to let them pass.
  9. Set the inbound rule to only notify you initially. As with DMARC in general, start small. Don’t block anything until you feel confident that only the truly unwanted spoofed messages are trapped. Your initial rule should simply check for a DMARC failure, and send an incident report to a mailbox that you monitor. An example rule is found here. And that leads me to the next tip once you ready to take action on DMARC failures.
  10. Quarantine the message, do not simply set it to a high SCL. You really have two options  ( I would not delete the message) on how to deal with illegitimate spoofed mail, you can force it the quarantine, or set it at a SCL high enough to mark it as SPAM. I recommend forcing it the quarantine so that end-user safe sender lists can not trump your rule.  If you have a user that has added a GAL object to their contacts ( A very common scenario), and has also checked “Also trust e-mail from my contacts” in Safe Senders, the spoofing rule will be defeated.
  11. Add a custom x-header to your rule. This helps you, the help desk and the end-user easily identify why this message was quarantined.

So there are some tips. This is by no means a comprehensive list. I plan to add more or revise these as time permits. If you want to read more, including how to setup DKIM in Office 365,  I would suggest following the blogs of Terry Zink  and Andrew Stobart.



Anything that works now with Microsoft Forefront Protection is probably just dumb luck

If you are still using Microsoft Forefront Protection 2010 for Exchange Server (FPE), you are officially out of time. I’m seeing a number of Technet Forum threads about things no longer working as expected or signatures that do not update.  Time to move to another on-prem product or a cloud solution like Exchange Online Protection (EOP).  ( And let’s not even talk about the support for Exchange 2010)

Subscriptions expiring before December 31, 2015 will not be renewed; virus updates and signatures will not be made available after this date and the service will end.

On September 12, 2012, Microsoft announced the End-of-Life date for the following Forefront Server and Forefront Protection products as of December 31, 2015:

  • Microsoft Forefront Protection 2010 for Exchange Server (FPE)
  • Microsoft Forefront Protection 2010 for SharePoint (FPSP)
  • Microsoft Forefront Security for Office Communications Server (FSOCS)
  • Microsoft Forefront Threat Management Gateway Web Protection Services (TMG WPS)

This announcement also applies to earlier versions of these products in the Microsoft Antigen 9 and Forefront Server ranges.

Transport Rules versus Safe Sender Lists in Office 365/EOP: ¿Quien es mas Macho?

One of the great powers of being the messaging guy or girl is the ability to create transport rules in response to business requirements. Seemingly subtle differences in the rule’s logic, however, can make a huge difference.

For example: You craft a rule to block spoofed messages from the internet that appear to come from your SMTP domain. Like all good internet citizens, you have enabled DMARC, so you construct a rule like this:



So, what happens to the message when the rule is applied? Since you are setting the SCL to 9, it will end up in the quarantine by default . Or will it?

Consider this: Since you are marking the message as SPAM, you are also giving the end-user the ability to bypass that rule by whitelisting the sender.

Because EOP honors both the RFC 5321 MAIL FROM: and the RFC5322 FROM:, if the MAIL FROM: just happens to be on an user’s safelist – added through Outlook or OWA – the message will be allowed,  even if the FROM: is a spoofed domain.

If you don’t like the prospect of messages potentially slipping through without hitting the quarantine first, force it instead:


Problem Solved!

Well, maybe. Since you are pushing the message to the quarantine by rule, the end-users will not see the messages in their personal quarantines and will not be able to release the message without administrator intervention as documented here:

But maybe that is what you want.

Regardless, you can craft the rule to meet your needs. And options are always good.






Reminder: Leave those Default Receive Connectors Alone!

I have been preaching this on the forums for many years, but it’s worth a reminder. There is generally no reason to muck with the default receive connectors.

And yes, I am aware of the advice from the 2010 days:

Note that in 2013/16, anonymous is already enabled on the “Default Frontend” connector to boot!

Messing with them is a sure way to stop mail flow between servers and who knows what else.

If you need to customize or have the very common requirement to enable support for inbound TLS with a common FQDN across servers, create a new receive connector on each server. You’ll be glad you did.


Is it really unsupported to use the Exchange PSSnapin?

I used to think so. It seemed pretty cut and dry to me at least. After all,  the official public documentation from Microsoft is very clear:

Loading the Microsoft.Exchange.Management.PowerShell.SnapIn Windows PowerShell snap-in and running cmdlets other than the *-TransportAgent cmdlets is not supported and may result in irreparable damage to your Exchange deployment.
This is reiterated by my friend Rhoderick:

But Rhoderick does say something I never really paid attention to before now:

Unless you are following a specific process that is documented by Microsoft or are working with a Microsoft support representative, the only way you should be connecting to Exchange is the method documented above

So there it is. Another exception to the rule that you may want to be aware of if you are running Exchange 2013 CU11. In the event of a “critical failure”, Microsoft advises you use the PSSnapin.

If you open EMS and are not able to connect to any Exchange Servers due to loss of communication, then you will need to add the PSSnapin for Exchange to your local PowerShell Session.

Hopefully you will never be in a failure scenario that necessitates using the PSSnapin, but if you are, it’s an available option.

For more on the mailbox anchoring issue, hop over to Andrew’s blog: