When an Exchange Online user has access to a shared mailbox through full access permissions, he can reply on behalf of that address. The problem is that, by default, emails sent as the shared mailbox are saved in the user’s main mailbox instead of the delegated mailbox. To fix that you have 2 options:

Option 1: Use Exchange Online Powershell

For emails sent as the shared mailbox (Full Access)

Set-Mailbox <shared mailbox> -MessageCopyForSentAsEnabled $true

For emails sent on behalf of the mailbox (Send On Behalf)

Set-Mailbox <shared mailbox> -MessageCopyForSendOnBehalfEnabled $true

Option 2: Registry

HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\Preferences

DWORD DelegateSentItemsStyle 1

Note! Outlook must be configured to run in cached mode, otherwise mails will get stuck in the Outbox.

References:

https://learn.microsoft.com/en-us/exchange/troubleshoot/user-and-shared-mailboxes/sent-mail-is-not-saved

Mailing is daily business in an organization and to increase the trustworthiness of your domain, you should firstly configure a TXT/SPF record and secondly configure DomainKeys, also known as DKIM.

DKIM works by adding a digital signature to the header of an email message that verifies that the message was sent from a trusted source and has not been tampered with during transmission.
When an email is sent using DKIM, the sender’s domain name is included in the digital signature. This allows the receiving email server to verify that the message was sent from an authorized sender and that the message has not been modified in transit. If the digital signature is valid, the email is considered to be legitimate and is delivered to the recipient’s inbox. If the digital signature is invalid, the email is likely to be marked as spam or blocked entirely.

Configuring DKIM if you have Microsoft 365 Exchange Online as a mail system is very straightforward. Just go to https://security.microsoft.com/dkimv2 and enable DKIM on the corresponding domain. Afterwards create the DNS entries as instructed by Microsoft 365.

Usually you’ll have 2 entries, for example:

selector1 and selector2._domainkey.ajni.it CNAME pointing to a Microsoft internal DNS entry.

After creating the DNS entries (like usual you’ll have to wait a bit because of DNS and its slowness), you can verify them in the M365 portal and activate the DKIM signature on all emails (see reference below).

If you have a newsletter solution that does not use Microsoft 365 to send emails, you should check whether they offer DKIM (they should otherwise it’s not a proper newsletter software). Usually you’ll have to configure two CNAME DNS entries on your domain with a selector, similar to Microsoft 365:

k1_domainkey.domain.com and k2_domainkey.domain.com CNAME points to the newsletter solution domain. The TXT record of that DNS record contains the public key. See mailchimp for example:

Looking at the message headers, you can see that domain signature is all right:

ARC-Authentication-Results  i=2; mx.google.com; dkim=pass header.i=@ajni.it header.s=selector1 header.b=TJJLfT54; arc=pass (i=1 spf=pass spfdomain=ajni.it dkim=pass dkdomain=ajni.it dmarc=pass fromdomain=ajni.it); spf=pass (google.com: domain of test@ajni.it designates 2a01:111:f400:7e24::614 as permitted sender) smtp.mailfrom=test@ajni.it

The next step would be to configure a DMARC policy, so that someone trying to impersonate your domain gets rejected and reported to you.

When an email is received, the receiving email server checks the sender’s domain for a DMARC policy, and then follows the instructions specified in that policy to determine whether the email is legitimate or not.

A sample DMARC policy would look like this:

_dmarc.ajni.it TXT
v=DMARC1; p=reject; rua=mailto:dmarcreports@example.com; ruf=mailto:dmarcfailures@example.com; sp=none; aspf=r;

This policy tells email receivers to reject any messages that fail authentication checks (p=reject), and to send aggregate and forensic DMARC reports to the specified email addresses (rua and ruf). The policy also indicates that the domain owner is not enforcing a policy for messages that do not pass SPF checks (sp=none), and that they are requesting SPF-aligned messages to be treated as passing but are not requiring DKIM alignment to pass (aspf=r).

This is just an example and policies may vary depending on the organization’s specific needs and email infrastructure.

References:

https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-authentication-dkim-configure?view=o365-worldwide

Microsoft’s decision to stop supporting Microsoft 365 services on Office 2016/2019 after October 2023 (which is this year) can be viewed as a cynical attempt to encourage users to upgrade to newer versions of Office. This can be seen as a ploy to generate more revenue for the company, rather than a genuine concern for its users.

Furthermore, the frequent updates and changes to Microsoft’s productivity tools can be overwhelming for some users. The constant need to adapt to new features and interfaces can lead to frustration and reduced productivity. Users may feel like they are always playing catch-up and never have the opportunity to fully master their tools before they are outdated.

Moreover, the cost of upgrading to a newer version of Office can be prohibitive for some individuals and businesses. For smaller organizations, the cost of upgrading may be a significant burden. This can create an uneven playing field, where only those with the financial resources to upgrade can fully take advantage of the latest productivity tools.

In conclusion, while the announcement that Microsoft 365 services are supported on “modern” apps may appear positive at first glance, the fact that Office 2019 is considered “old” is a cause for outrage. The frequent updates and changes to Microsoft’s productivity tools can be overwhelming, and the cost of upgrading can be prohibitive for some users. These factors can create an uneven playing field and may cause frustration for end users and solutions providers who cannot keep up with the pace of technological advancements.

My two cents: Microsoft is greedy and wants to maximize profit while showing the middle finger to customers and solution providers.

Sources:

ChatGPT helped me out, just a little bit https://chat.openai.com/chat

One or a few users are not able to connect to their mailbox using the newest Outlook version there is? Well the issue might be TLS 1.2 not being active on the user’s side.

Just set this registry key and you should be good to go:

HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings

or

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings

DWORD SecureProtocols 00000A80

HEX A80 or decimal 2688 enables TLS 1.0, 1.1 and 1.2, while decimal 640 only enables TLS 1.0 and 1.1.

References:

https://www.anoopcnair.com/disable-enable-tls-1-0-1-1-internet-explorer-ie/

In Microsoft 365 / Exchange Online, to connect a soft deleted mailbox, you have need to use the cmdlet New-MailboxRestoreRequest to restore the mailbox to another user.

Get-Mailbox -SoftDeletedMailbox | select guid

Get-Mailbox <NewMailbox> | select guid

New-MailboxRestoreRequest -SourceMailbox <GUID> -TargetMailbox <GUID of new mailbox> -AllowLegacyDNMismatch

To check the status of the restore:

Get-MailboxRestoreRequest | Get-MailboxRestoreStatistics

References:

Reddit