mailwel
Controllables · updated 2026-04-11

Authentication & Identity Control

Why Authentication Is the Foundation

Email was designed in an era of implicit trust. The original SMTP protocol has no built-in way to verify that a sender is who they claim to be. Anyone can set the From header to any address. This fundamental limitation gave rise to phishing, spoofing, and spam — and forced the industry to build authentication layers on top of SMTP.

Today, SPF, DKIM, and DMARC form the authentication triad. Together, they answer three questions that every mailbox provider asks about incoming mail:

  1. Is this server authorized to send for this domain? (SPF)
  2. Is this message actually from who it claims to be, unmodified? (DKIM)
  3. What should I do if authentication fails, and does everything align? (DMARC)

Passing all three is the minimum requirement for serious senders. Failing any of them doesn’t guarantee spam placement, but it significantly lowers the probability of inbox delivery and leaves your domain vulnerable to spoofing.

SPF (Sender Policy Framework)

What SPF Does

SPF allows a domain owner to publish a DNS TXT record listing which IP addresses and servers are authorized to send email on behalf of that domain. When a receiving server gets a message, it checks the sending IP against the SPF record of the envelope sender’s domain (the Return-Path or MAIL FROM address).

How SPF Works

  1. You publish a TXT record at your domain: v=spf1 include:_spf.google.com include:amazonses.com -all
  2. A receiving server extracts the Return-Path domain from the incoming message
  3. The server looks up the SPF record for that domain
  4. The server checks if the sending IP is listed in the authorized sources
  5. The result is one of: pass, fail, softfail, neutral, or permerror

SPF Record Syntax

v=spf1                          — Version declaration (required)
ip4:203.0.113.0/24              — Authorize an IPv4 range
ip6:2001:db8::/32               — Authorize an IPv6 range
include:_spf.google.com         — Include another domain's SPF record
a                               — Authorize the domain's A record IPs
mx                              — Authorize the domain's MX record IPs
redirect=_spf.example.com       — Redirect SPF evaluation to another record
-all                            — Hard fail: reject anything not listed
~all                            — Soft fail: accept but mark as suspicious
?all                            — Neutral: no assertion

SPF Best Practices

Keep it under the 10-lookup limit. SPF evaluation allows a maximum of 10 DNS lookups (includes, redirects, MX, A record lookups). Exceeding this limit causes a permanent error (permerror), which means SPF effectively fails. This is the most common SPF misconfiguration.

Use -all not ~all. Hard fail (-all) tells providers to reject unauthorized mail. Soft fail (~all) tells them to accept it but treat it as suspicious. In practice, most providers treat softfail similarly to fail, but -all sends a stronger signal that you take authentication seriously.

Flatten when necessary. If you use multiple ESPs, your include chain can easily exceed 10 lookups. SPF flattening resolves the include chain into direct IP lists. Tools and services can automate this, but you must keep the flattened record updated when ESP IPs change.

Don’t forget the Return-Path. SPF evaluates the Return-Path (envelope sender), not the From header. If your ESP uses their own Return-Path domain, SPF passes for their domain, not yours. This is where DMARC alignment becomes critical.

Common SPF Mistakes

  • Publishing multiple SPF records (only one TXT record starting with v=spf1 is allowed per domain)
  • Exceeding the 10-lookup limit without realizing it
  • Using +all (authorizes everyone — defeats the entire purpose)
  • Not including all sending services (forgetting CRM, helpdesk, or other tools that send on your behalf)
  • Stale records with IPs from services you no longer use

DKIM (DomainKeys Identified Mail)

What DKIM Does

DKIM adds a cryptographic signature to outgoing messages. The sending server signs the message (specific headers and the body) with a private key. The corresponding public key is published in DNS. The receiving server retrieves the public key and verifies that the signature is valid and the message hasn’t been tampered with.

How DKIM Works

  1. The sending server generates a hash of specified message headers and body content
  2. The hash is encrypted with the domain’s private key
  3. The encrypted hash is added as a DKIM-Signature header
  4. The receiving server reads the DKIM-Signature header to identify the signing domain and selector
  5. The server fetches the public key from DNS (selector._domainkey.yourdomain.com)
  6. The server decrypts the hash and compares it against a freshly computed hash of the message
  7. If they match, DKIM passes. If not, it fails.

DKIM Signature Anatomy

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=selector1;
  h=from:to:subject:date:message-id;
  bh=abc123...=;
  b=xyz789...=;

Key fields:

  • d= — The signing domain (critical for DMARC alignment)
  • s= — The selector (identifies which key to use)
  • h= — Which headers were signed
  • c= — Canonicalization method (relaxed allows minor modifications)
  • a= — Algorithm (rsa-sha256 is standard; ed25519 is emerging)

DKIM Best Practices

Use 2048-bit keys minimum. 1024-bit RSA keys are still common but increasingly considered weak. 2048-bit keys provide significantly better security. Some DNS providers have issues with the longer TXT records — split them across multiple strings if needed.

Rotate keys periodically. Rotate DKIM keys every 6–12 months. The process is: publish the new key alongside the old one, update your signing configuration to use the new key, verify mail is signing with the new key, then remove the old key after a transition period.

Sign with your own domain. Many ESPs sign with their own domain by default (e.g., d=sendgrid.net). For DMARC alignment, you need DKIM to sign with YOUR domain (d=yourdomain.com). Most ESPs support custom DKIM signing — configure it.

Include critical headers in the signature. At minimum, sign From, To, Subject, Date, and Message-ID. The From header is required for DMARC alignment.

Use relaxed canonicalization. The relaxed/relaxed setting allows minor whitespace and header case changes that can occur during mail transport. simple/simple is stricter but more likely to cause false DKIM failures from legitimate modifications.

Common DKIM Mistakes

  • Not configuring custom DKIM signing at your ESP (relying on the ESP’s default domain)
  • Using 512-bit or 1024-bit keys that can be cracked
  • Publishing the DKIM TXT record with formatting errors (missing quotes, truncated key)
  • Not signing with the same domain as the From header (breaks DMARC alignment)
  • Forgetting to update DNS when rotating keys

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

What DMARC Does

DMARC ties SPF and DKIM together with a policy layer. It tells receiving servers:

  1. How to check alignment — Does the authenticated domain (SPF or DKIM) match the From header domain?
  2. What to do on failure — Should the server reject, quarantine, or do nothing with unauthenticated mail?
  3. Where to send reports — Aggregate (rua) and forensic (ruf) reports provide visibility into authentication results.

How DMARC Alignment Works

DMARC requires that at least one of SPF or DKIM aligns with the From header domain:

  • SPF alignment: The Return-Path domain matches (or is a subdomain of) the From header domain
  • DKIM alignment: The DKIM d= domain matches (or is a subdomain of) the From header domain

Alignment can be strict (exact domain match) or relaxed (subdomain matches parent). Relaxed is the default and is recommended for most senders.

Example:

  • From header: user@example.com
  • Return-Path: bounces@mail.example.com — SPF relaxed alignment passes (subdomain of example.com)
  • DKIM d=example.com — DKIM alignment passes (exact match)
  • DKIM d=sendgrid.net — DKIM alignment fails (different domain)

DMARC Record Syntax

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; pct=100; adkim=r; aspf=r;

Key fields:

  • p= — Policy: none (monitor only), quarantine (spam folder), reject (refuse delivery)
  • rua= — Aggregate report address (daily XML reports)
  • ruf= — Forensic report address (per-failure reports, often not sent by providers)
  • pct= — Percentage of mail to apply the policy to (useful for gradual rollout)
  • adkim= — DKIM alignment mode: r (relaxed) or s (strict)
  • aspf= — SPF alignment mode: r (relaxed) or s (strict)

DMARC Deployment Strategy

The recommended rollout path:

Phase 1: Monitor (p=none) Publish a DMARC record with p=none and an rua address. This tells providers to send reports but take no action on failures. Analyze reports for 2–4 weeks to identify all legitimate sending sources.

Phase 2: Quarantine (p=quarantine; pct=10) Start with a low percentage to quarantine (spam folder) unauthenticated messages. Monitor for false positives — legitimate mail that fails alignment. Gradually increase pct as you fix alignment issues.

Phase 3: Reject (p=reject) Once you’re confident all legitimate mail passes alignment, move to reject. This tells providers to refuse delivery of unauthenticated messages entirely. This is the strongest protection against domain spoofing.

DMARC Best Practices

Always have an rua address. Aggregate reports are the only way to see who is sending mail as your domain — including unauthorized senders. Use a DMARC report analysis service to process the XML data.

Move toward p=reject. A p=none DMARC record provides monitoring but no protection. Only reject or quarantine policies actively prevent spoofing. Providers also give a slight reputation boost to domains with enforced DMARC policies.

Account for third-party senders. Before enforcing DMARC, make sure every service that sends mail on your behalf (CRM, helpdesk, marketing tools, billing systems) passes either SPF or DKIM alignment with your domain.

Monitor reports continuously. DMARC isn’t set-and-forget. New services, IP changes, or misconfigurations can cause legitimate mail to fail. Regular report analysis catches problems early.

ARC (Authenticated Received Chain)

ARC is a newer standard that addresses a specific problem: mail forwarding breaks authentication. When a message is forwarded (e.g., university mail forwarded to Gmail), SPF fails because the forwarding server isn’t in the original domain’s SPF record. DKIM may also break if the forwarder modifies the message.

ARC creates a chain of authentication results at each hop. If the original message passed authentication, and the forwarding server is trusted, the final recipient’s provider can honor the original results.

ARC is primarily implemented by mailbox providers rather than senders. As a sender, your role is to ensure SPF, DKIM, and DMARC are solid — ARC helps preserve those results through forwarding chains.

BIMI (Brand Indicators for Message Identification)

BIMI allows senders with enforced DMARC policies (p=quarantine or p=reject) to display their brand logo next to messages in the inbox. It’s not directly an authentication mechanism, but it builds on authentication:

  1. Publish a BIMI DNS record pointing to your logo (SVG format)
  2. Obtain a VMC (Verified Mark Certificate) from a certificate authority
  3. Mailbox providers that support BIMI (Gmail, Yahoo, Apple Mail) display the logo

BIMI is a visual trust signal. It doesn’t directly improve deliverability scoring, but it can improve open rates (branded messages are more recognizable) and it requires strong authentication as a prerequisite.

Putting It All Together

The complete authentication stack for a well-configured sender:

  1. SPF: TXT record authorizing all legitimate sending IPs, using include for ESP senders, ending with -all
  2. DKIM: 2048-bit key, signing with your own domain, proper selector configuration at your ESP
  3. DMARC: p=reject policy with rua reporting, relaxed alignment for both SPF and DKIM
  4. rDNS: Sending IP resolves to a hostname under your domain
  5. TLS: All connections encrypted (most modern ESPs handle this automatically)
  6. BIMI (optional): Brand logo display for enforced DMARC domains

Authentication alone doesn’t guarantee inbox placement. But without it, you are fighting with one hand tied behind your back. Every other deliverability optimization builds on this technical trust foundation.