SixXS::Sunset 2017-06-06

FAQ : Account : Email Bounces / Email address requirements

Other FAQ sections

  • FAQ Item
    • Bouncing Email
    • Common Email Configuration/Setup Mistakes
    • SPF, DKIM, DMARC and forwarding email
    • White- and Blacklists

Email Bounces / Email address requirements

We require that users provide a valid and properly configured email address for the purposes of being able to contact the user in case of problems and other details surrounding their account.

We thus expect users to provide an email account that they actually read on a regular basis.

A personal/non-role account is prefered.

SixXS does not send any email newsletters, hence there is no need to setup a specific account for this.

The current policy is codified and the validity of an e-mail address is determined as follows:

  1. It is syntactically correct (ie, it has one @)
  2. If it is in a domain whitelist, it is accepted
  3. If it is in a domain blacklist, it is rejected
  4. The local name (part in front of the @) is less than 64 characters
  5. The local part is not a role account¹
  6. The domain name (part after the @) is less than 255 characters
  7. The local name and domain name is valid (ie does not have two consecutive dots), do not have non ISO characters, and are quoted properly
  8. The domain is configured properly (see below)

For the domain, the NS and MX records are looked up and resolved to their A and AAAA records so that we have a list of addresses. The MX records are then checked in the white- and blacklist again (such that we can accept e-mail domains hosted on well-known clusters. For each of the A (IPv4) addresses, we check a number of policy DNSBLs (such as,, and with the intent to find home-setups, which we do not accept.

Note:In a study performed by SixXS on 32019 e-mail addresses, we found that 11.2% of all addresses (3608) bounced at least once. Of the valid addresses, 9.49% bounced. Of the addresses that our new policy considers invalid, 16.6% bounced. We understand that our policy comes across as harsh, but we assert that it makes a difference to be strict.

Information In general: use your ISP's mail address, or a hosted solution, but don't run a mailserver at home - you may be listed in DNSBLs!

Bouncing Email

We expect that email accounts are reachable. If you are not reachable by email we cannot contact you regarding (mal)function of your tunnel. When we receive a bounce on an email address the account will automatically and directly be set into the disabled state. Connectivity provided to a disabled account will therefor be disabled.

If your e-mail address bounced, and you would like to have your connectivity back, update your handle with a valid email address in the appropriate registry and notify SixXS of the change, we can then reinstate your account.

Messages from your mailhost notifying us that the message we send could not be delivered (for example, greylisting longer than 5hrs) and other automatic replies are also treated as bounces and thus will automatically disable your account.

Common Email Configuration/Setup Mistakes

RFC1912 - Common DNS Operational and Configuration Errors lists a number of common problems, for instance MX DNS records pointing to CNAMEs². Domains that are misconfigured are not accepted.

Make sure that the domain of your email address is RFC compliant and has at least 2 distinctly separate working MX servers or a proven cluster solution. If your DNS contains only one MX record and it has a cluster behind it, direct signups will not be able to detect that, thus contact SixXS in that case. Mail servers on dynamically-assigned IP addresses and/or DSL/cable links are not accepted as they have proven not to be stable enough.

Information Check your domain using for example using ZoneCheck, IIS.SE DNS Check if it looks okay. If you have weird DNS records or had problems in your DNS setup, note well these could get cached in which case you won't be reachable either.

SPF, DKIM, DMARC and forwarding email

SixXS uses SPF, DKIM and DMARC in strict modes. Thus be very mindful when forwarding email as it can cause email to bounce because the address you are forwarding from is not in our SPF records. Also make sure to not break DKIM signed headers.

Forwarding email breaks SPF verification unless you are able to control the receiving end to ignore SPF checks for forwarded messages.

White- and Blacklists

In an attempt to be transparent on the e-mail verification system, here's the currently configured regular expressions for domains and MX hosts from which we automatically reject any e-mail address:

  • @users\.(sf|sourceforge)\.net$
  • @(sf|sourceforge)\.net$
  • @rediffmail\.com$
  • (@|\.)moerstaal\.nl$
  • (@|\.)mail386\.com$
  • (@|\.)(mailhop\.org|(mydyndns|dyndns)\.(com|org))$
  • (@|\.)homeip\.net$
  • (@|\.)afraid\.org$
  • (@|\.)no-ip\.(com|org)$
  • (@|\.)wdyn\.de$
  • (@|\.)ath\.cx$
  • (@|\.)eu\.org$
  • (@|\.)$
  • (@|\.)mailinator\.com$
  • (@|\.)spamgourmet\.com$
  • (@|\.)163\.com$
  • (@|\.)trash-mail\.com$
  • (@|\.)zoneedit\.com$
  • (@|\.)xname\.org$
  • (@|\.)42\.pl$
  • (@|\.)riseup\.net$
  • (@|\.)(gmx|web|yandex|rambler|alice|mail|qq|126|o2|)\.[^\.]+$
  • (@|\.)(protonmail|tuta|tutanota)\.[^\.]+$
  • (@|\.)(hotmail|live|msn|aol)\.[^\.]+$
  • (@|\.)(yahoo)\.[^\.]+$

As we do not want to encourage the usage of any provider we do not publish the whitelist. Of course, the white and blacklists are not final, if we notice that a domain is unacceptable even though it passes the above tests we may still consider rejecting the address.

If you have a properly set up ISP account, or another email account like one from work we prefer that you provide and use that. Setting up throwaway accounts will be noticed and such accounts will be rejected or disabled. To note, we specifically reject mailinator kind of accounts as these accounts are definitely not intended for proper email communication.

If you would like to file a petition to be added (or removed) from our white or blacklist, please contact SixXS and provide proper argumentation.

¹ = A role account is an account that is not associated with a particular person, but with an office, position, or task. Those doing the task use the account only to do the task. They have other accounts for other work.

² = Using a CNAME in your domain breaks your email because sendmail (and possibly other SMTP software) will rewrite the domain portion of the destination email address to that of the label in the CNAME. See also CNAME records in mail by D. J. Bernstein. Note that having a CNAME for example.tld is of course impossible unless you get the tld to have the same record. Having an MX point to a CNAME record causes additional DNS lookups, which might cross a threshold, and thus cause your mail to be dropped. Additionally "Mail loops back to me" errors might be caused by this. Also see RFC1034 - DOMAIN NAMES - CONCEPTS AND FACILITIES for more details. In short: Don't use CNAMEs in relation to SMTP.

Static Sunset Edition of SixXS
©2001-2017 SixXS - IPv6 Deployment & Tunnel Broker