What are SPF, DKIM and DMARC and how do you set them up?

Sajjad
Security
22 Sep, 2026

SPF, DKIM and DMARC are three email authentication standards that you publish as DNS records on your domain. SPF lists which servers are allowed to send email for your domain, DKIM adds a cryptographic signature to each message so receivers can check it wasn't forged or altered, and DMARC tells receiving mail servers what to do when a message fails those checks and sends you reports about it. You set them up by adding TXT records at your DNS provider, starting with SPF and DKIM for every service that sends mail as you, then adding a DMARC record in monitoring mode and gradually tightening it.

If you've ever had a customer receive a fake invoice "from" your domain, or found that your own emails land in spam, these records are the fix. This guide explains each standard in plain language, shows real record examples, walks through the setup order that avoids breaking legitimate email, and covers how to read DMARC reports and move to full enforcement.

Why Email Authentication Matters

Email was designed without any built-in way to verify the sender. Anyone can send a message with any address in the From field, which makes spoofing trivial. Attackers use this for phishing, fake invoices, and business email compromise, where they impersonate a manager or supplier to request payments.

Email authentication gives receiving servers, such as Gmail, Outlook, and Yahoo, a way to check whether a message claiming to be from your domain really is. Setting it up helps you:

Stop spoofing: Prevent criminals from sending convincing email as your domain.
Improve deliverability: Authenticated email is more likely to reach the inbox instead of spam.
Meet provider requirements: Since 2024, Google and Yahoo have required SPF or DKIM for all senders, and SPF, DKIM, and DMARC for bulk senders. Other providers have followed with similar rules.
Gain visibility: DMARC reports show you every service sending email on your behalf, including ones you may have forgotten about.

What Is SPF?

SPF (Sender Policy Framework) is a TXT record that lists the servers and services allowed to send email for your domain. When a receiving server gets a message, it looks up the SPF record for the domain in the message's envelope sender (the Return-Path, not the visible From address) and checks whether the sending server's IP address is on the list.

How an SPF Record Looks

A typical SPF record for a domain that uses Google Workspace and a newsletter service looks like this:

example.com.  TXT  "v=spf1 include:_spf.google.com include:servers.mcsv.net -all"

Here's what each part means:

v=spf1: Identifies the record as SPF version 1. Every SPF record starts with this.
include:: Pulls in another domain's SPF record, used for third-party services such as Google Workspace, Microsoft 365, or Mailchimp.
ip4: / ip6:: Authorises specific IP addresses or ranges, for example ip4:203.0.113.10.
a / mx: Authorises the IP addresses in your domain's A or MX records.
-all: Fail anything not listed (hard fail).
~all: Soft fail anything not listed, which usually means "accept but treat as suspicious".

Common include values for popular providers are:

Google Workspace: include:_spf.google.com
Microsoft 365: include:spf.protection.outlook.com

For other services, such as transactional email providers or your web host, use the exact value from their documentation, since these change occasionally.

SPF Rules to Remember

SPF has a few strict rules that trip people up:

Only one SPF record per domain: If you have two TXT records starting with v=spf1, SPF fails. Merge them into a single record.
The 10 DNS lookup limit: Each include, a, mx, exists and redirect counts as a DNS lookup, including nested lookups inside included records. More than 10 causes a permanent error. Remove services you no longer use, and consider using a subdomain for some senders.
SPF breaks on forwarding: When a message is forwarded, the forwarding server's IP isn't in your SPF record. This is one reason DKIM matters.
SPF checks the envelope sender, not the From header: On its own, SPF doesn't stop someone from spoofing the address people actually see. DMARC closes that gap.

What Is DKIM?

DKIM (DomainKeys Identified Mail) adds a digital signature to the headers of every email you send. Your sending service signs the message with a private key, and you publish the matching public key in DNS. The receiving server fetches the public key and verifies the signature. If the message was altered in transit, or wasn't signed by someone holding your key, the check fails.

How a DKIM Record Looks

DKIM keys are published at a selector under the _domainkey subdomain. The selector lets you have multiple keys, one for each sending service:

google._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

google: The selector, chosen by the sending service.
v=DKIM1: The DKIM version.
k=rsa: The key type.
p=: The public key itself, usually a long string.

Some services, such as Microsoft 365 and many marketing platforms, ask you to add CNAME records instead, pointing your selector to a key they host. This lets them rotate keys without you changing DNS.

selector1._domainkey.example.com.  CNAME  selector1-example-com._domainkey.example.onmicrosoft.com.

The exact target is shown in your Microsoft 365 admin portal, so always copy it from there rather than from an example.

DKIM Tips

Use 2048-bit RSA keys where your provider supports them. 1024-bit keys are considered weak.
Set up DKIM separately for every service that sends as your domain: your mailbox provider, your newsletter tool, your e-commerce platform, your helpdesk, and so on.
Rotate keys periodically if your provider doesn't do it for you.
Some DNS providers split long TXT values into multiple strings automatically. That's normal and valid.

What Is DMARC?

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together and connects them to the address people actually see in the From field. It does three things:

Checks alignment: A message passes DMARC only if SPF or DKIM passes and the domain that passed matches the visible From domain. This is what stops spoofing of the address readers see.
Sets a policy: You tell receivers what to do with messages that fail: do nothing, send them to spam, or reject them.
Sends reports: Receivers send you aggregate reports showing who is sending email as your domain and whether it passes.

How a DMARC Record Looks

DMARC is always published at the _dmarc subdomain:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1"

The main tags are:

v=DMARC1: Identifies the record as DMARC.
p=: The policy for failing messages: none (monitor only), quarantine (send to spam), or reject (block).
rua=: Where to send aggregate reports.
ruf=: Where to send failure reports. Many providers don't send these for privacy reasons.
pct=: The percentage of failing messages the policy applies to, useful for gradual rollout.
sp=: A separate policy for subdomains.
adkim= / aspf=: Alignment mode, r (relaxed, the default, allows subdomains to match) or s (strict, exact match required).
fo=1: Request failure reports when any check fails, where supported.

What Alignment Means in Practice

Say your newsletter tool sends mail with the From address news@example.com, but its envelope sender is bounce@mail.newslettertool.com and it signs with its own domain. SPF and DKIM might both pass, but for the newsletter tool's domain, not yours. DMARC fails because neither aligns with example.com.

The fix is to set up custom DKIM signing (and ideally a custom return path) in the tool's settings, so it signs with example.com. Most reputable email services offer this, often labelled "domain authentication" or "sender authentication".

How to Set Up SPF, DKIM and DMARC Step by Step

The order matters. Setting a strict DMARC policy before SPF and DKIM are in place for every sender can cause your own legitimate email to be rejected.

Step 1: List Every Service That Sends Email as Your Domain

Before touching DNS, make a list. Common senders include:

Your mailbox provider (Google Workspace, Microsoft 365, Zoho Mail, or your host's email).
Your website, for contact forms and password resets, especially WordPress sites.
Newsletter and marketing platforms.
Transactional email services such as SendGrid, Postmark, Mailgun, Amazon SES, or Brevo.
E-commerce, invoicing, CRM, and helpdesk tools.

If your WordPress site sends mail using PHP's default mail function from your web server, consider routing it through an authenticated SMTP or API service using a plugin such as WP Mail SMTP, FluentSMTP, or Post SMTP. That makes it much easier to authenticate properly.

Step 2: Create or Update Your SPF Record

Combine every legitimate sender into a single SPF record. For example, a domain using Google Workspace and a transactional service:

example.com.  TXT  "v=spf1 include:_spf.google.com include:spf.transactional-provider.example ~all"

Starting with ~all is a sensible, lower-risk choice while you confirm everything is listed. Once DMARC reports show all legitimate mail passing, you can switch to -all. In practice, once DMARC is enforcing, the difference between ~all and -all matters less, because DMARC's policy decides the outcome.

For domains that never send email, such as parked domains, publish a record that authorises nothing:

parked-example.com.  TXT  "v=spf1 -all"

Step 3: Enable DKIM for Each Sender

For each service on your list:

Find the DKIM or domain authentication setting: In Google Workspace, it's at Apps > Google Workspace > Gmail > Authenticate email in the Admin console. Other services have similar pages.
Generate the key: The service gives you a TXT or CNAME record to add.
Add the record at your DNS provider: Copy the host name and value exactly.
Start authentication: Go back to the service and click the button to verify or start signing. It may take some time for DNS to propagate.

Step 4: Add a DMARC Record in Monitoring Mode

Start with p=none so nothing is blocked while you gather data:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Aggregate reports arrive as XML files attached to emails, usually daily from each large provider. They're hard to read by hand, so many people use a DMARC reporting service to turn them into dashboards. Popular options include Postmark's free DMARC monitoring, dmarcian, Valimail, EasyDMARC, and Cloudflare's DMARC Management for domains on Cloudflare.

If your reports go to an address on a different domain, that domain must publish a record authorising it to receive them. Reporting services handle this for you.

Step 5: Review Reports and Fix Gaps

For a few weeks, review the reports. Look for:

Legitimate services failing: Add them to SPF or set up DKIM with your domain.
Unknown sources passing: Investigate. It might be a forgotten tool, or a sign of a compromised account.
Unknown sources failing: Usually spoofing attempts. These are exactly what DMARC enforcement will block.

Step 6: Move to Enforcement Gradually

Once your legitimate mail consistently passes, tighten the policy. A cautious path looks like this:

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com"

Increase pct to 50, then 100, while watching the reports. When you're confident, move to full rejection:

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

At p=reject, receivers that honour DMARC will refuse spoofed mail claiming to be from your domain. This is the goal, and it's the setting that gives real protection against impersonation. Keep monitoring reports after you get there, because new tools get added over time.

How to Check Your Records

You can check your published records from a terminal using dig:

# SPF (look for the record starting with v=spf1)
dig example.com TXT +short

# DKIM for a specific selector
dig google._domainkey.example.com TXT +short

# DMARC
dig _dmarc.example.com TXT +short

On Windows, use nslookup -type=TXT _dmarc.example.com instead.

To check a real message, send an email to a Gmail account, open it, and choose Show original from the message menu. Gmail shows whether SPF, DKIM, and DMARC passed. Other free tools, such as MXToolbox and Google Admin Toolbox, can also check your records and flag common errors like duplicate SPF records or too many lookups.

Common Mistakes to Avoid

Multiple SPF records: Always merge into one.
Exceeding 10 SPF lookups: Audit your includes regularly.
Jumping straight to p=reject: You may block your own invoices or password resets.
Forgetting subdomains: Attackers can spoof billing.example.com. By default subdomains inherit your DMARC policy, but you can set sp=reject explicitly.
Ignoring reports: A DMARC record at p=none forever gives visibility but no protection.
Leaving website email unauthenticated: WordPress contact form notifications sent from the web server often fail DMARC. Route them through an authenticated service.

FAQ: SPF, DKIM and DMARC

Yes, for proper protection. SPF and DKIM authenticate the sender, but only DMARC connects those checks to the visible From address and tells receivers what to do when they fail. Major providers now expect all three for bulk senders.

No. A domain must have exactly one TXT record starting with v=spf1. If you have more than one, SPF returns an error. Merge all your include and ip4 entries into a single record.

Start with p=none so you can collect reports without affecting delivery. After confirming all legitimate senders pass, move to p=quarantine and then p=reject.

DNS changes usually propagate within minutes to a few hours, depending on TTL settings. DMARC aggregate reports typically start arriving within a day or two.

SPF may be passing for a different domain than the one in your From address, usually a third-party service's bounce domain. Set up custom DKIM signing or a custom return path with that service so the authenticated domain aligns with yours.

Yes. Domains that never send email should publish v=spf1 -all and a DMARC record with p=reject. This stops attackers from using them for spoofing.

No. DMARC stops exact-domain spoofing of your domain. It doesn't stop lookalike domains, display-name tricks, or phishing from compromised legitimate accounts, so staff awareness still matters.

Conclusion

SPF, DKIM and DMARC work as a team. SPF says which servers can send for your domain, DKIM proves each message is genuine and unaltered, and DMARC ties both to the From address people see while telling receivers how to handle failures. Together, they make it much harder for criminals to impersonate you and much easier for your real email to reach the inbox.

The safest way to set them up is step by step: list every sender, publish a single SPF record, enable DKIM everywhere, then start DMARC at p=none and use the reports to guide you towards p=reject. It takes a little patience, but once you reach enforcement, your domain is protected against one of the most common tactics used in email fraud.