https://www.esecurityplanet.com/applications/how-to-set-up-imlement-dmarc-email-security.html
Curious about DMARC? Learn how to set up a
basic DMARC email security policy, including SPF and DKIM, in this
eSecurity Planet tutorial.
Domain-based Message Authentication, Reporting and Conformance (DMARC) is an increasingly important approach for helping ensure the integrity of email coming from a given domain.
In this installment, we'll go over how to implement a basic DMARC setup on your own domain. It's a set of processes that includes changing DNS records at the domain registrar and optimally configuring email providers to send signed emails.
At its most basic level, SPF just requires a simple one line change to a domain record in order to work.
Example SPF record:
So, for example, on the domain DMARC.site (a test domain we created just for this article), a basic SPF policy might look like this:
Using the ~ (tilde) is typically preferred in an initial SPF configuration to using a "-" (for example : -all rather than ~all), as the tilde denotes a Soft Fail. That is, using the ~ will still enable mail to be sent that doesn't meet the policy, but the mail won't be identified as non-compliant. To have a strict policy (after initial testing), the '"-" indicates a hard fail if the policy is not met.
In many cases, organizations will have mail servers that are separate from the domain host (i.e. Google, Office 365 or a mail forwarder). So how do you enable an SPF policy to define authorized email servers beyond the domain host? That's where the 'include:' items come in.
For example, to specify an SPF policy that will enable Google's mail servers to send email on behalf of a domain, the following simple policy will work:
There are two elements to DKIM: a DNS record that includes a public cryptography key to help verify that a sender is allowed to send email for a given domain, and the private key that is used for signing outgoing email.
Adding a DKIM entry to a domain's DNS is the same basic process as it was for the SPF record:
There are also multiple online tools that can help generate the public/private key pair; one of the easiest is DKIM Core Tools.
Sample DKIM entry:
The DNS entry is only half the equation for DKIM. The other half is getting a DKIM signer setup on a mail server, which is a process that isn't all that easy for many email systems. The exception is Google's Gsuite, which has a simple how-to guide to get a DKIM signer in place.
Microsoft Office 365 users can benefit from Microsoft's detailed guide on how to implement DKIM signing on that platform.
There are also multiple vendors that can help enable DKIM signing with different approaches, which we will detail in the next article in this series, an outline of vendor solutions.
DMARC policies define how SPF and DKIM records should be handled by email servers. A critically important element of DMARC policy is that it also provides a reporting mechanism so domain administrators can identify if email is failing or if an attacker is attempting to spoof a given domain.
Just like SPF, DMARC is a simple one line entry in the domain's DNS records.
v=DMARC1; p=quarantine; rua=mailto:reports@dmarc.site; ruf=mailto:reports@dmarc.site; adkim=r; aspf=r; rf=afrf
It's important to test configuration for SPF, DKIM and DMARC to make sure that the defined policies work as intended and don't end up blocking legitimate email. That's why starting with relaxed and quarantine options is likely a good place to start.
DMARC reporting and forensics allow an organization to understand what is going on with their email domains. While it's possible to look at and parse each DMARC report email to see what is going on, that's not an approach that scales.
In the next part of the eSecurityPlanet guide to DMARC, we'll provide an overview of different DMARC vendor solutions that can help organizations with implementation and report monitoring.
Curious about DMARC? Learn how to set up a
basic DMARC email security policy, including SPF and DKIM, in this
eSecurity Planet tutorial.
Unfortunately, DMARC is not turned on by default for every domain, at
every web host or every email server. DMARC requires organizations and
email administrators to configure and set up policies. While DMARC is
not the default for email servers, adoption is now growing, thanks to
adoption by the U.S. government and enterprises around the world.
In the first part of the eSecurityPlanet
series on DMARC, we provided an overview of the components that make up
DMARC, including Sender Policy Framework (SPF) and Domain Keys
Identified Mail (DKIM).In this installment, we'll go over how to implement a basic DMARC setup on your own domain. It's a set of processes that includes changing DNS records at the domain registrar and optimally configuring email providers to send signed emails.
How to set up Sender Policy Framework (SPF)
Sender Policy Framework (SPF) is one of the easiest parts of a DMARC deployment to set up and configure. SPF is used to specify which email exchanges are authorized to send email for a given domain name.At its most basic level, SPF just requires a simple one line change to a domain record in order to work.
- Log into your domain registrar and click on the option to manage or configure DNS settings
- Find and click the 'Add a New Record' option and choose a 'TXT' record
- In the host name dialogue, enter either @ or the name of your domain.
Example SPF record:
So, for example, on the domain DMARC.site (a test domain we created just for this article), a basic SPF policy might look like this:
"v=spf1 dmarc.site ~all"
In the above policy, only an email exchange hosted on dmarc.site
would allowed to send email for the domain. The ~all piece of the policy
is typically the right way to end an SPF DNS entry and simply means
that the policy is all there is and no other servers should be sending
email on behalf of a given domain.Using the ~ (tilde) is typically preferred in an initial SPF configuration to using a "-" (for example : -all rather than ~all), as the tilde denotes a Soft Fail. That is, using the ~ will still enable mail to be sent that doesn't meet the policy, but the mail won't be identified as non-compliant. To have a strict policy (after initial testing), the '"-" indicates a hard fail if the policy is not met.
In many cases, organizations will have mail servers that are separate from the domain host (i.e. Google, Office 365 or a mail forwarder). So how do you enable an SPF policy to define authorized email servers beyond the domain host? That's where the 'include:' items come in.
For example, to specify an SPF policy that will enable Google's mail servers to send email on behalf of a domain, the following simple policy will work:
"v=spf1 include:_spf.google.com ~all"
There are lot of other options that can be inputted for an SPF
record. Another common configuration is to specifically allow email to
be sent only from the same email servers that are already defined in the
MX (mail exchange) record for the given domain's DNS entry. An example:"v=spf1 mx mx:DMARC.site ~all"
Once the DNS TXT record for SPF has been inputted and saved, it's time to move to the next step of the DMARC process.How to set up Domain Keys Identified Email
Domain Keys Identified Email (DKIM) is a somewhat more involved and challenging element to implement than SPF. With DKIM, in addition to a DNS entry, organizations also need to make changes on outgoing email servers.There are two elements to DKIM: a DNS record that includes a public cryptography key to help verify that a sender is allowed to send email for a given domain, and the private key that is used for signing outgoing email.
Adding a DKIM entry to a domain's DNS is the same basic process as it was for the SPF record:
- Log into your domain registrar and click on the option to manage or configure DNS settings
- Find and click the 'Add a New Record' option and choose a 'TXT' record
- For the host name option, DKIM requires what is known as a 'selector,' which is basically a prefix (Example: dmarc._domainkey.dmarc.site)
- Instead of inputting a policy (as was the case for SPF), what is needed with the DKIM entry is a public cryptography key
There are also multiple online tools that can help generate the public/private key pair; one of the easiest is DKIM Core Tools.
Sample DKIM entry:
The DNS entry is only half the equation for DKIM. The other half is getting a DKIM signer setup on a mail server, which is a process that isn't all that easy for many email systems. The exception is Google's Gsuite, which has a simple how-to guide to get a DKIM signer in place.
Microsoft Office 365 users can benefit from Microsoft's detailed guide on how to implement DKIM signing on that platform.
There are also multiple vendors that can help enable DKIM signing with different approaches, which we will detail in the next article in this series, an outline of vendor solutions.
How to set up a DMARC record
Now that SPF and DKIM have been set up, it's time to finally set up the DMARC policy. It is possible to define a DMARC policy in a DNS record without first setting up SPF and DKIM, but it actually won't be able to do anything.DMARC policies define how SPF and DKIM records should be handled by email servers. A critically important element of DMARC policy is that it also provides a reporting mechanism so domain administrators can identify if email is failing or if an attacker is attempting to spoof a given domain.
Just like SPF, DMARC is a simple one line entry in the domain's DNS records.
- Log into your domain registrar and click on the option to manage or configure DNS settings
- Find and click the 'Add a New Record' option and choose a 'TXT' record
v=DMARC1; p=quarantine; rua=mailto:reports@dmarc.site; ruf=mailto:reports@dmarc.site; adkim=r; aspf=r; rf=afrf
- The "p" option has three options: none, quarantine, or reject, for how email that violates policies should be handled
- The adkim and aspf options define how strictly DKIM and SPF policy should be applied, with 's' indicating strict and 'r' indicating relaxed
- The RUA provides an address for aggregate data reports, while the RUF provides an address for forensic reports
Testing and next steps
Following the steps in this guide, it's possible to set up a basic set of policies that will enable DMARC for a given domain. Simply setting up DMARC in a test implementation is only the beginning of the DMARC journey, however.It's important to test configuration for SPF, DKIM and DMARC to make sure that the defined policies work as intended and don't end up blocking legitimate email. That's why starting with relaxed and quarantine options is likely a good place to start.
DMARC reporting and forensics allow an organization to understand what is going on with their email domains. While it's possible to look at and parse each DMARC report email to see what is going on, that's not an approach that scales.
In the next part of the eSecurityPlanet guide to DMARC, we'll provide an overview of different DMARC vendor solutions that can help organizations with implementation and report monitoring.
No comments:
Post a Comment