Often Organisations suffer fighting fraudulent email. Spoofing is one major concern to organizations across, and if not every report most of the cybercrime reports have listed email-based fraud as a top source. Even with advance anti-spam gateway solutions organizations are falling for spoofed emails. Spoofing campaigns have become more and more sophisticated and often bypass Spam filters.
Implementing DMARC “Domain-based Message Authentication Reporting and Conformance” is currently the good way around to defend from phishing and spoofing attacks. DMARC is built on two other authentication protocols – SPF, DKIM.
With this blog we try to simplify the SPF, DKIM, DMARC- Email Authentication Protocol measures the way they work and for your easy adoption.
So what are these – SPF, DKIM, DMARC?
In a nutshell – SPF, DKIM, DMARC would help step-up the protection measures by confirming and validating the sender domain and that an email came from the domain that says it does. And verifies that the email is not forged or altered.
SPF – Sender Policy Framework:
This has been there around for a long time (as a next measure to the PTR),. It is a method for authorizing mail servers of a particular domain for sending authoritatively and a way for recipient servers ( mail receiving party ) to verify if the sending server (MTA) is authorized for sending emails for that domain.
By Creating an SPF record in domain DNS, you can designate (kind of whitelist) which all email servers are authorized to send an email for the domain on your behalf.
- Sender adds a DNS record for their domain with “authorized to send email server’s ip addresses”. A typical SPF DNS TXT record looks like : (example only)
v=spf1 ip4:213.42.193.66/32 ip4:86.96.198.0/29include:spf.protection.outlook.com~all
(ref- https://en.wikipedia.org/wiki/Sender_Policy_Framework )
- Recipient server while receiving an email from senders MTA/SMTP Server, it checks against the DNS TXTrecord of that domain name – If the IP Address is listed/ authorized. (extracts domain name from the “return-path:” field of the envelope)
- If the IP address match – the message passes the SPF
- If the IP address not listed in SPF, or does not match in the list, it is considered – “Hard-fail”; in most cases, the email ends up rejected, or marked spam by the receiving party.
- For not having an SPF record for a domain is considered “soft-fail” and the receiving party may very well treat this as spam too.
DKIM – DomainKeys Identified Mail:
As it sounds, it is an email authentication protocol to protect against email spoofing (both email body, header) using public-key cryptography.
With DKIM configured sender’s MTA would inject a digital signature to the outgoing emails with a hash value. And the receiving MTA uses public key made available through a TXT record by sending party to decrypt the hash value in the email header and recalculate the hash value for the email message is received. If these two hashes match, then the email is passed indicating email has not been altered and the email did originate from the listed domain.
With most of the email SaaS providers and outbound SMTP gateways, it is about defining the policies and configuring out-of-the-box functionality, but if you are running any on-prem servers like MS Exchange you may have to look at some 3rd party software packages which can make the DKIM insertions possible.
- Setup the mail server / the mail provider to support DKIM
- Per domain, Generate a pair of DKIM Keys [ Public and Private ]
- Make the public key available in the DNS as TXT record ( in some cases as CNAME)
- Configure to enable DKIM signing
To understand the DKIM DNS TXT record it mainly has two parts, the selector and the payload. Example below :
TXT Mta1._domainkey v=DKIM1; k=rsa; p=[public key]
Mta1 can be anything and is identified as “selector” or “mta”,. The ‘p’ field shall be the public key ( part of the pair that originally generated along with private key at the server/ MTA)
Note: (More please refer : rfc5585)
- DKIM by itself does not filter email
- Does not authenticate or verify the contents of the message header or body, such as the author From field, beyond certifying data integrity between the time of signing and the time of verifying.
- Does not offer any assertions about the behaviors of the signer.
- Does not prescribe any specific actions for receivers to take upon successful signature verification.
- Does not provide protection after signature verification.
- Does not protect against re-sending (replay of) a message that already has a verified signature; therefore, a transit intermediary or a recipient can re-post the message — that is, post it as a new message — with the original signature remaining verifiable, even though the new recipient(s) might be different from those who were originally specified by the author.
- Example DKIM Signature
DKIM-Signature a=rsa-sha1; q=dns;
d=test.com;
i=user@eng.test.com;
s=TEK2007.eng; c=relaxed/simple;
t=22276972764; x=11179856433;
h=from:xxxxto:xxxxsubject:xxxxdate:xxxx;
b= ADS2134321AFDSFD2134adsfdsd154
DSFKNSADFKHDASNF243KNASDFN234
- From Domain (RFC5322) – is the domain part of the email address.
- Signing Domain – During DKIM Signing, the domain takes the responsibility for the message signing, it inserts its name into the header in a key-value tag.
- It is possible to sign emails on “Per-user-DKIM keys” or “Per-email-address-DKIM”.
DMARC [Domain-based Message Authentication, Reporting, and Conformance]
We can say DMARC is best of both worlds, it uses SPF, DKIM and ensures emails are properly authenticated for their legitimacy. DMARC provides directions to the receiving party (Recipient Server) on what to do if an email claiming that ‘from your domain’ is not properly authenticated.
An email passes DMARC if the email must pass SPF authentication and SPF alignment and/or DKIM authentication and DKIM alignment. The email will fail DMARC if the message fails both (A) SPF or SPF alignment and (B) DKIM or DKIM alignment.
In order for DMARC validation checks to pass, DMARC requires that there be domain alignment as follows:
- For SPF, the RFC5322. From domain and the Return-Path domain must be in alignment
- For DKIM, the RFC5322. From domain and the DKIM d= domain must be in alignment
DMARC requires a DNS record to be published for the domain you wish to use in your “FROM:” address. Example:
“v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@senderdomain.com”
The DNS TXT record for DMARC can include several values, but required mainly two of them :
- (v) tells the receiving server to check DMARC
- (p) gives instructions on what to do if authentication fails.
The parameter options for p can include:
- p=none, which instructs the receiving server to take no specific action if authentication fails but to provide data reports.
- p=quarantine, which instructs the receiving server to consider quarantining the message. it could mean routing the mail to spam/junk folders
- p=reject, which instructs the receiving server to reject all non-aligned messages and send a report.
It is advised to start with configuring the DMARC Policy flags from “none” to “quarantine” to “reject” phases and with a thorough evaluation.
DMARC Overview:
Image source : https://dmarc.org/overview/
Definitely, DMARC is a very good enhancement to improve organizations email communication, reputation. It greatly minimizes the risks of email spoofing and impersonation while letting you keep a track of fraudulent attempts via reports. However it is not 100% foolproof, user education and awareness are still key.