Tuesday, April 4, 2017

Prevent Spoofing Email Attack – Steps to Implement SPF, DKIM and DMARC on O365

1 – Implement SPF
An SPF TXT record is a DNS record that helps prevent spoofing and phishing by verifying the domain name from which email messages are sent. SPF validates the origin of email messages by verifying the IP address of the sender against the alleged owner of the sending domain
Requirements for your SPF TXT record and Office 365
If you set up mail when you set up Office 365, you already created an SPF TXT record that identifies the Microsoft messaging servers as a legitimate source of mail for your domain. This record probably looks like this:
v=spf1 include:spf.protection.outlook.com –all
If you have a hybrid deployment (that is, you have some mailboxes on-premises and some hosted in Office 365), or if you’re an Exchange Online Protection (EOP) standalone customer (that is, your organization uses EOP to protect your on-premises mailboxes), you should add the outbound IP address for each of your on-premises edge mail servers to the SPF TXT record in DNS.
A typical SPF TXT record for Office 365 has the following syntax:
v=spf1 [<ip4>|<ip6>:<IP address>] [include:<domain name>] <enforcement rule>
For example, let's say that your domain contoso.com uses Office 365. You add an SPF TXT record that lists the Office 365 messaging servers as legitimate mail servers for your domain. When the receiving messaging server gets a message from joe@contoso.com, the server looks up the SPF TXT record for contoso.com and finds out whether the message is valid. If the receiving server finds out that the message comes from a server other than the Office 365 messaging servers listed in the SPF record, the receiving mail server can choose to reject the message as spam.
Also, if your domain does not have an SPF TXT record, some receiving servers may reject the message outright. This is because the receiving server cannot validate that the messages come from an authorized messaging server.
Example: SPF TXT record for multiple outbound on-premises mail servers and Office 365
In case you are only using Office 365 for outbound emails, you should only have the recommended TXT record:
v=spf1 include:spf.protection.outlook.com –all (the SPF defined for your organization is: v=spf1 include:spf.protection.outlook.com~all)
If you have multiple outbound mail servers, include the IP address for each mail server in the TXT record and separate each IP address with a space followed by an “ip4:” statement. For example:
v=spf1 ip4: ip4: ip4: include:spf.protection.outlook.com ~all
If you know all of the authorized IP addresses, they should be added using the –all (Fail) qualifier. If you’re not sure that you have the complete list of IP addresses then you should use the ~all (SoftFail) qualifier.
In case you are sending messages smarthosted through Office 365 or even if you have a Hybrid environment and you are sending emails to a different Office 365 organization, you will have to add the on-premise IP address in your SPF record AND spf.protection.outlook.com.
Once you have formed your SPF TXT record, you need to update the record in DNS.
If an SPF TXT record exists, instead of adding a new record, you need to update the existing record.
If you already have an SPF record, you should append the new Office 365 values to it, rather than create a new one. You can verify/test the syntax of the SPF with 3 tools : https://support.office.microsoft.com/en-us/article/Tools-you-can-use-to-validate-SPF-records-for-your-domain-92a43f6a-4651-455a-a1cc-300684bedcfa?ui=en-US&rs=en-US&ad=US .
SPF is designed to help prevent spoofing, but there are spoofing techniques that SPF cannot protect against. In order to protect against these, once you have set up SPF, you should also configure DKIM and DMARC for Office 365. To get started, see Use DKIM to validate outbound email sent from your domain in Office 365.
2 - Implement DKIM
For more information, please see the link :
Here’s how to enable DKIM signing for your domain if it is hosted in Office 365 (Exchange Online Protection).
The <domainGUID> is the same as the <domainGUID> in the customized MX record for yourdomain that appears before mail.protection.outlook.com. For example, for a domain contoso.com:  
contoso.com.    3600  IN  MX   5 contoso-com.mail.protection.outlook.com.
The <initialDomain> is the same one that you signed up with for Office 365. For example, contoso.com may have signed up with contoso.onmicrosoft.com. Therefore, the two CNAMEs that contoso.com would publish are the following:
Host name:                  selector1._domainkey
Points to address or value: selector1-contoso-com._domainkey.contoso.onmicrosoft.com
TTL:                        3600 
Host name:                  selector2._domainkey
Points to address or value: selector2-contoso-com._domainkey.contoso.onmicrosoft.com
TTL:                        3600 
In the above, the host name does not contain the full FQDN of the domain you are provisioning. You could explicitly include the full thing, that is, instead of Host name selector1._domainkey, you could put selector1._domainkey.<domain>.
Note : For each other domain you have provisioned with Exchange Online, you will need to enable DKIM signing for it. 
For example, if your initial domain is contoso.onmicrosoft.com and you have provisioned contoso.com and fabrikam.com, you will need to provision 4 CNAMEs (two for each domain). The two CNAMEs are so that we can perform automatic DKIM key rotation for you. You need to do this for each domain that you use to send email. DKIM signing does not inherit DKIM settings for other domains that you have provisioned for your organization. For a company trying to DKIM-sign contoso.com and fabrikam.com, you’d have four additional DNS records that look like this: 
selector1._domainkey.contoso.com IN CNAME selector1-contoso-com._domainkey.contoso.onmicrosoft.com
selector2._domainkey.contoso.com IN CNAME selector2-contoso-com._domainkey.contoso.onmicrosoft.com
selector1._domainkey.fabrikam.com IN CNAME selector1-fabrikam-com._domainkey.contoso.onmicrosoft.com
selector2._domainkey.fabrikam.com IN CNAME selector2-fabrikam-com._domainkey.contoso.onmicrosoft.com
Second, you need to enable DKIM-signing for the domain within the service. You can do this in the EAC by going to protection > dkim and clicking Enable for each domain you own.
Alternatively, if you use Powershell:
New-DkimSigningConfig –DomainName <domain> –Enabled $true
3 – Implement DMARC to Prevent Spoofing
Once you have SPF and DKIM properly configured, you may choose to 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.
You’ll likely want to start with an action of “none” meaning that you just want to monitor emails not but take any action. 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.
After determining the action type, you will probably want to use a third-party service to help analyze the DMARC reports. Your published DMARC record will tell recipients that support DMARC to email reports to the address specified in the DNS record. These reports will arrive as a compressed attachment containing an XML file. There are a number of services that can assist with analyzing DMARC reports, some that are free, some that are paid and many that have 30-day trials. For my low-volume testing, I used “dmarcian” but there are a number of others listed at “dmarc.org“. These services will usually provide you two email addresses to publish: one for the aggregate reports and one for failure reports.
Now it’s time to publish your DMARC record. This record is a TXT record but instead of being at the root like your SPF, the record will have a host name of “_dmarc”. Some DNS providers do not support hostnames that begin with an underscore in which case you may need to switch DNS providers if you want to configure DMARC.
A typical DMARC record might look this this:
Host: _dmarc
TXT Value: "v=DMARC1; p=none; pct=100; rua=mailto:dmarc_aggr@dmarcservice.com; ruf=mailto:dmarc_fail@dmarcservice.com;"
- You should replace mailto:dmarc_aggr@dmarcservice.com/ mailto:dmarc_fail@dmarcservice.com with your email address, or you can create an address created especially for reports . 
Again, you should use one of the validation sites like “MxToolbox” to check your published DMARC record.
EOP more-or-less follows the DMARC specification for outbound messages. If a message is outbound from EOP and fails DMARC, then if the action is p=quarantine it will be routed through the High Risk outbound IP pool. However, if the message fails DMARC and the action is p=reject, the message will be rejected. There is no override for outbound email.
If you publish a DMARC reject policy (not p=quarantine, and not p=none), no other customer in Office 365 can spoof your domain because they will not be able to pass SPF or DKIM for your domain when relaying a message outbound through the service.
However, if you do publish a DMARC reject policy but don’t have all of your email authenticated, some of it may be marked as spam for inbound email (as described above), or it will be rejected if you do not publish SPF and try to relay it outbound through the service.
Many companies publish p=none because they are unsure about how much email they may lose by publishing a more restrictive DMARC policy. Microsoft, for example, is not yet in a position to publish p=reject because email sent to other third parties like Gmail, Yahoo, AOL, and so forth may discard important email if it does. Your company may be in the same position.
If you set up DMARC records, you can create an ETR that marks messages as spam for spoofed messages of your company that fail DMARC.
This means that all spoofed email of your domain into Office 365 will be marked as spam, but anywhere else – at Gmail, Yahoo, AOL – will not be marked as spam (at least not due to DMARC). Some legitimate email may be marked as spam, but to get around this either ensure that the email is authenticated by updating SPF records or signing it with DKIM; or, add a safe sender or ETR allow rule for the sender
You should still properly authenticate your email because it reduces false positives and it shrinks the list of exceptions. If you publish p=reject you will no longer need this rule.


Post a Comment