Using V7.

I had working emails, and then changed the email server settings in the Other Tasks > Edit Defaults > Email.  Test messages sent from this email defaults page work fine, but existing backup jobs have this error in the log:

Email Notifications
  Recipients:    (correct address as set in the job-specific email settings)
  ERROR Failed to send email message
  Check SMTP server settings/recipient list

I do not have settings in the Email Defaults for Success, Warning or Failure since I have these set to job specific values.

So email sending broke I think when I changed the server settings in the defaults.  What do I need to touch to get emails working again?

Job-level mail settings should not need to be adjusted for a mail server change.  However, are you sending the test emails to the same recipients that the actual jobs are using? If not, are the test emails and "production" recipients in different email domains? Your new mail server might have different sending restrictions than the original. In some cases, such as Google and Microsoft, the sending restrictions in place can vary based on factors such as what level of authentication you use (if any) and whether the sending IP (assuming static) is listed as a trusted sender. For example, some providers allow you to send mail without storing credentials on the sending device (if that's undesirable and the device doesn't support modern auth), but will then restrict you to sending mail only within that domain, or possibly even within your organization in managed account scenarios --- unless maybe you've specified the sending IP address as trusted, but that requires a static IP to be practical. Otherwise, you typically have to authenticate to benefit from the least restrictive sending policies.

Thanks for your detailed reply.  I take it that there should not be any email server config data stuck in the job definitions.

Turns out that I have the same recipient in both the test email and the production jobs. 

The change I made to the server settings in the Defaults > Email was due to my ISP (Cox) requiring TLS / port 587 and that the sender email must be in the cox.net domain.  These are set as required, and sending to the same recipient via the Test feature works successfully, but per the OP the job status sends are failing.  Hum...

Correct, mail server data is never stored in definition files. You can check the XML yourself if you'd like additional verification. But if you're using the same recipient in both areas and are absolutely, positively sure there are no typos (are you?), then I'm not sure what to suggest next here...

I've not seen this documented, and based on the amount of thrash on email send failures here's a few notes on how all this works.  Please correct me if you have detailed, inside information:

1) The email server settings are defined ONLY on the Reflect Defaults > Email Server Setting page.

2) Settings on the Default Email > Email Success/Warning/Failure pages are used ONLY if the corresponding backup job specific page (backup job definition file > Advanced Options > Email > Email Success/Warning/Failure) are NOT defined. 

3) If the job-specific email settings (eg for Email Failure) has "Send Email Notification on Failed Backups" checked then NONE of the setting in the Default Email Failure page (if set) are used.  All of the default settings are completely overridden by the job-specific settings.  It follows that if job specific settings are used then the defaults need not be configured.

4) Default versus job-specific settings for Success are independent from Warning (and from Failure).  In other words a job may define job-specific settings for Failure and rely on Default Email Success settings, if defined.

Just trying to nail down ambiguity since there are ongoing problems in this area.

Again, I'm using V7.  Are these statements true for all versions?

Thanks again,
cjn

The Success/Warning/Failure settings under Email Defaults are used only to pre-populate the settings of completely new backup jobs that you define by stepping through a wizard. They are NOT "policies" that apply across the board except where overridden by downlevel settings on the definition file. So when determining what if anything will happen in terms of email notifications within a given job, only the settings you actually see defined within that job will come into play -- apart from the email server and authentication settings, which are indeed application-wide.

This applies at least for Reflect V6 through V8. I didn't use Reflect with email notifications prior to V6.