Are you in the email jungle? This article describes how to get out of the jungle with an outline of best practices for managing your domain reputation to ensure that your email is considered to be trustworthy, which is essential today where we all rely of this still somewhat backward technology.
How to Emerge Out of the Email Jungle
Managing Domain ReputationDomain reputation, in terms of email, is a measurement of how trustworthy others believe your domain’s email is. Every email recipient maintains their own specific measure of reputation, but there are many industry-accepted recommendations that domain owners can follow to build a solid reputation. As more and more email providers are strengthening their rules for what is considered untrustworthy, failure to follow these recommendations might lead to your mail being considered spam, rate limited, or rejected. The three pillars of any domain reputation strategy are Sender Policy Framework (SPF), Domain Keys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC). These features are designed to provide two basic things:
- A method of verifying that the email comes from a legitimate source specified by the domain owner.
- A way for you, as the domain owner, to tell email providers what to do with messages that do not meet those legitimacy requirements.
- Create an SPF record. SPF is a DNS record that tells the world where your email is authorized to come from. This record typically contains entries for your email hosting provider and any email services you use, such as ticketing systems, Customer Relationship Management systems (CRMs), and bulk sending services.
- Enable DKIM. DKIM applies an encrypted signature that is specific to your domain on every message sent from your domain. Most email service providers offer DKIM as a feature of their service. Typically, each sending service listed in your SPF record has its own DKIM signature that it adds to your email.
- Create a DMARC policy. DMARC is built on SPF and DKIM. It combines the validation results from both SPF and DKIM, and adds a “sender alignment check” to protect against many forms of spoofing. The policy part of DMARC is what allows you, as the domain owner, to specify what to do with email that fails these checks. It also includes a reporting aspect that is critical to long-term management of your domain’s reputation. This reporting gives you visibility into the email being sent as your domain: where it’s coming from (SPF), whether or not it’s properly signed (DKIM), and whether or not it is passing your DMARC policy.
Separate your email needsYou should always separate mail by purpose and class (marketing, sales, transactional, person-to-person, and so on) by using specific subdomains wherever possible. The following table shows different email purposes and their suggested domain naming conventions:
|Ticket system emails||Marketing emails||Newsletter emails|
- Never share DKIM keys between services. Each source should have its own DKIM key. Most services offer this as a feature. If a subdomain has multiple sending sources, then it has multiple SPF includes and DKIM keys. This is perfectly normal.
- Segregating emails enables you to lock down each mail stream, as well as isolate each mail stream from any issues the others might have. This is important when it comes to managing the sending reputation of your different email sources. When it comes to managing your domain’s (and subdomain’s) reputation, different classes of email have different considerations.
- Configure SPF, DKIM, and DMARC for each subdomain.
- Keep your sending sources segregated and manageable for both SPF and DKIM records.
Person-to-person corporate mail is specialFor person-to-person corporate mail, consider the following best practices:
- Reserve your primary domain for only person-to-person email (your employees).
- Don’t use vanity addresses on your primary domain for automated systems, such as [email protected] for your ticketing system.
- Configure an umbrella DMARC policy on the root domain, and create subdomain-specific DMARC policies based on the specific requirements and class of mail it represents.
- For example, you might use
p=quarantineon your primary domain (person-to-person email), but
p=rejecton your outbound-only transactional email (support tickets).
- Taking this step also ensures that the root domain catches all DMARC reporting that might be missed or misconfigured at the subdomain level, as well as catching any unauthorized subdomains attempting to spoof your brand.
- For example, you might use