Ensuring emailing platform
deliverability
Neolane v6.0
This document, and the software it describes, are provided subject to a License Agreement and may not be used or copied outside of the
provisions of the License Agreement. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any
form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the prior written permission of Neolane.
The information contained in this document is provided for informational purposes only and may be revised without notice. It does not
constitute a commitment on the part of Neolane. Neolane does not guarantee the accuracy nor the completeness of the information
contained within this document. References to company names are intended to be ficticious and for illustrative purposes only and do not
refer to any real-world company.
Any brands cited are the property of their respective owners. Windows is the registered trademark of Microsoft Corporation in the United
States and other countries. Java, MySQL and Open Office are trademarks of Oracle Corporation in the United States and in other countries.
Linux is the registered trademark of Linus Torvalds in the United States and in other countries. This product includes software developed
by Apache Software Foundation (http://www.apache.org/).
For any questions or queries, please send a message to the following address: [email protected].
Version number : 6845
Neolane
18 rue Roger Simon Barboux, 94110 Arcueil - France
+33 1 41 98 35 35
www.neolane.com
Table of Contents
Neolane v6.0 - Ensuring emailing platform deliverability
Chapter 1. Introduction to deliverability . . . . . . . . . . . . . . . .
5
Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Recommendations . . . . . . . . . . . . . . . . . . . . . . . . .
Managing deliverability in Neolane . . . . . . . . . . . . . . . . . . .
5
5
6
Chapter 2. Functional recommendations . . . . . . . . . . . . . . . .
7
Opt-out link and form .
Sender address . . .
Duplicates . . . . .
Starting a new platform
White lists . . . . . .
Non commercial white
Commercial whitelists
7
7
8
8
9
9
9
. .
. .
. .
. .
. .
lists
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Chapter 3. Technical recommendations . . . . . . . . . . . . . . . .
11
Reverse DNS . . . . . . . .
SPF . . . . . . . . . . .
Configuration of the application
DNS configuration . . . . .
Feedback loop . . . . . . .
List Unsubscribe . . . . . . .
Presentation . . . . . . .
Installation . . . . . . . .
Precedence tag . . . . . . .
Presentation . . . . . . .
Installation . . . . . . . .
DomainKeys . . . . . . . .
Introduction . . . . . . .
Overview . . . . . . . .
Installation . . . . . . . .
DKIM . . . . . . . . . . .
Verifying SMTP error messages .
MX Rules . . . . . . . . .
Verifying bounce messages . .
IP rotation . . . . . . . . .
11
12
12
12
13
13
13
14
15
15
15
15
15
16
16
19
19
19
19
20
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Neolane v6.0 - Ensuring emailing platform deliverability | 3
Neolane
External hosting . . .
Choice of domains .
Domain delegation .
Choosing sender and
Other aliases . . .
.
.
.
.
.
20
20
20
21
21
Chapter 4. Domain-specific conditions . . . . . . . . . . . . . . . . . . .
23
Objet . . . . . . .
AOL . . . . . . . .
Feedback loop . . .
Whitelisting . . . .
Report Card . . .
MSN Hotmail . . . .
SenderID . . . . .
Feedback loop . . .
Yahoo . . . . . . .
Feedback loop . . .
Whitelisting . . . .
DomainKeys . . .
Gmail . . . . . . .
Mail.ru, inbox.ru . . .
Web.de . . . . . .
Comcast . . . . . .
Outblaze . . . . . .
Usa.net . . . . . .
Excite . . . . . . .
Mailtrust . . . . . .
United Online (NetZero,
RoadRunner . . . .
EarthLink
. . . . .
Cox . . . . . . . .
Bluetie . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
24
24
24
24
24
24
25
26
26
26
27
27
27
27
27
28
28
28
28
28
28
28
29
29
Chapter 5. Blacklisting databases . . . . . . . . . . . . . . . . . . . . .
31
Objet . . .
Spamcop . .
Spamhaus .
RFC Ignorant
SORBS . .
No-more-fun
URIBL . . .
iX Manitu . .
.
.
.
.
.
.
.
.
31
31
32
32
32
32
32
32
Chapter 6. The Deliverability module . . . . . . . . . . . . . . . . . . . .
33
Objet . . . . . .
Technical monitoring
Inbox monitoring . .
Inbox rendering . .
.
.
.
.
33
33
34
34
Chapter 7. SpamAssassin . . . . . . . . . . . . . . . . . . . . . . . . .
37
Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
39
4 | © Neolane 2013
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . .
. . .
. . .
bounce
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
Juno)
. . .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
mail
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . .
. . . . .
. . . . .
addresses
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
CHAPTER 1
Introduction to
deliverability
Table of Contents
Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . .
Managing deliverability in Neolane . . . . . . . . . . . . . . . . . . . . .
5
5
6
Foreword
Deliverability issues generally result from anti-spam measures implemented by internet service
providers and administrators of e-mail servers. Such issues range from IP-address blacklisting,
which can result in reduced throughput, to recipient-side issues (such as the qualification of messages
categorized as spam).
Recommendations
Unsolicited email has certain characteristics that you should avoid as much as possible:
n
n
n
n
n
An incorrect network configuration: Spammers try to conceal their real identity and as a
consequence make their servers difficult to identify. A legitimate network configuration that
does not try to hide the identity of the server is essential to sending email in large volumes.
Sending to invalid addresses: Spammers often use address generators based on lists of
frequent names and first names; In addition, they rarely process technical notifications sent
back by mail servers. A high rate of invalid addresses is often interpreted as a sign of spam.
Double opt-in mechanisms and effective handling of technical bounce messages make it possible
to avoid this.
High complaint rate: ISPs usually have a prominent means of reporting a received message
as spam. This makes it possible to identify unreliable sources. By rapidly honoring opt-out
requests, making regular use of a given list, verifying consent through a double opt-in system,
and implementing feedback loops, you can reduce complaint rates.
Sending to honeypot addresses: ISPs and other organizations (refer to
http:/www.projecthoneypot.org/) make use of mailboxes that do not correspond to physical
persons but are created simply to trick spammers. These so-called "honey pot" addresses are
published on the Web in order to be collected by spambots and thus catch illegitimate senders.
The use of a double opt-in mechanism precludes this sort of address being added to a list. When
using a third-party list, you must be sure of the methods employed by its maintainer.
Aggressive vocabulary and insistent use of images: To a lesser degree, the content of
certain messages can lead certain filters to detect it as spam. The use of certain words, the use
Neolane v6.0 - Ensuring emailing platform deliverability - Introduction to deliverability | 5
Neolane
of exclamation points in the subject line and within the messages are read as telltale signs of spam.
Spammers are also known to replace text with images to stop offending text from being analyzed
automatically by anti-spam filters. In response to this, a message (in HTML format) with a high proportion
of images, or images as attachments, may end up being blocked..
Managing deliverability in Neolane
Neolane includes functionality to manage the risk of non-deliverability and to track messages.
See sections The Deliverability module [page 33] and SpamAssassin [page 37].
6 | © Neolane 2013
CHAPTER 2
Functional
recommendations
Table of Contents
Opt-out link and form .
Sender address . . .
Duplicates . . . . .
Starting a new platform
White lists . . . . .
Non commercial white
Commercial whitelists
. .
. .
. .
. .
. .
lists
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
8
8
9
9
9
Opt-out link and form
By default, when the message is analyzed, a typology rule checks whether an opt-out link has been
included and generates a warning if it is missing. It is possible to change this rule so that an error
is raised rather than a simple warning and stop a delivery from going out without this link.
You must check that the opt-out link works correctly before each time you send: For example, when
sending the proof, make sure the link is valid, that the form is on-line and that validating this
changes the value of the No longer contact this recipient field to Yes. You should make this
check systematically because human error is always possible when entering the link or when changing
the form.
If a problem is detected concerning unsubcription after the delivery is started, it is still possible to
perform an unsubscription manually (using the mass-update function, for example) for those
recipients who click the opt-out link even if they were not able to confirm their choice.
As a general rule, do not try to get in the way of recipients who want to opt-out by requiring them
to fill out fields such as their email address or name, for example. The form should have one
validation button only, and reconciliation should be performed on the encrypted identifier only.
Requesting additional confirmation is not reliable: a user may have two email addresses redirected
to the same box. If the recipient is able to remember the first address only and wishes to unsubscribe
via a message sent to the other one, the form will refuse this because the encrypted identifier and
the email address entered will not match.
Sender address
Certain ISPs check validity of the sender address (From) before accepting messages. A badly formed
address may result in it being rejected by the receiving server. You must make sure a correct
Neolane v6.0 - Ensuring emailing platform deliverability - Functional recommendations | 7
Neolane
address is given at the instance level (menu Tools >Advanced >Deployment wizard...) or in the most
frequently-used scenarios.
Duplicates
Having duplicate email addresses can have multiple consequences:
n
n
The same message being sent more than once. Even if Neolane performs a deduplication procedure by
default before sending, there is nothing to stop the same message being sent by different actions having
the same content when a target is split.
Unsubscription requests not honored. If a recipient unsubscribes after receiving a message, their duplicate
profile will still be eligible for future messages.
Besides this side-stepping of opt-in procedures, this situation will likely lead user to consider the messages
as spam and to trigger a blacklisting procedure at the ISP.
You must be especially prudent when performing operations on the database:
n
n
n
n
Imports must be meticulously configured, in particular when choosing the reconciliation key.
Changed email addresses can also be a source of duplicates. In particular, two addresses with different
domains may be routed to the same mailbox, for example in the case of a company that has changed
name and has maintained the former domain for a certain period of time: [email protected] and
[email protected].
Automatic imports, whether they be of lists or from other database are elements to be taken into account
when managing profiles. What happens when you delete or move a profile in another partition? It might
be recreated in the initial partition by an automatic import, for example, when a purchase order is placed.
The storing of profiles in different folders can be implemented using views rather than partitions. In this
way, you are sure that the profiles are in the same physical partition while still enabling the adequate
rights to be displayed and managed.
There are, all the same, cases in which duplicates between the different partitions is normal. For example,
when sending for third-parties or different company entities, it is logical for the same person to be a recipient
for different reasons. It is, however, rarely normal to find duplicates within the same partition.
Starting a new platform
Starting to send email on a new platform is a sensitive step because the platform does not have any history
of use and no reputation (when the sending IPs have never been used for this purpose). ISPs are naturally
suspicious of IP addresses that have never been used to send email and that suddenly start to send large
volumes of email traffic. In effect, spammers generally use "unknown" IP addresses (that is to say addresses
that have never been blacklisted) to send the largest possible number of messages before detection.
You cannot expect to reach operational speed in terms of output at the very start of the production phase.
Furthermore, you should not attempt to send messages at this rate as it might lead the ISPs to block the
sending addresses and to severely compromise the rest of the start-up phase.
Starting a platform often happens when using a list of addresses for the first time and which may not be
fully qualified. If you send to invalid addresses or to honeypot addresses this will contribute to diminishing
the reputation of the platform. If you have a list of invalid addresses, it is in your best interests to import it
into the quarantines table (Campaign Management/Administration/Non deliverables
Management/Non deliverables and addresses) before sending for the first times. If, all the same, you
wish to requalify the invalid addresses, it is by far preferable to do this once the reputation of the platform
is established and bit by bit in order to "dilute" the use of bad addresses over time.
To summarize the principles to be followed when starting up:
n
n
n
n
If you have this information, importing invalid addresses into the quarantines table,
Limiting the throughput rate (technical setting: limiting the number of mtachilds),
Progressively increasing the volumes sent: Do not target the whole database from the very start, but
rather add an extra fraction of the list each time you send; This should enable you to increase the volume
at each step while reducing the overall rate of invalid addresses
Send regularly: To a certain extent is is better to send small shots regularly than large campaigns
sporadically,
8 | © Neolane 2013
Functional recommendations
n
Paying close attention to the delivery reports: high error indicators can mean a technical setting is badly
configured.
White lists
The main internet service providers (ISPs) and Web mail providers manage whitelists from recognized email
message senders.
Non commercial white lists
To be accepted by these whitelists, the sender must pass a series of tests based on an technical verification
(its email server must not be an open relay and have a static IP) of the infrastructure or its activity (delivery
frequency, volume, number of complaints).
If the sender does not follow one of these rules, it may be deleted from the whitelist. In its Neolane Email
Deliverability package, Neolane offers an accompanying expert consulting service for the certification process
for non commercial whitelists.
Commercial whitelists
Commercial whitelists are based on a system that allows a sender through anti-spam filters or an incoming
bonus in the anti-spam. These paying white lists (CPT or on an annual basis) are offered by systems such
as Return Path Sender Score.
ISPs are free to use these services and the number of ISPs can vary depending on the whitelist. A sender
can therefore better trusted after sending these messages by having a delivery guarantee. Certain whitelists
also offer to open images and activate links.
Appearing in a whitelist is an undeniable asset for any email campaign. In its Neolane Email Deliverability
package, Neolane offers a commercial whitelist certification service such as CSA and Return Path Sender
Score.
Neolane v6.0 - Ensuring emailing platform deliverability - Functional recommendations | 9
Neolane
10 | Neolane v6.0 - Ensuring emailing platform deliverability
CHAPTER 3
Technical recommendations
Table of Contents
Reverse DNS . . . . . . . . . . . . .
SPF . . . . . . . . . . . . . . . .
Configuration of the application . . . . .
DNS configuration . . . . . . . . . .
Feedback loop . . . . . . . . . . . .
List Unsubscribe . . . . . . . . . . .
Presentation . . . . . . . . . . . .
Installation . . . . . . . . . . . .
Precedence tag . . . . . . . . . . . .
Presentation . . . . . . . . . . . .
Installation . . . . . . . . . . . .
DomainKeys . . . . . . . . . . . . .
Introduction . . . . . . . . . . . .
Overview . . . . . . . . . . . . .
Installation . . . . . . . . . . . .
DKIM . . . . . . . . . . . . . . .
Verifying SMTP error messages . . . . . .
MX Rules . . . . . . . . . . . . . .
Verifying bounce messages . . . . . . . .
IP rotation . . . . . . . . . . . . .
External hosting . . . . . . . . . . .
Choice of domains . . . . . . . . . .
Domain delegation . . . . . . . . . .
Choosing sender and bounce mail addresses
Other aliases . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
12
12
12
13
13
13
14
15
15
15
15
15
16
16
19
19
19
19
20
20
20
20
21
21
Reverse DNS
A tool to verify the configuration of a domain: http://www.dnsreport.com/
An important point in the network configuration is making sure a correct reverse DNS is defined
for each of the IP addresses for outgoing messages. This means that for a given IP address, there
is a reverse DNS record (PTR record) with a matching DNS (A record) looping back to the initial IP
address.
The choice of the domain for a reverse DNS has an impact when dealing with certain ISPs. AOL, in
particular, only accepts feedback loops with an address in the same domain as the reverse DNS
(see Feedback loop [page 24]).
Neolane v6.0 - Ensuring emailing platform deliverability - Technical recommendations | 11
Neolane
SPF
Refer to http://www.openspf.org/. A wizard is available to create SPF records.
A tool to verify an SPF record: http://www.kitterman.com/spf/validate.html
The SPF (Sender Policy Framework) is a technique that, to a certain extent, enables you to make sure domain
name used in an email is not forged. When a message from a received from a domain, the DNS server of
the domain is queried. The response is a short record (the SPF record) that details which servers are authorized
to send emails from this domain.
In the final RFC 4408 specification (http://new.openspf.org/svn/project/specs/rfc4408.txt), two elements of
the message are used to determine the domain considered as the sender: The domain specified by the SMTP
"HELO" (or "EHLO") command and the domain specified by the address of the "Return-Path" (or "MAIL
FROM") header, which is also the bounce address. Different considerations make it possible to take into
account one of these values only; we recommend making sure that both sources specify the same domain.
Checking the SPF provides an evaluation of the validity of the sender's domain:
n
n
n
n
n
n
n
None: No evaluation could be performed
Neutral: The domain queried does not enable evaluation
Pass: The domain is considered as authentic
Fail: The domain is forged and the message should be rejected
SoftFail: The domain is probably forged but the message should not be rejected solely on the basis of
this result
TempError: A temporary error stopped evaluation. The message can be rejected on the basis of other
information.
PermError: The SPF records of the domain are invalid
It is worth noting that records made at the level of the DNS servers can take up to 48 hours to be taken into
account. This delay depends on how often the DNS caches of the receiving servers are refreshed.
Configuration of the application
To define the domain used for the HELO command, edit the configuration file of the instance
(conf/config-instance.xml) and define a "localDomain" attribute as follows:
<serverConf>
<shared>
<dnsConfig localDomain="mondomaine.net"/>
</shared>
</serverConf>
The MAIL FROM domain is the domain used in technical bounce messages. This address is defined in the
deployment wizard or via the NmsEmail_DefaultErrorAddr option.
DNS configuration
An SPF record can currently be defined on a DNS server as a TXT type record (code 16) or an SPF type
record (code 99). An SPF record takes the form of a character string. For example:
v=spf1 ip4:12.34.56.78/32 ip4:12.34.56.79/32 ~all
defines the 2 IP addresses 12.34.56.78 and 12.34.56.79 as authorized to send emails for the domain. ~all
means that any other address should be interpreted as a SoftFail.
Recommendations for defining an SPF record:
n
n
Add ~all (SoftFail) or -all (Fail) at the end to reject all servers other than those defined. Without this,
servers will be able to forge this domain (with a Neutral evaluation).
Do not add ptr (openspf.org recommends against this as costly and unreliable).
12 | © Neolane 2013
Technical recommendations
Feedback loop
A feedback look works by declaring at the ISP level a given email address for a range of IP addresses used
for sending messages. The ISP will send to this mailbox, in a similar way as what is done for bounce messages,
those messages that are reported by recipients as spam. The platform should be configured to block future
deliveries to users who have complained. It is important to no longer contact them even if they did not use
the proper opt-out link. It is on the basis of these complaints that an ISP will blacklist an IP address. Depending
on the ISP, a complaint rate of around 0.3% will result in the blacklisting of an IP address.
A standard is currently being drawn up to define the format of feedback loop messages: the Abuse Feedback
Reporting Format (ARF). See http://www.mipassoc.org/arf/ for further details.
Implementing a feedback loop for an instance requires:
n
n
A mailbox dedicated to the instance, which may be the bounce mailbox,
IP sending addresses dedicated to the instance.
Implementing a simple feedback loop in Neolane uses the bounce message functionality. The feedback loop
mailbox is used as a bounce mailbox and a rule is defined to detect these messages. The email addresses
of the recipients who reported the message as spam will be added to the quarantine list.
n
n
Create or modify a bounce mail rule, Feedback_loop, in Administration>Campaign
Management>Non deliverables Management>Mail rule sets with the reason Refused and the
type Hard.
If a mailbox has been defined specially for the feedback loop, define the parameters to access it by
creating a new external Bounce Mails account in Administration>Platform>External accounts.
The mechanism is operational immediately to process complaint notifications. To make sure this rule is
working correctly, you can temporarily deactivate the accounts so that they do not collect these messages
and then check the contents of the feedback loop mailbox manually. On the server, execute the following
commands:
nlserver stop inMail@instance
nlserver inMail -instance:instance -verbose
If you are forced to used one single feedback loop address for multiple instances, you must:
n
n
n
Replicate the messages received on as many mailboxes as there are instances,
Have each mailbox picked up by one single instance,
Configure the instance so that they process only those messages that concern them: the instance
information is included in the Message-ID header of messages sent by Neolane and is therefore located
also in the feedback loop messages. Simply, specify the checkInstanceName parameter in the instance
configuration file (by default, the instance is not verified and this may lead certain address to be
quarantined incorrectly):
<serverConf>
<inMail checkInstanceName="true"/>
</serverConf>
List Unsubscribe
Presentation
This technique involves adding a header to your emails with the following format:
List-Unsubscribe :<http://domain.com/unsubscribe.jsp?id=encryptedid>
Neolane v6.0 - Ensuring emailing platform deliverability - Technical recommendations | 13
Neolane
MSN Live and Gmail support this method and an unsubscribe button is available directly in their interface.
This technique lowers complaint rates.
Installation
Neolane enables you to add additional SMTP headers via the delivery wizard. Specify one of the following
list-unsubscribe parameters:
1 List-Unsubscribe: <mailto:[email protected]>
2
Clicking the unsubscribe link opens the user's default email client.
List-Unsubscribe: <http://domain.com/unsubscribe.jsp>
Clicking the unsubscribe link redirects the user to your unsubscription form.
Example:
14 | © Neolane 2013
Technical recommendations
Precedence tag
Presentation
Some ISPs ask for mass senders to add a tag to their header which allows them to be identified. A good
example is Gmail where this tag is a pre-requisite.
Installation
Neolane lets you add additional SMTP headers using the delivery properties, like the 'list unsubscribe' tag.
This type of SMTP addition can also be added to certain domains only.
For example, to only include this SMTP header in Gmail, the function is as follows:
<%
if (recipient.domain == 'gmail.com')
{
%>
Precedence: bulk
<%
}
%>
DomainKeys
This technology, mainly sponsored by Yahoo, can be implemented in Neolane.
Introduction
DomainKeys is a specification using public key technology to digitally sign an email to prove the origin of the
message.
Neolane v6.0 - Ensuring emailing platform deliverability - Technical recommendations | 15
Neolane
Note:
The approving domains currently Domainkeys are: Yahoo, Gmail.
Overview
Private and public key
The domain owner generates a pair of keys (public/private) that will be used to sign the messages sent by
the users of this domain. The public key is placed in the DNS of the domain as a TXT type record. The private
key is kept on the messaging server that sends emails for this domain.
When an email is sent by the user of the domain, the messaging server uses the private key to sign the
message. The signature is added to the message header before it is sent.
When a signed message is received, the messaging server reads the signature and message domain then
queries the DNS in order to obtain the public key of the domain. With this public key, the messaging server
then checks whether the signature of the message is valid.
Selectors
Selectors enables a domain to have multiple public keys in the DNS. The administrator can then choose a
given key depending on the type of traffic. If the selector is 'test' and the domain is 'example.com', the public
key will be available from the test._domainkey.example.com TXT-type DNS record. The name preceding
_domainkey is the selector.
Neolane uses default as the default selector.
Installation
This section describes the required configuration in Neolane to enable DomainKeys.
Prerequisites
You must be able to update the DNS records for your domain.
Generating the keys
From a command prompt, use the following syntax:
$ openssl genrsa -out rsa.private 1024
The result is an rsa.private file such as:
-----BEGIN RSA PRIVATE KEY----MIICXQIBAAKBgQCUBBPm/6CGCw3Imbgka0GWIp95KTlE645kZVLp3MWLMox4bQUu
2Jks9+3eg/qk5ITFmxH//LB6efRgroW005En7u18nZ4FPWj0rKUuGYQTbMLq7+sB
KmSZNiVFcuGCl3O8oA7EPPuf0oK9B84FAwp94cBw5qzSdkvd5bMMCwkfVQIDAQAB
AoGAWgo8/SmFweTZhq0UGntwk18Oecr8/pL4tNP6Yy8csHeYge132K6ER5muhszs
XQByUC7r/Tf/NxIW+fVQeta0lpRki+SBvQOJyzTfXYf1S9XyyIgbPmVz8sQK2nWr
KdzUeM1ueSuL82dPJXvkXaXirpm0rSHSYu0D7878/CGzxaUCQQDFUAXsIq3u+iwl
27kkMPKqAb96fUxmF14huxmoB6oMbblFwAT94IxfoXOR5lwEoHZvklcnfk0wiIyk
vUv+Fj1/AkEAwAp1NARz6wtYChft+ruMAI5cZyfC9BmaCesTkvmLb3411ooql5QP
m2vAeuUw3I8GmjI3uzdnJ18gTeTV6S61KwJBALLZEkU0Ogx/3zyBqZPQemT3KKTS
pklzrPNOMLdKGy0g1+sNXnjw7MxR//ujnozjFfeT4kP+C+GOJE2+9/7cEekCQGrb
ptnZ/HJ2bne3VwmkoEOS86HGwzk2obsRHmQzDT5t2SFW4lpT3ddavtDjhSvFPiRA
+zfmnTSQPxZ41fqZrd8CQQDCcnFVQUMtMasfV5hGQjOPLoX8a6ivFNmSk7P0gPVt
2iwz49E+Os0q5AhghyOmxsmwLjUOmptLBrWMR/gt2w7Q
-----END RSA PRIVATE KEY-----
16 | © Neolane 2013
Technical recommendations
Note:
Neolane supports 512, 768, 1024, 1536 and 2048-bit keys. To date, a minimum length key is not a prerequisite,
however, it is generally accepted that a 512-bit key can potentially by falsified. The length of the key can
have an impact on throughput (if CPU is a limiting factor):
n
n
n
n
n
512 bit: - 19 % compared to sending unsigned
768 bit: - 37 %
1024 bit: -60 %
1536 bit: -80 %
2048 bit: - 90 %
To extract the public key from the private key, use the following command:
$ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM
The result is an rsa.public file such as:
-----BEGIN PUBLIC KEY----MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCUBBPm/6CGCw3Imbgka0GWIp95
KTlE645kZVLp3MWLMox4bQUu2Jks9+3eg/qk5ITFmxH//LB6efRgroW005En7u18
nZ4FPWj0rKUuGYQTbMLq7+sBKmSZNiVFcuGCl3O8oA7EPPuf0oK9B84FAwp94cBw
5qzSdkvd5bMMCwkfVQIDAQAB
-----END PUBLIC KEY-----
In Window, you must download the OpenSSL library from the following URL:
http://www.openssl.org/related/binaries.html
Saving the public key in the DNS
Creating a TXT-type DNS record for selector._domainkey.example.com :
n
Syntax for BIND
default._domainkey.example.com. IN TXT "k=rsa; t=y;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCUBBPm
/6CGCw3Imbgka0GWIp95KTlE645kZVLp3MWLMox4bQUu2Jks9+3eg
/qk5ITFmxH/
/LB6efRgroW005En7u18nZ4FPWj0rKUuGYQTbMLq7
+sBKmSZNiVFcuGCl3O8oA7EPPuf0oK9B84FAwp94cBw5qzSdkvd5bMMCwkfVQIDAQAB"
n
Syntax for DJBDNS (TINYDNS)
'default._domainkey. example.com:k=rsa;t=y;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCUBBPm
/6CGCw3Imbgka0GWIp95KTlE645kZVLp3MWLMox4bQUu2Jks9+3eg
/qk5ITFmxH/
/LB6efRgroW005En7u18nZ4FPWj0rKUuGYQTbMLq7
+sBKmSZNiVFcuGCl3O8oA7EPPuf0oK9B84FAwp94cBw5qzSdkvd5bMMCwkfVQIDAQAB;:86400
The parameters of the record are defined with the syntax parameter=value.
The valid parameters are:
n
g= defines the applicability of the key in relation to the local name of the sender.
g=*: enables all senders in the domain example.com to use the key,
n
n
n
n
g=sender;: enables this key to used for messages sent from [email protected].
k = key type. Only the value rsa is supported. This parameter is optional.
n = note concerning the key. This note is intended for administrators and is not used by the signature
and authentication processes. This parameter is optional.
p = public key encoded in Base64. An empty value means that the key has been revoked. This parameter
is mandatory.
t = flags defining attributes. One single attribute is currently defined by the specification: t=y means
that the domain is using this key in test phase.
The public key encoded in Base64 corresponds to the contents of the rsa.public file between the lines:
----- BEGIN PUBLIC KEY----- and -----END PUBLIC KEY-----
.
Neolane v6.0 - Ensuring emailing platform deliverability - Technical recommendations | 17
Neolane
You must also delete the spaces and the carriage returns.
Saving the private key in Neolane
The private key is saved in the form of an option in the Neolane database. Connect to Neolane as the
Administrator and then create an option:
Internal name:
selector_RSA_PRIVATE_KEY_domain
Type:
Long text
Value:
The private key encoded in Base64.
In the internal name of the option, the selector part is optional . As the default selector in Neolane is default,
the default_RSA_PRIVATE_KEY_example.com and RSA_PRIVATE_KEY_example.com options are
equivalent.
Important:
For the domain value, the period is changed by Neolane to the underscore character "_".
The private key populated in the option must be the exact contents of the rsa.private, including
----- BEGIN PRIVATE KEY----- and -----END PRIVATE KEY-----
.
Enabling handling of DomainKeys
To enable the signing of messages for a domain, go to the Administration / Campaign management
/ Non deliverables Management / Mail rule sets folder and then select Domain management from
the list. If the domain is already in the list, simply select the DomainKeys database, else create a new rule
for this domain and then select the DomainKeys option.
Important:
Enabling senderId on the domain forces the technical domain to be used to sign the message. Enabling
senderId with DomainKeys may be useful when managing multiple sender domains.
Testing the configuration
The easiest is to create a test mailbox on yahoo.com. If DomainKeys is correctly configured, you should
receive a message from Yahoo! using the address of the sender confirming the origin of the message.
Further information is given in the full headers:
18 | © Neolane 2013
Technical recommendations
DKIM
DKIM results from a combination of the DomainKeys, Yahoo! and Cisco Identified Internet Mail authentication
principles and is used to check the authenticity of the sender domain and guarantee the integrity of the
message.
DKIM is an improvement on DomainKeys, and will supersede it in the future.
Note:
n
n
n
n
Functionality available from build 1937 onwards.
If you have configured DomainKeys for your Neolane instance, you just need to select dkim in the domain
handling rules. If not, follow the same steps (private/public key) as for DomainKeys.
It is not necessary to enable both DomainKeys and DKIM for the same domain as DKIM is an improved
version of DomainKeys.
The following domains currently validate DKIM: aol, gmail.
Verifying SMTP error messages
The SMTP errors that are not checked by a given rule are listed in the Administration/Campaign
Management/Non deliverables Rules/Non deliverables Rules folder. These error messages are by
default interpreted as unreachable soft errors. The most common errors must be identified and a corresponding
rule added in Administration/Campaign Management/Non deliverables Rules/Mail rule setsl if
you wish to correctly qualify the feedback from the SMTP servers. Without this, the platform will perform
unnecessary retries (case of unknown users) or to wrongly place certain recipients in quarantine after a given
number of tests.
Neolane recovers the new SMTP error rules, generated when sending emails to every single client, using its
Deliverability platform. The total number of errors generated from these new rules is accumulated and allows
Neolane to qualify these new rules when it reaches a critical number of errors.
These rules are updated daily via a specific workflow. For this, you must open a https type flow. Another
important point: the client can qualify a rule in his instance. However, if this is then qualified in a Neolane
deliverability instance, it is the deliverability instance qualification that will be taken into account by default.
MX Rules
MX rules (Mail eXchanger) corresponds to the communication management rules between a sending server
and a receiving server.
Depending on the material capacities and the internal policy, an ISP will accept a predefined number of
connections and messages per hour. This variables may be modified automatically by the ISP system depending
on the reputation of the IP and sending domain. Via its deliverability platform, Neolane manages more than
150 specific rules by the ISP, and, in addition, one generic rule for other domains.
This rules are updates via a daily workflow in order to regulalry supply the client instance.
Note:
For more information, refer to the MX rules & Bounces.
Verifying bounce messages
As for the SMTP errors, unprocessed bounce mail or bounce mail processed by Ignored type rules must be
monitored to determine whether new rules should be added. For this, it is possible to specify an address the
platform will forward these messages to.
Neolane v6.0 - Ensuring emailing platform deliverability - Technical recommendations | 19
Neolane
IP rotation
In particular when starting up a new platform, we recommend implementing a system of rotating the IP
addresses used at the hardware level. This consists of keeping a certain number of IP address as backup
addresses if the IP addresses being used are blacklisted by an ISP. You can start reusing the IP addresses
you have let 'lie fallow' once the restriction is raised, in generally after a few hours or at worst a few days.
You must, however, make sure each IP is used regularly (at least 100 messages over a day per month) so
that it does not lose its reputation or get removed from the feedback loops or whitelists. When the reputation
of the platform is firmly established, you may consider using all the IPs permanently.
External hosting
When discussing sending emails, we shall refer to external hosting when the Neolane platform is:
n
n
Entirely hosted externally (database, tracking servers and MTA servers),
In mid-sourcing mode: the database and application server are located within the local network whereas
the MTA portion is externalized.
Choice of domains
External hosting, for technical reasons, implies almost systematically that the domain used in the technical
sending addresses and the tracked links is different from the main address of the sender. For example:
n
n
n
The advertiser uses the domain domain.com in all communications
The hoster cannot technically use this domain to receive bounce messages because domain.com is the
corporate messaging domain and is not intended for such purposes.
The hoster can technically use domain.com for tracking because it is used by the Web site of the
advertiser.
The hoster must therefore use a different domain that we will refer to as a technical domain, for example
dmnl.net. This domain will be used to receive bounce mail and redirect tracked links. With this said, we
will make two points:
1 The sender address (From), which is the most commonly displayed address, can always be given as the
address of the advertiser domain.com
2 The tracked links within the message will use the technical domain dmnl.net
To date, this way of operating is permitted, however:
n
n
n
If we consider Hotmail, using SenderId will display the sender as From: [email protected] on
behalf of Marketing Domain ([email protected]), which may confuse the recipient as
to the origin of the message.
If the message is supposed to be sent by an advertiser recognized by the domain domaine.com, then
an email containing links using the domain dmnl.net could be considered as an attempt at phishing.
In extreme cases, certain anti-spam filters may reject the message as suspicious based on the difference
between the bounce domain and the sender domain.
It is therefore increasingly important that there is no doubt as to the authenticity of the sender based on the
technical sending domain. For this reason, we recommend using a technical sending address that is a
sub-domain of the advertiser's domain. In the previous example, we could use nl.domain.com, and in this
way a recipient would have no doubt that the technical sender of the message and the tracked links really
do come from domain.com. The bounce address as nl.domain.com can be managed directly by the
hoster and the tracking links nl.domain.com can point to their redirection servers.
Domain delegation
If a sub-domain needs to be set up by the hoster it must be initiated by the domain owner (the advertiser).
It is technically possible for the owner to perform the DNS configuration (MX, A, SPF...) of the sub-domain,
however we advise against this because the hoster depends on it for any modification made to the DNS and
this is a potentially dangerous situation (risk of losing bounce mail, or failure of tracking mechanisms) given
the constraints of running an email platform. Neolane strongly recommends delegating the sub-domain to
the hoster.
20 | © Neolane 2013
Technical recommendations
To delegate the administration of a sub-domain to a third party, the owner of the main domain must declare
NS records for the sub-domain designating the DNS servers of the hoster.
Note:
For more information about domain delegation, refer to the Domain delegation document.
Choosing sender and bounce mail addresses
Because the sender address is the most visible address to the recipient, there should be no doubt as to its
identity and should be defined using the domain of the advertiser or at least a sub-domain, for example
[email protected] or [email protected].
If the SPF record of the advertiser's domain authorizes the IP addresses used by the platform, it is not
necessary to enable the Sender ID parameter in Neolane for MSN Hotmail domains and the choice of the
address for bounce messages is not restricted.
If the SPF record of the advertiser's domain does not authorize the IP addresses used by the platform, the
Sender ID parameter will have to be used for MSN Hotmail. In this case, the bounce address is given to
the recipient in the message header. You must choose an address that does not suggest spam, meaning an
address that refers to the sender and does not appear to be too technical, for example
[email protected] rather than [email protected].
Other aliases
Neolane enables you to define different aliases for tracking, mirror pages and web forms and thus define an
architecture that is appropriate for the availability and production constraints you have. To maintain consistency
between these domains, you can, for example, define extra sub-domains as shown below:
n
n
n
Tracking: nl.domain.com
Mirror pages: m.nl.domain.com
Web forms: f.nl.domain.com
Neolane v6.0 - Ensuring emailing platform deliverability - Technical recommendations | 21
Neolane
22 | Neolane v6.0 - Ensuring emailing platform deliverability
CHAPTER 4
Domain-specific conditions
Table of Contents
Objet . . . . . .
AOL . . . . . . .
Feedback loop . .
Whitelisting . . .
Report Card . . .
MSN Hotmail . . . .
SenderID . . . .
Feedback loop . .
Yahoo . . . . . .
Feedback loop . .
Whitelisting . . .
DomainKeys . . .
Gmail . . . . . .
Mail.ru, inbox.ru . .
Web.de . . . . .
Comcast . . . . .
Outblaze . . . . .
Usa.net . . . . .
Excite . . . . . .
Mailtrust . . . . .
United Online (NetZero,
RoadRunner . . . .
EarthLink . . . . .
Cox . . . . . . .
Bluetie . . . . . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
Juno)
. . .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
24
24
24
24
24
24
25
26
26
26
27
27
27
27
27
28
28
28
28
28
28
28
29
29
Objet
This section describes the specific mechanisms of a representative selection of ISPs in the B2C
arena.
Reading the message headers received by the ISPs is often a good indication of how the messages
are considered in relation to spam. Email software and Webmail services general enable you to
display the message headers in full (usually, by default, on the sender, date, subject and recipient
are shown).
Neolane v6.0 - Ensuring emailing platform deliverability - Domain-specific conditions | 23
Neolane
AOL
AOL provides high-volume senders with feedback loop and whitelisting services. Whitelisting enables messages
from certain IP addresses to be delivered without filtering. It is essential to implement a feedback loop before
requesting whitelisting because whitelisting will only be accepted if there is low complaint rate for the sending
IP addresses, which is unlikely if the feedback loop is not implemented. You must then wait for at least 30
days before requesting whitelisting.
Feedback loop
The following form enables you to request a feedback loop: http://postmaster.aol.com/fbl/. Once validated,
you will receive an email with a confirmation link at the feedback address. You must make sure, before
validating this form, that the mailbox is working and that you can collect its contents. After validating the
link, the service is usually implemented within 24 hours.
The rule for bounce notifications from AOL is already implemented in Neolane
Whitelisting
Whitelisting requests can be made from http://postmaster.aol.com/whitelist/index.html. On request, AOL
will monitor outgoing emails and complaint rates over a period of 3 weeks. After such time, a decision is
made and notification sent to the contact address specified in the form.
Important:
The whitelisting form goes hand in hand with a feedback loop request. If both whitelisting and feedback loop
requests are made, the feedback loop messages will be sent twice.
Report Card
On days when the complaint rate exceeds 0.1%, AOL automatically sends a Report Card to the postmaster
address of the domain mentioning the complaint rate and necessity of maintaining a low rate. These messages
are sent from [email protected] with a subject such as AOL email concerns for yourdomain.com.
This indicator enables you to evaluate the correct functioning of the feedback loop and the opt-in mechanisms.
MSN Hotmail
Refer to http://postmaster.msn.com/. The site has a form to contact technical support.
Consult the complaint rates for IP addresses: http://postmaster.msn.com/snds/. Using this service enables
you to monitor, on a daily basis and for each IP address, the complaint rates and the number of messages
received by honeypot addresses. To use this service, you must be able to receive messages sent to one of
the following email addresses whose domain name is deduced by reverse DNS and the RIPE database using
the requested IP addresses:
n
n
abuse@domain
postmaster@domain
A message with the confirmation data will be sent to the one of these addresses.
If you contact MSN Hotmail support, you will learn that spam filtering is operated by two different entities.
Emails received are first processed by Symantec (contact Symantec Brightmail,
<[email protected]> for any queries due to filtering at their level) who filters
messages based on complaint rates and the number of messages received at honeypot addresses. Secondly,
MSN Hotmail processes those messages that have been let through by Symantec. At this level, they are not
aware of the reasons for which messages are blocked at the Symantec level.
SenderID
MSN Hotmail is implementing an email authentication technology called SenderID. It is essentially a variant
of the SPF recommendations.
24 | © Neolane 2013
Domain-specific conditions
The DNS configuration required for SenderID is more stringent than that required by SPF. In particular, 3
records SPF, MX and A are checked for the sending domain. The Microsoft wizard
http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/default.aspx enables you
to verify the DNS configuration of a domain and offers help in defining the SPF record.
Certain headers are interesting from this point of view:
X-SID-PRA: Marketing Domain <[email protected]>
X-SID-Result: TempError
From: Marketing Domain <[email protected]>
Return-Path: [email protected]
The X-SID-PRA header is the address of the purported responsible sender (for more information on the PRA,
refer to http://www.microsoft.com/mscorp/safety/technologies/senderid/resources.mspx), calculated from
other lines in the header as the address most representative of the identity of the sender. It is the domains
in this address and the Return-Path address that are used as the reference for checking the SPF records. If
there are specific constraints for the domains used, using a proprietary extension of the SenderID technology
it is possible to configure the SPF records so that they only apply to the Return-Path or the PRA.
Note:
n
If the sender address (From) does not match the PRA, Microsoft recommends displaying both addresses
explicitly in the email client, which has the effect of showing the bounce address to the final recipient.
Thus, in Hotmail, is sender is shown as follows:
From: [email protected] with the name Marketing Domain ([email protected])
n
In order to make sure the bounce address does not appear in the message header, you must apply the
following recommendations:
1 Disable SenderID in Neolane.
2 Make sure there is a valid SPF for each of the sending domains
3 Make sure there is a valid public domainKey for each of the sending domains.
The X-SID-Result header gives the SenderID evaluation of the message upon receipt. The values used are
the same as defined in the SPF.
If the sending and the DNS records are correct and a TempError is evaluated, it may be a problem of an
obsolete DNS cache. MSN Hotmail uses a cache mechanism for SenderID. To make sure the record is in the
cache, simply fill in the online form at the following address:
https://support.msn.com/eform.aspx?productKey=senderid&page=support_senderid_options_form_byemail&ct=eformts
Note:
When senderId is selected in Neolane, a Sender header with the bounce mail address is added to the
messages. Thus the PRA value matches the bounce mail address.
Feedback loop
Below is a questionnaire for companies/clients interested in this program:
1 Your company name, the primary contact and a contact e-mail
2 Does your company follow standard CAN-SPAM Act practices?
3 The opt-out link for each list.
Please include a functional link that we can use for a one time test. If you require users to have an
account, please provide an account that we can access and close for the purpose of testing.
The home page where people sign up for each list.
4
5 Sender IPs for verification.
6 Is the IP address registered under your company's name/domain name? Or do you have exclusive sending
7
rights from the IP via your hosting company (not shared with any other senders)? Please provide supporting
documentation.
Can you remove recipients that complain from these lists?
Neolane v6.0 - Ensuring emailing platform deliverability - Domain-specific conditions | 25
Neolane
If the answers to items 6 and 7 are "no", Microsoft will be unable to enroll your company at this time.
The answers to questions 6 and 7 must be yes in order to use a feedback loop. With Neolane, answer to
question 7 is yes.
You can request a feedback loop by filling in the following form:
http://postmaster.live.com/Services.aspx#JMRPP
The service will return a so-called Junk E-Mail Reporting Agreement, which you must complete and sign
digitally.
At the same time, you must send the technical details of the feedback loop required by email:
1
2
3
4
5
6
7
8
Name of the principal company contact,
Address,
Telephone number,
Email address,
The IP addresses used (a maximum of 150, separated with semi-colons),
The email address of the feedback loop,
The maximum number of emails to send per day using the feedback loop (optionally no limit),
The message format: Attached according to RFC 822 or the original messages.
For question number 8, you must choose format RFC 822. The bounce mail rule for Hotmail is already
implemented in Neolane.
Yahoo
Refer to http://help.yahoo.com/help/us/mail/defer/
Two items from the header are used to qualify the sending platform:
X-YahooFilteredBulk: 12.34.56.78
Authentication-Results: mta244.mail.mud.yahoo.com
from=domain.com; domainkeys=neutral (no sig)
An X-YahooFilteredBulk header means that the message was directed to the user's spam folder.
The Authentication-Results header gives the evaluation of the sender using the Domain Keys technology.
In the example, domainkeys=neutral (no sig) means that the sending platform has not implemented
this technology.
Feedback loop
The following form enables you to request a feedback loop: http://feedbackloop.yahoo.net.
Note:
1 The Yahoo feedback loop (FBL) is based on the domain, as opposed to other FBL that are based on the
2
IP.
In order to implement a feedback loop, you must:
n
n
have a Yahoo FBL account,
use the DomainKeys or DKIM authentication standard.
Whitelisting
Without a prior request, Yahoo will consider messages sent from an unknown IP address as spam and users
will receive these messages in the correspond folder of their webmail. A whitelisting request can be made
using the form at http://help.yahoo.com/l/us/yahoo/mail/postmaster/forms_index.html.
26 | © Neolane 2013
Domain-specific conditions
Important:
When you request whitelisting from Yahoo, it is very important to correctly understand and scrupulously
respond to all the questions. If you do not do this, Yahoo will probably reject your request and at the same
time recommend that you review your practices before making a new request in 6 months time.
Yahoo will then monitor messages sent over a period of several days. During this time, emails will be received
in either the inbox or the spam folder. Yahoo will make a decision to whitelist the platform based on this.
This period usually lasts about 3 weeks.
DomainKeys
When the domain validated by DomainKeys is identical to the sender domain, Yahoo displays a key to tell
the user that the sender is legitimate and tested by DomainKeys.
Gmail
Gmail uses SPF and DKIM. Using a Gmail account is also a good way of checking the SPF is configured
correctly. If the SPF is configured correctly, messages received will include the following in the header:
Received-SPF: pass (gmail.com: domain of [email protected] designates
123.45.67.89 as permitted sender)
Received-SPF: pass (gmail.com: best guess record for domain of [email protected]
designates 234.56.78.90 as permitted sender)
When the SPF is not defined for the domain, this line will look like the following:
Received-SPF: neutral (gmail.com: 34.56.78.90 is neither permitted nor denied by domain
of [email protected])
Finally, when the sender address is forged, the header contains the following line:
Received-SPF: softfail (gmail.com: domain of transitioning [email protected] does not
designate 98.76.54.32 as permitted sender)
Gmail also checks the DomainKeys signatures.
Mail.ru, inbox.ru
Refer to http://win.mail.ru/cgi-bin/support_bl?ip=ip1.ip2.ip3.ip4
Web.de
It is possible to contact technical support via the on-line forms available at the following address:
https://www2.kundenservice.web.de/Angebote/FreeMail/Klassen/Abuse/
Comcast
You can request a feedback loop using the following form: http://feedback.comcast.net/
Neolane v6.0 - Ensuring emailing platform deliverability - Domain-specific conditions | 27
Neolane
Outblaze
Write to the following address to request a feedback loop: [email protected].
You must communicate the following information:
n
n
n
n
The
The
The
The
IP list or range in question.
sending domain used.
principal contact (full name, email and telephone).
feedback loop email account.
Usa.net
The following form enables you to request a feedback loop: http://fbl.usa.net/.
Excite
The following form enables you to request a feedback loop: http://feedback.bluetie.com.
Mailtrust
The following form enables you to request a feedback loop: http://fbl.mailtrust.com.
United Online (NetZero, Juno)
The following form enables you to request a feedback loop:
http://www.unitedonline.net/postmaster/whitelisted.html.
Whitelisting requests can be made through the following page:
http://www.unitedonline.net/postmaster/whitelisted.html.
Important:
The whilelisting form works with the feedback loop request.
RoadRunner
The following form enables you to request a feedback loop: http://feedback.postmaster.rr.com.
EarthLink
Write to the following address to request a feedback loop: [email protected].
You must communicate the following information:
n
n
n
n
The
The
The
The
28 | © Neolane 2013
IP list or range in question.
sending domain used.
principal contact (full name, email and telephone).
feedback loop email account.
Domain-specific conditions
Cox
The following form enables you to request a feedback loop: http://fbl.cox.net.
Bluetie
The following form enables you to request a feedback loop: http://feedback.bluetie.com.
Neolane v6.0 - Ensuring emailing platform deliverability - Domain-specific conditions | 29
Neolane
30 | Neolane v6.0 - Ensuring emailing platform deliverability
CHAPTER 5
Blacklisting databases
Table of Contents
Objet . . . . .
Spamcop . . . .
Spamhaus . . .
RFC Ignorant . .
SORBS . . . . .
No-more-fun . . .
URIBL . . . . .
iX Manitu . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
31
32
32
32
32
32
32
Objet
Several organizations maintain databases of IP addresses and domains that are reputed to be used
by spammers. Consulting these sites can be useful to understand why certain messages were
rejected as spam. It is generally possible to request the removal of an address erroneously added
to these lists.
These databases are called RBLs (Real-time Blackhole Lists) and they are consulted via a DNS
mechanism. There are three types of RBLs:
n
n
n
By IP address: lists IP addresses sending spam or likely to be relaying spam
By sender domain: lists sender domains (full domain of the bounce mail address) sending spam
or incorrectly configured
By web domain: lists the domains (high-level domains as registered with the registrars) found
in the URLs of the links and images contained in spam content. In Neolane, the domain to be
taken into consideration is generally the address used for tracking.
The following is a list of the most widely used RBLs. For a more comprehensive list, you can refer
to http://www.declude.com/Articles.asp?ID=97 or http://www.dnsstuff.com/ ("IP Tools" section,
"Spam Database Lookup" form).
Spamcop
Refer to http://www.spamcop.net/
One of the best know databases. If you are on this list, it is generally a bad sign.
Neolane v6.0 - Ensuring emailing platform deliverability - Blacklisting databases | 31
Neolane
Spamhaus
Refer to http://www.spamhaus.org/
One of the best know databases. If you are on this list, it is generally a bad sign.
RFC Ignorant
Specialized in the compliance with the RFC recommendations, this site does not measure reputation but
rather the technical compliance of a domain.
SORBS
http://www.nl.sorbs.net compiles a list of IP addresses that are reputed to be dynamic IP address (i.e.
attributed temporarily to ISP subscribers) or "open relay" addresses. Certain domains check whether the IP
address of a sender is not listed on this site before accepting email. Checking the IP addresses on this site
can prove useful.
No-more-fun
Refer to http://moensted.dk/spam/no-more-funn/
Lists the IPs assigned dynamically by the major ISPs to the general public. Newly used IPs are frequently
listed here. Removal is simple and quick.
URIBL
Refer to http://www.uribl.com/
This list contains the domains found in the URLs within spams. We will therefore test the domain used for
the tracking links against this database.
iX Manitu
This is a list of IPs and is widely used in Germany. See http://www.heise.de/ix/nixspam/
32 | © Neolane 2013
CHAPTER 6
The Deliverability module
Table of Contents
Objet . . . . .
Technical monitoring
Inbox monitoring .
Inbox rendering . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
33
34
34
Objet
Neolane offers tools to track the deliverability peformance of your platform. These functions are
part of a dedicated option, the Deliverability module.
When this module is configured for your Neolane platform, you have access to the following
information:
n
n
n
Technical tracking report for day to day deliverability performance (technical monitoring)
ISP inbox rendering report,
Oveview of message quality (inbox, spam),
Technical monitoring
The technical monitoring report is available via the Deliveries>Deliverability>Technical
monitoring link in the Neolane home page.
It includes a number of deliverability quality indicators for your platform (the indicators are updated
daily at 9 AM).
Neolane v6.0 - Ensuring emailing platform deliverability - The Deliverability module | 33
Neolane
In addition, you are able to receive a daily report by email at a specified address. Please let us know the
requested email address by email.
Some technical terms:
n
n
n
n
n
n
IP and RBL domain (Realtime Blackhole List): List of IP addresses of polluting domains.
These lists are maintained by dedicated organizations (such as SpamHaus, Spamcop...). Neolane currently
processes these lists. These RBLs reflect your reputation and can be queried by the ISPs before accepting
to receive your emails.
SPF (Sender Policy Framework): Mechanism enabling you to check whether the email sender is authorized
on the sending domain.
SNDS(Smart Network Data Services): A Windows Live Hotmail anti-spam service.
(https://postmaster.live.com/snds/FAQ.aspx)
DomainKeys: service developed by Yahoo and intended to certify the identity of an email sender.
Reverse DNS: Neolane checks whether a reverse DNS is given for an IP address and that this correctly
points back to the IP.
SenderScore: Database of reputed servers (https://www.senderscore.org/)
Inbox monitoring
This report is available from the Deliveries>Deliverability>Inbox monitoring section of the Neolane
home page.
It gives an overview of the quality of emails sent over a given period of time. A benchmark comparison is
also made with the other platforms that have subscribed to the deliverability service.
Inbox rendering
This report is available for each delivery, in the the Email rendering tab.
Note:
The number of rendering reports is limited monthly according to your license agreement. The counter is
reset every 25th day of the month.
34 | © Neolane 2013
The Deliverability module
Neolane has implemented a dedicated workflow (Update seed network for Inbox Rendering) to enable
you to recover the target addresses to use for your proof emails. This workflow is located in the
Administration>Production>Technical workflows node of the Neolane tree.
This workflow creates and updates the addresses used in the seed network. It runs daily at 5 AM. To force
it to run straightway, right click on the scheduler and select Execute pending task(s) now.
The contacts are inserted in a folder named Inbox Rendering recipients and assigned to a group Inbox
Rendering recipients to enable rapid targeting.
Simply add this group in your delivery actions to enable the Neolane capture process.
The rendering thumbnails can be accessed in the Inbox rendering tab of the delivery a few minutes after
sending the emails.
Note:
Each sending is counted off against your number of authorized rendering reports. Use the Update rendering
button to update the list.
Neolane v6.0 - Ensuring emailing platform deliverability - The Deliverability module | 35
Neolane
Example of a rendering report:
Note:
If you have defined specific access rights for your operators, they require read rights for the "Inbox rendering
recipients" and the associated group.
This mode implies using the nmsRecipient table. If not, you you have to include the target addresses in
your contact table.
If you use personalization elements in your emails, the "source" profiles must be specified as a consequence.
36 | © Neolane 2013
CHAPTER 7
SpamAssassin
Table of Contents
Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
39
Presentation
Neolane can be configured to work with SpamAssassin. This makes it possible to score emails to
determine whether a message runs the risk of being considered as spam by the anti-spam tools
used upon receipt.
Before starting a delivery, the Preview tab enables you to evaluate the risks. A warning message
give the result of the test as in the following example:
Neolane v6.0 - Ensuring emailing platform deliverability - SpamAssassin | 37
Neolane
The Detail... link enables you to view the analysis type, from the Anti-spam checking tab.
If a high level of risk is detected, the following message is displayed:
38 | © Neolane 2013
SpamAssassin
The reasons for this risk are given in the Points/Rule/Description section of the Anti-spam checking
tab.
Note:
SpamAssassin must be installed and configured on the Neolane application server.
Installation
For further information on configuring SpamAssassin in Neolane, please refer to the Installation Guide.
Neolane v6.0 - Ensuring emailing platform deliverability - SpamAssassin | 39
Neolane
40 | Neolane v6.0 - Ensuring emailing platform deliverability