Endpoint Central can generate beautiful patch and inventory reports — and deliver none of them, silently, for months, if the mail server was never configured. Set it up once and prove it works with a test mail today.
Scheduled reports, alert notifications and user-facing mails all leave Endpoint Central through one mail server configuration. Skip it during setup — as most people do — and nothing complains. The console looks fine. The reports exist. They simply never reach an inbox, and the gap is usually discovered at the worst possible moment: an audit, a compliance check, or a manager asking for the patch status mail that was 'scheduled' half a year ago. This page configures the mail server properly and, more importantly, proves it with a test — because an untested mail setting is just an assumption with a save button.
Every field can look correct while delivery fails — wrong password, blocked port, an MFA-protected mailbox. Only a test mail separates “configured” from working.
Example settings for a Microsoft 365 mailbox. Whatever provider you use, the test mail is the step that matters.
The schedule was real. The reports were generated. The delivery path simply did not exist.
A schedule without a working mail server produces perfect reports that nobody ever sees.
You need the SMTP server name, the port, the security type, and a mailbox with a password you are allowed to use for sending. For Microsoft 365 that is typically smtp.office365.com on port 587 with TLS; for Google Workspace, smtp.gmail.com on 587. Use a dedicated mailbox such as an IT reports address — not your personal one — so delivery survives staff changes, and so recipients learn to trust and file mails from that sender.
Open the mail server settings in the console’s Admin/server settings area and enter the server, port and security type. Set the from address to the dedicated mailbox. If your mail platform supports it, give the mailbox a display name people recognise — a report from 'IT Reports' gets opened; a report from a random string gets filtered, ignored or reported as phishing by your own users.
Be honest about the modern catch: mailboxes protected by multi-factor authentication often refuse plain username-and-password SMTP logins. If your test mail fails with an authentication error on a Microsoft 365 or Google mailbox, the usual correct answers are an app password where the platform still offers one, or SMTP AUTH enabled for that specific mailbox by your mail administrator. Do not respond by weakening the whole organisation’s mail security — fix it for the one sending mailbox.
Use the test mail option in the settings and send it to your own inbox. Then actually open your inbox and confirm it arrived, from the right address, not in spam. If it fails, read the error literally: connection failures mean the server name, port or a firewall between the Endpoint Central server and the internet; authentication failures mean credentials or MFA/app-password issues. Each error class has a different owner — network, mailbox, or settings — and the test tells you which.
Finish by scheduling one real report — a weekly patch status summary is a good start — and confirm its first scheduled delivery lands in the recipients' inboxes. Only now is the mail configuration done. Also tell recipients once, in advance, that these mails are starting; the first automated report from a new sender is otherwise a phishing suspect in every cautious office.
Every setting on this page is shown live in the ManageEngine configuration video — watch it once and your own setup becomes easy.
▶️ Watch Full VideoThe most common cause is that the mail server was never configured, or its credentials stopped working — for example after a password change or MFA rollout on the sending mailbox. Send a test mail from the mail server settings; the error will tell you whether it is a connection or authentication problem.
Typically smtp.office365.com on port 587 with TLS, using a dedicated mailbox. If the mailbox has MFA, you may need an app password or SMTP AUTH enabled for that mailbox by your mail administrator.
You can, but you should not. Use a dedicated IT reports mailbox so delivery survives staff changes, recipients recognise the sender, and your personal credentials are not stored in a server configuration.