How to set up SPF, DKIM, and DMARC for your domain

If you send transactional email from your own domain - password resets, order confirmations, verification codes - then SPF, DKIM, and DMARC are not optional. Gmail, Yahoo, and Microsoft all require proper authentication for reliable inbox delivery, and as of 2024, Gmail and Yahoo explicitly reject bulk email from domains without these records.

This guide walks through setting up all three, step by step. If you want to understand how each protocol works under the hood, the linked snippets above go into detail. Here we focus on the practical setup.

Before you start

You will need:

DNS access for your sending domain (the domain in your From address). This is usually your DNS provider - Cloudflare, Route 53, Google Cloud DNS, Namecheap, or wherever your domain’s nameservers point.
Your email service’s SPF and DKIM values. Every email provider gives you specific records to publish. Check your provider’s documentation for the exact values. Common examples are included below.

All three protocols use DNS TXT records. The process is always the same: create or edit a TXT record at a specific hostname with the value your provider gives you.

Step 1: Set up SPF

SPF tells receiving servers which IP addresses are allowed to send email on behalf of your domain. It is a single TXT record at your domain’s root.

Find your provider’s SPF include

Every email service documents the include value you need to add. Common examples:

Provider	SPF include
Google Workspace	`include:_spf.google.com`
Amazon SES	`include:amazonses.com`
Postmark	`include:spf.mtasv.net`
Mailgun	`include:mailgun.org`
SendStreak (via SES)	`include:amazonses.com`

Create or update your SPF record

If you don’t have an SPF record yet, create a TXT record at your domain root with this value:

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

Replace _spf.google.com with your provider’s include value. If you use multiple providers (e.g., Google Workspace for company email and AWS SES for transactional email), combine them in a single record:

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

Use -all (hard fail) for production domains. During initial setup, you can start with ~all (soft fail) to monitor without risking rejected mail, then switch to -all once you have confirmed everything works.

Important: Your domain must have exactly one SPF record. If you already have one, edit it to add the new include - do not create a second TXT record starting with v=spf1.

Verify SPF

After publishing the record, verify it propagated:

dig TXT yourdomain.com +short

You should see your SPF record in the output. DNS changes can take up to 48 hours to propagate, but most providers update within minutes.

You can also use an online SPF checker to validate the syntax and count DNS lookups. SPF allows a maximum of 10 DNS lookups - each include, a, mx, and redirect mechanism counts as one. If you exceed 10, the entire SPF check fails.

Step 2: Set up DKIM

DKIM adds a cryptographic signature to every outgoing message. The receiving server verifies the signature using a public key in your DNS records. This proves the message was authorized by you and was not modified in transit.

Get your DKIM record from your provider

Unlike SPF, you don’t write the DKIM record yourself. Your email provider generates a key pair and gives you the public key to publish. The process varies:

Google Workspace:

Open the Google Admin Console.
Go to Apps > Google Workspace > Gmail > Authenticate email.
Select your domain and click Generate new record.
Google gives you a TXT record to publish at google._domainkey.yourdomain.com.

Amazon SES:

In the SES console, go to Verified identities > your domain.
Under the Authentication tab, expand DomainKeys Identified Mail (DKIM).
If using Easy DKIM, SES provides three CNAME records to publish.
If using BYODKIM, SES gives you a TXT record with the public key.

Postmark, Mailgun, SendStreak, and most other providers follow a similar pattern: go to your domain’s settings in the provider’s dashboard and copy the DKIM record they give you.

Publish the DKIM record in DNS

Create a TXT record (or CNAME records for AWS SES Easy DKIM) at the hostname your provider specifies. The hostname always follows the pattern:

{selector}._domainkey.yourdomain.com

For example, Google Workspace uses the selector google, so the record goes at:

google._domainkey.yourdomain.com

The value is the public key your provider gave you. It looks something like:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQE...

Verify DKIM

Check that the record is published:

dig TXT google._domainkey.yourdomain.com +short

Replace google with your provider’s selector. You should see the DKIM public key in the output.

Most providers also show DKIM verification status in their dashboard. Google Workspace shows a green checkmark next to the domain once it detects the record.

Step 3: Set up DMARC

DMARC ties SPF and DKIM together. It checks that the domain in the From header matches the domain verified by SPF or DKIM (this is called alignment), and it tells receiving servers what to do with messages that fail.

Start with monitoring mode

Do not jump straight to p=reject. Start with p=none to collect data without affecting delivery:

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

Publish this as a TXT record at _dmarc.yourdomain.com.

The rua address receives aggregate reports - XML files that receiving servers send daily, summarizing how many messages passed or failed authentication for your domain. These reports tell you if any legitimate email services are misconfigured before you start blocking.

Read the reports

After 1-2 weeks of p=none, review the aggregate reports. You are looking for:

Legitimate services that fail SPF or DKIM. This means you missed an include in your SPF record or didn’t set up DKIM for that service. Fix these first.
Unauthorized senders. IP addresses you don’t recognize sending as your domain. These are the messages you want DMARC to block.

Free tools like Postmark’s DMARC monitoring or MXToolbox’s DMARC Report Analyzer can parse the raw XML into readable dashboards.

Escalate to quarantine, then reject

Once all legitimate senders pass, move through the enforcement levels:

Quarantine - Messages that fail DMARC go to spam:

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

Start with pct=25 so only 25% of failing messages are quarantined. Monitor for a week, then increase to pct=100.

Reject - Messages that fail DMARC are blocked entirely:

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

This is the goal. A p=reject policy fully protects your domain from spoofing.

Verify DMARC

dig TXT _dmarc.yourdomain.com +short

You should see your DMARC record in the output.

Testing everything together

After setting up all three records, send a test email to an address you control (a Gmail account works well for this) and inspect the email headers. In Gmail, open the message, click the three-dot menu, and select Show original. Look for the Authentication-Results header:

Authentication-Results: mx.google.com;
    dkim=pass header.d=yourdomain.com;
    spf=pass (google.com: domain of [email protected] designates ... as permitted sender);
    dmarc=pass (p=REJECT) header.from=yourdomain.com

All three should show pass. If any shows fail:

SPF fail - The sending server’s IP is not in your SPF record. Check that you included the correct include for your provider.
DKIM fail - The public key in DNS does not match the private key used to sign. Verify the selector and the key value in your DNS record.
DMARC fail - Neither SPF nor DKIM passed with alignment to the From domain. This usually means the envelope sender or DKIM signing domain is on a different domain than your From address. Check your provider’s custom domain setup.

Quick reference

Record	DNS hostname	Example value
SPF	`yourdomain.com`	`v=spf1 include:_spf.google.com -all`
DKIM	`{selector}._domainkey.yourdomain.com`	`v=DKIM1; k=rsa; p=MIIBIj...`
DMARC	`_dmarc.yourdomain.com`	`v=DMARC1; p=reject; rua=mailto:[email protected]`