>>What Craig was suggesting (and obviously he can jump in) is to abandon the idea of output parameters, and use a general try...catch block , which gives you a repeatable approach towards capturing and reporting on errors. It's not that output parameters for error codes don't work - it's just that structured error/exception handling is a better approach. It will mean some re-work on your code and will probably take a bit of time, but in the long run it's worth it.
>
>I actually do have Try/Catch code in the method in order to catch the errors, but notifying the calling method is where I am sticking. When the error occurs I need to catch it but continue trying to send all the other emails and then when the process is complete to display the errors to the user. How should I approach this?

One way:

   public class EmailFailure
    {
        public string ErrorCode { get; set; }
        public string ErrorMessage { get; set; }
    }

Then:

       public static void SendEmails(Guid emailPK, string subject, string html, out List<EmailFailure> failures)
        {
            failures = new List<EmailFailure>();
            //Iterate email list.  When you hit a problem email:
            failures.Add(new EmailFailure { ErrorCode = "123", ErrorMessage = "Bugger" });
        }

Calling:

          List<EmailFailure> failures;
            SendEmails(Guid.Empty, "Testing", "html", out failures);
            foreach (EmailFailure f in failures)
            {
                //Display
            }

but still raise an exception for anything not handled in the above.....