Sending bulk email (Faculty/Staff)

Sometimes faculty or staff need to send an email message to a large number of recipients. You can do this with an ad-hoc listserv list, Google group, or using a mail merge program. If you send individual emails to each user, you will be limited to sending a few thousand per hour.

Detailed Information

Internal Services for sending bulk email

Listserv

Ad hoc listserv lists can be created for sending bulk e-mail that is essentially the same to a list of recipients. Such a list can be re-used for many mailings with a new mailing list uploaded via a web page prior to sending. Contact Glenn Eichel through email: glenn.eichel@maine.edu or phone: 207-581-4631 for details.

Google Group

Ad hoc google groups can be created for sending bulk e-mail that is essentially the same to a list of recipients. Such a group can be re-used for many mailings.   For groups, the members can either subscribe themselves or you can cut/paste the member list. There is as yet no upload option. Anyone can create a group with a name ending in "-group", groups with other names require approval and should follow the guidelines at Google Group naming conventions.

Google Groups that need to be renamed (for example, to have the "-group" removed) can be escalated to T3 - Sysadmin.

Use of External Vendors to send bulk email

Organizations within the University system sometimes have outside vendors sending mail on their behalf.   This mail can be marketing, surveys, or applications hosted by a vendor that need to send mail to members of the University community.   Below are some items that may need to be considered when looking at using an external vendor:

White listing

• White listing is frequently requested by vendors as a matter of course, but it is rarely ever needed.   Our email is hosted by Google and any vendor sending email should be able to reliably deliver email to Google.  So far, we have no white-listing in our google domain.
• For mail that passes through our mail relays, the only kinds of white-listing we do are to exempt some mail sources from some types of anti-spam measures.   There is no global white-list. These are things like bulk detection, rate limiting, flow threshold checking, and etc.
• Our stock answer to vendors is.   We do not do preemptive white-listing of any sort.   We do encourage sample email be sent to see if there are any issues and we are happy to take a look at samples to see if we can see any problems.   In the unlikely case of something that can be dealt with only by white-listing, we will consider what might be necessary to mitigate the problem.

Don't have vendors send mail from maine.edu addresses

• We strongly discourage external vendors from trying to send email with a From: address containing an address like userid@maine.edu.  
  •  Increasingly spam filters across the Internet are requiring the use of SPF and DKIM to validate the source of email and any mail source not matching SPF or not signed by DKIM are more and more likely to be blocked or flagged as spam.   
  • Mail that was delivered fine yesterday, may well be blocked or tagged as spam tomorrow.
  • As of March 2019 we are specifying "soft fail" for email sources not listed in our SPF record. This will cause any mail from sources not listed in the SPF record for maine.edu to be flagged as suspicious or spam.
• Current best practices are that vendors should send email from domains they control, for example mainedept.vendor.com or from a sub-domain we provide for the purpose, for example app.campus.maine.edu. This allows separate SPF and/or DKIM records for these domains.

SPF

• SPF (Sender Policy Framework) is an attempt to identify valid sources of email for a given domain in an attempt to reduce the amount of forged email.   Many mail systems require that there be SPF records published in DNS for domains in incoming mail in order to avoid being flagged as spam.
• We cannot offer adding vendor data to our SPF record for maine.edu except under exceptional circumstances.  (We get too many requests and SPF does not scale to large numbers of sources.)
  • A record should not be larger than 450 characters and no more than 10 DNS lookups may be done in processing SPF records. 
  • We can offer to add SPF records for subdomains.
  • NOTE: the use of a subdomain requires prior approval. 
    • If for some reason vendor domains or subdomains cannot be used, we can add a small list of IP addresses. 
    • Additions to this list require review before adding and periodic review to remain in the list.
• Our current SPF record for maine.edu allows only our own mail relays, Gmail, and Brightspace.

DKIM

• DKIM (DomainKeys Identified Mail) is a mechanism for signing email with a digital signature to verify it came from a valid source.    This is not widely required by mail systems yet, and mail can still generally be delivered without it, but this is likely to change in coming years.  Using it can decrease the likelihood of mail being flagged as spam.
• We can add DKIM records on request for maine.edu or for subdomains when they are provided by a vendor.  Note that use of a domain or a subdomain requires prior approval.
• If authenticated SMTP is used with our bulkmail queue (see above), we will DKIM sign mail using @maine.edu addresses.

Use of our mail relays from outside our network

• At this time, we do not permit use of our mail relays from outside the University network except to deliver mail to our own domains or those we provide networking services to.
• We are currently evaluating allowing use of authenticated mail relay for outside mail senders for purposes like this but on a case by case basis.
• Additional Detailed information on Administrative bulk email use/sending can be found here: Detailed information on Administrative bulk email sending

Risk

Anti-spam measures we employ that may affect administrative bulk email

Greet Pause

This inserts a 5 second pause between the time a connection is made to our mail relays and when they respond with the initial greeting.   Some spam sending programs don't wait for the greeting and start sending right away (so-called spam cannons).   When this is happens, our mail servers close the connection avoiding a significant amount of spam.     Most mail servers open a connection and send all the mail they have queued through the single connection so mail is not significantly delayed.   However, we have seen software being used by some departments that opens a new connection for each mail file sent rather than the better practice of opening a single connection.   This can lead to it taking a very long time to send a large batch of email.   If the program cannot be fixed or replaced, the connection rate limit can be overridden by adding the NM tag mail.greetpause to the host entry of the machine used to send the email.  A value of 0 will turn off the greet pause.

Client Connection Rate limit

This limits the number of connections per minute from a given IP address.  This protects our mail servers from being swamped by huge numbers of incoming connections and can slow down the incoming rate of spam emails.   We have exceptions in place for our own mail relays and for those we receive a lot of email from (Google, Microsoft, Qualtrics, and etc.).   Bulk mail programs that open a new connection for each email rather than sending all mail down a single connection may hit this limit.   Some especially poorly written email programs may not be able to handle the return codes from the mail server that say, try again later, and fail.   If these programs cannot be replaced or reconfigured,   the connection rate limit can be overridden by adding the NM tag mail.clientrate to the host sending the email.  The value of the tag is in connections per minute.

Environment

Web-based bulk emailing