E-Mail Security | SPF, DKIM, DMARC

The terms SPF, DKIM, and DMARC initially seemed like complex and unfamiliar concepts to me. They were technical topics that I hesitated to explore due to the abundance of technical information. In this article, I will try to explain these concepts in a simple way for those who are not familiar with them and clear up any doubts for those who are already acquainted with them.

A Brief Overview for Those Who Don’t Need Many Details:

SPF, DKIM, and DMARC are standards that help enhance email security.

a. SPF allows us to determine the true sender of an email (e.g., whether an email claiming to be from Facebook actually originated from Facebook or if someone is trying to deceive us).

b. DKIM, like SPF, verifies the authenticity of the claimed sender but also ensures that the email’s content remains unchanged and original.

c. DMARC allows us to create rules based on SPF and DKIM outcomes. We can decide whether to accept the incoming email, mark it as spam, or reject it outright. Additionally, DMARC specifies where these events should be reported (logs).

Mechanism Workflows:

A Bit More Detail:

SPF (Sender Policy Framework):

By creating an SPF record for our domain or organization, we can prevent attempts to send phishing emails using our domain name. So, how do we add an SPF record?

An SPF record is a DNS TXT record. We can create an SPF record by writing the relevant text in the DNS TXT record. Here’s an example of an SPF record:

v=spf1 ip4:61.1.1.1 include:thirdparty.com -all

Explanation of the SPF record example:

v=spf1: The “v” parameter indicates the SPF version. It is generally set as static and often uses “spf1” in the modern context.

ip4:61.1.1.1: The “ipv4” parameter represents the email source IP address. This condition applies to emails coming from these specific IP addresses.

include:thirdparty.com: The “include” parameter indicates the accepted source domain addresses. Multiple domains can be included separately with the “include” parameter. The SPF record of the included domain is checked (via DNS TXT query). If the incoming email is present in the included domain’s SPF records, the condition is met. Note that a DNS query is performed for each include value.

Working Logic of the “include” Variable in SPF:

-all: If the sending server is not listed in the SPF records, reject the email (considered “fail and discard”).

~all: If the sending server is not listed in the SPF records, accept the email but mark it as spam (referred to as “Not pass” or “Softfail”).

+all: Accept the email regardless of the SPF records of the sending server.

Additionally, other parallel parameters may exist in DNS records, such as “a=example.com.” In this case, “example.com” represents an A record IP address. If the A record (or multiple A records) for “example.com” matches the sender’s server IP address, it is considered valid. The same logic applies to MX, IPv6, and PTR DNS records.

DKIM (DomainKeys Identified Mail):

DKIM uses asymmetric encryption methods to verify the authenticity and source of an email.

Asymmetric encryption uses a public key to encrypt data and a private key to decrypt it. Data encrypted with the public key can only be decrypted with the private key. Data signed with the private key can be verified with the public key.

How Does DKIM Work?

1. The email sending server signs the email headers using its private key (stored only on the sending server).
2. The email content (body) is then signed with the private key.
3. The resulting signatures are treated as hashes. These signatures are also added to the email headers.
4. The email receiving server checks if the domain has a DKIM record by performing a DNS query. If a DKIM record is found, it retrieves the corresponding public key.
5. The email receiving server verifies the signatures using the public key from the DNS record.
6. Based on the verification result, the email’s validity is determined.

Example of a DKIM Signature:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=ilgilidomain.com; s=selektor;
 h=from:content-transfer-encoding:subject:message-id:date:to:mime-version;
 bh=LtrWiLQ8B7I9vFIen3+/FXErUuKv33PmCuZAwpemGyp=;
 b=iY53DkXsbP5bMGzOwivNE4fmF125W2/Yq0YqXD4Og1fPT6ViqB35uLxLGGhHv2lqXBWwFhODPVPauUXxRYEpMsuisdU5TgYmbwSJYYrFLFj5ZWTZ7VGgg6/nI1hoPWbzUpL1Rl

An Example of a DKIM Record (inside a DNS TXT record):

myselector._domainkey.domain.com TXT “k=rsa; p=AIGf … AQAB”

In the email, the selector appears as “selector_domainkey.domain.” The “_domainkey” part is automatically generated, and the selector is not mandatory. However, multiple selectors can be used along with their corresponding assigned public keys.

“K” specifies the encryption algorithm used, and “p” indicates the public key.

DMARC (Domain-based Message Authentication, Reporting, and Conformance):

The DMARC standard makes decisions based on specific parameters of incoming emails (e.g., SPF, DKIM) and determines whether to accept the email, mark it with a different flag, or reject it. DMARC is satisfied if either SPF or DKIM meets the condition. If both fail, DMARC is not satisfied and is marked as “fail.” The DMARC policy then decides what action to take. Subsequently, this event is reported.

Example of a DMARC Record:

_dmarc.mydomain.com. IN TXT “v=DMARC1; p=none; rua=mailto:dmarc-aggregate@mydomain.com; ruf=mailto:dmarc-afrf@mydomain.com; pct=100”

Explanation of the DMARC record:

v: Specifies the used version. We can use “DMARC1” as a constant.

p: Defines the desired policy or rule.

1. none: No specific policy is defined. If there is no DMARC, the action will be the same as in the absence of DMARC.
2. quarantine: Allow the email but move it to the spam folder. Usually, these emails end up in the spam folder.
3. reject: Reject the email.

rua: The email address to which daily email reports will be sent.

ruf: The email address to which immediate reports will be sent in case of failure.

pct: Indicates what percentage of incoming emails should follow the specified DMARC rules. For example, if pct=10, only 10% of incoming emails will follow the defined DMARC rules, while the remaining 90% will have “none” as the policy.

References:

1. Email Security: Stop Sender Fraud with SPF, DKIM & DMARC — https://www.bettercloud.com/monitor/the-academy/what-is-dmarc/
2. DKIM Core Technical Specification — https://tools.ietf.org/html/rfc6376
3. How to Create a DKIM Record and Add it to DNS — https://blog.mailtrap.io/dkim-explained/
4. SPF Record: Protect your domain reputation and email delivery — https://postmarkapp.com/guides/spf
5. Mail Trafiklerinde Güvenlik | DMARC, DKIM ve SPF Kayıtları — https://www.bariskoparmal.com/mail-trafiklerinde-guvenlik-dmarc-dkim-ve-spf-kayitlari/