SPF, DKIM, and DMARC Explained: The Complete Email Authentication Guide

Every day, over 3 billion phishing emails are sent worldwide. Many of them claim to be from legitimate organizations: your bank, your employer, your SaaS provider. The recipients see a familiar domain in the "From" field and trust it. But the email didn't come from that organization at all. It came from an attacker who exploited a gap in the domain's email authentication configuration.

Three DNS-based protocols exist specifically to prevent this: SPF, DKIM, and DMARC. Together, they form a layered defense that tells the receiving mail server who is authorized to send email on your behalf, proves that messages haven't been tampered with in transit, and defines what should happen when authentication fails.

When configured correctly, these three protocols make it extremely difficult for attackers to spoof your domain. When misconfigured, or missing entirely, your domain becomes an open invitation for phishing, business email compromise, and brand impersonation.

This guide explains how each protocol works, how they fit together, the most common misconfigurations that break them, and how to verify your setup is correct.

---

Why Email Authentication Matters

Email was designed in the 1970s without any built-in authentication. The SMTP protocol, which still carries virtually all email today, allows anyone to put anything in the "From" field. There's nothing in the protocol itself that prevents an attacker from sending email that claims to be from your CEO, your billing department, or your domain.

This isn't a theoretical problem. Business Email Compromise (BEC) attacks caused over $2.9 billion in reported losses in 2023, according to the FBI's 2023 Internet Crime Report. Many of these attacks rely on domain spoofing, where the attacker sends email that appears to come from a trusted domain.

SPF, DKIM, and DMARC were developed to close this gap. They don't replace email encryption or prevent all phishing, but they do give receiving mail servers the tools to verify that an email claiming to be from your domain actually was sent by an authorized server.

Major email providers now enforce these standards aggressively. Google and Yahoo implemented strict requirements in February 2024: domains sending more than 5,000 messages per day to Gmail or Yahoo must have valid SPF, DKIM, and DMARC records, or their email will be rejected. Even smaller senders benefit from proper authentication, as it significantly improves deliverability and protects brand reputation.

---

SPF: Who Is Allowed to Send Email for Your Domain

SPF (Sender Policy Framework) is published as a TXT record on your domain and lists the servers authorized to send email on your behalf. When a receiving mail server gets a message claiming to be from your domain, it checks your SPF record to see if the sending server's IP address is on the authorized list.

How SPF Works

1. An email arrives at Gmail claiming to be from [e-mail]
2. Gmail extracts the sending server's IP address from the email headers
3. Gmail queries the DNS TXT records for yourcompany.com
4. It finds the SPF record and checks whether the sending IP is authorized
5. If the IP matches, SPF passes. If not, SPF fails.

Anatomy of an SPF Record

An SPF record is a TXT record that starts with v=spf1 and contains a series of mechanisms that define authorized senders:

yourcompany.com.  3600  IN  TXT  "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:sendgrid.net -all"

Breaking this down:

• v=spf1 — Version identifier. Must be the first element.
• ip4:203.0.113.0/24 — Authorize this entire IP range (your own mail servers)
• include:_spf.google.com — Include Google Workspace's authorized servers (if you use Gmail for business)
• include:sendgrid.net — Include SendGrid's servers (if you use SendGrid for transactional email)
• -all — Fail everything not explicitly authorized (hard fail)

The Qualifier: all Matters

The all mechanism at the end of your SPF record defines the default policy for IPs that don't match any earlier mechanism:

• -all (hard fail) — Reject unauthorized senders. This is the recommended production setting.
• ~all (soft fail) — Mark unauthorized senders as suspicious but don't reject. Useful during initial rollout when you're still identifying all your sending services.
• ?all (neutral) — Don't make any assertion. Essentially the same as having no SPF record.
• +all (pass all) — Authorize the entire internet to send as your domain. Never use this. It completely defeats the purpose of SPF.

Critical SPF Limitation: The 10-Lookup Rule

This is the single most common SPF misconfiguration. The SPF specification limits the total number of DNS lookups during evaluation to 10. Each include, a, mx, and redirect mechanism counts as one lookup. Nested includes count too: if _spf.google.com itself has 3 includes, that's 4 lookups total (1 for the include + 3 nested).

When the lookup count exceeds 10, SPF returns a permanent error (permerror). Many receiving servers treat permerror the same as a fail, which means your legitimate email gets rejected or sent to spam.

This problem creeps up over time as your organization adds email services. Marketing adds Mailchimp. Sales adds HubSpot. Support adds Zendesk. Engineering adds SendGrid. Customer success adds Intercom. Each one requires an include in your SPF record, and suddenly you're at 12 lookups without realizing it.

How to check: Use the DNS lookup tool at dnsassistant.com/tools to query your domain's TXT records and see your current SPF record. If you need a full audit, the Free Domain Risk Report will flag SPF issues including missing records and policy weaknesses.

Other SPF Gotchas

• Subdomains don't inherit SPF. If you have an SPF record on yourcompany.com, it does not apply to billing.yourcompany.com. Each subdomain that sends email needs its own SPF record.
• Only one SPF record per domain. If you have two TXT records that start with v=spf1, SPF evaluation returns permerror. This happens frequently when different teams add SPF records without coordinating.
• SPF checks the envelope sender, not the From header. SPF validates the MAIL FROM address (the envelope sender), which can differ from the From: header that users see. This is why SPF alone isn't enough — you need DMARC to tie everything together.

---

DKIM: Proving the Message Wasn't Tampered With

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing email that the receiving server can verify. Unlike SPF, which checks the sending server's identity, DKIM checks the message itself: was it actually signed by an authorized key for this domain, and has the content been modified since signing?

How DKIM Works

1. Your mail server signs outgoing messages with a private key, adding a DKIM-Signature header to the email
2. The signature includes a hash of specific headers and the message body, plus a reference to the selector (a name that identifies which key was used)
3. The receiving server extracts the selector from the signature and queries DNS for the DKIM public key: [selector]._domainkey.yourcompany.com
4. It verifies the signature using the public key
5. If the signature is valid and the content hasn't changed, DKIM passes

The DKIM DNS Record

The DKIM public key is published as a TXT record under a specific subdomain:

google._domainkey.yourcompany.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA..."

Breaking this down:

• google — The selector name. Each sending service typically uses its own selector (Google uses google, Postmark uses pm, etc.)
• _domainkey — Fixed namespace for DKIM records
• v=DKIM1 — Version identifier
• k=rsa — Key type (RSA is standard; Ed25519 is emerging)
• p=MIGf... — The actual public key (base64-encoded)

Multiple Selectors

Most organizations have multiple DKIM selectors because each email-sending service generates its own key pair. You might have:

• google._domainkey — Google Workspace
• s1._domainkey — SendGrid
• pm._domainkey — Postmark
• k1._domainkey — Mailchimp

Each selector operates independently. A receiving server uses the selector specified in the email's DKIM-Signature header to know which DNS record to query.

DKIM Pitfalls

• Key rotation: DKIM keys should be rotated periodically (annually at minimum). The new key must be published in DNS before the sending infrastructure switches to it. If the DNS record is removed or changed before the transition, messages signed with the old key will fail DKIM validation.
• Message modification: Mailing lists, forwarding services, and some email security gateways can modify message headers or body content, breaking the DKIM signature. This is a known limitation and one of the reasons DMARC's alignment check is important.
• Key length: 1024-bit RSA keys are still common but increasingly considered weak. 2048-bit keys provide better security but may need to be split across multiple TXT record strings due to DNS's 255-character string limit.

---

DMARC: Tying It All Together

DMARC (Domain-based Message Authentication, Reporting & Conformance) is the policy layer that ties SPF and DKIM together. It does two critical things:

1. Alignment: It checks that the domain in the From: header (what the user sees) matches the domain that passed SPF or DKIM. Without this, an attacker could pass SPF using their own domain while spoofing yours in the From: header.
2. Policy: It tells receiving servers what to do with messages that fail authentication, and provides a reporting mechanism so you can see who's sending email as your domain.

The DMARC DNS Record

DMARC is published as a TXT record at the _dmarc subdomain:

_dmarc.yourcompany.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[e-mail]; ruf=mailto:[e-mail]; pct=100; adkim=s; aspf=s"

Breaking this down:

• v=DMARC1 — Version identifier
• p=reject — Policy: reject messages that fail authentication
• rua=mailto:... — Aggregate report destination (XML summaries of authentication results, typically daily)
• ruf=mailto:... — Forensic report destination (individual failure details)
• pct=100 — Apply the policy to 100% of messages
• adkim=s — Strict DKIM alignment (domain must match exactly)
• aspf=s — Strict SPF alignment (domain must match exactly)

The Three DMARC Policy Levels

p=none (Monitor only) — Don't take any action on failing messages, but send reports. This is the starting point for every DMARC deployment. It lets you see who's sending email as your domain without risking legitimate email delivery.

p=quarantine (Send to spam) — Messages that fail authentication are sent to the recipient's spam or junk folder. This is the intermediate step once you've identified and authorized all legitimate senders.

p=reject (Block entirely) — Messages that fail authentication are rejected outright. This is the goal for maximum protection, but it requires confidence that all legitimate email sources are properly authenticated.

The DMARC Deployment Path

Jumping straight to p=reject without preparation will block legitimate email. Here's the recommended path:

1. Start with p=none — Publish a DMARC record with p=none and aggregate reporting enabled. Let it run for 2-4 weeks.
2. Analyze reports — Review the aggregate reports to identify all services sending email as your domain. You'll likely discover services you forgot about: the CRM sending notifications, the project management tool sending invitations, the billing system sending receipts.
3. Fix authentication — For each legitimate sender, ensure it's covered by your SPF record and has DKIM signing configured.
4. Move to p=quarantine — Once you're confident all legitimate sources are authenticated, move to quarantine. Start with pct=10 (apply to 10% of messages) and gradually increase.
5. Move to p=reject — After confirming no legitimate email is being quarantined, move to reject at pct=100.

This process typically takes 4-8 weeks. Rushing it risks blocking legitimate email. Taking too long leaves your domain unprotected.

Subdomain Policy

DMARC has a separate sp tag for subdomain policy:

v=DMARC1; p=reject; sp=reject; rua=mailto:[e-mail]

The sp=reject ensures that subdomains are also protected. Without it, an attacker could spoof billing.yourcompany.com or support.yourcompany.com even if your main domain has p=reject.

---

How SPF, DKIM, and DMARC Work Together

Each protocol covers a different aspect of email authentication. None of them is sufficient alone:

• SPF alone: Validates the sending server's IP but doesn't check the From: header that users see. An attacker can pass SPF using their own domain while spoofing yours in the From: field.
• DKIM alone: Validates the message signature but doesn't specify a policy for failures. A receiving server knows the signature is invalid but doesn't know if it should reject, quarantine, or accept the message.
• DMARC alone: Defines policy and alignment but has nothing to evaluate without SPF and DKIM results to align against.

Together, the flow works like this:

1. Email arrives claiming to be from [e-mail]
2. Receiving server checks SPF: is the sending IP authorized for yourcompany.com?
3. Receiving server checks DKIM: does the message have a valid signature from yourcompany.com?
4. Receiving server checks DMARC: does the domain in the From: header align with the domain that passed SPF or DKIM?
5. If alignment fails, the DMARC policy (none, quarantine, or reject) determines what happens
6. The result is reported back to the domain owner via DMARC aggregate reports

For a message to pass DMARC, it needs either SPF or DKIM to pass with alignment. It doesn't need both, although having both provides the strongest protection.

---

Common Misconfigurations and How to Spot Them

Missing SPF record

A domain with MX records (accepting email) but no SPF record is telling the world "I have no opinion on who can send email as me." Any server can claim to be you.

SPF with +all

An SPF record ending with +all authorizes every IP address on the internet to send email as your domain. This is equivalent to having no SPF at all, but worse because it looks like you intentionally authorized everything.

SPF exceeding the 10-lookup limit

Common in organizations that use many SaaS tools. Each include adds to the count, and nested includes compound the problem. The result is permerror, which many receivers treat as a fail.

DMARC at p=none indefinitely

Many organizations set up DMARC with p=none to "start monitoring" and never progress to quarantine or reject. A p=none policy provides no protection. It only generates reports. If your DMARC record has been at p=none for more than two months, it's time to move forward.

Missing DMARC on subdomains

Without sp=reject (or individual DMARC records on subdomains), attackers can spoof subdomains like hr.yourcompany.com or payroll.yourcompany.com, which are often more convincing in targeted phishing.

Orphaned DKIM selectors

When you stop using an email service, its DKIM selector often stays in DNS. While this isn't directly exploitable (the attacker would need the private key), orphaned DNS records create confusion during audits and should be cleaned up.

No DKIM at all

Some organizations configure SPF and DMARC but forget DKIM. Since DMARC requires either SPF or DKIM to pass with alignment, this means every forwarded email fails DMARC (because forwarding changes the sending IP, breaking SPF, and there's no DKIM to fall back on).

---

How to Check Your Configuration

Verifying your email authentication setup doesn't require any special tools or command-line knowledge.

Quick Check: DNS Lookup

Use the DNS lookup tool at dnsassistant.com/tools to query your domain's TXT records. You'll see your SPF record (starts with v=spf1) and DMARC record (query _dmarc.yourdomain.com, starts with v=DMARC1). For DKIM, you'll need to know your selector names and query [selector]._domainkey.yourdomain.com.

Comprehensive Audit: Domain Risk Report

The Free Domain Risk Report scans your domain and checks all three protocols automatically. It identifies missing records, weak policies, and misconfigurations, then delivers a branded PDF report to your inbox. This is the fastest way to get a complete picture of your email authentication posture.

Ongoing Monitoring

Email authentication records change more often than most organizations realize. A developer adds a new SaaS tool and updates the SPF record. An IT admin rotates a DKIM key. A well-intentioned change accidentally downgrades the DMARC policy from reject to none.

DNS Assistant monitors your SPF, DKIM, and DMARC records continuously and alerts you when anything changes. If your DMARC policy gets downgraded, if a new include pushes your SPF past the 10-lookup limit, or if a DKIM selector stops resolving, your team knows immediately rather than discovering the issue weeks later when email deliverability drops or a spoofing attack succeeds.

---

Quick Reference

Here's a summary of what a well-configured email authentication setup looks like:

SPF:

• One TXT record starting with v=spf1
• All legitimate sending services included
• Total DNS lookups under 10
• Ends with -all (hard fail) in production
• Published on every domain and subdomain that sends email

DKIM:

• Valid public key published for every sending service's selector
• Keys at least 2048-bit RSA (or Ed25519)
• Rotated periodically (at least annually)
• Orphaned selectors removed when services are decommissioned

DMARC:

• TXT record at _dmarc.yourdomain.com
• Policy at p=quarantine or p=reject (not p=none indefinitely)
• Subdomain policy set with sp=reject
• Aggregate reporting (rua) enabled
• pct=100 (apply to all messages)

---

Protect Your Domain

Email authentication isn't optional anymore. Major providers enforce it, customers expect it, and attackers exploit every gap. The good news is that SPF, DKIM, and DMARC are entirely DNS-based, which means visibility into your DNS records is the foundation of your email security posture.

Start with a free scan: Run a Free Domain Risk Report to see where your email authentication stands today. Check your TXT records with the DNS lookup tool for instant results.

For continuous protection, sign up at dnsassistant.com to monitor your SPF, DKIM, and DMARC records around the clock, with alerts the moment anything changes.