SPF, DKIM, and DMARC Explained: How to Authenticate Your Email Domain
Email was designed in the 1980s without any built-in way to verify who sent a message. The "From" address in an email is just a text field — anyone can write anything in it. That's why phishing works. That's why your domain can be spoofed. And that's why three protocols were invented to fix the problem: SPF, DKIM, and DMARC.
These aren't optional extras. Major email providers like Gmail, Outlook, and Yahoo now require proper authentication. Messages from domains without SPF, DKIM, and DMARC are increasingly sent to spam or rejected outright.
SPF: Who Is Allowed to Send
SPF (Sender Policy Framework) is a DNS record that declares which mail servers are authorized to send email on behalf of your domain.
When a receiving server gets an email claiming to be from you@yourdomain.com, it looks up the SPF record for yourdomain.com. If the sending server's IP address appears in that record, the check passes. If not, the message fails SPF.
What the Record Looks Like
yourdomain.com. IN TXT "v=spf1 include:spf.reusable.email -all"
Breaking this down:
v=spf1— identifies this as an SPF recordinclude:spf.reusable.email— authorizes Reusable.Email's servers to send for your domain-all— tells receivers to reject any server not listed (hard fail)
Common Variations
~all(soft fail) — messages from unauthorized servers are accepted but marked as suspicious. Used during testing.-all(hard fail) — unauthorized messages are rejected outright. Recommended for production.+all— authorizes everyone. Never use this. It defeats the entire purpose of SPF.
SPF Limitations
SPF only validates the "envelope from" address (the server-level sender), not the "header from" address (what the recipient sees). This means SPF alone doesn't prevent display-name spoofing. That's why you need DKIM and DMARC too.
SPF also has a 10-lookup limit. Each include: directive counts as a lookup. Exceed 10, and the entire SPF check fails. If you use multiple email services (marketing, transactional, support), this limit can become a real problem. Keep your SPF record lean.
DKIM: Proving the Message Is Authentic
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing message. The receiving server verifies this signature against a public key in your DNS.
Unlike SPF, DKIM validates the message itself, not just the sending server. If anyone alters the email in transit — changes the body, modifies a link, adds a header — the signature breaks and the DKIM check fails.
How It Works
- Your mail server generates a key pair: a private key (kept on the server) and a public key (published in DNS).
- When sending a message, the server uses the private key to create a hash of specific message headers and the body.
- This hash is added to the email as a
DKIM-Signatureheader. - The receiving server fetches the public key from DNS and uses it to verify the hash.
If the hash matches, the message hasn't been tampered with and came from a server with access to the private key.
What the Record Looks Like
selector._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4..."
selector— identifies which key to use (a domain can have multiple keys for rotation)_domainkey— standard prefix for DKIM recordsv=DKIM1— version identifierk=rsa— the key typep=— the public key, base64 encoded
The public key is typically a long string. This is normal.
Why DKIM Matters
DKIM is the strongest form of email authentication because it ties the message content to a cryptographic proof. SPF says "this server is allowed to send." DKIM says "this specific message was authorized and hasn't been altered."
DMARC: The Policy Layer
DMARC (Domain-based Message Authentication, Reporting & Conformance) sits on top of SPF and DKIM. It does two things:
- Defines a policy for what receivers should do when SPF and DKIM both fail.
- Enables reporting so you can see who's sending email as your domain.
Without DMARC, each email provider decides independently how to handle SPF/DKIM failures. Some reject, some quarantine, some do nothing. DMARC lets you set the rules.
What the Record Looks Like
_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com"
v=DMARC1— version identifierp=— the policy (what to do when checks fail)rua=— where to send aggregate reports
DMARC Policies
| Policy | Meaning | When to Use |
|---|---|---|
p=none |
Don't take action, just report | Initial setup, monitoring phase |
p=quarantine |
Send failing messages to spam | Transition phase |
p=reject |
Block failing messages entirely | Full enforcement |
Start with p=none if you're setting up a new domain and want to monitor before enforcing. Once you're confident your legitimate email passes SPF and DKIM, move to p=quarantine and eventually p=reject.
DMARC Alignment
For DMARC to pass, at least one of SPF or DKIM must pass and be aligned with the "From" header domain. Alignment means the domain in the SPF or DKIM check matches the domain in the visible "From" address.
This is what closes the gap SPF leaves open. Even if SPF passes for a different domain, DMARC requires alignment with the domain the recipient actually sees.
How the Three Work Together
Here's what happens when someone receives an email from your domain:
- SPF check: Is the sending server authorized? (DNS lookup for SPF record)
- DKIM check: Is the message signature valid? (DNS lookup for DKIM public key)
- DMARC evaluation: Did SPF or DKIM pass with alignment? If not, apply the DMARC policy.
All three passing means the message is fully authenticated. The recipient's mail server has high confidence that the message is legitimate and delivers it to the inbox.
If you send email without these records, providers like Gmail and Yahoo will increasingly flag or reject your messages. As of 2024, Google requires SPF, DKIM, and DMARC for bulk senders. The threshold for "bulk" keeps dropping.
Common Mistakes
Multiple SPF records. A domain can only have one SPF TXT record. If you add a second one, both are invalid. Combine multiple services into a single record using include: directives.
Forgetting DKIM key rotation. DKIM keys should be rotated periodically. If your key is compromised and you haven't rotated, an attacker can sign messages as your domain.
Starting with p=reject. Going straight to reject without monitoring will block legitimate email from services you forgot to authorize. Start with p=none, review reports, fix any issues, then escalate.
Exceeding the SPF lookup limit. Each include:, a, mx, and redirect counts toward the 10-lookup limit. Flatten your SPF record if you're getting close.
Not setting up DMARC at all. SPF and DKIM without DMARC means you have no control over what happens when checks fail, and you get no visibility into spoofing attempts.
Reusable.Email's Auto-Configuration
Setting up SPF, DKIM, and DMARC manually requires understanding all of the above — and getting every record exactly right. One misplaced character in a DKIM key breaks signing. A misconfigured SPF record silently causes rejections.
When you add a custom domain to Reusable.Email, the dashboard auto-generates all three records plus the MX record. You copy the values into your registrar's DNS settings using the provided step-by-step guides. The system verifies your configuration and tells you if anything is wrong.
For the complete domain setup process, see the custom domain email setup guide. For a broader look at how custom domain email works with unlimited aliases and catch-all routing, see the custom domain email guide.
Summary
| Protocol | Purpose | Validates |
|---|---|---|
| SPF | Declares authorized senders | Sending server IP |
| DKIM | Signs messages cryptographically | Message content integrity |
| DMARC | Enforces policy + reporting | SPF/DKIM alignment with From domain |
All three are necessary. SPF alone has gaps. DKIM alone has no enforcement policy. DMARC alone has nothing to evaluate. Together, they form a complete authentication system that protects your domain from spoofing and ensures your legitimate email gets delivered.