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.

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 > Apps > Google Workspace > Gmail > 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 > Policies & Rules > Threat Policies > Email Authentication Settings > DKIM. Select your domain and enable DKIM signing. Microsoft uses two selectors -- selector1 and selector2 -- and requires you to add two CNAME records:

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

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.
• p=quarantine -- Messages that fail authentication are sent to the spam or junk folder. This is the intermediate step.
• 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.

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:[e-mail]

The key tags are:

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

DMARC Record Examples: The Progression

DMARC deployment should follow a deliberate progression from monitoring to full enforcement.

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

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

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:[e-mail]

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:[e-mail]

Full protection. Any message that fails both SPF alignment and DKIM alignment is rejected.

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. Free options to parse them include Postmark's DMARC tool and Google's Postmaster Tools.

SPF vs. DKIM vs. DMARC: Quick Comparison

	SPF	DKIM	DMARC
Purpose	Authorizes sending servers	Signs messages cryptographically	Sets policy for auth failures
DNS Record	TXT at yourdomain.com	TXT at selector._domainkey.yourdomain.com	TXT at _dmarc.yourdomain.com
Validates	Sending server IP	Message integrity and origin	Alignment of SPF/DKIM with From domain
Works Alone?	Partially	Partially	No -- requires SPF and/or DKIM

Putting It All Together: Implementation Order

If you are starting from scratch, follow this order:

1. SPF first. Audit every service that sends email as your domain. Create a single SPF TXT record that includes all of them. End with -all.
2. DKIM second. Enable DKIM signing for each service. Each service will provide its own selector and DNS record.
3. DMARC third, starting with p=none. Publish a DMARC record and wait 2-4 weeks reviewing reports. Fix any legitimate sources that are failing.
4. Tighten DMARC to p=quarantine. Start with pct=50 if cautious, then increase.
5. Enforce with p=reject. After confirming no false positives, move to full rejection.

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), publish v=spf1 -all and v=DMARC1; p=reject on all of them. Attackers specifically target unprotected non-sending domains.

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, someone changes the DMARC policy to troubleshoot deliverability and never changes it back, a DKIM key rotation breaks a selector record.

You can quickly check your current email authentication setup with a free domain security scan -- it checks SPF, DKIM (common selectors), and DMARC in seconds and tells you exactly what's missing or misconfigured.