Support & frequently asked questions

ok, Taanks Samuel. Sorry for unclear scenario. It is about scripted marketing sendouts. (created by scripts and there sending email set, as per ToDay one of mailbox addresses handled in SO) And yeah it is SuperOffice Online. So changing from info@company.com (that exsits as a valid mail-adress) to noreply@comany.com should be no problem if SPF and DKIM are set. (customer using own domain).  (I have always learned that it is better to have the "sending address" exsisting then not..(onPrem world)) (In most of the cases it should work without having the noreply@company.com address existing but if recieving mail-server (or pre systems) are doing extra validation of sending address the risk of getting tagged as SPAM increases.  I asked my SuperOffice and Commnit MS Copilot Agent: It answered as bellow: == Short answer: I would recommend that noreply@company.com actually exists as a mailbox (a shared mailbox is perfectly fine). While email can still be sent from a non-existent address, having a real mailbox generally results in better deliverability, easier bounce handling, and a more professional setup. SuperOffice also places strong emphasis on SPF, DKIM, and domain validation for email delivery. [docs.superoffice.com] , [docs.superoffice.com] , [docs.superoffice.com] Scenario Can emails be sent? Spam risk Recommendation 1. Address does not exist Usually yes Slightly higher Not recommended 2. Address exists (shared/dedicated mailbox) Yes Lower Recommended Scenario 1: noreply@company.com does not exist If SuperOffice sends emails with: From: noreply@company.com the recipient's mail server will typically validate: SPF DKIM DMARC Domain reputation As long as SPF, DKIM, and DMARC are configured correctly for company.com , the email can still be delivered successfully. SuperOffice supports SPF validation and DKIM signing of outgoing emails. [docs.superoffice.com] , [docs.superoffice.com] Potential drawbacks: Any recipient who replies will receive a bounce message. Some mail filters perform additional sender validation checks. Bounce messages cannot be received or reviewed through that address. Troubleshooting delivery issues becomes more difficult. It may create a poorer recipient experience. I would not expect a significant increase in spam classification solely because the mailbox does not exist, but it is generally not considered a best-practice configuration. Scenario 2: noreply@company.com exists as a mailbox This is normally the preferred approach. Benefits include: Reply messages can be received and handled if needed. Bounce messages can be monitored and investigated. The sender identity appears more legitimate. Easier troubleshooting and administration. Future flexibility if the business later decides to process replies. Many organizations create noreply@company.com as a shared mailbox and then: Automatically delete incoming messages Send an auto-reply such as "This mailbox is not monitored" Forward selected messages to support or customer service More important than whether the mailbox exists In practice, deliverability is usually affected much more by: Correct SPF configuration DKIM signing DMARC policy Sender reputation Complaint and bounce rates SuperOffice documentation explicitly highlights SPF validation and DKIM configuration as important requirements for sending from your own domain. [docs.superoffice.com] , [docs.superoffice.com] , [docs.superoffice.com] Recommendation For a SuperOffice Online solution, my recommendation would be: ✅ Create noreply@company.com as a Shared Mailbox in Microsoft 365 ✅ Configure SPF according to SuperOffice recommendations ✅ Enable DKIM for the sending domain ✅ Keep your existing reply template explaining that the address is not monitored ✅ Optionally configure an automatic response or forwarding rule This provides the best balance between deliverability, maintainability, and future flexibility. [docs.superoffice.com] , [docs.superoffice.com] , [docs.superoffice.com] == //Anders

HI Bas, thanks. We have a single Support mailbox to support Emergency Incident with our Support Teams from diff. Regions for all global Customer. Currently integrierted is our Support Teams in HQ Bremen and Singapore, later planned is more Countries/Regions in Far east. I check in Database, the Escalation Level will be reached if alert-timeout is on time, with exception of Weekend and Red days. Maybe I must buld Logic to calculate this with seprated Time frame and red days for our diff. User groups in Scripts.

That's amazing news, thank you, I will let the customer know 😊