Skip to main content
Web & Security How-To Guide Research-Based Assessment Beginner

How to Authenticate Domain Email: SPF, DKIM, and DMARC Guide

Aadil Prawez Aadil Prawez 6 min read

Technical Implementation Guide: This tutorial provides standard RFC-compliant DNS specifications for email authentication protocols. HonestyReviewed is reader-supported and maintains strict editorial independence. Implementation requires administrative access to your domain’s DNS provider (e.g., Cloudflare, Route 53, Namecheap, or GoDaddy).

Introduction: Why Domain Authentication is Mandatory

In modern email infrastructure, domain authentication is no longer optional. As of 2024, major mailbox providers—led by Google Workspace and Yahoo Mail—enforce mandatory technical requirements for all domain senders. Senders who fail to implement proper cryptographic authentication face aggressive spam filtering, delayed message delivery, or outright 550 5.7.1 bounce rejections.

Email authentication relies on three foundational, interlocking DNS protocols:

  1. SPF (Sender Policy Framework): Specifies which IP addresses and mail servers are authorized to send email on behalf of your domain name.
  2. DKIM (DomainKeys Identified Mail): Appends a cryptographic digital signature to outgoing email headers, proving that the message was authorized by the domain owner and was not altered in transit.
  3. DMARC (Domain-based Message Authentication, Reporting, and Conformance): Instructs receiving mail servers how to handle messages that fail SPF or DKIM checks (e.g., none, quarantine, or reject) and provides automated delivery reports.

Step 1: Configuring Sender Policy Framework (SPF)

SPF is published as a single TXT record at the root of your domain (@). It contains an authorized list of IP addresses, hostnames, and third-party email service provider mechanisms.

SPF Record Syntax Structure

v=spf1 include:mailgun.org include:_spf.google.com ~all

Key SPF Mechanisms & Rules:

  • v=spf1: Mandatory version identifier tag. Must appear at the very beginning of the string.
  • include:provider.com: Authorizes a third-party email service (e.g., Google Workspace, Kit, Brevo, or SendGrid) to send on your behalf.
  • ip4:192.0.2.1: Authorizes a specific static IPv4 address.
  • ~all (SoftFail): Recommends that receiving servers accept unlisted senders but flag them for scrutiny (ideal during initial deployment).
  • -all (HardFail): Instructs receiving servers to strictly reject any messages originating from unauthorized IP addresses.
Critical Rule — The 10 DNS Lookup Limit: RFC 7208 limits SPF evaluations to a maximum of 10 DNS lookups per message. Exceeding 10 lookups results in a PermError, causing authentication to fail. Never publish more than one SPF TXT record for a single domain name; combine all authorized senders into a single TXT record string.

SPF Flattening & Overcoming the 10-Lookup Limit

When organizations use multiple SaaS platforms simultaneously (for example, Google Workspace for corporate email, Kit for newsletters, Zendesk for support tickets, and Stripe for receipts), nested include: mechanisms quickly exceed the 10-lookup threshold. SPF flattening resolves this by replacing nested include domains with their resolved, direct IP addresses (ip4: or ip6:), reducing DNS lookups to zero while maintaining security compliance.

Step 2: Generating & Publishing DKIM Records

DKIM utilizes asymmetric public-key cryptography (RSA). Your email delivery service holds the private key and signs outgoing headers, while you publish the corresponding public key in your domain’s DNS as a TXT or CNAME record.

DKIM DNS Record Example

DKIM records are indexed using a Selector prefix (e.g., k1._domainkey.yourdomain.com):

Record TypeHost / NameValue / Target
TXTk1._domainkeyv=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3...
CNAMEs1._domainkeys1.domainkey.brevomail.com

Always use 2048-bit RSA keys whenever supported by your DNS host and email platform. 1024-bit keys are considered cryptographically weak and are deprecated by modern security standards.

Step 3: Implementing DMARC Policy

DMARC ties SPF and DKIM together by enforcing Domain Alignment (ensuring the visible From: address matches the validated SPF or DKIM domain) and providing instructions on how to handle failed authentication.

DMARC DNS Record Configuration

Publish a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; pct=100; aspf=r; adkim=r

DMARC Policy Progression:

  1. Phase 1: Monitoring (p=none): No messages are blocked. Aggregate XML reports are sent to your rua address to identify legitimate sending sources across your organization.
  2. Phase 2: Quarantine (p=quarantine): Messages that fail alignment are diverted to the recipient’s Spam/Junk folder.
  3. Phase 3: Enforcement (p=reject): Mailbox providers immediately reject and drop all unauthenticated spoofed messages at the gateway.

Analyzing DMARC XML Aggregate Reports

Receiving mail servers generate daily XML reports containing sending IP addresses, message volumes, SPF/DKIM verification statuses, and domain alignment evaluations. Utilizing dedicated DMARC analysis tools (such as Postmark DMARC Monitor, Valimail, or DMARCLY) allows administrators to identify unauthorized shadow IT sending services or malicious spoofing attempts originating from rogue servers.

Step 4: Verification & DNS Propagation Testing

After adding your DNS records, verify that they are publicly resolving and correctly formatted using command-line terminal utilities or online check tools:

Verifying via Command Line (Linux/macOS):

# Check SPF Record
dig +short TXT yourdomain.com

# Check DKIM Record
dig +short TXT k1._domainkey.yourdomain.com

# Check DMARC Record
dig +short TXT _dmarc.yourdomain.com

Common Implementation Mistakes & Troubleshooting

  • Multiple SPF Records: Having two TXT records with v=spf1 causes receiving servers to return an SPF PermError. Always merge into a single line.
  • Missing DMARC rua Address: Without a valid rua=mailto:... tag, you will not receive the daily XML reporting needed to diagnose deliverability bottlenecks.
  • DNS Syntax Quotation Errors: When pasting long DKIM public keys, ensure quotes are not malformed or duplicated by your DNS provider interface.

Related Guides & Platform Teardowns

Continue strengthening your email delivery infrastructure with our companion resources:

DKIM Canonicalization: Simple vs. Relaxed

DKIM header signing allows two canonicalization algorithms for both headers and message bodies: simple and relaxed (e.g., c=relaxed/relaxed). The simple algorithm tolerates zero whitespace or capitalization modifications during email transmission. The relaxed algorithm normalizes consecutive whitespace characters and case variations, preventing legitimate cryptographic signatures from breaking when intermediary mail transfer agents (MTAs) reformat line breaks. Always configure your email service provider to use relaxed/relaxed canonicalization.

DMARC Alignment: Strict vs. Relaxed Modes

DMARC alignment tags (aspf for SPF and adkim for DKIM) define how strictly the domain in the visible From: header must match the authenticated domain in SPF (Return-Path) or DKIM (d= tag). By default, relaxed alignment (aspf=r; adkim=r) allows organizational subdomains (e.g., marketing.yourdomain.com) to align with the apex domain (yourdomain.com). Strict alignment (aspf=s; adkim=s) requires an exact, character-for-character domain match.

Was this evaluation helpful to your research?

Tutorial by Aadil Prawez

Founder & Editor • 5 years professional experience

Aadil Prawez is the Founder & Editor of HonestyReviewed, bringing 5 years of professional experience across email marketing, infrastructure deliverability, performance marketing, and SaaS technology.