Tech – Current Training Article –
Protect your email systems from Email Impersonation!
I major problem on the Internet is junk email claiming to be from domains that it really isn’t from. Besides being unwanted to begin with, when someone impersonates your domain it can adversely affect the reputation of your server, and thus the deliverability success of your legitimate email.
In order to protect your domain’s reputation and the Internet in general, there are three systems that you need to implement: SPF, DKIM, and DMARC
SPF is a type of record that gets added to your DNS records which announces which valid IPs can send email on your behalf.
For example, to advise others to reject all email accept from one IP address:
webmagic.com. IN TXT “v=spf1 a ip4:18.104.22.168 -all”
If you also send email from, say Office 365 or Outlook.com, you can include a bit to automatically include Microsoft’s servers. This has the benefit of being automatically updated over time:
webmagic.com. IN TXT “v=spf1 a ip4:22.214.171.124 include:spf.protection.outlook.com -all”
If sending email via Mailchimp, this could e added also:
webmagic.com. IN TXT “v=spf1 a ip4:126.96.36.199 include:spf.protection.outlook.com include:spf.mandrillapp.com -all”
There are plenty of detailed online tutorials for setting up SPF records, so we won’t duplicate it all here. One thing often lacking in these tutorials though is the fact that an SPF record only protects a single domain, and not the sub-domains underneath it. If you want to allow or reject email claiming to be from a sub-domain, you have to add that to DNS too. A sample ‘reject all’ record for a sub-domain would look like this:
subdomainname.webmagic.com. IN TXT “v=spf1 -all”
DKIM is for digitally singing outgoing email. A key is generated on your server, and your mail server is configured to sign outgoing mail with it. Then a matching public key is published in DNS. For example:
default._domainkey.webmagic.com. IN TXT “v=DKIM1; k=rsa; ” “p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAYDCMT+Ui4OlfeV4DrN321GGVE5fqudq8M/kqlWlPS8eOkNivMoivwDDzQ/pXjmXo6Mj/ir6yEPTnpBS30LKbqlpTuTAGnFz8JoA0ZY/HyqBTxFY2xXTS3D/Fy7A8txB1w1IXpR9H8Jx2H8TWVwjqZy7SDjDzSoGE1HbZSy/7XwIDAQAB”
If sending email through a third party service (ie: MailChimp, etc.), you can often upload your private key to this service so that they can sign email for your domain.
DKIM records are better if they are aligned – that is, matching the domain of the email address they come from. In other words, ‘webmagic.com’ could sign email for ‘arcade-museum.com’ if WebMagic’s public key is included in the DNS record for arcade-museum.com contained WebMagic’s DKIM public key, but it would be better if email send on behalf of arcade-museum.com (even if sent by webmagic.com) is signed with the key for arcade-museum.com (and such key is included in the DNS record for arcade-museum.com. On Linux, opendkim (which can be added to Postfix and Sendmail) can be configured to automatically utilize multiple keys and to use the appropriate one depending on the email address of email address being sent.
DMARC is another record published in DNS and provides two very important functions: (1) It advises the world on how you want it to treat email that fails to pass SPF or DKIM checks, and additionally, (2) provides an email address for other participating ISPs to send you reports on email deliverability. This helps you know if your systems are configured correctly and that your mail is not marked as spam. It also lets you know how much junk email trying to impersonate your domain is being rejected, and what it is coming from. Since multiple ISPs can send reports in a single day, it can be tedious to go through them. There are online services such as DMARC Analyzer that can parse these reports for you and automatically email you notifications if certain levels are met for further review. (such as too high an email sending failure rate). When setting up a DMARC record, at first you would suggest no action be taken for non-matching email (“p=none”). When you think you have your systems set up properly and your legimate email is being flagged correctly, you can move to a more restrictive level for non-matching email (“p=quarantine” or even “p=reject”). A sample DMARC record might look like:
_dmarc.webmagic.com. IN TXT “v=DMARC1; p=quarantine; rua=mailto:email@example.com; ruf=mailto:firstname.lastname@example.org; fo=1; adkim=r; aspf=r”
Note: unlike SPF, a DMARC record covers sub-domains, so a single record protects all.
While it is better for SPF AND DKIM to match when an email is received, an email is generally considered valid if either one matches.
You might ask, “Why do I need DKIM” if I’m already using SPF? Well, SPF attempts to authenticate the IP addresses the emails are coming from. If your recipient automatically forwards email addresses to another account (ie: Gmail or Office 365), the IP address will not match. DKIM provides another way to authenticate email, provided that the forwarding service doesn’t tamper with the message as it forwards it (most servers handle this email graciously now).
We hope you find this information helpful. For customized assistance, please contact a WebMagic team member.