Email security: SPF, DKIM, DMARC and sender impersonation

The SMTP (Simple Mail Transfer Protocol) has no native authentication mechanism: anyone can send an email with any sender address. SPF, DKIM, and DMARC are extensions that add verification mechanisms. Their absence allows an attacker to send convincing emails on behalf of your organisation, facilitating phishing, BEC (Business Email Compromise), and social engineering attacks.

SPF (Sender Policy Framework)

SPF is a DNS TXT record that lists the servers authorised to send emails on behalf of your domain. When a mail server receives an email from your domain, it checks whether the sender's IP is listed in your SPF record. If not, the email is suspect. Absent SPF allows any server to send emails in your name. Overly permissive SPF (+all) is equivalent to no SPF.

SPF record example

# Enregistrement DNS TXT pour example.com :
example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all"

# -all : rejeter les emails qui ne correspondent pas (strict, recommandé)
# ~all : soft fail (marquer comme suspect, pas rejeter) - moins sécurisé
# +all : accepter tout - ne pas utiliser

# Tester : dig TXT example.com | grep spf

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to each sent email. The sending server signs the email with a private key. The receiving server verifies the signature with the public key published in the domain's DNS. DKIM guarantees two things: the email comes from a server controlling the domain's private key, and the email content hasn't been modified in transit. DKIM alone isn't enough: an attacker can send a DKIM-signed email from a subdomain or similar domain.

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

DMARC coordinates SPF and DKIM and defines what the receiving server should do when checks fail. It also allows receiving reports on emails sent in your domain's name. The three DMARC policies: none (monitor only, block nothing), quarantine (spam-flag failing emails), reject (reject failing emails). A p=none policy doesn't protect against impersonation.

Recommended DMARC record

# Enregistrement DNS TXT pour _dmarc.example.com :
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-reports@example.com; sp=reject"

# p=reject : rejeter les emails qui échouent SPF et DKIM
# pct=100 : appliquer à 100% des emails (commencer à 25% pour une transition progressive)
# rua : adresse de réception des rapports agrégés
# sp : politique pour les sous-domaines

Recommended progression

Deploy SPF, DKIM, and DMARC progressively to avoid blocking legitimate emails. Step 1: set up SPF with ~all (soft fail) and DKIM on all sending servers. Step 2: deploy DMARC with p=none and analyse reports for 2 to 4 weeks. Step 3: identify and fix missing legitimate servers. Step 4: move to p=quarantine then p=reject. Step 5: change SPF from ~all to -all.