According to a recent study, 250 billion emails are sent every day. Email has become part and parcel of our social and professional lives. Email was first designed in 1982. The Internet was different back then, and the threats we see today were not that obvious those times.
Email spoofing is when someone sends an email with a forged sender address. Because email does not have authentication built in, spam, phishing and attackers use spoofing to take advantage of the trust that the spoofed domain carries, and to get users to give up sensitive information. If got worse, the domain reputation becomes at stake.
How to help the receiving email servers to determine if the mail coming from or pretend to come from your mail server is legitimate and have not been tempered with. For this purpose you, the domain administrator, have to create one or more SPF, DKIM and DMARC records in the DNS zone of your domain. To avoid email spoofing, authentication should be configured properly on the mail server.
SPF
SPF (Sender Policy Framework) is a record that is applied to the DNS-record (a global database containing information about domain names and their corresponding address) that specifies what servers are allowed to send email using that domain.
SPF can be set up to have three different actions: hardfail, softfail and neutral.
SPF set up to hardfail means that all emails that are suspected to be forged or spam are rejected and not delivered. If the SPF record is set up to softfail, emails are accepted / shown for the user, but marked with a warning as suspicious / spam. If the SPF is set up as neutral, all emails are accepted.
Softfail is usually recommended as a first step when setting up a SPF record, this way you are able to check if legit emails are marked as spam or not, and then able to accept them as legitimate for future correspondence. After softfail has been in place for a while, it is common to switch the configuration to hardfail.
Examples
“v=spf1 mx -all“
Allow domain’s MXes to send mail for the domain, prohibit all others.
“v=spf1 -all“
The domain sends no mail at all.
“v=spf1 +all“
The domain owner thinks that SPF is useless and/or doesn’t care, so wherever the mail comes from, it is valid.
DKIM
When sending an email from a server with DKIM configured, the server will hash the body and the header of the email separately. It will then, with a private key, create a signature it will send along with the email.
When the receiver then receives the email, it will do a DNS-request to the domain that the email said it was from, and by doing so get the public key which is the DKIM-record. It will then, with help from that, verify that the signature is correct, and by doing so confirming that the sender is correct and the mail have not been manipulated on its way there. A nice way of protecting email from being altered after it has been sent.
DMARC
DMARC takes advantage of both SPF and DKIM, and can be seen as the recommended action to take when neither SPF or DKIM confirm an email as legit. DMARC actions are: ‘reject’, ‘quarantine’ or ‘none’.
‘Quarantine’ is to put the email into some kind of quarantine, while ‘reject’ is a full rejection. If rejected, an end-user will never see the email.
Another key feature of DMARC is to generate a report on when it failed, so the owner of the domain can know when someone is trying to send emails on their behalf.
Spammers can sometimes forge the “From” address on email messages so the spam appears to come from a user in your domain. To help prevent this sort of abuse, Google is participating in DMARC.org, which gives domain owners more control over what Gmail does with spam email messages from their domain.
G Suite follows the DMARC.org standard and allows you to decide how Gmail treats unauthenticated emails coming from your domain. Domain owners can publish a policy telling Gmail and other participating email providers how to handle unauthenticated messages sent from their domain. By defining a policy, you can help combat phishing to protect users and your reputation.
Prerequisites
You must send all email messages through your own domain for DMARC to be effective. Messages sent on your behalf through third-party providers will appear unauthenticated and therefore can be rejected, depending upon your policy disposition. To authenticate messages sent from third-party providers, either share your DKIM key with them for inclusion on messages or have them relay messages through your network.
If you’re a domain owner, you’ll first need to configure SPF records and DKIM keys on all outbound email streams. DMARC relies upon these technologies to ensure signature integrity. A message that fails SPF and/or DKIM checks will trigger the DMARC policy. A single check failure using either technology allows the message to pass DMARC. See the corresponding SPF and DKIM sections of the DMARC specification for example messages filtered by these tools.
