Why not to use your organisational domain for sending

The decision on if and how to receive a mail and where to place it, is on the receiving side (ISP). This decision is taken automatically by machines, lets call those machines "spam filters" for convenience. Spam filters make decisions not only based on quantity and quality aspects, but also based on historical knowledge, better known as "reputation". Reputation is taken from various aspects of an E-mail. This can vary from a preciously known signed header key to particular, individual and well-known misconfigurations on the sending side. Most commonly used parameters used to gather reputation are IPs and sending domains.

Based on all those metrics, the spam filter attempts to detect the type of E-Mail and match its expectations. For example: If the mail originates from a Gmail domain, known to be used for private purposes, but it contains a company logo or the same content has been sent to multiple recipients, the message may look suspicious. Depending on type and expectation matches, it may or may not weigh more (or less) strict on, for example, specific content features, sender domain authentication or the presence of blocklistings.

For that reason, it's a good idea to adhere to the expectations of the receiving end. Those expectations are usually different per mail type. In fact, some ISPs much appreciate different mail types to be sent via different domains and IPs, so they are able to make the difference.

Scalability

The primary purpose of many businesses is to grow. Scalability is an important aspect in that regard. Using different subdomains for different purposes generally allows to scale better. Using the same domain used for the website also for business E-Mail or commercial E-mail may result in development overhead, workarounds, or - even worse - malfunction. Things that cost money!

Domain delegation

Main article: Domain Delegation

One of the most complicated aspects of sending E-Mail and probably the main reason why companies prefer to outsource E-Mail sending is sender domain authentication with SPF, DKIM and DMARC. Proper authentication is highly recommended for every sender and a must-have to some. ISPs are generally less strict with human-to-human E-Mail and companies with an established reputation (Such as, for example, Microsoft) need to do less efforts in order to deliver their mail.

In order to fully delegate the task of configuring and testing E-Mail authentication to a third party, it is more than just useful to delegate also the authority and control over the domain used. Without control over this domain, parties such as InboxSys can't set DNS resource records on your behalf. Setting DNS resource records is necessary every time, for example, sending IPs or a DKIM key change. Delegating control over a domain can be done in three ways:

1. Sharing login credentials.
2. Domain delegation - by changing NS resource records on a subdomain.
3. Cname - by changing Cname resource records on a subdomain.

Two things to consider here

• As long as no subdomain is used, sharing login credentials is the only option.
• If the same subdomain is used for other E-Mail types or other services, confusion over the authority to edit this particular subdomain is only a matter of time.

Examples

E-Mail sending is a business that only a few companies do by themselves. Most companies outsource E-Mail sending. There are many types of E-Mail and each type of E-Mail has different requirements. There are specialists to be found for each type of sending.

• Consumer E-Mail (ISP). Examples are:
  • Outlook.com
  • Gmail
  • GMX
  • Protonmail (known for added security and privacy features)
• Business E-Mail (ISP). Examples are:
  • Office365
  • Google Suite Gmail
  • Zoho Mail
• Commercial E-Mail (ESP)
  • Transactional E-Mail. Usually sent via the same providers as Bulk Mail, but from a different source. One example of a provider that is specialising further:
    • vutu.re
  • Bulk E-Mail. Some providers are:
    • MAPP
    • Mailgun
    • Inxmail
    • ...and many more.