Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from this space and version 9.2

...

  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 the link contained in the message. You can verify the FROM EMAIL when you configure a List in your MailUp account, when you set up a new mailing or when you add a new From email in Deliverability checkup page.
     
  3. Configure the SPF record for the sending domain
    Adding SPF authentication is easy. Here is what you need to do:

    • Contact your Web hosting company, domain registrar, or network administrator that manages this domain
    • Tell them that you need to make a change to the DNS (Domain Name System) records
    • If you are not already publishing an SPF record, ask them to add the following TXT record:  

    v=spf1 include:musvc.com ~all 

    • If you already have an SPF record in place (e.g.: you have a TXT record starting with v=spf1) then you should only add the "include:musvc.com" before the final "all" keyword

    Example: v=spf1 include:mydomain1.com include:mydomain2.com include:musvc.com ~all 

    • Wait 24-48 hours: it takes a bit of time to changes to the DNS to propagate around the Internet
    • Run the SPF test in Deliverability checkup to confirm that the SPF record has been successfully updated.

  4. Enable DKIM authentication
     Adding DKIM authentication is easy. Here is what you need to do:
    • Contact your Web hosting company, domain registrar, or network administrator that manages this domain
    • Tell them that you need to make a change to the DNS (Domain Name System) records
    • Ask them to create the following two CNAMEs (replace "mydomain.com" with your domain)
      (1) ml01._domainkey.mydomain.com 
     
    • ... and point it to
      ml01.dkim.musvc.com
      (2) ml02._domainkey.mydomain.com
     
    • ... and point it to
      ml02.dkim.musvc.com
     
    • If a CNAME cannot be created, you may also establish DKIM authentication by adding the following TXT records to the DNS settings. Please contact us for additional details
     
    • Wait 24-48 hours: it takes a bit of time to changes to propagate around the Internet
    • Run the DKIM test in Deliverability checkup to confirm that the CNAMEs have been successfully updated.

  5. 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. 

  6. 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 a subdomain as the one used for the FROM EMAIL (e.g. if the FROM EMAIL is news@mydomain.com the Envelope Sender could be bounce@bounce.mydomain.com). In order for the MailUp system to be able to process bounces, it will need to access sent to that address.
    Create two DNS records as follows:
    1) Type: MX
    Name
    : bounce.mydomain.com
    Value
    : mx01.musvc.com
    Priority
    :10

    2) Type: TXT
    Name
    : bounce.mydomain.com
    Value
    :"v=spf1 include:musvc.com ~all"

    For more information regarding the second record(SPF) please see this page.

    Note

    By modifying the MX record, MailUp will take control over the email management for that domain that will be handled by the platform. Previously created accounts will no longer be able to send and receive emails.


  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 include:musvc.com ~all 
    mx67202.newsletter.mydomain.com TXT spf2.0/pra 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...