Tagged: Transparency Toggle Comment Threads | Keyboard Shortcuts

  • admin 9:48 am on April 5, 2017 Permalink
    Tags: , , , Transparency   

    The Government Road to Financial Transparency 

    Teradata White Papers

  • admin 9:49 am on November 2, 2016 Permalink
    Tags: , , , , , Reductions, , Transparency   

    Greater Transparency in the Automotive Supply Chain Enables Cost Reductions 

    Teradata Case Studies

  • admin 10:36 am on August 29, 2015 Permalink
    Tags: , , Transparency   

    Data Transparency 2015 

    Data Transparency 2015 (#DT2015) is the third annual gathering of the most influential U.S. open data leaders– from the executive branch, the legislative branch, state and local, the nonprofit sector, and the tech and financial industries. Data Transparency 2015 is hosted by the Data Transparency Coalition, the world’s only open data trade association, representing market leaders in data publication, data analytics, and data reporting.
    Teradata Events

  • admin 9:54 am on June 16, 2015 Permalink
    Tags: , , , , HelloBEST, , , , , Transparency   

    HelloBEST Best Practices For Email Marketing: What You Need To Know About Data Transparency 

    MAAWGThis post was authored by a leader of Teradata’s Global Deliverability team, Mary Youngblood, director, Reputation Desk.

    In my last post, I discussed the three levels of email marketing consent and the best ways for you to obtain email addresses. Today, I’d like to explore another hot topic for email marketers: data transparency.

    As outlined in the recently updated Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) Sender Best Common Practices, data transparency involves multiple, disparate elements, including Authentication, Correct Up-To-Date Whois Information, Technical IP Information, Shared vs Dedicated IP Environments, Vetting Practices, Feedback Loops (FBLs), Forwarding Services and Connection/Non Delivery Report (NDR) Handling (aka Email Bounces).

    If you don’t have time to read all 17 pages of the M3AAWG document, here are my key takeaways:


    Authentication is one of the primary ways senders/marketers can identify and verify themselves and their data. The main email authentication protocols that every ESP should make available to sender/marketers who qualify for use are:

    • DKIM – Combines key signing technology with DNS records to authenticate a message as being signed by the owner of the domain.
    • SPF – Uses DNS to authorize IPs to send on behalf of a domain or bounce domain.
    • SenderID –Employs DNS to authorize IPs to send on behalf of a domain or bounce domain, based on the same records as the SPF protocol. Used mainly by Hotmail and is being phased out.
    • DMARC – Uses DKIM and SPF records for the same domain to establish a tighter authentication protocol. Senders/marketers in shared environments may have trouble with this protocol if they are required to share the same bounce domain.

    Correct Up-To-Date Whois Information

    Correct Up-To-Date Whois Information is available through online services and analytics tools that provide information as to the owner and/or user of a domain or IP address. These services can answer questions like:

    • Does the From Domain contain accurate Whois information about the sender/marketer?
    • Does the Whois information provide alternative ways to contact the Sender/Marketer with questions, complaints and unsubscribe requests?
    • Is there Whois information for the IP that includes the ESP/sender’s information so that complaints and/or unsubscribe requests can be made against the marketer?

    Technical IP Information

    Technical IP Information includes Forward DNS, Reverse DNS and HELO (or EHLO). You need to know that:

    • The ESP or sender must have the correct settings for these items established in their DNS records and MTA settings.
    • These records and settings help to properly identify the sending IP and the Host Name of the Sending IP. Spammers usually do not do this, so the good guys do this as a way to set them apart from looking like spammers.

    Shared vs Dedicated IP Environments

    Please be aware that:

    • Some sender/marketers do not have enough consistent volume to justify being on their own dedicated IPs, so they will share an environment with other sender/marketers.
    • There are pros and cons to participating in a shared environment. If one user of the environment does something to harm the reputation, all users may suffer the consequences.
    • Optimally, shared environments contain like users, meaning that users have similar metrics and content and are thoroughly vetted before being allowed into the environment.
    • Shared environment users should differentiate themselves from other users in the environment by authenticating with DKIM.

    Vetting Practices

    Vetting is a way for ESPs to determine whether a sender/marketer is the right type of client for what they do. The wrong sender/marketer can not only cause issues for other clients but can also damage the reputation of the ESP as a whole. Vetting the sender/marketer’s sending history, reputation, content and list before signing a contract can prevent finding out too late that the sender/marketer was not a good fit. Also, it’s imperative to have a process in place after the sender/marketer has begun sending.  For instance,  bounce rate thresholds, complaint thresholds, etc. can act as red flags that the email list in use may contain old or non-consent data that may compromise theirs and your overall reputation.  Having policies in place that watch for reputation issues is a must.

    Feedback Loops (FBLs)

    Most major ISPs offer Feedback Loops (FBLs). FBLs not only help in the removal of end users that do not want to receive future emails from a sender/marketer, but they also help ESPs monitor clients sending trends, list hygiene issues and content relevancy.

    Forwarding Services

    ESPs should have the capability to forward reply-to addresses and from addresses back to the sender/marketer. There should also be a way to collect all abuse@domain and postmaster@domain mail for either the ESP to use, or to forward to the sender/marketer to monitor for complaints and unsubscribes.

    Connection/Non Delivery Report (NDR) Handling, aka Email Bounces

    Do you know what response codes (ex: 2.x.x, 4.x.x, 5.x.x) mean and how to respond?

    For each email sent, the receiving mail server either issues a code of 2.x.x, 4.x.x, 5.x.x, with the x’s representing a number that pertains to an action or a reason.  Along with each code, there is usually a description of the action or problem that was associated with the message or the connection attempt.  Here is what the response codes mean:

    • 2.x.x – Message was Accepted by receiving mail server (Delivered).
    • 4.x.x – Temporary Failures (Deferrals) – Try again Later, may be a temporary network issue or a rate limiting issue.
    • 5.x.x – Permanent Failures  (Bounces) – Don’t try anymore, it’s not going to deliver today. Includes User Unknowns (Hard), Blocks, Full Mailboxes (Soft), Authentication Errors, Out of Office Messages, Dead Domains.

    Having the mail servers (MTAs) set to properly interpret the codes and take the correct action is a must.  Part of that interpretation and action include giving the bounce a categorization, such as Hard, Soft, Network, DNS, Informational, Block, Temporary, etc.  These categorizations help the MTAs determine the next course of action and help sender/marketers understand issues with the data or segmentations. A few more insights about bounces:

    • You need to determine whether your bounces are synchronous or asynchronous. Does the bounce happen during the mail server conversation (synchronous) or afterwards at a separate time (late bounce or asynchronous)? When bounces happen during the mail server conversation (Synchronous), the sending mail server can make decisions on the best way to proceed and will have an easier time determining the reason for the bounce and how to process.
    • When bounces happen after the mail server conversation, the mail is first considered Delivered and must then be updated to Undelivered, if the Late Bounce (Asynchronous) is determined to be a non-delivery failure versus a simple out of office reply.  Asynchronous bounces are often wordy and more difficult to categorize which can cause some confusion as to the nature of the bounce.
    • ESP operators will need to constantly monitor bounces and categorizations of them as sometimes ISPs and other receivers will change these Non Delivery Reports (bounces) from time to time. M3AAWG emphasizes that removing hard bouncing addresses and those that permanently bounce repeatedly is an important part of list hygiene and the failure to do so can cause delivery issues at recipient domains.

    Want even more detail about best practices regarding email marketing data transparency? You can read the entire M3AAWG document here.

    The post HelloBEST Best Practices For Email Marketing: What You Need To Know About Data Transparency appeared first on Teradata Applications.

    Teradata Blogs Feed

Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc