Over time a comprehensive email authentication framework was developed by the industry to improve email security, deliverability and the reputation of senders by means of verifying the integrity of an email as well ensuring that the sender of an email is authorised to do so.

These frameworks are enabled at a domain level where the owner of a domain publishes DNS records to let the receiving systems know what they can expect when processing the email for the recipients. The receiving email servers can then take action to ensure these policies are enforced.

The three frameworks are

SPF or Sender policy framework and is defined in RFC 7208. The framework’s purpose is to explicitly designate who is allowed to send email on behalf of that domain. This prevents spoofing by not allowing anyone to impersonate you, thereby increasing the trustworthiness of the email. It is enabled by adding a specific record to DNS that specifies the IP addresses that are allowed to send email for the domain.

DKIM or DomainKeys Identified Mail as defined in RFC 6376. This is a digital signature that gets added onto each email at the sending server to ensure that an email is authentic and hasn’t been tampered with, thereby confirming the integrity of the email. The public cryptographic key is then hosted in DNS and the recipient email server uses the key to verify the signature for the domain.

DMARC or Domain-based Message Authentication, Reporting, and Conformance as defined in RFC 7489. It allows senders to publish domain wide policies that defines what should happen with emails that do not align with SPF or DKIM. It also provides a feedback loop mechanism to report back on the authentication results to the domain owner to help understand how the domain is used and to identify potential sources of abuse and to increase the overall email security posture. DMARC ensures SPF and DKIM works correctly together.

The records we require that our customers setup to ensure alignment is achieved:

SPF is a check which happens on the receiving email server using a special DNS record that will check whether the IP address of the sending mail server is authorised to send emails on behalf of the domain. The SPF record for your domain should reference all email senders for your domain.

If third-party senders aren’t included in your SPF record, messages from these senders are more likely to be marked as spam or discarded. SPF primarily checks the “Return-Path” header, also known as the envelope sender or bounce address. The “Return-Path” header is generally used to handle non-delivery notifications. Because the domain portion of the “Return-Path” address is being rewritten to @eversrv.customerdomain.com the SPF check will run against it.

We require customers to have a CNAME record to bounce-mx.eversrv.com for this domain, as  bounce-mx.eversrv.com contains the correct IP addresses for the Everlytic infrastructure. For Everlytic customers we need to have SPF passing the check.

SPF Alignment

• SPF alignment refers to the condition where the domain specified in the “Return-Path” (or “MAIL FROM”) header aligns with the domain in the “From:” header. Alignment checks ensure that the domains are the same or are part of an authentication mechanism that indicates legitimacy.
• For SPF alignment, the “Return-Path” domain is typically validated against the domain in the “From:” header. If they align, SPF alignment is achieved.

SPF Passing

• SPF passing simply means that the SPF check for the email has succeeded. It indicates that the sending server’s IP address is authorized to send emails on behalf of the domain specified in the “Return-Path” header.
• SPF passing is a binary result—it’s either a pass or a fail based on the SPF authentication mechanism. It doesn’t inherently consider alignment with the “From:” domain.

When the email leaves the mail server infrastructure a digital signature is added to the email as a header, which is done using a private key that is hosted on the infrastructure. The DKIM-Signature header also contains additional information like the header and the signing domain. The receiving mail server inspects this signature and uses the selector and the domain to retrieve the public key that is hosted on the DNS servers. The public key is then used to verify the signature.

For DKIM alignment to occur, the “d=” (domain) value in the DKIM signature header must align with the domain specified in the “From:” header. Everlytic customers need to ensure that DKIM aligns.

Example when inspecting an email header

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=everlytickey1; d=eversrv.com; h=Reply-To:List-Unsubscribe:From:To:Subject:MIME-Version:Date:Message-Id: Content-Type; bh=gbk5LZZp3PJ8Ga8i44p5hHLn+q4jatWyiBAiPfs7oOc=; b=js9BF….

Components of the DKIM-Signature

v=1: Version of the DKIM specification.

a=rsa-sha256: Algorithm used for the digital signature.

s=everlytickey1: Selector specifying the specific key pair used.

d=eversrv.com: Domain of the signing entity.

h=from:to:subject: Headers included in the hash.

bh=gbk5LZZp3PJ8Ga8i44: Body hash of the email content.

b=js9BF….: The actual digital signature.

DKIM Passing

• DKIM passing means that the DKIM signature verification has succeeded. The cryptographic signature attached to the email has been validated, and the message hasn’t been altered since the signature was applied.
• A DKIM signature can pass even if the signing domain (specified in the “d=” tag of the DKIM signature) is different from the domain in the “From:” header. In other words, DKIM passing doesn’t inherently consider alignment.

DKIM Alignment

• DKIM alignment refers to the condition where the domain specified in the “d=” tag of the DKIM signature aligns with the domain in the “From:” header. Alignment checks ensure that the domains are the same or are part of an authentication mechanism that indicates legitimacy.
• For DKIM alignment, the signing domain in the DKIM signature is typically validated against the domain in the “From:” header. If they align, DKIM alignment is achieved.