Red Sift Leitfaden zur E-Mail-Protokollkonfiguration

In this chapter, we’ve answered some of the most common questions our Customer Success Engineers are asked about SPF, DKIM, and DMARC - the three pillars of modern email authentication. Let’s dive in!

SPF (Sender Policy Framework) is an email authentication standard that was developed to combat sender address forgery. By verifying the authenticity of the MAIL FROM or HELO/EHLO identities during transmission, SPF compares the sending server's IP address against a list of authorized senders specified in a TXT record within the domain owner's DNS. If the sending IP address aligns with the authorized list, SPF authentication succeeds. 

SPF focuses on the "domain" found in the email header, known by various names such as Return-Path, MAIL-FROM, Bounce address, or Envelope from. If this header is missing, SPF falls back and looks at the “HELO/EHLO” hostname and checks for an SPF record there.

The Return-Path header is a technical header that is not visible to the end user - unless they know how to display the headers of an email in their mail client they won't see it. 

DKIM (DomainKeys Identified Mail) is used to sign different header fields and bodies to authenticate the sending domain and prevent message modification during transit.

It achieves this by using asymmetric cryptography which consists of a combination of public and private keys. The private key is private to the sender’s domain and is used to sign the emails. The public key is published in the sender’s DNS so it can be retrieved by anyone receiving messages from the sender.

When an email is composed, its headers and body are signed using the private key of the sender to create a digital signature, which is also sent as a header field along with the email. On the receiver’s side (if DKIM is enabled), the server retrieves the public key and verifies if the email was indeed signed by the sending domain. If the signature is successfully validated that proves that the sending domain sent the message and also that the headers and body of the message have not been modified during transmission.

DKIM focuses on the “DKIM-Signature” header.

As is the case with SPF,  this header is not visible to the end user unless they know how to display the headers of the email they have received.

While DKIM can verify that an email isn't the exact email that was sent, and SPF can recommend that a receiving server should reject an email based on the IP, neither of these are effective at spoofing prevention.

The main reason for this is the header that is checked for each protocol.

SPF checks the record found at the domain in the return-path header, and DKIM checks the key found at the d= domain (Found within the DKIM header).

Both of the above protocols can be set to check any domain.

In an email, the major domain of the sender is the domain found in the From: header, this header determines the big name at the top of emails - the address that the end-user will see if they check who sent the email.

Given the above, your email domain could be impersonated as attackers could make the From: yourdomain.com and the return-path and d= theirdomain.com. Provided the SPF and DKIM records at theirdomain.com were correctly configured, the email would pass both SPF and DKIM resulting in a successfully impersonated domain..

SPF and DKIM have their purposes, but neither alone are enough to prevent imitation.

DMARC stands for Domain-based Message Authentication, Reporting and Conformance and builds upon SPF and DKIM, providing an additional layer of email authentication and policy enforcement. 

DMARC does a few things:

1. It takes into account the results from SPF and DKIM 
2. For DMARC to pass, it requires SPF or DKIM to pass and for the domain used by either one to also align with the domain found in the From: address. If you’re interested in learning more about Identifier Alignment, click here.
3. It reports SPF, DKIM, and DMARC results back to the domain found in the From: address (ie. sender).
4. Finally, it tells receivers how to treat emails that fail DMARC validation by specifying a policy in DNS.

By setting the DMARC policy to p=reject an organization can recommend to receiving servers to drop any emails set on behalf of their domain that don't pass the alignment check. This will stop all imitation attempts where the receiving server is correctly implementing DMARC.

DMARC focuses on the domain found in the From: or Header from header which is visible to the end user. 

SPF verifies if an email was sent by an authorized sender by checking a list of authorized IP addresses you publish in your DNS. The receiving server will take the domain found in the Return-Path header and check for an existing SPF record. It checks the SPF record to see if the sending IP address of the email is contained in the SPF record. If the IP address is contained in the SPF record that means that it is authorized to send emails. This means that SPF PASSED. If the IP address is not in the SPF record then SPF FAILS.

The overall logic is:

• If the sending IP address is contained in the SPF record = SPF PASS
• If the sending IP address is not contained in the SPF record = SPF FAIL

The receiving server will check the DKIM-Signature header which contains the selector (s=) and signing domain (d=) which are tags used to look up the public key. Once retrieved, the public key is used to validate the email message. If validation is successful then DKIM PASSES and if the validation process is unsuccessful then DKIM FAILS.

The overall logic is:

• If validation is successful = DKIM PASS
• If validation is unsuccessful = DKIM FAIL

The receiving server will check if either SPF or DKIM PASSED, then it will check if the Return-Path domain used by SPF and/or the d= domain used by DKIM aligns with From: domain, and finally, it will extract the DMARC policy published by the domain found in the “From” address and comply with the policy.

The overall logic is:

• If SPF PASSED and ALIGNED with the “From” domain = DMARC PASS, or
• If DKIM PASSED and ALIGNED with the “From” domain = DMARC PASS
• If both SPF and DKIM FAILED = DMARC FAIL

DMARC not only requires that SPF or DKIM PASS, but it also requires the domains used by either one of those two protocols to ALIGN with the domain found in the 

“From” address. Only then will DMARC PASS.

Strict alignment means that the Return-Path domain or the signing domain “d=” must be an exact match with the domain in the “From” address.

Relaxed alignment means that the Return-Path domain or the signing domain “d=” can be a subdomain of the “From” address and vice versa.

If you’re interested in learning more about Identifier Alignment, click here.

If DMARC fails, the receiving server would typically comply with the policy that you have specified in your DMARC record.

• If you are in report-only mode (p=none) the email will be accepted by the receiving server and scanned by other filtering criteria.
• If you are in quarantine mode (p=quarantine) the email will be quarantined and typically sent to the spam folder of the recipient.
• If you are in reject mode (p=reject) the receiving server will abort the connection with the sending mail server and the email will never reach the end user.

Irrespective of the policy, the metadata for the email will be logged along with the status of the authentication results and forwarded to your DMARC report processor. Learn more about DMARC reports here.

1. Make sure that you have an SPF record in your Return-Path domain.
2. Make sure that you have an SPF record in your HELO/EHLO domain in case of bounces where the Return-Path domain is empty.
3. Make sure there is a single SPF record per domain.
4. Make sure that the SPF record syntax is correct.
5. Make sure that your Return-Path domain aligns with the From domain.
6. Make sure that your authorized senders are part of the SPF record.
7. Make sure that unauthorized senders are not in your SPF record.
8. Make sure that you do not go over the 10 DNS lookup limit imposed by SPF. If you have gone over the 10 DNS lookup limit you will have to consider using a feature such as Red Sift’s OnDMARC’s Dynamic SPF.
9. Make sure that deprecated SPF record mechanisms such as the “ptr” mechanism are not used in your SPF record.

1. Make sure that the sending systems you use support DKIM.
2. Make sure that the emails are DKIM signed.
3. Make sure that the signing domain aligns with the “From” domain.
4. Make sure that you use a DKIM key size over 1024 bits (a 2048-bit key is advisable)
5. Make sure, where possible, that the DKIM selectors you choose closely identify the sending service so you can distinguish between them.
6. Make sure to revoke any keys that have been compromised.
7. Make sure that the DKIM keys you manage are rotated regularly.
8. Make sure that the DKIM key syntax is correct.
9. Make sure that there exists a public key for each corresponding private key that signs your emails.

1. As DMARC is based on both SPF and DKIM and the domains used by those two protocols, you will have to make sure that the Return-Path domain for SPF is either an exact match or a subdomain of the “From” domain. The same applies to the signing domain used by DKIM.
2. Make sure that the DMARC record syntax is correct.
3. Make sure that you have configured all of your systems correctly with SPF and DKIM before moving to a reject policy as your emails will be lost.
4. Make sure that you use a system or third-party provider such as Red Sift OnDMARC to receive DMARC reports so that you can make sense of those reports and discover any systems that are misconfigured.
5. Monitor the status of each of your sending sources and make sure that any changes to SPF and DKIM are identified. Red Sift OnDMARC has this feature as a core part of its product.