How DKIM SPF & DMARC Work to Prevent Email Spoofing and Phishing

Don’t get hooked by the scam emails!! There are so many scams and phishing on the internet today.

What is every hacker’s weekend gateway? They go Phishing.  Weekends of hackers can go by with very little activity, and then we will have several weeks of intense attack activity. We are in the periods of intense attacks right now.

Anyone from the Infosec team knows what I’m talking about. A dozen emails to set up a meeting time. A bunch of spam and phishing emails will be queued for review. Documents are attached and edited and reedited until no one knows which version is current. Urgent messages drowning in forwards and cc’s as spam.

Identifying spam and phishing emails can be hard if there are multiple emails to analyze. So Analysts need to think wider to set up filters to automatically reject or block those emails. There were few tools available to provide sender verification in the early days of “modern email.” Almost all spam, frauds, and viruses that transmitted by email used forged sender information, and some still do today. Verifying the identity of email senders was and continues to be a challenging task.

The three main email security protocols DMARC, DKIM, and SPF complement one another, so implementing them all provides the best protection. The three will authenticate your mail server and prove to ISPs, mail services, and other receiving mail servers that senders are truly authorized to send an email. When properly set up, all three prove that the sender is legitimate, that their identity has not been compromised, and that they’re not sending email on behalf of someone else. These antispam measures are becoming increasingly important, and will one day be required by all mail services and servers.

All are complex to configure, and it takes a lot of research to figure out how they interact and complement each other’s defensive features. The effort, on the other hand, is well worth the time spent learning how to use them.

What is SPF?

• SPF stands for Sender Policy Framework, and it’s another excellent email authentication mechanism for email delivery and security.
• It secures the DNS servers and limits who can send emails on your behalf. Domain spoofing can be avoided with SPF.
• Internet Service Providers can use an SPF record to verify that a mail server is permitted to send email for a certain domain. An SPF record is a DNS TXT record that lists the IP addresses that are permitted to send email on behalf of your domain.
• SPF consists of three primary components: a policy framework, an authentication technique, and particular headers in the email itself that convey this information.

How SPF detects fraud emails?

• Receiving mail servers use SPF to verify that incoming email from a domain was sent from a host approved by the domain’s administration. The following steps outline how SPF works:
• The SPF record is published in the DNS. The record is a list of all the IP addresses that are allowed to send email on behalf of the domain and it is listed as part of the domain’s overall DNS records.
• The SPF mechanism uses the domain in the return-path address to identify the SPF record. The inbound server then compares the IP address of the mail sender with the authorized IP addresses defined in the SPF record.
• The receiving mail server then uses the rules specified in the sending domain’s SPF record to decide whether to accept, reject, or otherwise flag the email message.

Importance of SPF:

• SPF improves the protection of email users from spammers. Because faked “from” addresses and domains are frequently used in email spam and phishing, publishing and validating SPF data is regarded one of the most dependable and simple anti-spam tactics.
• If you have a good sending reputation, a spammer may try to send email from your domain in order to benefit from your ISP’s good sender reputation. However, properly set up SPF authentication will show the receiving ISP that even though the domain may be yours, the sending server has not been authorized to send mail for your domain.
• The email could be genuine, but the sender list could be inaccurate. Real email could have been forwarded, which means it could have come from anyplace, and the list of approved senders isn’t really helpful. Alternatively, the email could be a forgery that you don’t want.

There are so many conceivable outcomes, it’s difficult to make sense of the absence of a link that SPF can provide. DKIM fills a gap in the DMARC technical framework by providing an extra method of attempting to link an email message to a domain.

Sample log:

Why is SPF-Only not enough for security?

Forwarding of email happens on the Internet and the SPF mechanism doesn’t survive the forwarding process. Here, the email appears to be coming out of the infrastructure that appears to have nothing to do with you. 

 DKIM signing can withstand forwarding. SPF does not work with forwarding since it is merely a list of servers that are authorized to send on behalf of your domain, and a domain owner cannot maintain a list of forwarders. 

behalf of your domain and a domain owner cannot maintain a list of forwarders. 

What is DKIM?

• DomainKeys Identified Mail (DKIM) is an email authentication method. This approach detects spoofed or fake sender email addresses. It is also another way to link an email back to a domain.
• When using DKIM, a sender can attach DKIM signatures to an email (header that is added to the message and is secured with encryption), and once the recipient receives the email, they can verify that it is actually you who sent it.
• Like SPF, DKIM is also used in DMARC alignment. The DNS has a DKIM record, although it’s a little more difficult than SPF. DKIM has the advantage of being able to withstand forwarding, making it preferable to SPF and a solid basis for email security.

Also Read: Cooking Malicious Phishing Email Headers with CyberChef

Key terms in DKIM:

DKIM Record: A domain owner adds a DKIM record, which is a modified TXT record, to the DNS records on the sending domain. This TXT record will contain a public key that’s used by receiving mail servers to verify a message’s signature. The key is often provided to you by the organization that is sending your email, for example, Gmail, SendGrid, Postmark, etc.

DKIM Signature: DKIM gives emails a signature header that is added to the email and secured with encryption. Each DKIM signature contains all the information needed for an email server to verify that the signature is real, and it is encrypted by a pair of DKIM keys. The originating email server has what is called the “private DKIM key,” which can be verified by the receiving mail server or ISP with the other half of the key pair, called the “public DKIM key.” These signatures travel with the emails and are verified along the way by the email servers that move the emails toward their final destination.

DKIM Selectors: The DKIM selector is specified in the DKIM-Signature header and indicates where the public key portion of the DKIM key pair exists in DNS. The receiving server uses the DKIM selector to locate and retrieve the public key to verify that the email message is authentic and unaltered. The DKIM selector is inserted into the DKIM-Signature email header as an s= tag when the email is sent. 

How DKIM detects suspect emails?

• When an inbound mail server receives a message, it will detect the DKIM signature and look up the sender’s public DKIM key in DNS. 
• Special DKIM signatures are attached to the emails that email servers transmit. These signatures travel with the emails and are confirmed as they make their way to their final destination by the email servers.
• These signatures operate as a watermark for email, allowing recipients to verify that the email came from the domain it claims to come from and that it hasn’t been tampered with.
• The variable or DKIM selector provided in the DKIM signature is used to determine where to look for this key. If the key is found, it can be used to decrypt the DKIM signature. This is then compared to the values retrieved from the received mail. If they match, the DKIM is valid.

Also Read : Latest IOCs – Threat Actor URLs , IP’s & Malware Hashes

Importance of DKIM:

DKIM is used to check the following 3 components:

• The sender of the email owns the DKIM domain, or is authorized by the owner of that domain.
• The contents of an email have not been tampered with.
• The headers in the email have not changed since the original sender sent and that there is no new “from” domain.

Sample signature log:

Why is DKIM-Only not enough for security?

DKIM isn’t a solid technique of validating the email sender’s identity on its own, and it doesn’t prevent the spoofing of the domain visible in the email’s header. The problem is solved by DMARC because the domain the end-user sees is the same as the domain that is validated by DKIM and SPF.

DMARC:

Domain-based Message Authentication, Reporting, and Conformance is the acronym for DMARC. Since it employs both DKIM and SPF records to validate the sender of an email, DMARC is particularly useful for businesses. A DMARC record allows a sender to declare that their messages are secured by SPF and/or DKIM, and it instructs a recipient what to do if neither of those authentication techniques succeeds – such as discard or reject the message.

Also Read : Threat Hunting using DNS logs – Soc Incident Response Procedure

How DMARC will suspect a malicious email:

• DMARC relies on the established SPF and DKIM standards for email authentication. It also piggybacks on the well-established Domain Name System (DNS). In general terms, the process of DMARC validation works like this:
• A domain administrator publishes the policy defining its email authentication practices and how receiving mail servers should handle mail that violates this policy. This DMARC policy is listed as part of the domain’s overall DNS records.
• When an inbound mail server receives an incoming email, it uses DNS to look up the DMARC policy for the domain contained in the message’s “From” (RFC 5322) header. The inbound server then checks evaluates the message for three key factors:
  • Is the DKIM signature on the message valid?
  • Did the message originate from IP addresses that the sending domain’s SPF records allowed?
  • Do the headers in the message show proper “domain alignment”?
• With this information, the server is ready to apply the sending domain’s DMARC policy to decide whether to accept, reject, or otherwise flag the email message.
• After using DMARC policy to determine the proper disposition for the message, the receiving mail server will report the outcome to the sending domain owner.

Key terms in DMARC:

DMARC Record: A DMARC record is a specially formatted version of a standard DNS TXT record with a particular name and it is included in an organization’s DNS database.

DMARC Record format:

v=DMARC1; p=reject; rua=mailto:[email protected], mailto:[email protected]; pct=100; adkim=s; aspf=s

DMARC record tags:

Tag	Required?	Description and values
v	Required	DMARC version. Must be DMARC1.
p	Required	Instructs the receiving mail server what to do with messages that don’t pass authentication. none – Take no action on the message and deliver it to the intended recipient. Log messages in a daily report. The report is sent to the email address specified with the rua option in the record. quarantine -Mark the messages as spam and send them to the recipient’s spam folder. Recipients can review spam messages to identify legitimate messages.reject – Reject the message. With this option, the receiving server usually sends a bounce message to the sending server.BIMI note: If your domain uses BIMI, the DMARC p option must be set to quarantine or reject. BIMI doesn’t support DMARC policies with the p option set to none.
pct	Optional	Specifies the percent of unauthenticated messages that are subject to the DMARC policy. When you gradually deploy DMARC, you might start with a small percentage of your messages. As more messages from your domain pass authentication with receiving servers, update your record with a higher percentage until you reach 100 percent. Must be a whole number from 1 to 100. If you don’t use this option in the record, your DMARC policy applies to 100% of messages sent from your domain. BIMI note: If your domain uses BIMI, your DMARC policy must have a pct value of 100. BIMI doesn’t support  DMARC policies with the pct value set to less than 100.
rua	Optional	Email address to receive reports about DMARC activity for your domain. The email address must include mailto:. For example: mailto:[email protected]To send the report to more than one email address, separate emails with a comma. This option can potentially result in a high volume of report emails. We don’t recommend using your own email address. Instead, consider using a dedicated mailbox, a group, or a third-party service that specializes in DMARC reports.
ruf	Not supported	Gmail doesn’t support the ruf tag, used to send failure reports. Failure reports are also called forensic reports.
sp	Optional	Sets the policy for messages from subdomains of your primary domain. Use this option if you want to use a different DMARC policy for your subdomains. none – Take no action on the message and deliver it to the intended recipient. Log messages in a daily report. The report is sent to the email address specified with the rua option in the policy .quarantine – Mark the messages as spam and send them to the recipient’s spam folder. Recipients can review spam messages to identify legitimate messages. reject – Reject the message. With this option, the receiving server should send a bounce message to the sending server. If you don’t use this option in the record, subdomains inherit the DMARC policy set for the parent domain.
adkim	Optional	Sets the alignment policy for DKIM, which defines how strictly message information must match DKIM signatures. Learn how alignment works – Strict alignment. The sender domain name must exactly match the corresponding d=domainname in the DKIM mail headers- Relaxed alignment (default). Allows partial matches. Any valid subdomain of d=domain in the DKIM mail headers is accepted.
aspf	Optional	Sets the alignment policy for SPF, which specifies how strictly message information must match SPF signatures. Learn how alignment works – Strict alignment. The message From header must exactly match the domain name in the SMTP MAIL FROM command – Relaxed alignment (default). Allows partial matches. Any valid subdomain of the domain name is accepted.

DMARC domain alignment:

• “Domain alignment” is a concept in DMARC that expands the domain validation intrinsic to SPF and DKIM. DMARC domain alignment matches a message’s “from” domain with information relevant to these other standards:
  • For SPF, the message’s From domain and its Return-Path domain must match
  • For DKIM, the message’s From domain and its DKIM d= domain must match
• The alignment can be relaxed (matching base domains, but allowing different subdomains) or strict (precisely matching the entire domain). This choice is specified in the published DMARC policy of the sending domain.

When implementing a DMARC record, you have 3 policies to choose from. These policies inform the recipient server how to treat mail sent from you that is not DMARC compliant. The recipient server is not required to treat mail as requested.

DMARC policies:

• None: Treat all mail sent from your domain as it would be without any DMARC validation
• Quarantine: The recipient server may accept the mail, but should place it somewhere other than the recipient’s inbox (usually, the spam folder)
• Reject: Completely reject the message.

DMARC report:

Inbound mail servers generate DMARC reports as part of the DMARC validation process. DMARC reports are available in two formats:

• Aggregate reports
• Forensic reports

Also Read : Soc Interview Questions and Answers – CYBER SECURITY ANALYST

Importance of DMARC:

• Phishing is the fraudulent practice of sending malicious emails pretending to be someone else in an attempt to steal a user’s credit card information or other personal information. Therefore, with DMARC, you are protecting yourself. 
• DMARC take the advantage of the existing email authentication techniques SPF (Sender Policy Framework) DKIM (Domain Keys Identified Mail). DMARC adds an important function, reporting.
• When a domain owner publishes a DMARC record into their DNS record, they will gain insight in who is sending email on behalf of their domain. This information can be used to get detailed information about the email channel. With this information a domain owner can get control over the email sent on his behalf.

How DMARC will reject or quarantine the mail based on the validation in Email Gateway?

As mentioned in DMARC policies, the email can get rejected or quarantined after validating SPF and DKIM.

Recognizing what tends to happen when a DMARC quarantine or reject policy is published is highly essential, so we’ve gathered some information to help you understand the differences.

Quarantine

When the DMARC policy is set to p=quarantine, email receivers are instructed to treat emails that fail the DMARC check with greater caution. Email is still accepted, and it is up to the recipient to decide what quarantine entails. The following are some examples of possible implementations:

• Deliver to spam folder: if an email receiver hosts the recipient’s mailbox, then the receiver might be able to deliver non-compliant email into the recipient’s spam folder.
• Temporary quarantine: an email receiver may choose to temporarily quarantine non-compliant email so that additional analysis of the email can be performed. An operator may then release email from quarantine after review.
• Increase aggressiveness of anti-spam filtering: Anti-spam filtering is a trade-off between identifying as much spam as possible versus accidentally identifying wanted email as spam. Email that falls under a DMARC policy set to quarantine is more likely judged as spam.

The important thing to know about publishing a quarantine policy is that non-compliant email is still delivered. Because of non-DMARC technology that may be present to block spam, the email may or may not arrive at its final destination, but email will continue to flow from email servers.

Reject

A DMARC policy set to p=reject instructs email receivers to refuse to accept email that fails the DMARC check. There are two known implementations:

• Refuse to accept non-compliant email at SMTP time. This is the preferred and most widely adopted implementation because delivery to DMARC verifying receivers is prevented. Senders will immediately be informed why non-compliant email isn’t getting through.
• Initially accept email via SMTP and then prevent the final delivery of the email that fails DMARC. This implementation is less optimal in that responsibility for delivery of an email has been assumed via SMTP, and yet the email is eventually not delivered. When delivery fails, one of two things can happen:
  • a Delivery Status Notification (aka a “bounce” message) is generated, or
  • the non-compliant email is silently dropped.

By default, email that falls under a DMARC reject policy is not delivered. This behavior is a great control against the sending of unauthorized emails.

Quarantine and Reject policies have the following impact:

• As a result, the impact of a reject policy on legitimate but non-compliant email will be clear right away: email will stop flowing. When switching to a reject policy, a domain owner should be prepared to deal with legitimate email sources that may encounter reject-based policies, as the source of email will almost certainly require assistance in becoming DMARC compliant.
• As a result, the impact of a quarantine policy on non-compliant legitimate email will not be immediately apparent to the email’s originators. The performance of legitimate-but-non-compliant email communications will be affected. The source’s email will be spam-foldered, delayed, and possibly rejected by email receivers due to the various ways the DMARC quarantine policy is applied. The impact of quarantine may go undiscovered for a long time unless the source of affected email is paying close attention to its own performance.

Conclusion:

With the ever-ending cyber-criminal activity, it seems only logical to secure your email streams from being used for fraud.  Implementing DMARC has benefits regardless of the size of a business. It provides full domain visibility, control over the email traffic, and security from phishers and spoofers. Moreover, DMARC is known to improve deliverability, since mailbox providers can confirm that you are a legitimate sender if your emails authenticate properly.

Also Read: Email Header Analysis – Use Cases Including SPF, DKIM & DMARC