Email is a wonderful thing for those people whose role in life is to be on top of things, but not for me: my role is to be on the bottom of things.
Donald Knuth
When you set up your own domain email, no matter where it is hosted, there are certain things you will have to do in order to make sure you are able to both send and receive email successfully.
The most important thing is to configure your DNS correctly. Your DNS directs where email to your domain is sent, and also provides information for recipient email servers which can be checked whenever they receive email from your domain. (You can see an overview of how DNS works here).
If your new email hosting isn’t working as expected – either receiving, sending or both, the problem likely lies in your DNS.
Wherever your email is hosted you will always need at least 3 records set up to ensure you get your email delivered to the correct server, and to ensure the best chance of successful delivery:
Additional Optional: DKIM Record (if your sending server is configured to use DKIM)
1. MX Records
Your MX records are the records looked up when any email server wants to send an email to anyone@yourdomain. They tell that sending server what server or servers will handle email sent to you. The MX records will be provided by your email hosts. Sometimes they are edge “relay” servers which pass off the email to other internal servers, sometimes they are the servers which actually process and store the email.
Important. Before adding any MX records for your domain, you should check and make sure that you have deleted any existing MX records – if you do not, your email may be sent to one of the old record hosts.
Important. Once you change your MX records your previous email host will stop receiving email to your domain, however the change may not be immediate and may take up to 72 hours before all email from every email sender globally is sending to the new updated MX. This means that during this time, some email may be sent to the old hosts, and some to the new hosts.
MX records are formed of 4 parts: Name, TTL, Priority, and lastly the Destination (or Mail Server, or Target).
- Name: this is the @yourdomain part. If you wanted to receive mail to yourdomain.com your would input yourdomain.com. (with the trailing dot after com) for the Name. If you wanted instead to configure email to @shop.yourdomain.com then the Name would be shop or shop.yourdomain.com. (note that the shop does not have a dot at the end but the shop.yourdomain.com. does). Some DNS editing pages will allow you to use the symbol “@” to represent the base domain (in this case yourdomain.com.)
- TTL: This is how long you wish for mail servers to store the destination of the record (in seconds) before checking back with the parent name server to see if it may have changed. Use shorter TTLs for records that change frequently.
- Priority: You can have multiple MX records. The priority tells sending mail servers which server to try to send your email to first. The lower the priority number the higher up the list of servers to try first it will be (so priority “0” will be tried before priority “10”).
- Destination: This is the host name of the mail server. Usually this will be given to you by your email host. Note that you can have several different destinations provided which may or may not all have different priority numbers. Usually you do not have to add a dot to the end of the host name for this field as it is assumed that it could be in a different domain than your base domain.
2. SPF Records
Your SPF record is a DNS record which tells email servers who are receiving email from your domain (someone@yourdomain) which email servers they should “trust” as being authorized by you (as the DNS record administrator) to be sending email from anyone@yourdomain.
You do not have to have an SPF record, however if you do not, most email servers will mark your email as Junk/Spam.
Important. If you send email from a server whose IP address is not included in your SPF record (either explicitly or by reference), then that email will be almost certainly be marked as Junk/Spam if it accepted at all.
Important. Before adding an SPF record, ensure you have deleted any old SPF records (TXT type records that start v=spf1) as having multiple SPF records can result in all of your email being marked Junk/Spam.
Your SPF record will be a TXT type record. It has 3 fields, Name, TTL and Content. The Name and TTL are the same as the MX records.
- Name: this is the @yourdomain part. If you wanted to receive mail to yourdomain.com your would input yourdomain.com. (with the trailing dot after com) for the Name. If you wanted instead to configure email to @shop.yourdomain.com then the Name would be shop or shop.yourdomain.com. (note that the shop does not have a dot at the end but the shop.yourdomain.com. does). Some DNS editing pages will allow you to use the symbol “@” to represent the base domain (in this case yourdomain.com.)
- TTL: This is how long you wish for mail servers to store the destination of the record (in seconds) before checking back with the parent name server to see if it may have changed. Use shorter TTLs for records that change frequently.
- Content: This gives the direction of the SPF record with how receiving mail servers should deal with email sent from your domain.
The Content is the meat of your SPF record here. It will always start with the SPF version (in this case v=spf1) next you will list the authorized servers who can send email, and then lastly what you would like to happen if email is received from servers which are not in this list.
A general example would be the following:
Name: example.com.
TTL: Auto
Content: v=spf1 a mx include:spf.someotherdomain.com -allBreaking this down:
v=spf1 – This denotes that the record is an spf record
a – If email is sent from the “A” record IP address for mydomain.com then allow (this is the same as putting +a). Often used if your website sends email.
mx – If email is sent from any of the servers listed as MX records for mydomain.com then allow. Often used if the mail exchange servers are responsible for both receiving and sending email.
include:spf.someotherdomain.com – If email is sent from any servers authorized in the SPF record for spf.someotherdomain.com then allow. Often used if your email host uses relays.
-all – If email is received from any other servers, then reject the email (the rejection is denoted by the “-“. You could instead use ~all which would accept the email from other servers but mark (usually as junk/spam). Lastly you could use ?all for neutral but this is not recommended!
Wikipedia has a really well explained and simple to understand article on SPF and I would recommend reading if you are interested further.
3. DMARC Record
The DMARC record tells mail servers what to do if the message they receive from anyone@yourdomain fails either a check against the SPF record or the DKIM check (more on that below).
The DMARC standard has quite a few options and is less straight forward than SPF or DKIM records. Rather than explain DMARC there is a great explanation from MXToolbox. Instead I will show you what I would suggest as a starter you configure your DMARC to be, then going from there, you can tweak to your needs. For the example, replace example.com with your own domain and make sure you have a postmaster email box set up. (This is also a TXT type record):
Name: _DMARC.example.com.
TTL: Auto
Content: v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=14. Additional Optional: DKIM
As well as setting your MX, SPF and DMARC records, if your server can (or is already configured to), you should also set a DKIM record which proves the email is sent from a server you as the domain owner trust, by signing it digitally.
To keep things simple, essentially when your email server sends an email from someone@yourdomain it takes a collection of the mail headers (metadata such as From:, Subject:, To: etc) with an encryption key called the selector. The result along with the selector and some other data is sent with the email. When a server receives that email, before delivering it to the recipient, they can look up your DKIM record for that selector, and then with the contents verify that the signature matches so can be absolutely sure it came from a trusted sender for yourdomain.
You should ask if your email host supports this – it will increase email deliver-ability and it makes it significantly easier to spot unauthorized spam from your domain when implemented.
Because you could have many mail servers that you allow to send email for yourdomain, you can have many selectors. In general, if your email host signs your emails, they will provide the DKIM record to add. Unless you are directly administrating the email server (at a root level), you will not need to construct the DKIM record by parts by yourself. If you are, and are stuck, feel free to email me at [email protected] and I can try to help.