A recent case highlighted an unusual issue verified against Outlook 2010.  If you have spell-checking enabled (and it usually will be by default), and also have the "Ignore original message text in reply or forward" option checked (found in Mail Options), there is an issue when programmatically replying to an email in that this setting is ignored.

When you reply to a message, the original text is declared with an attribute that causes Word to ignore it when spell-checking.  Unfortunately, when you programmatically reply to a message, this does not happen.  As an example, attach this code to a UI button (this was tested in an Outlook add-in):

private void button1_Click(object sender, RibbonControlEventArgs e)
{
var inspector = ThisAddIn._Application.ActiveInspector();
if (inspector.CurrentItem is MailItem)
{
MailItem item = ((MailItem)inspector.CurrentItem).Reply();
item.Display(false);
}
}

The above is basically an implementation of the normal Reply button - or it should be.  However, if you do implement the above, and then use the new button to reply to a message, then as soon as you start typing in the reply window, a complete spell-check will be performed (i.e. if there were any spelling mistakes in the original message, these will be underlined in red).  If you use the built-in reply button this does not happen.

The underlying cause for this issue is still being investigated.  However, there is a simple workaround.  You can programmatically apply the attribute to the email body that will prevent Word from performing the spell-check.  To demonstrate, the above method can be modified like this:

private void button1_Click(object sender, RibbonControlEventArgs e)
{
var inspector = ThisAddIn._Application.ActiveInspector();

if (inspector.CurrentItem is MailItem)
{
MailItem item = ((MailItem)inspector.CurrentItem).Reply();
string sHtml = item.HTMLBody;
sHtml = sHtml.Replace("<w:WordDocument>", "<w:WordDocument><w:SpellingState>Clean</w:SpellingState>");
item.HTMLBody = sHtml;
item.Display(false);
}
}

 The above is a simple example, and has not been robustly tested, but should help until a fix is introduced.