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.
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.
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.
Rate limiting / Throttling
Rate limiting is the process that ISPs use to delay the delivery of unwanted (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.
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 such 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.
DomainKeys Identified Mail (DKIM):
DKIM is one of the ways to authenticate email communication by adding an encrypted signature to your emails. Some information (our DKIM public Key) is added to your Web domain settings, and a specific signature is added to all the emails that we send for you. This signature is encrypted based on some elements of the email being sent and, for this reason, it is unique for each email. When the receiving mail server analyzes your email, it will decrypt the signature using the public key mentioned above and It will generate a new hash string based on the same elements. If the decrypted signature matches the newly generated hash string then the email is considered DKIM authenticated. 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; email@example.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.
Domain-based Message Authentication, Reporting and Conformance (DMARC):
DMARC is a method of email authentication focused on mitigating email-based phishing. It allows a domain owner and sender of email messages to ask mailbox providers not to deliver unauthorized messages that appear to have been sent from the same domain.This helps in the prevention of phishing schemes and spoofing attacks.
Technically speaking, DMARC – which stands for Domain-based Message Authentication, Reporting & Conformance – is a system that builds on the DKIM and SPF authentication protocols to help receiving servers (e.g. Gmail, Yahoo!, Hotmail, etc.) know what to do when a message cannot be authenticated. It does so by allowing the sender of an email to publish a "policy" on which mechanism (DKIM, SPF or both) is employed when sending email, which will instruct how email receivers should deal with failures (monitor, send to spam or reject the messages).
Additionally, it provides a reporting mechanism of actions performed under those policies. It thus coordinates the results of DKIM and SPF and specifies under which circumstances the FROM. which is often visible to end users, should be considered legitimate.
For more, please see to using DMARC with MailUp.
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.
Each MailUp account comes with authentication enabled by default (FCrDNS, SPF, DKIM), but on domains owned by us and directly associated with our sending infrastructure. These domains - by definition - are not related with the sender's brand identity. Even though the default settings are enough in terms of email authentication, some senders may need additional configurations (e.g. DMARC) and branding by using a custom domain.
Configure the SPF record for the sending domain
Adding SPF authentication is easy. Here is what you need to do:
v=spf1 include:musvc.com ~all
Example: v=spf1 include:mydomain1.com include:mydomain2.com include:musvc.com ~all
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 firstname.lastname@example.org the Envelope Sender could be email@example.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
2) Type: TXT
Value:"v=spf1 include:musvc.com ~all"
For more information regarding the second record(SPF) please see this page.
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.
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 220.127.116.11
mx67203.mydomain.com A 18.104.22.168
mx67202.newsletter.mydomain.com TXT v=spf1 include:musvc.com ~all
mx67202.newsletter.mydomain.com TXT spf2.0/pra include:musvc.com ~all
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:firstname.lastname@example.org; ruf=mailto:email@example.com.
* 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...