Configure email authentication - MX, SPF, DKIM, DMARC
Note: This guide DOES NOT apply to trial accounts (25,000 emails/month). Also, It only helps with email authentication for the transactional emails (Eg. Email notifications) sent using the delivery server we configured for you. It DOES NOT apply if you are using external providers like Sendgrid, Mailgun, Mailjet etc. You also need to add the DNS records they provide you with.
We configure outbound SMTP delivery servers with high reputation IP pools as a complimentary service. To ensure the server works well for your business and the emails get through to your inbox, you must set up these DNS records for the domain you would like to use for sending. For example, if you want to send from
@yourdomain.com, you need to set each of these records for that specific domain. You should be able to add new DNS records with ease. If you are unsure how to do it, you can get in touch with us or contact your DNS provider. There are also many guides on carrying this out, which show you how to add new records to your domain - just a google search away.
Default Sending Domain
First, determine what domain/sub-domain you would like to use to send emails. For example, many people use a sub-domain to send their marketing campaigns and another for sending transactional (notifications, sign-up emails). Doing this will help keep both channels seperate, which is the best practice. We will refer to this as the ‘default’ domain. Let’s say you have chosen
@newsletter.yourdomain.com to be your default domain. Let’s move ahead to creating an SPF record.
SPF (Sender Policy Framework) is a record to identify which email servers are authorised to send an email for any given domain. It is the most common form of email authentication. It helps prevent spammers from sending fraudulent emails using the ‘FROM’ address that belongs to you. Some providers allow adding SPF records directly, while others will enable you to add it as a TXT record type. Either is fine, and both will fulfil the purpose. Replace
yourdomain.com with the actual sending domain/sub-domain you have chosen
v=spf1 a mx include:default.sendtrack.email ~all
If you already have an SPF record or something that looks similar to the above, add the
include:default.sendtrack.email to it. So if your SPF record looked something like this:
v=spf1 include:_spf.google.com ~all. The changed record would look something like this:
v=spf1 include:_spf.google.com include:default.sendtrack.email ~all
DKIM (DomainKeys Identified Mail) allows receiving servers to verify that the mail is authorised and sent by you - the domain administrator. The process further authenticates you as the domain owner and legitimate sender and stops spammers since they cannot sign their emails using your key. Only you can sign with your key. Don’t forget to replace
yourdomain.com with your actual sending domain.
We provide extensive open and click tracking, allowing you to quickly view who opened or clicked on your email. These links utilise our domain, but this can sometimes trigger spam filters since the sending domain doesn’t match the domain used for tracking links. To fix this, you need to add a CNAME record which will allow us to mask your domain on top of our underlying link tracking mechanism. Then, replace your domain part with yours as in the previous steps.
If you use Cloudflare as your DNS provider, please ensure the Cloudflare cloud icon is grey (turned off). Or else the tracking links do not function as expected. See the example below.
DMARC (Domain-based Message Authentication, Reporting & Conformance) is another email authentication protocol built on the SPF and DKIM protocols we added in previous steps. Setting a DMARC policy allows you as a sender to indicate that SPF and DKIM sign your emails. It also details what the mail server should do if neither of those authentication methods passes when verified, such as classifying that email as Junk/Spam. It also allows you to specify where to send a report when these verifications fail, enabling you to evaluate further where these emails are originating. If they are yours, you can work on fixing them up. There are a few options for configuring it. The first option is straightforward - it is to say that you do not wish to receive any reports. The second option allows you to specify where the mail server can send notifications in case of failures and aggregate information. We will list these options, and you can choose what works best for you.
Option 1 - Simple and most common method
Option 2 - To specify where to send the reports
v=DMARC1; p=quarantine; ruf=mailto:email@example.com; rua=mailto:firstname.lastname@example.org
Please make sure you replace the
email@example.com with the email address to which you would like the reports sent. We highly recommend you create a new inbox specifically for this as the reports can get a lot in quantity when sending large amounts of emails or if the domain is popular.
MX (Mail Exchange) records allow mail servers to know which email server to communicate with if they have an email to send. It is the way to receive emails from other email servers. We highly recommend configuring proper MX records to ensure you are receiving emails belonging to
yourdomain.com. Another reason to have an appropriate MX record is to ensure that other mail servers see you as a legitimate domain and email sender. Most spam email senders tend not to have proper MX records as they want to send emails but not receive spam themselves.
After creating these records, ensure you verify the domain through the MailWizz backend or get in touch with our team to verify it from our backend. Once you get a thumbs up, your domain is ready to use. You can start sending emails from
@yourdomain.com without any restrictions.