BLUEHORNET USER GUIDE EMAIL AUTHENTICATION AND DOMAIN MONITORING TOOLS This user guide provides guidelines and recommendations for setting up your business s domain authentication to improve your deliverability rating. WHY IS EMAIL AUTHENTICATION IMPORTANT? The cornerstone of doing business on the internet is trust, and this user guide will explain how to verify that the emails you send are trustworthy as well as explain how to monitor fradulent emails claiming to be from your domain. As a way to combat spoofing and phishing attacks (where senders with malicious intentions impersonate a brand to coax an action or sensitive information from the recipients), Internet Service Providers (ISPs) use Sender Policy Framework (SPF) and Domain Keys Identified Mail (DKIM) to verify that your email was sent from the domain it says it was sent from. We urge you to set up not just one, but both of these. Following these methods decreases your chances of blocking and bulking, and helps ensure your emails reach the inbox. Without them, ISPs have no way of knowing if your message is legitimate or not. Once you have SPF and DKIM in place, you should consider implementing Domain-based Message Authentication, Reporting, and Conformance (DMARC). While not required, DMARC removes the guesswork from ISPs by telling them that emails from your domain should have SPF and DKIM in place. If someone tries to send an email from your domain, but does not have these email authentication pieces in place, the ISP instantly knows the message is fraudulent and won t deliver it. Furthermore, DMARC has a reporting component so ISPs can let brands know which messages sent from their domain name are compliant. This allows brands to have some insight into the type and volume of fraudulent emails sent impersonating their brand. If you don t have these methods in place, now is the time to get started. In this guide you will find a further explanation of each, as well as simple instructions for implementation. Anyone familiar with DNS entries and zone files will be able to set these up.
ABOUT SPF SPF is used to show that you are authorized to send from your Internet Protocol (IP) address. Benefits Without an SPF, ISPs and email providers will be less likely to accept mail from you and will be more likely to route you into a spam folder. BlueHornet uses a simple, one-line text record to show your sending IP is authorized. Implementing SPF The following one line of code is entered into your Domain Name Server (DNS) zone file of the sending domain: v=spf1 include: ~all Because all of BlueHornet s IPs contain BlueHornet. com in their Reverse Domain Name Server (RDNS) lookup, this line of code shows that the sender is authorized to use any IP address on the BlueHornet system. If for some reason you already have SPF in place (for another ESP or your in-house system) add the string below to your current SPF record: include: More than 10 entries to an SPF record can cause the SPF to timeout and seem like it doesn t exist. The SPF record is usually coded as a text record for most DNS providers. There are two great tools for checking SPF records: kitterman.com/spf/validate.html otalliance.org/resources/ authentication/spflookup.html
ABOUT DKIM DKIM is used to show that you are authorized to send from your domain. Benefits Without DKIM, you will likely not get to the inbox. During the 2012 holidays, BlueHornet saw that mail without a first-party DKIM signature did not reach the inbox. Please note that while BlueHornet has been attaching a DKIM signature to our mail for years, it is not the same as having a first party DKIM signature. First party DKIM is a DKIM signature that is specific to your sending domain. Without a first party signature some ISPs (such as Gmail) attach a via BlueHornet tag onto your message. DKIM is usually entered as a text record for most DNS providers. There are no tools to test DKIM without doing an email send. After the signature is made live you can send a live message test and check the header for validation of DKIM. BlueHornet offers two types of DKIM: Client-hosted DKIM (preferred) BlueHornet-hosted DKIM Implementing DKIM Client-hosted DKIM This type of DKIM is preferred due to the speed with which it can be implemented. It is also less intrusive to your DNS. Client-hosted DKIM requires you to send the following information to the BlueHornet DMS team, via your Account Management contact: a. Client sending domain b. A technical contact email address that will be used for the policy record Once the above data is passed to BlueHornet s DMS team, a text file will be created and passed back to the client with two DKIM records and two entries for the policy record. These entries and policy records will need to be added into your DNS zone file through your DNS provider page. Upon completion of these entries, the BlueHornet DMS team will need to be notified to verify entries are complete and correct by sending an email to your Account Management or DMS contact. BlueHornet DMS will make the entry live, and your Account Management contact will confirm back to you.
BlueHornet-hosted DKIM This type of DKIM takes 3-5 days for implementation and requires that you designate your DNS to BlueHornet s nameservers. The following entries will need to be made to your DNS zone file: Domain Type Value _domainkey.example.com TXT o=~; r=domainkeys@example.com bh._domainkey.example.com NS ns1.p07.dynect.net If your DNS provider is DYN DNS you will need to host all of DYN s nameservers as follows: bh._domainkey.example.com NS ns1.p07.dynect.net bh._domainkey.example.com NS ns2.p07.dynect.net bh._domainkey.example.com NS ns3.p07.dynect.net bh._domainkey.example.com NS ns4.p07.dynect.net ABOUT DMARC DMARC is an authentication method that allows the sender to choose whether or not ISPs accept mail that does not have a valid DKIM and SPF signature. DMARC is used by entities who send email that includes sensitive financial or personal information and requires that the sender have DKIM and SPF in place. DMARC can be set up in three different modes: None - Report only. Log affected messages on the daily report. Quarantine - Mark affected messages as spam and send them to spam folder. Reject - Block mail by cancelling the message at the SMTP layer.
Implementing DMARC Tag Required Purpose Sample v required Protocol version v=dmarc1 p required Policy for domain p=quarantine pct optional % of messages subjected to filtering rua optional Reporting URI of aggregate reports sp optional Policy for subdomains of the domain pct=20 rua=mailto:aggrep@example.com sp=r aspf optional Alignment mode for SPF aspf=r v = DMARC version p = The policy type you want to implement You can select one of three DMARC flags for increasing levels of control: None - Take no action. Log affected messages on the daily report. Quarantine - Mark affected messages as spam. Reject - Cancel the message at the SMTP layer. Always start implementing DMARC using the None flag. Check the reports to ensure the flag is working correctly before implementing Quarantine or Reject. Gradually modify your DMARC policy flags from monitor to quarantine to reject to improve control. The below string shows how to implement DMARC in a reporting only method. It will need to be entered into your DNS zone file: DMARC records are entered as text records. DMARC signatures can be checked here: otalliance.org/resources/ authentication/spflookup.html v=dmarc1; p=none; rua=mailto:postmaster@your_domain.com Contact Us www. (866) 586-3755 sales@ Twitter: @bluehornetemail