Understanding SPF and DKIM. 8 min read

Email was designed in the 1970s without any authentication mechanism. The SMTP protocol trusts whatever From address the sender claims. This makes email trivially easy to spoof — anyone can send an email claiming to be from your domain.

SPF and DKIM were developed to solve this problem. Together, they allow receiving mail servers to verify that an email claiming to be from your domain was actually sent by an authorized server (SPF) and hasn't been tampered with in transit (DKIM). Since February 2024, Google and Yahoo require at least one of these for all bulk senders.

SPF works by publishing a DNS TXT record that lists the IP addresses and hostnames authorized to send email on your domain's behalf. When a receiving server gets an email claiming to be from your domain, it checks your SPF record to see if the sending IP is on the list.

An SPF record looks like this: v=spf1 include:_spf.bird.com include:_spf.google.com ip4:203.0.113.0/24 -all. This record authorizes Bird's sending IPs, Google Workspace's IPs, and a specific IP range. The -all at the end means 'reject everything else' — a hard fail.

Common mistakes: including too many DNS lookups (SPF has a 10-lookup limit), using ~all (soft fail) instead of -all (hard fail) in production, and forgetting to add new sending services when they're provisioned. Each include: counts as one lookup, and nested includes count toward the total. If you exceed 10, SPF breaks entirely.

DKIM adds a cryptographic signature to each outgoing email. Your sending server signs the message with a private key. The corresponding public key is published in your DNS records. The receiving server retrieves the public key and verifies the signature, confirming that the message hasn't been altered since it was signed.

DKIM signing covers specific headers and the message body. This means if anyone modifies the content in transit — a common tactic in phishing — the DKIM signature fails and the receiving server knows the message was tampered with.

DKIM is configured per sending service. Each ESP, transactional email provider, and internal mail server needs its own DKIM key pair. The public key is published as a DNS TXT record under a selector subdomain (e.g., bird._domainkey.yourdomain.com). Use 2048-bit keys — 1024-bit keys are considered deprecated by most security standards.

Rotate DKIM keys annually. While there's no expiration mechanism built into DKIM, regular rotation limits the window of exposure if a private key is compromised.

SPF and DKIM solve different problems and are strongest when used together. SPF verifies the sending server's authorization. DKIM verifies message integrity. Neither alone is sufficient.

SPF can pass even if the message content was modified (it only checks the sending IP). DKIM can pass even if the email was sent from an unauthorized server (it only checks the signature). Together, they provide both authorization and integrity verification.

Both SPF and DKIM feed into DMARC, which is the policy layer that tells receiving servers what to do when authentication fails. Without DMARC, SPF and DKIM failures are informational — the receiving server might still deliver the message. With DMARC, you control the outcome: report, quarantine, or reject.

To verify your configuration, send test emails and check the Authentication-Results header in the received message. Both SPF and DKIM should show 'pass.' If either shows 'fail' or 'neutral,' investigate your DNS records and sending infrastructure configuration.