To set up SPF, DKIM, and DMARC, you add three kinds of DNS records: one SPF TXT record on each sending domain listing your authorized senders, one or more DKIM records (TXT or CNAME) publishing each sender’s public key, and one DMARC TXT record at _dmarc.yourdomain with a policy and a reporting address. Do them in that order, give SPF and DKIM time to take effect, then add DMARC at p=none and tighten it once the reports are clean.

This guide gives the exact records for the most common setups and a test for each step.

Before you start: map every sender

The most common setup failure isn’t a typo. It’s a sender nobody remembered. Before touching DNS, list every system that sends email with your domain in the From address:

Your mailbox provider (Google Workspace, Microsoft 365, or your own server)
Marketing email platform
Transactional email (password resets, receipts): Amazon SES, or an API provider
CRM and sales tools
Help desk / ticketing
Billing and invoicing
Website forms, e-commerce platform, WordPress plugins

For each one, find its documentation page for “custom domain authentication” or “domain verification.” You’ll need two things from each: the SPF include (or IP range) and the DKIM records.

If marketing or bulk mail is involved, consider sending it from a subdomain such as news.example.com. Microsoft’s SPF guidance recommends subdomains for services you don’t directly control, and each subdomain gets its own SPF lookup budget. It also keeps a marketing platform’s reputation problems from spilling onto your staff mail.

Step 1: Set up SPF

SPF is one TXT record per sending hostname. You can only have one per hostname, so if you have several senders, they all go in a single record.

SPF records for common providers

Provider	Record value	Source
Google Workspace	`v=spf1 include:_spf.google.com ~all`	Google
Microsoft 365	`v=spf1 include:spf.protection.outlook.com -all`	Microsoft
Amazon SES (on custom MAIL FROM subdomain)	`v=spf1 include:amazonses.com ~all`	AWS
Domain that never sends	`v=spf1 -all`	Microsoft

Combining senders

Say example.com uses Google Workspace for staff mail and an on-premises app server at 203.0.113.25. The single record is:

example.com.  TXT  "v=spf1 ip4:203.0.113.25 include:_spf.google.com ~all"

Rules to follow:

One record only. If a record already exists, edit it. Two records cause a permerror under RFC 7208.
Stay under 10 DNS lookups. Each include, a, mx, exists, and redirect counts, including nested ones. If you’re close, move a sender to a subdomain or drop includes you no longer use.
End with ~all or -all. Never +all.

For a full syntax reference, see SPF record explained.

Where SPF really gets checked

SPF is checked against the envelope sender (Return-Path), not the visible From. Many platforms use their own bounce domain by default, so your SPF record isn’t even consulted. For SPF to count toward DMARC, the platform must use a bounce domain under your domain. Amazon calls this a custom MAIL FROM domain; other platforms call it a “custom return path” or “bounce domain.” For SES it looks like this:

bounce.example.com.  MX   10 feedback-smtp.us-east-1.amazonses.com
bounce.example.com.  TXT  "v=spf1 include:amazonses.com ~all"

AWS requires exactly one MX record on that subdomain and notes it can take up to 72 hours for SES to detect it.

Test: dig +short TXT example.com should return exactly one line starting with v=spf1. Or paste the domain into the SPF checker.

Step 2: Set up DKIM

DKIM is set up per sending platform. Each platform gives you either a TXT record containing a public key or CNAME records pointing to keys it hosts.

DKIM for common providers

Google Workspace. Per Google’s DKIM setup page, go to Apps > Google Workspace > Gmail > Authenticate email in the Admin console, generate a key (default selector google), publish the TXT record it shows, then come back and click Start authentication. Google says to allow up to 48 hours after publishing for DKIM to start working, and to test by sending to a Gmail address rather than to yourself. Choose 2048-bit if your DNS host supports it; Google’s sender guidelines require at least 1024 bits and recommend 2048.

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

Microsoft 365. Microsoft’s DNS setup page has you add two CNAMEs, selector1._domainkey and selector2._domainkey, using the values shown in the admin center. Publishing the CNAMEs doesn’t start signing on its own; you then turn DKIM signing on for the domain, as described in Microsoft’s DKIM configuration guide.

selector1._domainkey.example.com.  CNAME  <value from admin center>
selector2._domainkey.example.com.  CNAME  <value from admin center>

Amazon SES. With Easy DKIM, SES signs with a 2048-bit key by default and gives you CNAME records to publish. If Route 53 hosts your DNS, SES can create them for you.

Your own mail server. Generate a 2048-bit key pair (the DKIM generator can do this), configure your MTA (OpenDKIM, Rspamd, or similar) with the private key, and publish the public key at <selector>._domainkey.example.com.

DKIM pitfalls during setup

Double domain names. Many DNS dashboards append your domain automatically. Enter google._domainkey, not google._domainkey.example.com, or you’ll create google._domainkey.example.com.example.com.
Long keys. A 2048-bit key exceeds 255 characters, so it must be split into multiple quoted strings inside one TXT record. Most dashboards handle it; some silently truncate.
Not turning signing on. Publishing the record isn’t enough for Google Workspace or Microsoft 365. You must also start signing in the admin console.

Test: Send a message to a Gmail account, open “Show original,” and look for dkim=pass header.i=@example.com. If the domain after @ is your platform’s domain rather than yours, custom DKIM isn’t active yet. Our DKIM checker validates the published key if you know the selector. For background, see DKIM explained.

Step 3: Set up DMARC

Wait until SPF and DKIM are working. Google’s recommended DMARC rollout says to set up DKIM and SPF at least 48 hours before setting up DMARC.

Start with monitoring

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

The record name is _dmarc, not the bare domain.
rua is where aggregate reports go. Use a dedicated mailbox or a DMARC reporting service; daily XML reports from many receivers add up quickly.
p=none meets the minimum for Gmail, Yahoo, and Outlook.com bulk sender rules.

The DMARC generator builds this record for you.

Read the reports, fix failures

After about a week (Google’s suggested minimum for representative data), look for:

Legitimate sources failing DKIM alignment: turn on custom DKIM in that platform.
Legitimate sources failing SPF alignment: set a custom bounce domain, or rely on DKIM.
Unknown sources: either a forgotten tool or someone spoofing you.

The existing post on reading DMARC aggregate reports shows how.

Move to enforcement

When every legitimate source passes with alignment:

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

Then, after another clean period:

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

The np tag, which covers subdomains that don’t exist, was added in RFC 9989, the 2026 DMARC standard. For the full migration process, see getting from p=none to p=reject without losing mail and DMARC explained.

Step 4: The supporting records

Three more items aren’t SPF, DKIM, or DMARC but get checked alongside them:

Reverse DNS (PTR). If you run your own sending IP, it needs a PTR record whose hostname resolves back to the same IP. Google and Yahoo require valid forward and reverse DNS for all senders. Hosted providers handle this for you. See reverse DNS (PTR) records.
MX records. Your sending domain should be able to receive replies and bounces. Publish MX records on the domain (or a bounce subdomain) so that mail has somewhere to land.
One-click unsubscribe for marketing mail, required by Gmail and Yahoo for bulk senders. Gmail’s sender guidelines and Yahoo’s both list it alongside authentication.

Setup checklist

Step	Record name	Done when
SPF	`example.com` (and each bounce subdomain)	One `v=spf1` record, under 10 lookups, `spf=pass` in headers
DKIM	`<selector>._domainkey.example.com` per platform	`dkim=pass` with `header.i=@example.com`
DMARC monitor	`_dmarc.example.com`	`p=none` with `rua`, reports arriving
DMARC enforce	`_dmarc.example.com`	`p=reject`, all legitimate sources aligned
PTR	Your sending IPs	Forward-confirmed reverse DNS

What authentication won’t fix

Authentication proves your mail is yours. It doesn’t make a bad list good. High bounce rates still damage your reputation even with perfect DMARC. Before your first authenticated send, run the list through our free email verifier: it flags invalid syntax, domains with no MX records, disposable domains, role addresses like info@, and typos like yaho.com. It doesn’t log in to mailboxes, so pair it with good bounce handling.

FAQ

What order should I set up SPF, DKIM, and DMARC in?

SPF and DKIM first, in either order, then DMARC. DMARC depends on the other two, and Google recommends waiting at least 48 hours after setting up SPF and DKIM before adding a DMARC record.

How long does SPF, DKIM, and DMARC setup take?

The DNS records take minutes to add and usually propagate within the record’s TTL. The real time goes into DMARC monitoring: plan on at least a week at p=none, and longer for organizations with many senders or infrequent mail streams.

Do I need all three?

For bulk sending, yes. Google requires SPF, DKIM, and DMARC for senders of more than 5,000 messages a day to Gmail, and Yahoo and Microsoft have similar rules. Smaller senders need at least SPF or DKIM at Gmail and Yahoo, but setting up all three is the safer default.

Can I set up DMARC without a reporting address?

You can, but you’d be enforcing blind. Without rua, you get no data about which sources pass or fail, so you can’t safely move from p=none to p=reject.

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