Traditionally, anti-abuse mechanisms for incoming email rely on the heuristic examination of the content of the message, and on collectively mantained blacklists of abusive hosts and domains. However, both these mechanisms have a problem: they can only work effectively “ex post”, by detecting the pattern underlying a certain quantity of past abuses and preventing further abuses of the same type.
A better paradigm is to allow every source that originates email messages to publish in advance some information and some policy to allow a destination server to determine the legitimacy of an incoming message even without any past history.
This is why all legitimate email sources, and especially those who send legitimate commercial, bulk or automated email (advertising, newsletters, transactional emails…), are expected to implement these protocols; most email providers, especially the biggest, use information from these protocols to reject or mark illegitimate messages and to prevent phishing, and at the same time to evaluate the originating domain’s reputation.
If you are not familiar with these technologies, we recommend you to read the specific pages on SPF, DKIM and DMARC before proceeding.
Implementing SPF and DMARC just requires some organizational effort; they do not require technical activities on your mail servers. DKIM, on the other hand, requires some email manipulation, so you will need to install a DKIM-signing application or, if your mail server application already provides it, turn it on in its configuration.
To implement SPF, you need to build a list of the hostnames/IP addresses of all email servers that will be sending email to the rest of the Internet; as you will also aim for SPF alignment in DMARC, you need to include all servers where messages having “From: anything@yourdomain” will be created. If you already enabled IPv6 connectivity on your mail servers, you have to remember to list IPv6 addresses as well – or, if you use name-based mechanisms such as “mx”, to add the proper AAAA records for the hostnames of your mail servers to your domain name zone.
Of course your main email server will be the first thing on your list, but, if you are an organization, it is likely that many other computers will be sending email for you and your users; it may be automatic reports created by hosts running some other services, or it may be email sent on your behalf by another company from which you bought a cloud-based service, such as newsletter platforms or customer relationship tools.
Once you create this list, you have to convert it into an SPF policy record, that you then have to publish in your DNS zone on your authoritative name servers. A typical SPF record would be something like:
v=spf1 a mx ip4:… ip4:… ip6:… ~all
This would allow all computers having a hostname in your domain, all servers listed as MX for your domain, and all the specified IP addresses to send legitimate email, while any other message will be marked as dubious. Also, you may use the “include” SPF mechanism to refer to the SPF record of any third-party email service providers you use, and allow verification to be successful if the originating server is included in their record; however, do not abuse this mechanism, as the standard puts an upper limit of ten maximum DNS queries to be able to resolve an SPF record, also counting recursive inclusions.
You may start with “~all” and use DMARC to monitor its effects and to integrate the list with any missing legitimate source that you may later notice. Only when you are reasonably sure that the list is complete, you may replace “~all” with “-all”, which will request the rejection of messages coming from unlisted sources.
To install DKIM and turn it on, you will have to refer to the specific instructions for your email server application and/or DKIM implementation, or to your vendor. In any case, this will involve creating a key for DKIM signing on each of your outgoing mail servers, and publishing the related public key in your DNS zone. You should assign a different selector to each of your keys, possibly using a name that helps you identify where it is deployed, and that includes a timestamp or iteration count; this will help in future key rollovers, where you will just assign a new timestamp/count to the new key, publish the new key in the DNS without removing the old one, and only start using the new key and remove the old key’s record after the DNS propagation time has passed.
As for SPF, you should deploy DMARC in monitoring mode for a while and keep an eye over DKIM verification failures; also, you should use online tools such as DKIM Validator to check your deployment.
Finally, DMARC deployment does not require any technical activity; you just need to create a DMARC policy statement and publish it in your DNS zone. Initially, as you deploy SPF and DKIM, you could publish a monitoring DMARC record such as this one:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain; ruf=mailto:dmarc-copies@yourdomain
This will request a report on all messages failing DMARC validation to dmarc-reports@yourdomain and a copy of all messages to dmarc-copies@yourdomain. Be prepared for lots of traffic if you activate this latter possibility; you may want to reduce the number of messages reported by adding “pct=20” to get only one message on five, etc. Also, please remember that, if you want to direct either type of reports to an email address in another domain, you have to publish a specific DMARC record in that domain’s zone as well, as a way to authorize the reception of DMARC messages.
You then have to examine the reports and messages you will receive and look for legitimate messages that are failing validation, which may lead you to fix your SPF and DKIM configurations. If you don’t want to do this yourself, there are companies that will sell you a DMARC report analysis service.
After you gain some confidence in your configurations, you can start to request quarantine for part of the messages that fail validation. For example, you may now say:
v=DMARC1; p=quarantine; pct=5; rua=mailto:dmarc-reports@yourdomain; ruf=mailto:dmarc-copies@yourdomain
This will quarantine 5% of the failing messages, while the other 95% will be delivered as usual. In this way, if you still have configuration issues, you will start to receive some complaints by your users about a limited number of “lost” emails, and start to address them. After a while, you can try raising the percentage in multiple steps.
Finally, you can move to “p=reject”, again starting with a small percentage and increasing it gradually. This will often break some legitimate uses of your email addresses, such as writing to mailing lists with older list servers, or to forwarding aliases. All of this will need to be explained, prompting the affected users to change their behaviours or update their configurations.
In particular, as SPF and DKIM both require that any email from an address in your domain is sent from a server that you control or at least authorize, you will have to tell your users that they can only send email from their address at your domain when using your own servers. It will be impossible for them, even when they travel around, to send an email from their email address at your domain while using some other ISP’s mail server; and if they are on a network that filters outgoing SMTP connections, this may become a real issue – unless you provide a webmail interface.
