The Complete Guide to SPF, DKIM, and DMARC

Email authentication is the single most important thing you can do to stop attackers from impersonating your domain. This guide walks you through SPF, DKIM, and DMARC from first principles to production-ready DNS records -- with real examples you can copy and adapt.

Why Email Authentication Matters

Email was designed in an era when trust was assumed. The SMTP protocol has no built-in way to verify that the person sending a message actually controls the domain in the "From" address. That means anyone, anywhere in the world, can send an email that appears to come from your domain -- and most recipients will never know the difference.

This is not a theoretical risk. Business email compromise (BEC) attacks cost organizations billions of dollars every year. A single spoofed email from your CEO's address can trick an employee into wiring funds to a fraudulent account. A phishing email that appears to come from your support team can harvest customer credentials. And even if your organization is never directly targeted, a domain with no email authentication will suffer from poor deliverability -- Gmail, Microsoft, and Yahoo now require SPF, DKIM, and DMARC for bulk senders, and increasingly penalize all domains that lack these records.

The consequences of inaction are concrete: spoofed emails damage your brand reputation, phishing attacks compromise your customers, and legitimate emails from your domain land in spam folders instead of inboxes. The fix is three DNS records that take less than an hour to implement correctly.

How Email Authentication Works: Three Layers

Email authentication is not a single technology -- it is three complementary protocols that each solve a different part of the problem:

• SPF (Sender Policy Framework) declares which mail servers are authorized to send email on behalf of your domain.
• DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to each outgoing message so the recipient can verify it was not altered in transit.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together with a policy that tells receiving servers what to do when authentication fails -- and sends you reports about it.

Each protocol addresses a specific weakness. SPF alone cannot prevent a modified message from passing checks. DKIM alone cannot tell a receiver what to do with an unsigned message. DMARC alone is meaningless without SPF or DKIM to evaluate. Together, they form a defense-in-depth stack that makes domain spoofing significantly harder. If you are looking at email security as part of a broader posture, our guide to domain security scoring explains how these records factor into an overall grade.

SPF: Sender Policy Framework

What SPF Does

Think of SPF as a return address whitelist published in your DNS. When you create an SPF record, you are telling the world: "Only these specific servers are allowed to send email as my domain. If a message comes from anywhere else, it is not from us."

When a receiving mail server gets a message claiming to be from yourcompany.com, it looks up the SPF record for that domain. If the sending server's IP address is listed in the record, the SPF check passes. If not, it fails.

How to Create an SPF Record

An SPF record is a TXT record in your domain's DNS. The syntax always starts with v=spf1, followed by the mechanisms that define authorized senders, and ends with a default action for everything else.

Here is the basic structure:

v=spf1 [mechanisms] [default]

The most common mechanisms are:

• ip4:203.0.113.5 -- authorize a specific IPv4 address
• ip4:203.0.113.0/24 -- authorize an entire IPv4 range
• include:_spf.google.com -- authorize all servers listed in another domain's SPF record
• a -- authorize the IP addresses in your domain's A record
• mx -- authorize the servers in your domain's MX records

The default action at the end should almost always be -all (hard fail) or ~all (soft fail). Hard fail tells receivers to reject unauthorized senders outright. Soft fail flags them but does not reject.

SPF Record Examples

Simple -- only Google Workspace sends email for this domain:

v=spf1 include:_spf.google.com -all

Microsoft 365 with a transactional email service:

v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all

Multiple sources -- Google Workspace, Mailchimp, and a custom mail server:

v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:203.0.113.10 -all

Domain that does not send email at all:

v=spf1 -all

This last example is critical for parked domains or domains used only for a website. Publishing v=spf1 -all tells receivers that no server is authorized to send email from this domain, making it much harder for attackers to spoof.

Common SPF Mistakes

Multiple SPF records. The SPF specification requires exactly one SPF record per domain. If you have two TXT records that both start with v=spf1, receivers may discard both and treat SPF as failing. Merge all your mechanisms into a single record.

Exceeding the 10-lookup limit. SPF allows a maximum of 10 DNS lookups (including nested lookups from include statements). Each include, a, mx, and redirect mechanism counts as a lookup. Exceeding 10 causes a permanent error (permerror), and your SPF record is effectively broken. If you use many third-party senders, consider SPF flattening tools that replace include statements with resolved IP addresses.

Using +all as the default. This tells receivers that any server in the world is authorized to send email as your domain. It negates the entire purpose of SPF. Always use -all or at minimum ~all.

DKIM: DomainKeys Identified Mail

What DKIM Does

If SPF is a whitelist of authorized servers, DKIM is a digital signature on each individual email. When your mail server sends a message, it uses a private key to generate a cryptographic signature over the message headers and body. The corresponding public key is published in your DNS. When a receiving server gets the message, it retrieves the public key and verifies the signature.

This proves two things: the message was actually sent by someone with access to your domain's private key, and the message was not modified after it was signed. SPF cannot provide this second guarantee -- it only validates the sending server, not the message content.

How DKIM Works

The DKIM signing process has two sides:

1. Signing (your mail server): Before sending, your server selects specific headers (From, To, Subject, Date, etc.) and the message body, runs them through a hash function, and signs the hash with your private key. The resulting signature is added to the email as a DKIM-Signature header.
2. Verification (the receiving server): The receiver reads the DKIM-Signature header, extracts the selector and domain, looks up the public key at selector._domainkey.yourdomain.com, and uses it to verify the signature. If the signature is valid, the DKIM check passes.

Setting Up DKIM

Google Workspace: Navigate to Admin Console, then Apps, then Google Workspace, then Gmail, then Authenticate email. Google will generate a DKIM key and give you a TXT record to add to your DNS. The default selector is google, resulting in a record at google._domainkey.yourdomain.com.

Microsoft 365: In the Microsoft 365 Defender portal, go to Email & Collaboration, then Policies & Rules, then Threat Policies, then Email Authentication Settings, then DKIM. Select your domain and enable DKIM signing. Microsoft uses two selectors -- selector1 and selector2 -- and requires you to add two CNAME records pointing to Microsoft's DKIM infrastructure:

selector1._domainkey.yourdomain.com  CNAME  selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com
selector2._domainkey.yourdomain.com  CNAME  selector2-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

Generic / Self-hosted: Generate a 2048-bit RSA key pair using openssl. Publish the public key as a TXT record at your chosen selector path, and configure your mail transfer agent (Postfix, Exim, etc.) to sign outgoing messages with the private key using a tool like OpenDKIM.

openssl genrsa -out dkim_private.pem 2048
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pem

Then create a TXT record at mail._domainkey.yourdomain.com with the public key:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA... (your public key)

DKIM Selectors Explained

The selector is a label that lets you publish multiple DKIM keys for the same domain. This is useful when you have different services sending email on your behalf -- Google might use the selector google, your marketing platform might use s1, and your transactional email service might use mailjet.

The full DNS lookup path for a DKIM key is always:

[selector]._domainkey.yourdomain.com

For example, if your selector is google and your domain is example.com, the receiving server will look up google._domainkey.example.com to find the public key.

You can have as many selectors as you need. Each one is independent, so rotating keys or adding new services does not affect existing signatures.

DMARC: Domain-based Message Authentication

What DMARC Does

SPF and DKIM tell receivers whether an email passes technical checks, but they do not tell receivers what to do when those checks fail. That is the role of DMARC.

DMARC does three things:

1. Alignment: It checks that the domain in SPF or DKIM actually matches the domain in the visible "From" header. This closes a loophole where an attacker could pass SPF with their own domain while spoofing yours in the "From" field.
2. Policy: It tells receiving servers exactly what to do with messages that fail authentication -- deliver them, quarantine them, or reject them outright.
3. Reporting: It provides a mechanism for receiving servers to send you aggregate reports about who is sending email as your domain and whether those messages are passing or failing authentication.

DMARC Policies: none, quarantine, reject

The p= tag in your DMARC record defines your policy. There are three options:

• p=none -- Monitor only. Messages that fail authentication are delivered normally, but you receive reports about them. This is the starting point for every DMARC deployment. Use it to discover all legitimate email sources before enforcing.
• p=quarantine -- Messages that fail authentication are sent to the spam or junk folder. This is the intermediate step. It protects recipients without the risk of blocking legitimate email that you missed during the monitoring phase.
• p=reject -- Messages that fail authentication are rejected entirely -- they never reach the recipient. This is the strongest protection and the goal of every DMARC deployment. It effectively prevents anyone from spoofing your domain.

Creating a DMARC Record

DMARC is published as a TXT record at _dmarc.yourdomain.com. Here is the minimum viable DMARC record to start monitoring:

v=DMARC1; p=none; rua=mailto:[email protected]

The key tags are:

• v=DMARC1 -- Required. Identifies this as a DMARC record.
• p=none|quarantine|reject -- Required. Your policy.
• rua=mailto:[email protected] -- Optional but strongly recommended. The address where aggregate reports are sent.
• ruf=mailto:[email protected] -- Optional. The address for forensic (failure) reports. Not all providers send these.
• pct=100 -- Optional. The percentage of messages the policy applies to (default is 100). Useful for gradual rollouts.

DMARC Record Examples: The Progression

DMARC deployment should follow a deliberate progression from monitoring to full enforcement. Jumping straight to p=reject without monitoring first is a common mistake that can block legitimate email.

Step 1 -- Monitor (weeks 1-4):

v=DMARC1; p=none; rua=mailto:[email protected]

Collect reports. Identify all legitimate email sources. Fix SPF and DKIM for any sources that are failing.

Step 2 -- Quarantine (weeks 5-8):

v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected]

Start with 50% to limit blast radius. Monitor reports for false positives. Increase to 100% once confident.

Step 3 -- Reject (week 9+):

v=DMARC1; p=reject; rua=mailto:[email protected]

Full protection. Any message that fails both SPF alignment and DKIM alignment is rejected. This is the target state for every domain.

Reading DMARC Reports

Aggregate reports (rua) are XML files sent daily by receiving mail servers. They contain data about every message that claimed to come from your domain: the sending IP, whether SPF and DKIM passed, and whether DMARC alignment succeeded.

Raw XML reports are not human-friendly. In practice, you will want a tool to parse and visualize them. Free options include Postmark's DMARC tool and Google's Postmaster Tools. For ongoing monitoring, services like Scanward track your DMARC record configuration and alert you to policy changes or misconfigurations as part of a broader domain security score.

SPF vs. DKIM vs. DMARC: Quick Comparison

Putting It All Together: Implementation Order

If you are starting from scratch, follow this order. Each step builds on the previous one:

1. SPF first. Audit every service that sends email as your domain -- your email provider, marketing tools, CRM, transactional services, support desk. Create a single SPF TXT record that includes all of them. End with -all. Verify it resolves correctly with a DNS lookup tool.
2. DKIM second. Enable DKIM signing for each service that sends email on your behalf. Each service will provide its own selector and either a TXT record or CNAME to add to your DNS. Verify each selector resolves by querying selector._domainkey.yourdomain.com.
3. DMARC third, starting with p=none. Publish a DMARC record with p=none and a rua address to receive reports. Wait at least two to four weeks and review the reports. Look for legitimate sources that are failing SPF or DKIM alignment and fix them.
4. Tighten DMARC to p=quarantine. Once reports show that all legitimate email passes authentication, move to quarantine. Start with pct=25 or pct=50 if you want to be cautious, then increase.
5. Enforce with p=reject. After another monitoring period with quarantine showing no false positives, move to p=reject. This is the end goal and provides maximum protection against domain spoofing.

The entire process typically takes six to twelve weeks for a medium-sized organization. Smaller domains with one or two email sources can often complete it in a week.

Do not forget non-sending domains. If you own domains that do not send email (parked domains, redirect domains, brand-protection domains), publish v=spf1 -all and v=DMARC1; p=reject on all of them. Attackers specifically target unprotected non-sending domains because they know no one is monitoring them.

Monitoring Your Email Security

Setting up SPF, DKIM, and DMARC is not a one-time task. Records drift over time: you add a new SaaS tool and forget to update SPF, a team member changes the DMARC policy to troubleshoot a deliverability issue and never changes it back, a DKIM key rotation breaks a selector record. Without ongoing monitoring, your email authentication can silently degrade.

This is where continuous monitoring makes a real difference. Scanward checks your SPF, DKIM, and DMARC records as part of every domain scan, including lookups for common DKIM selectors like google, selector1, selector2, default, k1, and others. The scoring is specific and actionable:

• A missing SPF record costs you points on your domain security score.
• A missing DMARC record is a significant deduction.
• A weak DMARC policy of p=none costs 15 points compared to full credit for p=reject. This reflects the real-world difference: p=none provides visibility but zero protection against spoofing.
• Missing DKIM records for detected selectors are flagged as well.

Beyond email authentication, Scanward monitors your SSL/TLS certificates, DNS configuration, HTTP security headers, and uptime -- rolling everything into a single A-through-F security grade. When something changes, you get an alert before it becomes a breach or a deliverability problem.

If you manage multiple domains -- whether for your own organization or as an MSP managing client infrastructure -- continuous monitoring turns email security from a periodic audit into a system that watches itself.