DMARCSPFDKIMemail authenticationemail securitymisconfiguration

DMARC, SPF, and DKIM Explained: Why Your Email Security Fails

C
Cyber121 Team
The Cyber121 team is a group of cybersecurity practitioners building community tools, training resources, and threat intelligence for security professionals.
April 2, 202610 min read0 views
DMARC, SPF, and DKIM Explained: Why Your Email Security Fails

DMARC, SPF, and DKIM Explained: Why Your Email Security Fails

Email spoofing β€” sending emails that appear to come from a domain you do not own β€” remains trivially easy for attackers. The three email authentication standards (SPF, DKIM, and DMARC) were designed to prevent this, but misconfiguration is widespread. A 2023 analysis found that over 80% of Fortune 500 domains do not enforce DMARC, leaving them open to impersonation.

This guide explains how each mechanism works, what correct implementation looks like, and how to verify your own domain's configuration.

The Problem: SMTP Was Not Designed for Security

The Simple Mail Transfer Protocol (SMTP), which underpins all email, was designed in 1982 without authentication in mind. By default, any mail server can claim to send email from any domain. SPF, DKIM, and DMARC are retrofitted standards that address this gap β€” but they require correct configuration to be effective.

SPF (Sender Policy Framework)

How It Works

SPF allows a domain owner to publish a list of authorised mail servers in a DNS TXT record. When a receiving mail server gets an email claiming to be from @example.com, it checks the DNS record for example.com to verify the sending server is on the authorised list.

Example SPF Record

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 -all
ComponentMeaning
v=spf1SPF version 1
include:_spf.google.comAuthorise Google Workspace servers
include:sendgrid.netAuthorise SendGrid (transactional email)
ip4:203.0.113.0/24Authorise a specific IP range
-allFail all other senders (hard fail)

Common SPF Misconfigurations

Using ~all (soft fail) instead of -all (hard fail): Soft fail marks unauthorised senders as suspicious but does not reject them. Many receiving servers treat soft fail the same as pass. Use -all for enforcement.

Exceeding the 10 DNS lookup limit: SPF records that include too many include: statements can exceed the 10 DNS lookup limit, causing SPF to fail for legitimate emails. Flatten your SPF record using tools like MXToolbox SPF Flattener.

Not including all sending services: If you use a third-party email service (Mailchimp, HubSpot, Salesforce, etc.) and do not include it in your SPF record, legitimate emails from that service will fail SPF.

DKIM (DomainKeys Identified Mail)

How It Works

DKIM uses asymmetric cryptography to sign outgoing emails. The sending mail server signs the email with a private key, and the public key is published in DNS. Receiving servers verify the signature against the public key β€” if it matches, the email was not modified in transit and was authorised by the domain.

Example DKIM Record

selector._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN..."

What DKIM Protects Against

DKIM prevents message tampering β€” an attacker intercepting an email cannot modify the content without invalidating the signature. It also provides a form of sender authentication, since only the domain owner controls the private key.

Common DKIM Misconfigurations

Key length too short: DKIM keys shorter than 1024 bits are considered weak. Use 2048-bit keys where possible.

Selector not published: If your email provider generates a DKIM key but you forget to publish the DNS record, all outgoing emails will fail DKIM.

Signing only some emails: Some configurations only sign transactional emails but not marketing emails, creating inconsistent authentication.

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

How It Works

DMARC builds on SPF and DKIM by:

  1. Specifying what receiving servers should do when authentication fails (none / quarantine / reject)
  2. Requiring alignment β€” the domain in the From header must match the domain that passed SPF or DKIM
  3. Providing a reporting mechanism so domain owners can see authentication failures

Example DMARC Record

_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100"
ComponentMeaning
p=rejectReject emails that fail DMARC
rua=Aggregate report destination
ruf=Forensic report destination
pct=100Apply policy to 100% of emails

The Policy Progression

Most organisations should follow this progression:

  1. p=none β€” Monitor mode. Collect reports without affecting email delivery. Start here to understand your email sending landscape.
  2. p=quarantine β€” Move failing emails to spam/junk. Implement after reviewing reports and fixing legitimate sending sources.
  3. p=reject β€” Block failing emails entirely. The target state for full protection.

Why p=none Is Not Protection

A DMARC policy of p=none provides zero protection against spoofing β€” it only generates reports. Yet many organisations set it and forget it, believing they are protected. Attackers specifically target domains with p=none DMARC policies.

Verifying Your Domain's Configuration

Using Command Line Tools

bash
# Check SPF
dig TXT example.com | grep spf

# Check DMARC
dig TXT _dmarc.example.com

# Check DKIM (replace 'selector' with your actual selector)
dig TXT selector._domainkey.example.com

Using the Cyber121 Phishing Analyser

The Cyber121 Phishing Analyser [blocked] checks SPF, DKIM, and DMARC records for any domain and provides a plain-English verdict on the authentication configuration. Enter your own domain to audit your setup, or enter a suspicious sender's domain to evaluate an incoming email.

The Complete Email Authentication Checklist

CheckStatusAction Required
SPF record publishedβœ“/βœ—Publish v=spf1 ... -all
SPF uses -all (hard fail)βœ“/βœ—Change ~all to -all
SPF under 10 DNS lookupsβœ“/βœ—Flatten SPF record
DKIM configured for all sending sourcesβœ“/βœ—Enable DKIM in each sending service
DKIM uses 2048-bit keyβœ“/βœ—Regenerate with 2048-bit key
DMARC record publishedβœ“/βœ—Publish _dmarc TXT record
DMARC policy is quarantine or rejectβœ“/βœ—Progress from p=none
DMARC aggregate reports configuredβœ“/βœ—Add rua= address

Going Further

Correctly implementing SPF, DKIM, and DMARC is a prerequisite for phishing defence, but it is not sufficient on its own. Attackers who cannot spoof your domain will simply register a lookalike domain instead.

For a complete phishing investigation framework β€” covering header analysis, URL inspection, attachment analysis, and incident documentation β€” the Cyber121 Phishing Investigation Toolkit [blocked] provides a 52-page playbook and Excel investigation log built by practitioners.


Published by the Cyber121 team. Cyber121 is a cybersecurity community platform providing free security tools, CVE intelligence, and professional training resources.

C
Cyber121 Team

The Cyber121 team is a group of cybersecurity practitioners building community tools, training resources, and threat intelligence for security professionals.

Share:LinkedInXFacebook

Comments

Sign in to join the conversation

No comments yet. Be the first to share your thoughts!