Email spam is an ongoing battle for mail administrators, and while cluttering up a mailbox with junk mail is undesirable, phishing campaigns can be a serious security issue. Those with malicious intent are highly motivated, and their practices have evolved. Fortunately, the technologies available to protect against such attempts have also improved.
Several technologies can help your organization validate that an email has been sent from an authorized source. Office 365 expanded its support for some of these technologies earlier this year; however, these features seem to get tiny talk.
SPF (Sender Policy Framework)
SPF is pretty well-known and commonly implemented. If you're unfamiliar with SPF, it's a DNS record (TXT) containing a list of approved senders by IP address, domain name, or some other mechanism. With Exchange Online, Microsoft provides the information to configure your SPF record properly. However, if you have third-party services sending on your behalf, you may need to customize the provided value. There are some limitations on the number of DNS queries you can have in your SPF record, and it's not uncommon to see syntax errors, so you should always validate your SPF record with one of the online validation tools. If a message is received from a source not authorized in the SPF record, you, as the receiving party, can do what you choose with that information. You may decide to block the message, rank it higher as prospective spam, or ignore it.
How the Sender Policy Framework Works
To facilitate our discussion, let's assume this setup:
your business domain is domain.com; you will send emails to your employees and customers from user1@domain.com;
your email delivery server, which sends the email for you, has an IP address of 192.168.0.1;
Some attackers use a scam email server at IP address 1.2.3.4 to try to send spoofed emails.
When an email delivery service connects to the email server serving up the recipient's mailbox:
The email server extracts the domain name from the envelope from the address; in this case, it's business.com;
The email server checks the connecting host's IP address to see if it's listed in the ain.com's SPF record published in the DNS. If the IP address is listed, the SPF check passes, but it is not.
For example, let's say your SPF record looks like this:
v=spf1 ip4:192.168.0.1 -allThis means that only emails from IP address 192.168.0.1 can pass the SPF check, while all emails from IP addresses other than 192.168.0.1 will fail. Therefore, no email from the scam server at the IP address 1.2.3.4 will ever pass the SPF check.
SPF DNS lookup limit
Each time an email message hits the email service host, the host looks up in the DNS to perform an SPF check. Care has been taken to prevent this from becoming a Denial of Service (DoS) attack.
The SPF specification imposes that the number of mechanisms and modifiers that do DNS lookups must not exceed ten per SPF check, including any lookups caused by using the "include" mechanism or the "redirect" modifier. If this number is exceeded during a check, a PermError is returned.
What if your SPF record exceeds the 10-DNS-lookup limit?
If your SPF record exceeds the 10-DNS-lookup limit, SPF authentication returns a permanent error indicating "too many DNS lookups". An SPF permanent error is interpreted in DMARC as a failure. Therefore, when this happens, it has a negative impact on your email deliverability.
DKIM (DomainKeys Identified Mail)
DKIM uses a public/private key instead of the published TXT record to sign messages. One advantage of DKIM over SPF is there is no limit to the number of partners you can authorize to send on your behalf (assuming they support DKIM). If you use several third-party senders, you likely have encountered issues when including them in your SPF. Another way to address the SPF limitation is to have senders send messages under a subdomain and publish a separate SPF. What Does It Protect? DKIM is also looking at the "Mail From" field and will show a "None", "Pass", or "Fail" once the message has been evaluated. The same potential phishing issue exists with DKIM, where the "Mail From" does not necessarily match the "From" field that the user sees.
Create DKIM records for Office 365
To set up DKIM in Office 365, you must first create 2 CNAME-typed DKIM records on each domain. These records look like the following:
Host name: selector1._domainkey.CompanyDomainNamePoints to: selector1-CompanyDomainName-com._domainkey.TenantName.onmicrosoft.comHost name: selector2._domainkey.CompanyDomainNamePoints to: selector2-CompanyDomainName-com._domainkey.TenantName.onmicrosoft.comEnable DKIM signing in Office 365
Next, you need to enable DKIM signing in Office 365. Log into the Exchange admin centre, then go to protection > dkim, choose the domain you want to enable DKIM on, then click Enable on the right pane.
Note that this operation will fail if the 2 DKIM records you published in the DNS haven't taken effect yet. When this happens, wait some time and try again. If you keep getting this error, check if your DKIM records are published correctly.
DMARC or Domain-based Message Authentication Reporting and Conformance
Once you have correctly configured SPF and DKIM, you may start using DMARC. Configuration of DMARC involves the creation of a DNS TXT record to advise recipients of what to do with DMARC failures and where to send the DMARC reports.
h. Even if you can't get to the point where you configure an action of "quarantine" or "reject", you can still use DMARC to help mitigate phishing attempts.
DMARC, among other things, can answer the above phishing issue. DMARC looks for a passed SPF or DKIM but also looks for "alignment" of the "Mail From" and "From" fields. Additionally, your configuration of DMARC allows you to tell recipient mail servers what to do with a message if DMARC fails.
This record is a TXT record, but instead of being at the root like your SPF, the record will have a hostname of "_dmarc". Some DNS providers do not support hostnames that begin with an underscore, so you may need to switch DNS providers if you want to configure DMARC. A typical DMARC record might look like this:
Host: _dmarc TXT Value: "v=DMARC1; p=none; pct=100; rua=mailto:dmarc_aggr@dmarc.com; ruf=mailto:dmarc_fail@dmarc.com;"
Walking through the logic of the text record :
v=DMARC1; = This just indicates the version (1) that is being used for DMARC
p=none; = The policy is set to "none" in this case, meaning that recipient servers need to take no particular action on your messages if they fail authentication (you can also choose to advertise quarantine or reject–more on that later)
rua=mailto:<dmarcfeedback@contoso.com>; = This is where you can specify a place to send failure reports (aggregate). You can also choose to get message-specific reports using ruf=
fo=1 = This indicates that a DMARC failure report should be produced for anything other than a "pass" result on either DKIM or SPF; other options are 0 (report only if both mechanisms fail), d (DKIM failures only), or s (SPF failures only)
Comments