Subscriber Records
- Table of Contents
- Overview
- Fields
- Require Confirmed Opt-In
Overview
Each subscriber in the system has a number of fields.
Fields
Email address
The email address of the subscriber.
An email address can only appear once on a mailing list.
The case of the email address is preserved by the system, but email addresses are always compared in a case-insensitive manner.
Leading and trailing whitespace is stripped whenever you enter an email address.
An email address is a valid local-part
followed by an @
followed by a valid domain name.
A local-part
may only contain the following characters:
- Letters (
a
–z
,A
–Z
) - Numbers (
0
–9
) - Dashes (
-
) - Dots (
.
) - Underscores (
_
) - Plus signs (
+
) - Equal signs (
=
) - Percent signs (
%
) - Forward slashes (
/
) - Colons (
:
) - Semi-colons (
;
) - Question marks (
?
) - Exclamation marks (
!
) - Hash symbols (
#
) - Dollar signs (
$
) - Ampersands (
&
) - Single quotes (
'
) - Asterisks (
*
) - Backticks (
`
) - Curly braces (
{
,}
) - Vertical pipes (
|
) - Tildes (
~
)
Additionally, a local-part
must be between 1
and 256
characters long.
The domain
part may be either:
- An ASCII domain name. Valid characters are: letters (
a
–z
andA
–Z
), numbers (0
–9
), dashes (-
), underscore (_
), and dots (.
) - An Internationalized Domain Name (IDN), specifically the IETF IDNA2008 standard. This supports Unicode/UTF-8 characters. Not all Unicode characters are supported; for example upper case characters are not allowed; see RFC 5892 for more information on supported characters.
Additionally, the domain
part:
- May not contain two consecutive dots, or a dot at the beginning or the end.
- May not contain a dash next to a dot or at the beginning or the end.
- Must be between
1
and256
characters long. - May not have the same form as an IP address. (For example:
me@192.168.0.1
orme@1.1.1.1
are not valid email addresses andme@[162.168.0.1]
is techincally a valid email address but it is not supported by SendSage Studio.)
Details of Internationalized Domain Name implementation
A strange quirk of Internationalized Domain Names is that a domain name containing non-ASCII characters is converted to a domain containing ASCII characters for use in non-unicode aware protocols. For example, test@ëxample.com
converts to test@xn--xample-ova.com
. This is named punycoding. We call test@ëxample.com
the unicode form and test@xn--xample-ova.com
the punycode form. Both forms are the same underlying email address, just different representations of it.
- You can add a subscriber using either the unicode or the punycode form of the email address.
- Whichever form you use to add the subscriber (or subsequently update it) will be returned when viewing the subscriber (through API, export, web-UI, etc).
- Both the unicode and punycode form are considered the same email address, and for mailing lists without an alternate primary key only one can exist in the mailing list at the same time. For example, if you add a subscriber using the unicode form, then later try to add using the punycode form, you will get an error because the subscriber already exists in the mailing list.
- When searching for a subscriber, you can search on either the unicode or the punycode form and regardless of what form was used to create the subscriber it will be found.
- When the email address is sent to, the email is sent using the punycode form:
- The recipient will see the punycode form in the
To
header (if their Mail User Agent does not decode punycoding). - The punycode form will be used for the email address replacement code and MD5 hash of the email address replacement code. (This may change in future versions.)
- The punycode form will be shown in the Engine reports
- The punycode domain will show in the “Domains with the Most Bounces”, “Spam Complaints”, and “SMTP” sections of the campaign and autoresponder statistics pages.
- The punycode form will be provided to any Special Sending Rules. (This may change in future versions.)
- The recipient will see the punycode form in the
There is one caveat: If you provide an email address that is partially punycode and partially unicode. For example, if you create a subscriber using user@點.xn--c1y.com
then when viewing the subscriber the email address will be user@點.看.com
and the email that will be sent to will be the fully punycoded version user@xn--md7a.xn--c1y.com
. The system will consider all three of these addresses identical when querying subscribers. We strongly recommend against using partially punycode and partially unicode email addresses.
Status
This describes the status of a subscriber.
There is one active status:
Status | Meaning |
---|---|
Active |
Subscriber is OK to be sent mail (i.e none of the above conditions apply.) |
There are four inactive statuses:
Status | Meaning |
---|---|
Unsubscribed |
Subscriber requested to stop getting mail, usually through clicking on an unsubscribe link. |
Spam complaint |
Subscriber complained using a spam-complaint mechanism. |
Bounced |
Due to receiving bounces, we determined this subscriber address is no longer valid. |
Deactivated |
Don’t send to this subscriber because they are no longer part of the parent/source list. (See import feature.) |
The inactive statuses have “precedence” in the above order, for example:
- If the subscriber is set to
bounced
but then clicks on an unsubscribe link, their status will be set tounsubscribed
, becauseunsubscribed
is a higher precedence status thanbounced
. - If the subscriber is set to
unsubscribed
but we detect their email address is bad due to bounces, their status will not be changed, because itbounced
is not a higher precedence thanunsubscribed
.
The subscribers on the list which have an inactive status is SendSage’s way of “remembering” these subscribers so that we don’t accidentally send mail to them again.
When importing to a mailing list, the default is to only update subscribers where the status is active
. This keeps you from accidentally re-activating and sending to subscribers that bounced
, unsubscribed
, or generated a spam complaint.
Confirmed
This value only exists if the mailing list is set to have a confirmed
field.
Valid values are: confirmed
/ unconfirmed
.
The default for new subscribers is: confirmed
.
Format
This value only exists if the mailing list is set to have a format
field.
Valid values are: html
/ text
.
The default for new subscribers is: html
.
This can be used to store the preference of how the subscriber would like to receive their email. If you send an campaign that contains both a text and HTML portion to a list with the format field enabled, then
- Subscribers with
format=html
will get multipart messages with HTML and text. - Subscribers with
format=text
will get text-only messages.
Subscribe Time
- This is the time that the subscriber subscribed
- This defaults to the time the subscriber is added. it may be overridden in the UI
Subscribe IP
- The IP address the subscriber was using when they subscribed (if we have this information)
Confirm Time
- This is the time that the subscriber was set to be confirmed
- This will exist if the subscriber is
confirmed
, and will be blank if the subscriber is notconfirmed
Confirm IP
- The subscriber’s IP address when they confirmed by clicking on a confirmation link
Remove time
- This is the time that the subscriber
status
was set to something other thanactive
- This will exist if the subscriber
status
is notactive
, and will be blank if the subscriberstatus
isactive
Remove IP
- This is the subscriber’s IP address when they caused the status to be set to something other than
active
, if we have it. (for example, their IP when clicking on an unsubscribe link.)
Require Confirmed Opt-In
An organization may be configured by the system administrator to require confirmed opt-in. When an organization requires confirmed opt-in, the following is true.
- Subscription Forms must have
Confirmation Required
turned on. - Subscriber Imports are unavailable.
- Subscribers created via the API must be created using a Subscription Form. See the Subscribers API for more information.
- Subscribers may still be added unconfirmed in the SendSage Studio web interface.
To turn this on for an organization, navigate to that organization’s configuration page. Towards the bottom of the page is the Require Confirmed Opt‑In
option.