Spammers and phishers can use the Sender Policy Framework (SPF), DomainKeys Identified Email (DKIM), and Domain-based Message Authentication, Reporting, and Conformance to spoof your domain in the FROM: addresses of email they send (DMARC). For the best phishing protection, all three should be used simultaneously. They’re simple to set up, and everyone should do so.
But here’s the thing: according to a recent analysis from phishing expert Agari, just 1/3 of Fortune 500 companies have set DMARC. What is the reason behind this? Let’s start with an explanation of the three email anti-spoofing strategies.
Sender Policy Framework (SPF)
After roughly six years of discussion and debate, SPF was initially published as an experimental RFP in 2006. It specifies which email gateways (Mail Transport Agents, or MTA’s) are permitted to send an email for a domain. An external DNS, such as a Linux server running Berkeley Internet Name Daemon (BIND), has the definition for them. BIND servers have zone files that return IP Addresses when requested with a server name (record types A or CNAME), Server Names when queried with an IP address (record type PTR), or information in the form of TXT records when queried with an IP address (record type PTR).
example.net. IN TXT “v=spf1 mx a:pluto.example.net include:aspmx.googlemail.com -all”
According to the DNS zone record above, MX (mail exchanges) that send an email for email addresses from the example.net domain are called pluto.example.net or aspmx.googlemail.com, with all other servers names not authorized. If an email comes from any other email gateway with a FROM address that includes example.net, this should not be trusted because it might be spoofed. The receiving email gateway validates this by looking at the SPF record in DNS of example.net. In order for your email to be delivered to them, many companies require SPF to be configured for your domain.
DomainKeys Identified Email (DKIM)
DKIM was created in 2004 when Yahoo’s “enhanced DomainKeys” and Cisco’s “Identified Internet Email” combined. Asymmetric public-key cryptography, i.e. a generated public and private key, is used in DKIM. The sending email gateway(s) are configured with the private key to include in the headers of the email to be sent; the public key is included in a TXT record along with some other bits of information. The keys can be produced in a number of methods, such as using free public sites.
Domain-Based Message Authentication, reporting, and conformance (DMARC)
SPF and DKIM-based domain-based message authentication, reporting, and conformance. If a message fails the spoofing check, DMARC contains instructions on what actions receiving gateways should take. It’s established in DNS as a TXT record, just like the others.
_dmarc.example.net IN TXT “v=DMARC1;p=none;sp=quarantine;pct=100;
rua=mailto:dmarcreports@example.net”
It states that the version is DMARC1, that there is no policy (both SPF and DKIM should be checked), that the recommended action is to quarantine (or send to spam folders), that almost all emails from example.net should be analyzed, and that reports should be sent to dmarcreports@example.net.
And here’s the thing: only 7% of DMARC customers have it configured for “quarantine” or “reject.” They only use it for reporting, negating its effectiveness as an anti-spoofing mechanism. That’s too bad because all three of these examples rely on the broad community/global adoption to provide meaningful value to people who utilize them. Configuring SPF, DKIM, and DMARC doesn’t prevent people from getting spam and phishing, but does prevent spammers and attackers from using your email domain to send spam and phishing to others. It’s all part of being a responsible citizen. Adoption could be poor due to a lack of immediate significant benefits from the effort. It is indeed conceivable that emails from domains that don’t use all three ways will be blocked by default, but that’s highly improbable.
Content Source:- https://dmarcservice.medium.com/spf-dkim-and-dmarc-provide-anti-phishing-protection-7199aa77fb66