While there are great benefits to email’s open and decentralized nature, this freedom also makes email easy to abuse. For example, any server connected to the internet can send an email to your friend pretending to be from you. Read on to see how we can protect your custom domain from these kinds of attacks.
SPF (strongly recommended)
The Sender Policy Framework (SPF) record basically tells the world what hosts or IPs are allowed to send email for your domain. When email servers receive email that claims to be from your domain, they can look up your SPF record and if the sending server is included. While not required, we strongly recommend you set up a SPF record that includes ProtonMail. This will not only make your email seem more legitimate and thus less likely to be sent to spam folders, but it will also help protect your domain from attackers who send emails with forged headers pretending to be you.
The recommended SPF record to add is:
The “include:_spf.protonmail.ch” means you allow the servers of ProtonMail to send on behalf of your domain. If you want to keep an existing SPF record, simply add the “include:_spf.protonmail.ch” to it right after the “v=spf1”. The “mx” also includes your domain’s MX records. The “~all” means any other servers not included should be treated as a softfail, which means accept the email but marks it as SPF failed. This is better than “-all”, which would reject emails that failed SPF, and cause delivery problems for certain legitimate emails. For example, SPF often fail during email forwarding where you send to address A, which automatically forwards to address B.Once we detect your domain’s SPF record includes ProtonMail, the SPF button in Settings->Domains will turn green.
Domain Keys Identified Mail (DKIM) is a method of email authentication that cryptographically verifies if an email is sent by trusted servers and untampered. Basically, when a server sends an email for your domain, it will calculate an encrypted hash of the email contents using a private key (that only trusted servers know) and add it to the email headers as a DKIM signature. The receiving server will verify the email contents by looking up the corresponding public key in your domain’s DNS records, decrypting the encrypted hash, and calculating a new hash based on the email contents it received to see if the decrypted hash matches the new hash. If there is a match, then the email must not have changed and so DKIM passes. Otherwise, DKIM fails and the email is treated with suspicion.
We use CNAME records to manage automatic DKIM key rotation, which is an accepted security best practice. We ask you to add and keep three CNAME records. One of them is always used for an active key, while the other two allow our system to smoothly rotate to a new key when necessary.
It all sounds complicated, but implementing DKIM for your domain is simple in ProtonMail. It will take your DNS a couple of hours to verify your custom domain once. Once your custom domain is verified, ProtonMail will generate the host names and values you will need for your DNS to create the CNAME records that are necessary for automatic DKIM key rotation. We will send you an email notification informing you that your custom domain, host names, and values are ready.
Instructions for new users
Log in to your account, go to Settings, and click on Custom Domains in the left-hand toolbar. Once the Custom Domains window is up, click on the DKIM tab.
Here you will see the three host names and values that you will need to add to your DNS settings. Once you add these records, ProtonMail will handle the rest for you. Following the current security best practices, every six months we will generate a new 2048-bit key and use it to sign your emails.
The CNAME records you add to your DNS must be an exact match with the ones shown in your setup wizard. Once we detect these records in your DNS, the DKIM button in Settings -> Custom Domains will turn green. We will then notify you and start signing outgoing emails from your custom domain with DKIM, just like we do for other ProtonMail addresses.
IMPORTANT: Some registrars do not accept CNAME values with a period at the end (while others require it). If your registrar does not accept your CNAME records, please delete the period at the end of each CNAME value and try again.
Instructions for users that use DKIM manual key rotation
If you previously configured DKIM manual key rotation using a TXT record, you will need to remove this record from the DNS before you can enter the CNAME records. You need to reconfigure your DNS with CNAME records because they give us the ability to set up automatic key rotation while your current TXT record does not.
Once you have deleted this TXT record, you can follow the instructions for new users. DKIM will stop signing your emails once you delete the TXT record. To maintain DKIM protection, you should enter your CNAME sectors and values into your DNS immediately.
We strongly advise everyone that currently uses DKIM manual key rotation to upgrade to the new automatic key rotation. Not only will this remove the need for you to rotate your keys manually, but it will also automatically upgrade your key strength (if you were using 1024-bit keys).
As you were learning about SPF and DKIM, you may have wondered what exactly should the receiving server do if it gets an email which failed the checks. This is where Domain-based Message Authentication, Reporting and Conformance (DMARC) comes in to allow the domain owner to specify what should happen with failed emails as well as get feedback. Basically, there are three actions for receiving servers to take if BOTH SPF and DKIM checks fail: none, quarantine, and reject.
A basic DMARC TXT record:
The “p=” specifies the action to take for emails that fail DMARC and here, “none” basically means don’t do anything, accept the email as usual.
The “p=quarantine”, tells the receiving server to send failed emails to the spam folder. We recommend you to set this value.
Once you are confident your legitimate emails are passing DMARC, you may want to set it even more aggressively to “p=reject”. This tells the receiving server to not accept failed emails. We recommend “p=reject” if you think you are likely to be a target of spoofing. For example, Yahoo, PayPal, and eBay uses “reject” to prevent spammers from impersonating them.
The “rua=” is an optional parameter that specifies an email address where other email services can send aggregate reports to so you can see how many of your emails are failing DMARC.
However, keep in mind there are risks for choosing these actions. For instance, when you email a mailing list which then forwards to individual recipients, this will break SPF. Annoyingly, some mailing lists also change the contents of the email, which breaks DKIM, causing DMARC to fail and thus delivery issues if you have quarantine or reject.