This document is for any department using or intending to use bulk email services from a third party vendor. Those departments’ IT staff should read and follow this document carefully. In addition, third party vendors will find the information in this document useful as well.

If your department has purchased or plans to purchase a bulk email marketing service, or a cloud-based ticketing system, or one or more of any number of services that, somewhere in the product’s operation, generates an email where “.rutgers.edu” appears on the right side of the @ symbol for the “from: address,” you will need to follow the best practices below to improve your email deliveries at Rutgers and externally. Otherwise, your mail may appear fraudulent, and that will make your mail significantly more likely to be classified as spam or phishing and not be delivered to a recipient’s inbox.

It is key to show that the systems sending your emails and the “from: address” is legitimate. To assist with this, the Office of Information Technology Messaging and Collaboration Services (MaCS) will be rolling out Domain-based Message Authentication, Reporting, and Conformance (DMARC). DMARC lets an organization publish its standard for sender authentication. At Rutgers, we intend to require that mail claiming to be from a Rutgers domain will either have to be authenticated by Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), or both.

Recommended best practices:

1. Don’t use a live domain that is used for day to day email. Use a domain dedicated for use with a third party mailer. If your domain for email is normally “department-x.rutgers.edu,” don’t use that but something like “service.department-x.rutgers.edu” instead. We call these utility domains. Rutgers’ day to day business email is provided by Microsoft and Google using massively shared resources. Just like any other cloud-based mail service, there are portions of the service that affect use and is not under the customer’s control. By keeping them separate, it minimizes interference between services and maximizes the ability to be flexible in accommodating the quirks of any given service without negatively impacting other services.
2. Consider using one utility domain per service. If you have a third party ticketing system, a cloud Customer Relationship Management (CRM) system, and a bulk mail marketing service, multiple domains are more robust than trying to force them all in one. Having “ticketing.department-x.rutgers.edu,” “crm.department-x.rutgers.edu,” and “marketing.department-x.rutgers.edu” allows a lot more flexibility in supporting vendor demands for sender authentication and prevents issues arising from conflicting vendor needs. It also allows you to manage reputation more flexibly. By isolating a vendor or service to a single domain, it provides maximal ability to accommodate the vendor’s technical needs while isolating other services from the impacts of those technical needs. It also prevents reputational issues from impacting other services.
3. Set up DKIM with the vendor. This means they need to sign mail as your utility domain, not as themselves. The vendor must support DKIM setup via CNAME selector or using verified unique per account keys in TXT records. In order to implement DMARC at the university, all email representing itself as from a Rutgers domain will need to implement some form of sender authentication. The options are essentially DKIM and SPF at this time. DKIM is the more robust standard for the manner in which Rutgers uses email.
4. Avoid SPF if possible. SPF doesn’t scale well and doesn’t survive forwarding. Because of this, if the vendor requires SPF, items 1 and 2 will become a requirement rather than recommended best practices. SPF has limitations scaling past a certain point of infrastructure complexity and doesn’t survive forwarding at all. These limitations can cause SPF to fail even under legitimate use, which can make your mail look fraudulent. That can cause a worse spam score and generate a reputational issue for your domain.
5. Avoid whitelisting as a part of a delivery strategy. While this is potentially useful for things that solely target internal Rutgers users, it can give a false sense of security of how your mailings will fare in the outside world. If the IP address is shared with other users of the service, it can cause security issues for Rutgers if the vendor is not absolutely preventing any malicious use by customers. There is also a whitelisting limit on the email servers at Rutgers. It is only possible for whitelisting to be deployed to systems and services under university control. If your service will be delivering to external addresses and you use test mailings to gauge the quality of content, you will get a false sense of security from whitelisting. Additionally, it puts our email security at least partially in the hands of external vendors that are not contracted to provide for university email security. Email servers also have limits on the number of whitelisting actions that can be performed. Because of these reasons, whitelisting is rarely used.
6. If the vendor’s service offers a dedicated IP for a reasonable price, consider obtaining one. This will ensure the reputation of other customers does not impact Rutgers’ reputation. Obtaining a dedicated IP insulates your service from certain reputational issues potentially caused by other customers of a vendor. If offered at a reasonable cost, having one maximizes flexibility in supporting your service within the existing and planned email architecture.
7. Don’t send from individuals; send from a limited number of accounts specifically dedicated to mailing from that service. For example, if you have a ticketing system at “ticketing.department-x.rutgers.edu,” you might want all the mail to come from “support@ticketing.deaprtment-x.rutgers.edu.” This will greatly simplify diagnostic efforts and avoids identity issues with changing employee responsibilities or employees leaving the university. This practice makes it easier for us to diagnose issues and support your service with the vendors supplying our day to day business email services.
8. Don’t send from undeliverable addresses unregistered in DNS. If you send from “support@ticketing.department-x.rutgers.edu,” make sure that that address can receive mail even if you never look at it. If your vendor does not provide this service, MaCS can assist you in creating a suitable “from: address.” Sending from non-existent addresses can result in reputational issues that will negatively impact the deliverability of mail from your service. These reputational issues may delay or prevent your mail from being delivered.
9. Where feasible, it is strongly suggested to include the following addresses as recipients for diagnostic and testing purposes: macs_bulk_subscriber@oit.rutgers.edu, macs_bulk_subscriber@scarletmail.rutgers.edu, and macs_bulk_subscriber@rutgers.edu. Adding these addresses will permit MaCS to proactively monitor deliverability, let us respond more rapidly to support issues for your service, and to preemptively test the impact of system changes on your service.
10. Enforce good list hygiene. You will be penalized by large mail systems for repeatedly trying to send mail to nonexistent and undeliverable addresses. Your email lists must be correct. Technology to manage bounces, “unsubscribe” requests, and daily database updates are essential. Good email list hygiene is necessary to keep your list compliant with policy and the law. Email list hygiene refers to keeping accurate email lists and not trying to send email to non-existent email addresses. Continued attempts to send to non-deliverable addresses is generally viewed as malicious probing by spammers or collateral effects of a misconfigured external mail system. The general response to both is to isolate the recipient system from the sending system in short order. Poor list hygiene will cause you specific delivery issue rapidly and larger reputational issues over time as the defensive choices of particular mail systems are aggregated and propagated via various blacklists.
11. Manage your reputation with care. Abide by CAN-SPAM and other applicable laws and regulations, as well as university policy and guidelines. Generally, try to be considerate of your recipient’s time and inbox. Additional information on the CAN-SPAM act and University Policy can be found below. Reputational issues can negatively impact delivery. Additionally, abusive behaviors can have repercussions beyond deliverability. If people don’t get your mail, your mail can’t do the job you intend.
12. Try to ensure your message content and formatting does not appear to be spam. Even if you have fully embraced the recommendations and implemented them well, if your legitimate mailings have content too similar to common spam or phishing emails, they will likely be blocked as spam or quarantined across a broad variety of systems. For example, a press release about a new drug may trigger on the same things that prevent pharmaceutical spam. Additionally, anything involving account maintenance or registration for an event or service need to be approached with great care as these are common vectors for phishing attacks.

Additional information on CAN-SPAM Act:

• CAN-SPAM Act: A Compliance Guide for Business
• CAN-SPAM
• FTC Completes Review of CAN-SPAM Rule

Additional information on related University Policy:

• Rutgers Information Technology – Section 70
  • 70.1.1 Acceptable Use Policy for Information Technology Resources
  • 70.1.6 Email and Calendar Policy

Additional information on related OIT Standards and Guidelines:

• Email and Calendaring Systems: Standards and Guidelines
• Guidelines for Use of Email for Official Purposes