Often misconfigured servers or missing DNS entries will have your mail end up in junk folders and not the recipients inbox. This is not only embarrassing there is normally a simple fix that can be applied in most cases to ensure that email ends up exactly where it should, the inbox
Check that email you are sending is not spammy
Avoid using url shortners, and general language that could come across as spam. This is especially true when it comes to users sending emails concerning financial transactions.
Think about your mail campaign make sure that the message is well formatted and has an “opt-out” option that works. There are also some online tools that can check the message you intend to send and offer some advice on improving delivery.
Lastly if you are sending large amounts of bulk mail consider using a bulk mailing service like mailchimp.
Domain Authentication
One of the most overlooked causes of messages ending up in the junk folder is misconfigured servers and especially DNS recors that have not been created or formatted correctly
PTR Records and mailserver hostname
It is very important that the hostname matches the IP address of the server sending your mail this means that your hostname should resolve to the correct IP (forward lookup) and your IP should resolve to the hostname (reverse lookup)
In simple terms if you ping mail.yourdomain.com it should resolve to 1.2.3.4 and if you do a reverse lookup of 1.2.3.4 it should resolve to mail.yourdomain.com
Make sure you have DKIM enabled
DKIM is a domain authentication method that digitally signs your emails to confirm that they do indeed come from a legitimate server.
DKIM can be a complicated process to configure but is well worth the effort however if your domain is being hosted by your ISP you can talk to them about enabling DKIM.
DKIM is also specific to the mail server software you are using so you need to research for DKIM packages that will work with your mail server.
Once you have DKIM installed for your server you need to create a key pair for your domain to add to the DKIM package then you need to publish your public key in your DNS zone with a TXT record usually with the name default._domainkey.yourdomain.com
Create a SPF record
SPF or sender policy framework is another TXT record that allows other mail server what your sender policy is. This in plain terms notifies recipient mailservers what IP’s, hostnames and MX are allowed to send mail on your domain’s behalf.
When configuring your SPF records it is very important to include all the mail servers that are allowed to send mail for your domain, this is especially true when using hard fail (-all)
your SPF record has a specific format and this format should be adhered to, to ensure that the SPF record is honoured
here is an example of a SPF record
v=spf1 a:mail.yourdomain.co.za mx IP4:a.b.c.d/32 -all
here is what each field mean
“v=spf1” specifies the version of SPF record in use
“a:mail.yourdomain.com” specifies what hostnames are allowed to send mail for your domain, there may be more that one “a:” entry and it is important to specify ALL hostnames that send mail for your domain
“mx” specifies that the hosts configured as MX records for your domain are able to send mail for your domain
“IP4:a.b.c.d/32” this is a list of IP’s in CIDR format that are able to send mail for your domain again there may be more that one “IP4:” entry and it is important to specify all IP ranges that are able to send mail for your domain
“-all” this lets mail servers know what to do when SPF fails your options are
- -all: Hard fail – Reject the message completely
- ~all: Soft fail – Accept the message but (possibly) add additional headers to the message
Create a DMARC policy
DMARC stands for “Domain-based Message Authentication, Reporting & Conformance.” DMARC is a protocol that uses Sender Policy Framework, (SPF) and DomainKeys identified mail (DKIM) to determine the authenticity of an email message. DMARC requires both SPF and DKIM to fail in order for it to act on a message.
Your DMARC record is published alongside your DNS records including:
- SPF
- A-record
- CNAME
- (DKIM)
Unlike SPF and DKIM, a properly configured DMARC policy can tell a receiving server whether or not to accept an email from a particular sender. It is important to note that not all receiving servers will perform a DMARC check before accepting a message, but all the major ISPs do and its implementation is growing.
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=0:d:s
“v=DMARC1” This is the identifier that the receiving server looks for when it is scanning the DNS record for the domain it received the message from. If the domain does not have a txt record that begins with v=DMARC1, the receiving server will not run a DMARC check.
“p=none” This part tells the receiving server what to do with messages that fail DMARC. In this case, the policy is set to “none.” This means that the receiving server will take no action if a message fails DMARC. This can still be valuable for a sender, because DMARC sends reports that alert the domain administrator of any DMARC failures.
“p=none” is generally a recommended first step on the way to implementing a policy that will drop unauthorized mail. Most people are surprised to find out how many different people/groups/organizations are sending mail (legitimate or otherwise) on behalf of their domain. Other options for the p= field are “quarantine” and “reject.” “Quarantine” will set messages aside for further processing; in most cases this means it will be sent to the spam folder. “Reject” will stop the messages outright.
“rua=mailto:dmarc@yourdomain.com” This part tells the receiving server where to send aggregate reports of DMARC failures. These aggregate reports are sent daily to the administrator of the domain that the DMARC record belongs to. They include high level information about DMARC failures but do not provide granular detail about each incident. This can be any email address you choose.
“ruf=mailto:dmarc@yourdomain.com” This part tells the receiving server where to send forensic reports of DMARC failures. These forensic reports are sent in real time to the administrator of the domain that the DMARC record belongs to. These forensic reports contain details about each individual failure. This email address must be from the domain that the DMARC record is published for.
“rf=afrf” This part tells the receiving server what kind of reporting the policyholder wants. rf stands for reporting format. In this case rf=afrf means aggregate failure reporting format.
“pct=100” This part tells the receiving server how much of their mail should be subjected to the DMARC policy’s specifications. In this case, if the p= was set to reject, 100% of the mail that fails DMARC would be rejected.
There are a number of other mechanisms that can be included in a DMARC record. A few notable ones include:
“sp=” This part would tell the receiving server whether or not to apply the DMARC policy to sub domains.
“adkim=” This sets the DKIM alignment. It can either be set to “s” for strict or “r” for relaxed. Strict means the DKIM portion of DMARC authentication will only pass if the d= field in the DKIM signature EXACTLY matches the from domain. If it is set to relaxed, messages will pass the DKIM portion of the DMARC authentication if the DKIM d= field matches the root domain of the from address.
“ri=” This sets the interval for how often you want to receive aggregate reports about DMARC failures.
Conclusion
While this list is by no means complete following these guidelines should increase your chances of mail ending up in the recipient’s inbox and not his junk folder.