Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Overview

Getting your MailUp account properly configured is an important part of maximizing your deliverability, that is your ability to deliver your emails in your recipients' inbox. You can think of deliverability as an equation: the result is whether or not your emails end up in the inbox, and many variables affect it. Among them: your reputation as a sender, the content of the message being sent, the level of engagement of the message recipients, the reputation of the sending infrastructure that you are using, etc. etc.

...

  • Authentication
    Email authentication is a collection of techniques aimed at equipping messages of the email transport system with verifiable information. Its purpose is to validate the identities of the parties who participated in transferring a message, as they can modify the message. The results of such validation can then be used in delivery decisions that do not imply any "content filtering" mechanism. There are several authentication methods (FCrDNS,  ADSP, SPF, DKIM, DMARC) and each of them go one step further in assessing sender validation and reputation.

  • Commercial email
    An email message that has as one of its purposes that of participation in a commercial activity. Commercial email typically promotes a product or service.

  • Content Filtering / Fingerprinting
    Techniques aimed at evaluating the content of an email message (specific words, URLs or "chunk") to detect spam messages or spammy patterns. Content filtering is more utilized in the corporate world where system administrators may set content restrictions on what employees can receive. In the consumer world, instead, major ISPs (e.g. Google, Yahoo!, etc.) see authentication, reputation and user interaction (see "Engagement") as more reliable than content filtering in detecting spam, though they may use both.

  • Engagement
    A "measure" of how subscribers respond to and act on the email messages you are sending to them. Positive engagement - such as views, time spent viewing, clicks, and replies - will likely improve the sender reputation and deliverability. Negative engagement, meant as the absence of any action or, worse, deleting or marking a message as spam, is very likely to cause deliverability issue in the short term.

  • Dedicated IP
    An IP address used exclusively for one sender or for a portion of its email traffic (e.g.. transactional emails). When a dedicated IP is used, email traffic being sent from that IP address is isolated to that specific sender. Consistent sending frequency - and of course high quality of the messages being sent - are crucial factors in building and maintaining a good reputation for dedicated IP addresses. Lack of sending volume and/or frequency can cause lack of reputation for the dedicated IP, which can lead to deliverability issues. For this reason, a dedicated IP address may or may not be a recommended solution.
     

  • Shared IP
    A group of IP addresses used for multiple customers that share common reputation metrics and allow them - as a whole - to maintain a consistent sending frequency.
     

  • Transactional email
    A one-to-one email message, usually sent as a result of a specific user's action (e.g. online order). Transactional emails are topically receipts, confirmations, reminders, or any non-commercial email personalized specifically to the recipient. Legally speaking (e.g. CASL), a transactional message that includes commercial content becomes a commercial email (see above).


  • Rate limiting / Throttling
    Rate limiting is the process that ISPs use to delay the delivery of unwantend (or unknown) email, filter spam, and ensure that wanted (e.g. transactional) emails reach the inbox in a timely manner. Each ISP has its own sending limits on a per-hour and/or per-day basis, and they can throttle the sending volume when it’s too high or too low.

     

  • Domain / Apex domain
    The right portion of the domain used by a sender when sending emails (e.g. mycompany.com). It is the root of all reputation and authentication mechanisms, and should be directly linked to the sender's corporate web site or brand identity.
     

  • Subdomain
    A lower-level domain. If mycompany.com is the top-level (apex) domain, news.mycompany.com is a subdomain of it. Since usually the apex domain is already configured to properly serve a sender's corporate web site, and any modifications to it could have unwanted side effects, it is usually recommended that a sender create subdomains to be used for email messaging purposes (3rd level domains such as news.mycompanyname.com and 4th level domain sunch as bounce.news.mycompanyname.com). The choice of domain, sub-domain, and naming conventions is important because it can have a significant effect on how ISPs and anti-spam authorities will consider the email stream. Please see Configuration steps below for more information.
     

  • Web interface domain:
    A subdomain that will be used:

    • in all tracked links in your email messages;

    • in the URL of the Web version of the message;

    • in the URL of all Web pages used by the system (e.g. subscription confirmation landing page);

    • in your MailUp admin console URL.

       

  • Envelop Sender / Return Path
    An e-mail address to which asynchronous bounce messages are delivered. As this email address is included in the Header section of the email, its domain takes part in the reputation assessment process.

...

  1. Forward-confirmed reverse DNS (FCrDNS):
    Also known as full-circle reverse DNS, double-reverse DNS, or iprev, FCrDNS is a networking parameter configuration in which a given IP address has both forward (name-to-address) and reverse (address-to-name) Domain Name System (DNS) entries that match each other. This is the standard configuration expected by the Internet standards supporting many DNS-reliant protocols and It is recommend as a best practice. A FCrDNS verification can create a weak form of authentication that there is a valid relationship between the owner of a domain name and the owner of the network that has been given an IP address.

  2. Sender Policy Framework (SPF):
    SPF is a simple email validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain is being sent from a host authorized by that domain's administrators. The list of authorized sending IPs for a domain is published in the Domain Name System (DNS) records for that domain in the form of a specially formatted TXT record (see using SPF authentication with MailUp).
     
  3. DomainKeys Identified Mail (DKIM):
    DKIM is an email validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain is authorized by that domain's administrators. A digital signature included with the message can be validated by the recipient using the signer's public key published in the DNS records. An example of DKIM signature is the following: 

    DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=transactional; d=mailup.com;
     h=From:To:Date:Subject:MIME-Version:Content-Type:List-Id:List-Unsubscribe:Message-ID; i=news-it@mailup.com;
     bh=eFMbGLxi/7mcdDRUg+V0yHUTmA1F4EXExVBQxIxBr2I=;
     b=ra3pGFHHvCr9OZsm9vnOid........Yj00/+nTKs=

    If the message has a valid signature (it is not forged), the signing domain, identified by the d= tag will tell the receivers who you are and they will handle your mail accordingly. Reputation assessment systems will look at the reputation of the signing domain and decide whether place the email in the inbox or in the spam folder based on that assessment.
     
  4. Author Domain Signing Practices (ADSP):
    ADSP is an optional extension to the DKIM e-mail authentication scheme, whereby a domain can publish the signing practices it adopts when relaying mail on behalf of associated authors. It is a way to tie the DKIM signing domain with the domain in the email address in the From: header of a message (also known as the "author domain"). To create that connection, a domain owner publishes an ADSP record in the DNS, containing a policy statement about the mail sent from that domain. A policy of "all" is intended to convey to receiving systems that all of their mail is signed with DKIM, but does not make any request about what to do with unsigned mail. A policy of "discardable" requests that unsigned messages be discarded. ADSP never achieved widespread adoption and in 2013 it was demoted to "historic". It has been superseded by DMARC.
     
  5. Domain-based Message Authentication, Reporting and Conformance (DMARC):
    DMARC is a method of email authentication focused on mitigating email-based phishing. It expands on the Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM), coordinating their results on the alignment of the domain in the From: header field, which is often visible to end users. It allows specification of policies (the procedures for handling incoming mail based on the combined results), and provides for reporting of actions performed under those policies. The sender will need to implement SPF and/or DKIM authentication with the same domain used as the FROM address (see implementing SPF authentication with MailUp). The DMARC "test" consists of checking that the two domains (the domain used for authentication and the one used in the FROM address) match, at least at the organizational level (e.g. news.yourcompany.com and marketing.yourcompany.com are not the same, but they match at the organizational level). For more, please see to using DMARC with MailUp

...

  1. Pick the FROM domain
    Which domain will you be using to send emails with MailUp? Your top-level domain (i.e. the apex domain as discussed above) or a subdomain (e.g. news.mydomain.com)? In the first scenario, the FROM EMAIL would be something like updates@mydomain.com, whereas in the second it would be something like updates@news.mydomain.com. The decision should be based on whether you have access and can modify the DNS records of that domain. Check with the person in your organization that has access to your domain management system to find the answer. In the examples below we are assuming that the sending domain corresponds to the apex domain (mydomain.com). If you cannot modify the DNS records of your apex domain, then you will need to set up a subdomain (eg news.mydomain.com) and refer to that one (in place of mydomain.com) in the steps outlined below.
     
  2. Verify your FROM EMAIL
    Now that you have picked the FROM domain, create a FROM EMAIL under that domain, and verify it in your MailUp account. To prevent abuse, MailUp requires that the FROM EMAIL is verified before it can be used. Verification is very simple: MailUp will send a verification message to the provided FROM EMAIL address, and you will need to click in the link contained in the message. You can verify the FROM EMAIL when you configure a List in your MailUp account, or when you set up a new mailing. 
  3. Configure the SPF record for the sending domain

    The following TXT records shoudbeadded to the DNS settings for your sending domain 

    v=spf1 ip4:93.174.64.0/21 include:musvc.com ~all 
    spf2.0/pra ip4:93.174.64.0/21 include:musvc.com ~all
    Once the records have been added, to verify that they were correctly configured, we suggest this tool: http://www.kitterman.com/spf/validate.html
    For more detailed instructions, please see Using SPF authentication with MailUp. 
  4. Configure a Web interface domain (optional)
    If you wish to use a custom Web interface domain (see the Glossary above for a definition), create a C-NAME in your domain management system (e.g. news.mydomain.com) and point c.mailup.com
    For more information, please see MailUp account settings. Please note that this configuration is available only for PRO and ENTERPRISE clients. 

  5. Configure a custom Envelope Sender (optional)
    Using a custom Envelope Sender (see the Glossary above for details) you can to "align" it with the FROM EMAIL address, which allows for more advanced sender configurations, as mentioned above. This address can be any email account of your choice under the same domain as the one used for the FROM EMAIL (e.g. if the FROM EMAIL is news@mydomain.com the Envelope Sender could be bounce@mydomain.com). In order for the MailUp system to be able to process bounces, it will need to access sent to that address. There are two options:

    1. You may provide us with POP3 access to that mailbox (port 110, PLAIN no TLS or SSL)

    2. You may forward messages received by that mailbox to a specific email address that we will provide

  6. Enable DKIM authentication
    In order to enable DKIM authentication on your sending domain you should point the CNAME record for mailup._domainkey.mydomain.com to dkim.musvc.com

    If you do not have the option of setting such CNAME, you can add the following TXT record to the DNS settings: 

    mailup._domainkey.mydomain.com IN TXT "k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCv+5lxtrNKrKKjF9Jvkidsk9UDOHht1tXZjhnt/ygrdFrQKKYxhgqSNtWBwA1TxukZIR382dYJhAHYDeeaGrUkf3C7VUzm+nO0fTMrN+lQXdYWIO9tTM9ZC3xVjG+uRrfnprJN8t2LfXwbC5oIGtRb8ZyQYiAhXO9qTHoAOK1/IQIDAQAB"
    Please also note that to use a custom DKIM signature the following email addresses (role accountsabuse@mydomain.com and postmaster@mydomain.com must exist, must be able to receive email, and must be actively monitored.
    If you are using a subdomain as sending domain (eg m.mydomain.com) you must also forward those emails (abuse@m.mydomain.com and postmaster@..) to abuse@mailup.com

     

  7. PTR of SMTP servers (For dedicated IPs):
    If your email streams will be delivered through dedicated SMTP servers, each one of them should have a PTR aligned with the base host domain. Example: 

    mx67202.mydomain.com A 93.174.67.202
    mx67203.mydomain.com A 93.174.67.203

    Each PTR should have the same SPF / Sender ID records as the sending domain:
    mx67202.newsletter.mydomain.com TXT v=spf1 ip4:93.174.64.0/21 include:musvc.com ~all 
    mx67202.newsletter.mydomain.com TXT spf2.0/pra ip4:93.174.64.0/21 include:musvc.com ~all

     

  8. Enable DMARC:
    Since DMARC is built upon SPF and DKIM all the previous steps are required before enabling DMARC.

    The proper TXT record (_dmarc.mydomain.com) should be added to the DNS settings for your sending domain.
    It can change depending on what you want your DMARC policy to be.

    A simple DMARC record is the following: v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc.rua@mycompany.com; ruf=mailto:auth-reports@mycompany.com.
    where:
    * v is the version, DMARC1 is the only version available at the moment.
    * p is the policy. Allowed values are *none* (take no action, just collect data and send reports) *quarantine* (treat with suspicion unqualified mail) *reject* (block any unqualified mail for the domain)
    * pct is the percentage of non-aligned messages that should be rejected (from 1 to 100 where 100 means all the messages)
    * rua: Send aggregate reports to this address (should be closely monitored)
    * ruf: Send forensic (detailed) reports to this address.

    Note that the email addresses that receive the aggregate and detailed reports (“rua” and “ruf”) can be on any domain, not necessarily the domain used for the authentication, for reporting purposes only.

    We strongly suggest ramping up DMARC use slowly by using the p=none policy at first. Monitor your traffic and look for anomalies in the reports (eg.: messages that are not yet being signed)
    Then, once you have verified that all legitimate messages are correctly being authenticated, move to "quarantine."
    Review the results again (look also in your spam folder) and when you're absolutely sure all of your messages are signed, change the policy setting to "reject" to make full use of DMARC.

    You can also leverage the pct tag to sample your DMARC deployment. If you want to be extremely conservative, after moving to the quarantine policy, you may start with pct=1 and then move to 10, 25, 50, 100...