top of page

Improve Email deliveribility

Updated: Oct 4, 2020

3 DNS Records Every Email Marketer Must Know


  • Reverse DNS (PTR)

  • SPF (Sender Policy Framework)

  • DKIM (DomainKeys Identified Mail)

Reverse DNS (PTR)


If you have to get one DNS record right, the reverse DNS record, also know as a PTR record, is the one. As the name states, these records do the reverse of what a normal DNS A record does — they map IP addresses back into host names.

Without a valid reverse DNS record, many ISPs will block your email .


SPF (Sender Policy Framework)


After reverse DNS, email service providers now often require valid SPF (Sender Policy Framework) records.   Even if they do not hard block your email, an absent or incorrect  SPF record may trigger additional email filtering.   This secondary filtering is what often causes the email to fail.

The SPF is a TXT type record that specifies what servers may send email on behalf of your domain.   In the figure below, you can see how a system uses SPF to make decisions about how to route an email.


Create your SPF record

  1. Start with the SPF version, this part defines the record as SPF. An SPF record should always start with the version number v=spf1 (version 1) this tag defines the record as SPF. There used to be a second version of SPF (called: SenderID), but this was discontinued.

  2. After including the v=spf1 SPF version tag you should follow with all IP addresses that are authorized to send email on your behalf. For example: v=spf1 ip4:34.243.61.237 ip6:2a05:d018:e3:8c00:bb71:dea8:8b83:851e

  3. Next, you can include an include tag for every third-party organization that is used to send email on your behalf e.g. include:thirdpartydomain.com. This tag indicates that this particular third party is authorized to send email on behalf of your domain. You need to consult with the third party to learn which domain to use as a value for the ‘include’ statement.

  4. Once you have implemented all IP addresses and include tags you should end your record with an ~all or -all tag. The all tag is an important part of the SPF record as it indicates what policy should be applied when ISPs detect a server which is not listed in your SPF record. If an unauthorized server does send email on behalf of your domain, action is taken according to the policy that has been published (e.g. reject the email or mark it as spam).What is the difference between these tags? You need to instruct how strict servers need to treat the emails. The ~all tag indicates a soft fail and the -all indicates a hardfail. The all tag has the following basic markers: -all Fail – servers that aren’t listed in the SPF record are not authorized to send email (not compliant emails will be rejected). ~all Softfail – If the email is received from a server that isn’t listed, the email will be marked as a soft fail (emails will be accepted but marked). +all We strongly recommend not to use this option, this tag allows any server to send email from your domain.


DKIM Records


Just like SPF records, you are better off having no DKIM record at all than having an incorrect one.   I find DKIM is often misunderstood.  While I see DKIM DNS records being used by some spam systems, the initial intent of DKIM was email security not spam.


The goal of DKIM is to allow you to be certain that a message from domain.com is indeed from domain.com.  To do this, DKIM automatically adds a digital signature to each message.  This signature is based on a private key known only to your server.   You then publish a public key in your domain’s DNS record.   The recipient server can then use the public key to decode the signature and be sure the message has not been altered.   So the main goal here is to someone from tampering with an email while in transit.


While the initial purpose was security, many ISPs, including Gmail, Yahoo and others, do use DKIM information in their screening efforts.  I know with Gmail, if your DKIM signature fails, you have a very high probability that your message will be routed to the spam folder.


Create DKIM records:

Below are steps to enable for Office 365:0


1. In order to DKIM sign your custom domain emails you will need to complete the following steps:

2. Sign in to Office 365 with your admin account and choose Admin.

3. Once in the Admin center, expand Admin centers and choose Exchange.

4. Go to protection --> dkim

5. Select the domain for which you want to enable DKIM and then, for Sign messages for this domain with DKIM signatures, choose Enable. Repeat this step for each custom domain.


Cname Records:


Host name: selector1._domainkey.<domain> Points to address or value: selector1-<domainGUID>._domainkey.<initialDomain> TTL: 3600 Host name: selector2._domainkey.<domain> Points to address or value: selector2-<domainGUID>._domainkey.<initialDomain> TTL: 3600


DMARC Records:


A DMARC record is the core of a DMARC implementation in which the DMARC record rulesets are defined. This DMARC record informs email receivers if a domain is set up for DMARC. If so, the DMARC record contains the policy which the domain owner wants to use. In essence, a DMARC record a DNS (Domain Name Service) entry. One can start using DMARC by implementing a DMARC DNS record. This DMARC record will be used by email receivers which have adopted DMARC. This will result in keeping track of all the messages which have been sent to your domain taking your DMARC policy into account.


The bottom line is that this will empower the organization publishing the DMARC record to instruct how non-compliance should be handled. The messages can be monitored (and delivered), moved to the junk folder or rejected.




Available DMARC policies


Three possible policy settings, or message dispositions, are available:

  • none policy: You just want to monitor the DMARC results and you do not want to take specific action on all the failing emails. You can use the “none” policy to start with DMARC and gather all DMARC reports and start analyzing this data.

  • quarantine policy: You put the emails which fail the checks in quarantine. Most of these emails will end up in the junk folder of the receiver.

  • reject policy: You can reject all emails that fail the DMARC check. The email receivers should do this ‘on SMTP level’. The emails will bounce directly in the sending process.

Choose one of the three DMARC policies to define how you want the email receivers to handle emails which fail the DMARC checks of your DMARC record.



8 views0 comments

Comentários


bottom of page