Email antispoofing on Technical Notes

Architecture and concepts - 1/9

Mon, 01 Jan 0001 00:00:00 +0000

Introduction#

Purpose and audience#

There are three types of users of the email system:

Mailbox users
Domain administrators
Email infrastructure maintainers

This series of articles is aimed at domain administrators who need to configure email mailboxes in a way that prevents identity spoofing.

Standard email addresses - 2/9

Mon, 01 Jan 0001 00:00:00 +0000

The anti-spoofing protocols we will cover in the following articles are the walls of your fortress, and the standard email addresses are the guard posts. If you build the walls (SPF/DKIM) but there is no one in the guard posts (postmaster/abuse) to hear the alarms, your security will eventually be bypassed or degraded without your knowing it. Let’s start by configuring the standard email addresses.

FCrDNS and cross-validation - 3/9

Mon, 01 Jan 0001 00:00:00 +0000

How it works#

This technique emerged as a best practice in the 1990s.

The security principle: The robustness of this technique relies on the need to control both the IP infrastructure (the hosting side) and the DNS zone (the domain side). An attacker who holds only one of the two accesses will not be able to pass the test.

SPF (Sender Policy Framework) - 4/9

Mon, 01 Jan 0001 00:00:00 +0000

How it works#

Standardized in 2006 (RFC 4408), updated in 2014 (RFC 7208).

SPF acts as a trust directory. The owner of domain a.com publishes in its DNS (a TXT record) the list of IPs authorized to send email on its behalf.
When an email arrives, the receiving server checks the sending IP against this list. Note: SPF verifies the domain announced in the envelope’s MAIL FROM command — the very one that will be copied into the Return-Path upon receipt —, and not the From (the header visible to the user).

DKIM (DomainKeys Identified Mail) - 5/9

Mon, 01 Jan 0001 00:00:00 +0000

How it works: the police evidence seal#

Standardized in 2007 (RFC 4871), updated in 2011 (RFC 6376).

Whereas SPF protects the envelope (the sending server), DKIM (DomainKeys Identified Mail) protects the message itself. It is the digital equivalent of a police evidence seal:

DMARC (Domain-based Message Authentication) - 6/9

Mon, 01 Jan 0001 00:00:00 +0000

The Conductor#

Published in 2015 (RFC 7489).

So far, we have seen that:

SPF validates the IP but verifies the Return-Path, not the From.
DKIM validates the content and verifies the signature domain (d=). It does not verify the From.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) does not offer a new technical authentication method, but a policy layer that builds on SPF and DKIM to solve the alignment problem.

BIMI and an analysis of its limits - 7/9

Mon, 01 Jan 0001 00:00:00 +0000

In the email security ecosystem, BIMI (Brand Indicators for Message Identification) is often presented as the logical next step after achieving DMARC compliance. The goal is to allow a certified logo to be displayed in email clients in order to reinforce visual trust.

However, an in-depth technical analysis reveals that this protocol is more complex than it appears. Unlike SPF or DKIM, which are purely declarative, BIMI generally relies on a trusted third party through a digital certificate called a VMC (Verified Mark Certificate). While this mechanism works in integrated environments (such as the Google or Yahoo webmails), it runs into major structural obstacles as soon as it is confronted with the open, standardized architecture of email.

Parked Domain Locking - 8/9

Mon, 01 Jan 0001 00:00:00 +0000

A domain that sends no email at all must still configure SPF, DKIM and DMARC in order to declare: “This domain never sends email. If you receive one, discard it immediately.” This is essential to protect against spoofing: attackers could use “dormant” domains or variations of your domain (typosquatting) to send phishing, since no one is watching them.

Here is the DNS configuration to apply:

Type	Host / Name	Value	Role
TXT	@	v=spf1 -all	SPF (Declares that no one is authorized to send email on behalf of the domain)
TXT	_dmarc	v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s;	DMARC (Asks the recipient to reject any email that claims to come from the domain)
TXT	*._domainkey	v=DKIM1; p=	DKIM (Invalidates all keys)
MX	@	. (Priority 0)	MX (this domain does not receive email RFC 7505 (Null MX))

Summary and conclusion - 9/9

Mon, 01 Jan 0001 00:00:00 +0000

Summary and conclusion#

Mechanism	Date / RFC	Metaphor	Role	Key limits
FCrDNS	~1990s	The technical inspection of the truck that carries the envelopes.	Validates that the infrastructure owner (the one who controls the IP / L3) and the identity owner (the one who controls the Domain / L7) agree. Verifies that the sender’s `PTR` is not generic.	Does not prove that the source IP is legitimate to send an email on behalf of the sending domain, nor that the message has not been forged.
SPF	2006 (RFC 4408) 2014 (RFC 7208)	Validates that the truck is authorized to carry the sender’s mail.	Authorizes a list of IPs to send email on behalf of the domain indicated in the `Return-Path`.	Vulnerable to redirection. No alignment with the visible field (`From`).
DKIM	2007 (RFC 4871) 2011 (RFC 6376)	Digital wax seal Police evidence seal	Guarantees the integrity and authenticity of the message by adding a cryptographic signature to it. (`d=` in the DKIM header).	No mandatory alignment with `From`. Does not guarantee confidentiality (the email remains readable).
DMARC	2015 (RFC 7489)	The Butler (head of the protocol). Verifies that the letter’s header is aligned either with the address on the back of the envelope (SPF) or with the digital wax seal (DKIM signature)	Verifies the alignment of the domain verified by SPF or DKIM with the visible domain (`From`). Defines the policy for handling failures (`none`, `quarantine`, `reject`). Enables reporting (RUA/RUF)	Works only if SPF/DKIM are implemented and the policy is active.

Securing email is not the business of a single protocol, but rests on a defense-in-depth strategy. Combining the FCrDNS, SPF, DKIM and DMARC protocols makes it possible to create a robust chain of trust, making technical identity spoofing almost impossible, provided the chain is not broken.