Advanced DNS & ExchangeDefender

ExchangeDefender supports and implements many of the popular DNS-based email auth/signing protocols like SPF and DKIM. To properly implement, manage, and troubleshoot these mechanisms some advanced DNS understanding is required and we hope that this article gives you some basic understanding of how ExchangeDefender relies on these protocols, how to troubleshoot issues, as well as best practices.

DNS (Domain Name System) is often referred to as the “phonebook of the Internet” as it translates easy to remember server names (www.exchangedefender.com) to IP addresses (65.99.255.247). When organizations want a domain name for their company, they go to a business called DNS registrar (Network Solutions, GoDaddy, NameCheap) who registers the domain name and tells the Internet where to find the name servers for the new domain. Name servers are operated by ISPs, major cloud providers, and DNS services that hold the address book for the organization – and their job is to hold all the server/hostname information about your domain and respond to DNS queries.

Every time a computer on the Internet is looking for your domain name (to send you email, to look at your web page, etc) a DNS query is made by their computer and often saved locally for a short period of time (caching). DNS servers are a glue that holds the whole Internet together, so when there are DNS issues they often cause cascading problems with services that rely on them like web, email, VoIP, etc.

We can troubleshoot DNS by simulating DNS lookups using a tool called nslookup. Here are some examples:

Mail Exchanger (MX) record designate the mail servers that all mail for your domain should be sent through. For all ExchangeDefender customers, that MX record is:

To check if your MX record is configured properly, you can use the nslookup tool:

If you see more than this in your MX listing, your email is not configured properly

Best practices: We strongly encourage use of the single MX record. Clients at times use masking hostnames for vanity purposes, or add a third party caching MX record for failover purposes, both of which our support team will ask you to remove before doing any kind of troubleshooting.

SPF (Sender Policy Framework) record is used as an email authentication method to prevent sender address spoofing/forging, the most popular form of email identity theft on the Internet. Setting up an SPF record essentially designates a list of mail servers that may send email on behalf of your domain and any mail server that runs an SPF check can verify if the email is in fact legitimate. Using an SPF record with ExchangeDefender is really simple, it’s just “v=spf1 include:proxy.exchangedefender.com -all”

The SPF record above is published in ownwebnow.com’s DNS and every time someone receives an email from an @ownwebnow.com address the remote server will check if the mail server delivering the message is authorized to relay it. In our case, our SPF record includes exchangedefender.com’s SPF record, allowing all the mail servers that exchangedefender.com uses to relay email to deliver messages on behalf of ownwebnow.com. When a mail server receives an email from a different source, that is not defined in our SPF record, the message is considered fraudulent and discarded.

Best Practices

Most organizations mess up their SPF records. If at all possible, leave the SPF record as recommended by ExchangeDefender. It bears repeating, most organizations mess up their SPF records. After you put any new SPF in production as requested by another organization, please use an SPF checking tool to make certain your new record is valid. ExchangeDefender exclusively recommends -all as the default mechanism, meaning if messages are coming from a mail server not listed in the SPF record the message should not be accepted. Use of the permissive mechanism, ~all, is not recommended or supported when it comes to spoofing or bouncebacks because those domains are often abused in backscatter SPAM schemes. For organizations that are unable/unwilling to follow this advice, ExchangeDefender has an exclusive “override” facility which is designed to block mail spoofing. This feature is available at https://admin.exchangedefender.com under the Domain Administrator, Mail Delivery > Phishing Options. ExchangeDefender will automatically move any mail that is originating outside of the ExchangeDefender network using your domain name into SureSPAM quarantine. This way you can use a permissive SPF record, and still have anyone forging your domain name end up in SureSPAM and out of your user’s mailbox. https://exchangedefender.com/docs/domain#mail-delivery-phishing-options

DomainKeys Identified Mail (DKIM) is an email authentication mechanism that uses private/public key cryptography to authenticate that the message is really coming from a legitimate and designated source. DKIM public key is generated by ExchangeDefender and placed in your DNS zone as a txt record. DKIM private key is generated by ExchangeDefender as well, and an encrypted signature is included in every email that goes through the ExchangeDefender network. When the recipients mail server receives a message from you, they look up the DKIM public key via DNS use it to decrypt the signature. Since only the sender (ExchangeDefender, with the private DKIM key) can properly encrypt the signature, there is an additional layer of security assuring the recipient that the message is sent by you.

ExchangeDefender DKIM implementation is simple and handled through our support system at https://support.ownwebnow.com. ExchangeDefender DMARC (SPF & DKIM) Setup Guide - setup full DKIM + SPF + DMARC in under 5 minutes!. Once completed, you can verify it with nslookup:

Once your DKIM is in, please update the original support ticket and we will clear the domain for signing.

Best Practices

As with SPF, DKIM signatures are very specific and leave no room for error, typos, or mistakes. ExchangeDefender encrypts all outbound messages from your domain using default._domainkey name, and we only do so after the domain passes DKIM validation. We do so out of abundance of caution and our experience that it generally takes some checking and tweaking when putting in a new policy in place. For example, if we were to start signing your messages before the public DKIM key has been published in your DNS, remote mail servers would fail validation and reject messages.