Email spoofing is the practice of sending email with a forged From address, making the message appear to originate from a domain the sender does not control. It is the technical mechanism behind most phishing attacks that impersonate organizations.
SPF, DKIM, and DMARC are three DNS-based mechanisms that together provide domain-level email authentication. Each addresses a different part of the spoofing problem, and each is insufficient on its own. This article explains what each mechanism does, how they work together, and how to verify your configuration is correctly deployed.
Why Email Spoofing Is Possible
The SMTP protocol, defined in RFC 5321, has no built-in authentication for the MAIL FROM address (the envelope sender) or the From header visible to email recipients. Any mail server can assert any return address and any From header. The receiving server has historically had no technical mechanism to verify the claim.
SPF, DKIM, and DMARC were developed to add that verification capability, but they are opt-in. A domain that does not publish these records has no declared authentication policy, and receiving servers must decide independently how to handle unauthenticated mail.
SPF: Authorizing Sending Servers
SPF (Sender Policy Framework) is a TXT record published at the root of a domain that lists the mail servers authorized to send email for that domain. When a receiving mail server receives a message, it checks the SPF record for the domain in the MAIL FROM (envelope sender) address to see whether the sending server's IP address is listed.
SPF Record Syntax
An SPF record is a single TXT record at the root domain. Only one SPF record is permitted per domain (RFC 7208, Section 3.2). Multiple SPF records cause an error and the policy becomes undefined.
# Authorize Google Workspace and a specific IP, reject everything else
v=spf1 include:_spf.google.com ip4:203.0.113.42 -all
# Authorize SendGrid, soft-fail everything else
v=spf1 include:sendgrid.net ~allCommon SPF mechanisms:
include:domain: Includes the SPF record from another domain. Used for third-party senders like email service providers.ip4:address/prefix: Authorizes a specific IPv4 address or CIDR range.ip6:address/prefix: Same for IPv6.a: Authorizes the domain's A record addresses.mx: Authorizes the domain's MX record hosts.-all: Hard fail. Reject messages from servers not listed.~all: Soft fail. Accept but mark messages from unlisted servers.?all: Neutral. No policy on unlisted servers.
Using -all (hard fail) provides the strongest policy. Using ~all (soft fail) is often used as a first step when transitioning, but should eventually be tightened to -all once all legitimate senders are confirmed in the record.
SPF Limitations
SPF checks the MAIL FROM envelope address, not the From header that recipients see. An attacker can configure their own domain to pass SPF for the envelope sender while setting the visible From header to your domain. SPF alone does not protect the From header visible to recipients.
SPF also has a DNS lookup limit of 10 per evaluation. Records with many include: directives can exceed this limit, causing SPF to return a PermError result, which is treated as neutral by many receivers.
DKIM: Signing Messages Cryptographically
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to email messages. The sending server signs specific headers and the message body with a private key. The receiving server retrieves the corresponding public key from DNS and verifies the signature.
A valid DKIM signature proves two things: the message was sent by a server in possession of the private key for the signing domain, and the signed portions of the message have not been modified in transit.
The DKIM DNS Record
DKIM public keys are published at a selector-specific subdomain: selector._domainkey.example.com. The selector is chosen by the email sender and referenced in the DKIM-Signature header of outgoing mail. This allows multiple DKIM keys to coexist (for different sending services) and enables key rotation without disrupting other senders.
# Example DKIM TXT record at google._domainkey.example.com
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...The DKIM key length should be at least 2048 bits. 1024-bit keys are considered insufficiently strong by current standards and should be rotated. Key rotation should be performed periodically (annually at minimum) following the procedure of publishing a new key, waiting for the TTL to expire, updating the signing configuration, and then removing the old key record.
DMARC: Policy and Alignment
DMARC (Domain-based Message Authentication, Reporting and Conformance) does two things: it ties SPF and DKIM results together through alignment requirements, and it allows domain owners to declare a policy for what receiving servers should do with messages that fail authentication.
Alignment
DMARC alignment is what closes the gap that SPF alone leaves. For DMARC to pass on a message, either SPF or DKIM must pass AND be aligned with the From header domain.
SPF alignment means the SPF-authenticated domain (the MAIL FROM domain) matches the From header domain. DKIM alignment means the DKIM signing domain (d= in the DKIM-Signature header) matches the From header domain.
An attacker who forges a From header with your domain cannot pass DMARC alignment unless they also control the private key for your DKIM selector or are authorized by your SPF record, neither of which they should be.
Policy Levels
A DMARC record is a TXT record at _dmarc.example.com.
# Report-only mode (no enforcement)
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
# Quarantine failing messages (move to spam)
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com
# Reject failing messages
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.comThe recommended deployment progression is: start with p=none and configure a reporting address to collect DMARC aggregate reports. Review the reports to identify all legitimate sending infrastructure. Once all legitimate senders pass authentication, move to p=quarantine, then to p=reject.
A DMARC policy of p=none provides reporting but no protection. It is a valid first step in deployment but should not remain at none indefinitely.
Why All Three Are Required
- SPF without DMARC: Protects the envelope sender but not the visible From header. Attackers can pass SPF with their own domain while spoofing your From header.
- DKIM without DMARC: Proves the signing server possessed the private key, but does not require the signing domain to match the From header. An attacker can sign with their own domain and spoof the From header.
- DMARC without SPF and DKIM: DMARC requires at least one of SPF or DKIM to produce an aligned pass result. Without both mechanisms configured, DMARC enforcement cannot function reliably.
- All three together: DMARC with alignment closes the From-header spoofing gap that SPF and DKIM individually leave open.
Verifying Your Configuration
Verify each record with DNS lookups:
# Check SPF record
dig TXT example.com | grep spf
# Check DMARC record
dig TXT _dmarc.example.com
# Check DKIM record (replace 'google' with your selector)
dig TXT google._domainkey.example.comFor SPF, verify there is exactly one TXT record containing v=spf1. Multiple records cause a PermError.
For DMARC, verify the policy is quarantine or reject and that a valid reporting address (rua) is configured. Confirm you can receive mail at that address or that it is routed to a DMARC reporting service.
Tools like MXToolbox (mxtoolbox.com) and dmarcian (dmarcian.com) provide web-based lookups that parse and explain these records and surface common errors.
To confirm DMARC reports are being received, send a test email from an external service and wait 24 hours for aggregate report delivery. The report will show authentication results for mail claiming to originate from your domain.
Common Mistakes
- Multiple SPF records: Creating two or more TXT records containing
v=spf1at the same domain. Per RFC 7208 this is an error and the policy becomes undefined. Merge all SPF mechanisms into a single record. - SPF with
+all: This authorizes all senders to send mail from your domain. It is effectively no policy at all. - DMARC
p=noneleft permanently: Many deployments start at none and never advance. Without enforcement, there is no protection against spoofing. - No DKIM key rotation: DKIM private keys that are never rotated represent a persistent risk if the key material is ever compromised or leaked.
- DMARC without a reporting address: Without
rua, you will not receive aggregate reports that show authentication failures, making it difficult to identify unauthorized senders. - SPF lookup limit exceeded: Using many
include:directives can exceed the 10-lookup limit. Use an SPF flattening service or manually inline IP ranges to stay within the limit.