The Complete Email Authentication Guide

Why Email Authentication Matters

Email was originally designed without built-in identity verification. Anyone could (and still can) send an email claiming to be from any address. Email authentication protocols were developed to solve this problem by providing mechanisms for receiving servers to verify that a message actually came from the domain it claims to be from.

Without authentication, your domain is vulnerable to spoofing (someone else sending email pretending to be you), phishing attacks against your customers, and poor deliverability because mailbox providers cannot distinguish your legitimate email from forged messages.

SPF (Sender Policy Framework)

SPF is the simplest of the three authentication protocols. It lets you declare which mail servers are authorized to send email on behalf of your domain by publishing a DNS TXT record.

How SPF Works

When a receiving mail server gets a message from your domain, it looks up your domain's SPF record in DNS. The SPF record contains a list of authorized sending IP addresses and hostnames. If the sending server's IP matches one of the authorized sources, the SPF check passes. If not, it fails.

SPF Record Syntax

An SPF record is a DNS TXT record published at your domain's root. It always starts with v=spf1 and ends with an "all" mechanism that defines the default policy for unauthorized senders.

v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:203.0.113.50 -all

Here is what each part means:

• v=spf1 - Version identifier (required, must be first)
• include:_spf.google.com - Authorize all servers listed in Google's SPF record (for Google Workspace)
• include:servers.mcsv.net - Authorize Mailchimp's sending servers
• ip4:203.0.113.50 - Authorize a specific IPv4 address
• -all - Fail any server not listed above (hard fail)

SPF Mechanisms

SPF Qualifiers

The qualifier before all determines what happens to unauthorized mail:

• -all (hard fail) - Unauthorized mail should be rejected. Recommended for most domains.
• ~all (soft fail) - Unauthorized mail should be accepted but flagged. Use during initial setup.
• ?all (neutral) - No assertion about unauthorized mail. Not recommended.
• +all (pass all) - Authorize everything. Never use this; it defeats the purpose of SPF entirely.

Common SPF Mistakes

• Multiple SPF records - A domain must have exactly one SPF TXT record. Having two or more causes SPF to fail.
• Exceeding 10 lookups - Too many include statements will break SPF validation.
• Using +all - This authorizes all servers on the internet and provides no protection.
• Forgetting third-party senders - Every service that sends email as your domain (ESP, CRM, ticketing system) needs to be included.
• Using ptr mechanism - The PTR mechanism is slow and unreliable. It is officially discouraged in the SPF specification.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to each outgoing email. The receiving server can verify this signature using a public key published in your DNS, confirming that the message was actually sent by your domain and was not tampered with during transit.

How DKIM Works

DKIM uses public key cryptography. Your mail server signs each outgoing message with a private key. The corresponding public key is published as a DNS TXT record. When a receiving server gets your message, it retrieves your public key from DNS and uses it to verify the signature.

The signing process covers specific headers (typically From, Subject, Date, Message-ID) and the body of the message. If any of these are modified after signing, the DKIM check will fail.

DKIM Signature Header

A DKIM signature is added as a header to the email message. Here is an example:

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

Key fields in the signature:

• d= - The signing domain (must align with the From domain for DMARC)
• s= - The selector, used to locate the public key in DNS
• a= - The signing algorithm (rsa-sha256 is standard)
• h= - List of headers included in the signature
• b= - The actual signature
• bh= - Hash of the message body

DKIM DNS Record

The public key is published as a TXT record at selector._domainkey.yourdomain.com. For example, if your selector is google, the record would be at:

google._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

Key fields in the DKIM DNS record:

• v=DKIM1 - Version (required)
• k=rsa - Key type (rsa is standard)
• p= - The public key, base64 encoded. An empty p= means the key has been revoked.

DKIM Key Length

DKIM keys should be at least 1024 bits, though 2048-bit keys are now recommended. Some DNS providers have a 255-character limit for TXT record strings, which means 2048-bit keys may need to be split across multiple strings within the same record. Your DNS provider should handle this automatically.

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

DMARC ties SPF and DKIM together and adds two critical capabilities: a policy that tells receiving servers what to do when authentication fails, and a reporting mechanism that lets you see who is sending email as your domain.

How DMARC Works

When a receiving server gets an email, it checks DMARC by looking up the DMARC record for the domain in the From header. DMARC passes if either SPF or DKIM passes AND the domain is aligned (meaning the domain in the SPF or DKIM check matches the domain in the From header).

DMARC Record Format

A DMARC record is published as a TXT record at _dmarc.yourdomain.com:

_dmarc.example.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-forensics@example.com; pct=100; adkim=r; aspf=r"

DMARC Tags Explained

DMARC Policies

• p=none - Monitor only. No action is taken on failing messages, but you receive reports. Start here.
• p=quarantine - Messages that fail DMARC are sent to spam/junk. Good intermediate step.
• p=reject - Messages that fail DMARC are rejected entirely. Maximum protection, but only deploy after thorough monitoring.

DMARC Alignment

Alignment is what makes DMARC powerful. It ensures that the domain authenticated by SPF or DKIM matches the domain in the visible From header that the user sees.

• Relaxed alignment (default) - The organizational domain must match. For example, mail.example.com aligns with example.com.
• Strict alignment - The exact domain must match. mail.example.com would NOT align with example.com.

How SPF, DKIM, and DMARC Work Together

These three protocols form a layered defense system:

1. SPF verifies that the sending server is authorized by the domain owner.
2. DKIM verifies that the message content has not been altered and was signed by the claimed domain.
3. DMARC ensures that at least one of SPF or DKIM passes with proper alignment, and tells receivers what to do when both fail.

A properly configured domain has all three working together. SPF alone cannot prevent spoofing because it only checks the envelope sender (Return-Path), not the visible From header. DKIM alone cannot prevent spoofing because a receiver has no policy for what to do when it fails. DMARC bridges this gap by combining both checks with alignment and a clear policy.

Setting Up Authentication Step by Step

Here is the recommended order for implementing email authentication:

Step 1: Audit Your Email Sources

Before changing any DNS records, identify every service and server that sends email using your domain. This includes your primary email platform (Google Workspace, Microsoft 365), marketing tools (Mailchimp, HubSpot), transactional email services (SendGrid, Amazon SES), CRM systems, helpdesk software, and any on-premise servers.

Step 2: Configure SPF

Create a single SPF TXT record that includes all identified sending sources. Start with ~all (soft fail) while testing:

v=spf1 include:_spf.google.com include:amazonses.com ip4:198.51.100.0/24 ~all

Step 3: Configure DKIM

Enable DKIM signing in each email service. Each service will provide you with a CNAME or TXT record to publish. The selector names will vary by provider (for example, Google uses google, SendGrid might use s1 and s2).

Step 4: Set Up DMARC (Monitor Mode)

Start with a monitoring-only DMARC policy and a reporting address:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100

Step 5: Review Reports

Monitor DMARC aggregate reports for 2-4 weeks. Look for legitimate sources that are failing SPF or DKIM. Fix any gaps in your authentication configuration.

Step 6: Tighten the Policy

Once you are confident that all legitimate mail passes DMARC, move to p=quarantine. After another monitoring period, move to p=reject for maximum protection.

Testing Your Configuration

After setting up authentication, use these tools to verify everything is working correctly:

• SPF Record Checker - Validate SPF syntax, mechanisms, and lookup count
• DKIM Record Checker - Verify DKIM key publication and key length
• DMARC Record Checker - Check DMARC policy, alignment, and reporting settings
• Sender Reputation Checker - Get a comprehensive Sender Reputation Score