Many companies run campaigns to raise user awareness around phishing and malware and while these campaigns do raise awareness, they also create user uncertainly about which emails are valid, so system emails need to be designed so users can identify which emails are legitimate. One key factor is the email domain, which users could potentially use to identify which emails are legitimate. So which domain should you use?
When implementing a new system that will send emails, should you use the vendor or company email domain? Often the choice is made to use an email address in the company’s domain. Companies do this because they hope that if the email comes from their email domain users will trust the emails enough to open, read, click on links and respond. The new system will not be successful if users ignore the emails or report them as phishing. Using your company’s email domain could make emails more legitimate to your users, but before you decide to do that, there are a few things you should be aware of.
Disadvantages of using your company domain
- You are trusting an external company with the ability to send emails to anyone inside or outside your company from any address in your domain.
- Once you add entries to your SPF and/or DKIM records they are authorized to send from any address in that domain.
- Setting up a system to send from a new domain takes a lot of work these days.
- SPF and DKIM records must be added, updated and verified
- As part of the intake process, you will now need to assess the security risks posed by the fact the system is authorized to send from your company domain, which adds work to the setup process.
- If you use your company email domain, you are accepting a larger share of the responsibility for the deliverability of the emails.
- SPF record needs updating, that’s you.
- DKIM keys changed, also you.
Some vendors double-down on the concept of sending from customer’s domains by also spoofing the user’s email address, so the email looks like it comes from the user. This is a bad idea which keeps coming back, like bell-bottoms. This design will run afoul of systems designed to detect spoofing and has other technical limitations, so please continue reading for better alternatives.
Send from the vendors’ domain
If you are thinking authorizing vendors to send from your user domain(s) is not such a good idea, what are the alternatives? At DMARC Envoy, we believe in giving the vendor as much responsibility for delivering their system emails as possible. That means vendors should send from their domains, not yours.
SharePoint Online is a good example of how we think system emails should look. SharePoint sends from a Microsoft domain and adds information to the subject and body so the recipient can make the connection between the email they received, the system that sent the email, and the person who took the action, for example sharing a file on a SharePoint site.
You might be thinking, didn’t Microsoft add the ability to SharePoint to send emails from customer domains? Yes, they did. Microsoft is in a special position because Office 365 is already authorized to send from their customer’s domains, and we believe most systems should send from the vendor’s domain.
Send from your company domain
If after reading this you decide using your company domain is the best fit for your new application, there are still ways to reduce security and operations risks.
- If you use Office 365, you can create a service account and allow the account to authenticate to the Office 365 SMTP server, smtp.office.com. You will have to disable MFA and assign a license on the account and the application will still be using your company’s domain, but it can only send from the email address you configure and you don’t have to authorize external servers to send from your domain. (How to set up a multifunction device or application to send email using Microsoft 365 or Office 365: https://docs.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365)
If the application doesn’t support authentication or it’s not a good fit for some other reason, another alternative is to set up an application subdomain. If the company email is @company.com the system sends from @appplication.company.com. You need to add the new subdomain, SPF, DKIM, and DMARC records, but you gain granularity, allowing you to set u the domain specifically for the capabilities and requirements of the system. When the system has been set up in a subdomain it will not be able to impersonate your users (a good thing) and you won’t risk messing up your main SPF record.
System emails are important for the flow of business information and as part of digital business processes. Application emails must be designed so that users can identify the application that sent the email, the purpose of the email, and the person who generated the email so that they will open, read, and respond. Security and maintenance are primary concerns, which can be optimized by using the vendor domain for system emails.