Introduction to Email Authentication. 11 min read

Email authentication proves that an email actually came from who it claims to be from. Without authentication, anyone can send email pretending to be your brand — and they do. Phishing attacks cost businesses $17,700 per minute globally. Email spoofing is used in 90% of data breaches.

Beyond security, authentication is now a deliverability requirement. Since February 2024, Google and Yahoo require SPF, DKIM, and DMARC for all bulk senders. Without proper authentication, your legitimate marketing and transactional emails may be rejected or filtered to spam.

This guide covers the three authentication protocols in plain language with practical setup steps for each.

Sender Policy Framework (SPF) lets you declare which servers are authorized to send email from your domain. You publish this as a DNS TXT record, and receiving servers check it when they get an email from your domain.

Setting up SPF: identify all services that send email on your behalf — your email marketing platform, transactional email service, CRM, helpdesk, and internal mail server. Each one has specific IP addresses or hostnames that need to be included in your SPF record.

A typical SPF record: v=spf1 include:_spf.bird.com include:_spf.google.com ip4:198.51.100.0/24 -all. This authorizes Bird, Google Workspace, and a specific IP range. The -all at the end means 'reject anything not on this list.'

Common pitfalls: the 10-DNS-lookup limit is the most frequent cause of SPF failures. Every 'include' counts as one lookup, and nested includes within those count too. If you exceed 10, SPF evaluation stops and fails. Use SPF flattening tools if you're approaching the limit.

Verification: send an email and check the Authentication-Results header. SPF should show 'pass.' If it shows 'softfail' or 'fail,' your SPF record doesn't include the sending server.

DomainKeys Identified Mail (DKIM) adds a digital signature to each email you send. The signature is created with a private key that only your sending server has. The matching public key is published in your DNS records. Receiving servers use the public key to verify the signature, confirming that nobody modified the email after it left your server.

Setting up DKIM: generate a key pair (most ESPs do this for you). Publish the public key as a DNS TXT record under a selector subdomain — for example, bird._domainkey.yourdomain.com. Configure your sending server to sign outgoing emails with the private key.

Use your own domain for DKIM signing, not the ESP's default. When you sign with your own domain (custom DKIM), the reputation benefits accrue to your domain. Default ESP signing means you're sharing reputation with every other sender on that ESP.

Key size: use 2048-bit keys. 1024-bit keys are technically functional but considered weak by modern security standards. Some DNS providers limit TXT record length, which can make 2048-bit keys tricky — you may need to split the key across multiple strings in the TXT record.

Rotate keys annually as a security best practice. When rotating, publish the new key before removing the old one, and allow a 48-hour overlap to account for DNS propagation and in-flight messages signed with the old key.

Domain-based Message Authentication, Reporting & 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 reporting that tells you who is sending email from your domain.

DMARC requires domain alignment — the domain in your email's From header must match the domain authenticated by SPF or DKIM. This prevents an attacker from authenticating with their own domain while spoofing your From address.

Start with monitoring: publish a DMARC record with p=none to collect reports without affecting delivery. The record looks like: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100. The rua address receives daily aggregate reports from mailbox providers showing authentication results for all email sent from your domain.

Analyze reports for 2 to 4 weeks to identify all legitimate sending sources and fix any authentication gaps. Once all legitimate sources pass DMARC, move to enforcement gradually: p=quarantine at pct=10, then 25, then 50, then 100. Finally, move to p=reject at pct=100.

At p=reject, your domain is fully protected: any email that fails DMARC authentication is blocked by receiving servers. This is the gold standard for email security and deliverability.