Email Authentication Guide: SPF, DKIM, DMARC Setup

Why Email Authentication Matters

Email authentication is the foundation of deliverability. Without it, mailbox providers have no way to verify that a message claiming to be from your domain was actually sent by you. Unauthenticated email is indistinguishable from phishing, and providers like Gmail, Outlook, and Yahoo treat it accordingly: straight to spam, or rejected outright.

According to Google and Yahoo's 2024 bulk sender requirements, all senders must authenticate with SPF, DKIM, and DMARC starting February 2024. Senders who deliver more than 5,000 messages per day must also publish a DMARC policy (at minimum p=none), provide one-click unsubscribe headers, and keep spam complaint rates below 0.3%. Non-compliant senders face throttling and outright rejection.

Authentication works alongside list hygiene to maximize inbox placement. Even perfectly authenticated emails will damage your sender reputation if you send to invalid or disengaged addresses. The MailOdds Email Validation API catches invalid, disposable, and risky addresses before they enter your pipeline, while authentication protocols prove your identity to receiving servers.

If you are sending transactional or marketing email through the MailOdds Email Sending API, authentication is handled automatically when you verify your sending domain. This guide explains each protocol in depth so you understand what is happening behind the scenes and can troubleshoot when things go wrong.

SPF: Sender Policy Framework

RFC 7208

SPF lets domain owners publish a DNS TXT record listing the IP addresses and third-party services authorized to send email on their behalf. When a receiving server gets a message, it checks the sending IP against the SPF record of the domain in the envelope MAIL FROM address. If the IP is not authorized, the check fails.

SPF Record Syntax

An SPF record is a TXT record at your domain root. Here is an example that authorizes MailOdds and Google Workspace:

v=spf1 include:spf.mailodds.net include:_spf.google.com ~all

DKIM: DomainKeys Identified Mail

RFC 6376

DKIM adds a cryptographic signature to every outgoing email. The sending server signs message headers and body using a private key. The receiving server retrieves the corresponding public key from DNS and verifies the signature. If the signature checks out, the receiver knows the message was not altered in transit and that it genuinely originated from the claimed domain.

How DKIM Signing Works

RSA vs Ed25519: Dual Signing

MailOdds uses dual DKIM signing: Ed25519 as the primary algorithm for modern receivers that support it, with RSA 2048-bit as a fallback for older systems. Ed25519 signatures are smaller, faster to verify, and cryptographically stronger than equivalent RSA keys. However, some older mail servers do not yet support Ed25519 (defined in RFC 8463), so the RSA fallback ensures universal compatibility.

DNS Record Format

DKIM public keys are published at selector._domainkey.example.com. The selector is a label chosen by the sender that allows multiple keys per domain (useful for key rotation and multi-provider setups).

;; DKIM public key record
mo2024._domainkey.example.com IN TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."

DMARC: Domain-based Message Authentication

RFC 7489

DMARC builds on SPF and DKIM by adding a policy layer and a reporting mechanism. It tells receiving servers what to do when neither SPF nor DKIM passes with alignment, and it provides aggregate and forensic reports so domain owners can monitor authentication failures across all sending sources.

Policy Progression

DMARC policies should be deployed gradually. According to Valimail's 2024 Email Authentication Report, only 30% of domains have reached DMARC enforcement (quarantine or reject), leaving 70% vulnerable to spoofing. MailOdds recommends the following progression:

DMARC Record Example

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

Alignment Modes

Reporting

Advanced: MTA-STS and DANE/TLSA

SPF, DKIM, and DMARC authenticate the identity of the sender. The next layer protects the transport channel itself, ensuring that messages are encrypted in transit and delivered to the correct server. These protocols guard against man-in-the-middle attacks and DNS spoofing.

version: STSv1
mode: enforce
mx: mail.example.com
max_age: 604800

_25._tcp.mail.example.com IN TLSA 3 1 1 a]b2c3d4e5f6...

Step-by-Step Setup with MailOdds

Follow these five steps to fully authenticate your sending domain. The entire process takes about 15 minutes, plus DNS propagation time.

v=spf1 include:spf.mailodds.net ~all

mo._domainkey.example.com CNAME dkim.mailodds.net

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Verify Domain via API

Check the authentication status of your sending domain programmatically.

curl -X POST https://api.mailodds.com/v1/sending-domains/verify \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '"domain": "example.com"'

{
  "domain": "example.com",
  "spf": { "status": "pass", "record": "v=spf1 include:spf.mailodds.net ~all" },
  "dkim": { "status": "pass", "selector": "mo", "algorithm": "ed25519-sha256" },
  "dmarc": { "status": "pass", "policy": "none" },
  "verified": true
}

Frequently Asked Questions

Related Resources