SPF, DKIM, and DMARC Explained: How to Authenticate Your Email Domain

Email was designed in the early 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. There is no authentication, no verification, and no technical barrier to sending an email that appears to come from someone else. That is why phishing works. That is why your domain can be spoofed. And that is why three protocols were invented to fix the problem: SPF, DKIM, and DMARC.

These are not optional extras. They are foundational requirements for email deliverability and security in 2026. Major email providers like Gmail, Outlook, and Yahoo now require proper authentication for incoming messages. Google's email sender guidelines mandate SPF, DKIM, and DMARC for bulk senders, and the threshold for what constitutes "bulk" keeps dropping. Messages from domains without these records are increasingly sent to spam or rejected outright.

According to the Cybersecurity and Infrastructure Security Agency (CISA), email authentication is critical enough that CISA issued Binding Operational Directive 18-01, requiring all federal agencies to implement DMARC with a policy of reject. The directive recognized that email spoofing posed a significant and pervasive threat to government communications and public trust.

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. It is the first line of defense against domain spoofing.

When a receiving server gets an email claiming to be from [email protected], it looks up the SPF record for yourdomain.com in DNS. If the sending server's IP address appears in that record, the SPF check passes. If not, the message fails SPF, and the receiving server handles it according to its local policies (and your DMARC record, if one exists).

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 record (version 1)
• include:spf.reusable.email — authorizes Reusable.Email's mail servers to send for your domain
• -all — tells receivers to reject any server not listed (hard fail)

The include: directive is how you authorize third-party email services. Each service you use — transactional email, marketing platforms, helpdesk tools — needs to be included in your SPF record.

Common Variations

Qualifier	Meaning	When to Use
-all (hard fail)	Reject unauthorized messages outright	Production — recommended for most domains
~all (soft fail)	Accept but mark unauthorized messages as suspicious	Testing phase — while verifying all legitimate senders are listed
?all (neutral)	No opinion on unauthorized messages	Rarely useful — provides no real protection
+all	Authorize everyone	Never use this. It defeats the entire purpose of SPF

SPF Limitations

SPF has two important limitations that you need to understand.

First, SPF only validates the "envelope from" address (the server-level sender used in the SMTP transaction), not the "header from" address (what the recipient sees in their email client). This means SPF alone does not prevent display-name spoofing — an attacker can send from their own server while setting the visible "From" header to your address. This gap is exactly why you need DKIM and DMARC in addition to SPF.

Second, SPF has a 10-lookup limit. Each include:, a, mx, and redirect directive counts as a DNS lookup. Nested includes count toward the total. If your SPF evaluation exceeds 10 lookups, the entire SPF check results in a permerror (permanent error), and the check is treated as a failure.

This limit becomes a real constraint when you use multiple email services. A marketing platform, a transactional email provider, a helpdesk, and your primary email service can easily consume the entire lookup budget. If you are approaching the limit, SPF record flattening — replacing include: directives with the actual IP addresses they resolve to — can help, though it requires ongoing maintenance as those IP addresses change.

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 published 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. This makes DKIM the strongest form of email authentication because it provides both sender verification and content integrity.

How It Works

1. Your mail server generates a key pair: a private key (kept securely on the server) and a public key (published in DNS as a TXT record).
2. When sending a message, the server uses the private key to create a cryptographic hash of specific message headers and the body.
3. This hash is added to the email as a DKIM-Signature header, along with metadata specifying which headers were signed and which selector to use for key lookup.
4. The receiving server extracts the selector from the signature, fetches the corresponding public key from DNS, and uses it to verify the hash.
5. If the hash matches, the message has not been tampered with and was sent by 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 DKIM keys, each with a different selector, enabling key rotation without downtime.
• _domainkey — standard prefix for DKIM records, required by the specification.
• v=DKIM1 — version identifier.
• k=rsa — the key type. RSA is the most common, though Ed25519 keys are gaining adoption for their smaller size and stronger security properties.
• p= — the public key, base64 encoded. This is typically a long string (1024 or 2048 bits for RSA).

Why DKIM Matters for Security

DKIM is the only email authentication mechanism that validates message content. SPF says "this server is allowed to send." DKIM says "this specific message was authorized by the domain owner and has not been altered since it was sent."

This matters for more than just spam prevention. DKIM provides a cryptographic audit trail that proves a message is genuine. If a phishing email claims to come from your bank but fails DKIM verification, your email client and provider can flag it accordingly. If a legitimate email passes DKIM, the recipient has high confidence that it arrived exactly as the sender intended.

DKIM Key Management

DKIM keys should be rotated periodically. The National Institute of Standards and Technology (NIST) recommends using 2048-bit RSA keys at minimum and rotating them regularly. If a private key is compromised and you have not rotated, an attacker can sign messages as your domain until you publish a new key and revoke the old one.

Key rotation with DKIM is straightforward because of the selector mechanism. You can publish a new key under a new selector, configure your mail server to use it, verify that messages are being signed correctly, and then remove the old selector from DNS. The transition can happen with zero downtime and zero disruption to email delivery.

DMARC: The Policy Layer

DMARC (Domain-based Message Authentication, Reporting & Conformance) sits on top of SPF and DKIM. It does two critical things that neither SPF nor DKIM can do alone:

1. Defines a policy for what receivers should do when both SPF and DKIM fail (or fail to align with the visible "From" address).
2. Enables reporting so you can see who is sending email as your domain — including unauthorized senders you might not know about.

Without DMARC, each email provider decides independently how to handle SPF and DKIM failures. Some reject, some quarantine, some do nothing. DMARC lets you set the rules for your domain and get visibility into how those rules are applied.

What the Record Looks Like

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100"

• v=DMARC1 — version identifier
• p= — the policy to apply when authentication fails
• rua= — where to send aggregate reports (XML reports showing authentication results for your domain)
• pct= — percentage of messages to which the policy applies (useful for gradual rollout)

DMARC Policies

Policy	Meaning	When to Use
p=none	Do not take action, just send reports	Initial setup and monitoring phase
p=quarantine	Send failing messages to spam	Transition phase — after verifying legitimate senders pass
p=reject	Block failing messages entirely	Full enforcement — the goal state

Start with p=none if you are setting up a new domain and want to monitor before enforcing. This policy tells receivers to deliver all messages normally but send you reports about authentication results. Review these reports to identify any legitimate email sources that are not properly authenticated.

Once you are confident that all your legitimate email passes SPF and DKIM, move to p=quarantine. This sends failing messages to spam rather than the inbox, protecting recipients while still allowing you to catch misconfigurations. After a period of stable operation at quarantine, move to p=reject for full enforcement.

CISA's Binding Operational Directive 18-01 required federal agencies to reach p=reject within one year. The phased approach — none, then quarantine, then reject — is the recommended path for any organization.

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 checked by SPF or DKIM matches the domain in the visible "From" address that the recipient sees.

This alignment requirement is what closes the gap that SPF leaves open. Without DMARC, an attacker could send email from their own authorized server (passing their own SPF) while spoofing your domain in the "From" header. DMARC catches this because the SPF-authenticated domain does not match the "From" domain.

DMARC alignment can be configured as "strict" (exact domain match) or "relaxed" (organizational domain match, allowing subdomains). Relaxed alignment is the default and works for most configurations.

How the Three Work Together

Here is the complete authentication flow when someone receives an email claiming to be from your domain:

1. SPF check: The receiving server checks whether the sending server's IP address is authorized in your domain's SPF record.
2. DKIM check: The receiving server verifies the cryptographic signature on the message against the public key in your DKIM DNS record.
3. DMARC evaluation: The receiving server checks whether SPF or DKIM passed with alignment to the "From" header domain. If neither passes with alignment, the DMARC policy is applied.

When all three checks pass, the message is fully authenticated. The recipient's mail server has high confidence that the message is legitimate — it came from an authorized server, its content has not been tampered with, and the authentication aligns with the domain the recipient sees. The message is delivered to the inbox.

When authentication fails and DMARC is set to reject, the message is blocked before it reaches the recipient. Spoofing attempts against your domain are stopped at the gate.

Common Mistakes to Avoid

Multiple SPF records. A domain can only have one SPF TXT record. If you add a second one (perhaps when configuring a new email service), both records become invalid according to the specification. The fix is to combine multiple services into a single SPF record using include: directives.

Forgetting DKIM key rotation. DKIM keys should be rotated periodically. If your key is compromised and you have not rotated, an attacker can sign messages as your domain. Set a calendar reminder to rotate keys at least annually, and use 2048-bit RSA keys at minimum.

Starting with p=reject immediately. Going straight to reject without a monitoring phase will block legitimate email from services you forgot to authorize — marketing platforms, transactional email providers, helpdesk tools, and other third-party senders. Always start with p=none, review the aggregate reports, fix any authentication gaps, then escalate through quarantine to reject.

Exceeding the SPF lookup limit. Each include:, a, mx, and redirect directive counts toward the 10-lookup limit. Nested includes within those directives also count. Use tools like MXToolbox or dmarcian to check your current lookup count. If you are at or near 10, flatten your SPF record or consolidate services.

Not setting up DMARC at all. SPF and DKIM without DMARC means you have no control over what happens when authentication checks fail, and you get no visibility into spoofing attempts against your domain. DMARC is the enforcement and reporting layer that makes SPF and DKIM actionable.

Ignoring DMARC reports. Setting p=none and never reading the reports defeats the purpose. The reports show you which services are sending email as your domain, whether those services are passing authentication, and whether anyone is attempting to spoof your domain. Review them regularly, especially during the initial monitoring phase.

Reusable.Email 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. A missing DMARC record means no enforcement and no reporting.

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 — missing records, incorrect values, or lookup limit issues.

This auto-configuration means you get enterprise-grade email authentication without needing to understand the technical details of each protocol. Your domain is protected from spoofing, your legitimate email is properly authenticated, and you have full DMARC reporting from day one.

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. And for the security context of why these protocols matter, see email security best practices.

Summary

Protocol	Purpose	Validates	Limitation Without Others
SPF	Declares authorized sending servers	Sending server IP address	Does not validate message content or "From" header
DKIM	Signs messages cryptographically	Message content integrity and sender authorization	No enforcement policy for failures
DMARC	Enforces policy and provides reporting	SPF/DKIM alignment with the visible "From" domain	Nothing to evaluate without SPF and DKIM

All three are necessary. SPF alone has gaps — it does not protect the "From" header. DKIM alone has no enforcement policy — it proves authenticity but does not tell receivers what to do when authentication fails. DMARC alone has nothing to evaluate — it depends on SPF and DKIM results. Together, they form a complete authentication system that protects your domain from spoofing, ensures your legitimate email gets delivered, and gives you visibility into who is using your domain to send email.

Frequently Asked Questions

Do I need SPF, DKIM, and DMARC if I only send personal email?

Yes. Even personal domains benefit from email authentication. Without these records, email from your domain may be flagged as spam or rejected by major providers like Gmail and Yahoo. SPF and DKIM ensure your messages are delivered, and DMARC protects your domain from being spoofed by attackers. The setup is a one-time investment that pays dividends every time you send an email.

What happens if I exceed the SPF 10-lookup limit?

If your SPF record exceeds 10 DNS lookups, the entire SPF evaluation results in a permanent error (permerror). Most receiving servers treat this the same as an SPF failure, which can cause your legitimate email to be flagged as spam or rejected. Use tools like MXToolbox to check your current count, and flatten your SPF record (replacing include: directives with the actual IP addresses) if you are approaching the limit.

How do I read DMARC aggregate reports?

DMARC aggregate reports are XML files sent to the address specified in your rua= tag. They contain data about which servers sent email using your domain, whether SPF and DKIM passed, and how many messages were affected. Raw XML is hard to read, so use a DMARC report analyzer like dmarcian, Postmark's DMARC tool, or DMARC Analyzer to visualize the data and identify issues.

Can DMARC break my existing email setup?

It can, if you skip the monitoring phase. Starting with p=none ensures that no messages are blocked while you review which services are sending email as your domain. Once you have verified that all legitimate senders pass SPF and DKIM with alignment, you can safely escalate to quarantine and then reject. The phased approach prevents disruption.

How long does it take for DNS changes to take effect?

DNS changes typically propagate within minutes to a few hours, depending on the TTL (time to live) settings of your records and the caching behavior of recursive resolvers. Most SPF, DKIM, and DMARC changes are effective within one to four hours. During the propagation period, both old and new records may be returned depending on which DNS resolver the receiving server queries.