SPF, DKIM and DMARC explained: example records and a safe DMARC rollout

SPF, DKIM and DMARC are three DNS records that tell mailbox providers your email really comes from you. Gmail, Yahoo and Outlook now require all three from anyone sending in volume, and mail without them is far more likely to be filtered or rejected.

This guide explains what each record does, shows example records you can adapt, and walks through a DMARC rollout that won't block your own mail. All examples use example.com; swap in your own domain and the values your email providers give you.

The short version

SPF and DKIM each authenticate *a* domain. DMARC ties that result to the domain your reader actually sees in the From line. That last step, called alignment, is where most setups go wrong.

SPF: who may send for your domain

SPF (Sender Policy Framework, RFC 7208) is a list of servers allowed to send mail for a domain. The receiving server looks up the SPF record of the domain in the envelope sender (also called MAIL FROM or Return-Path), not the From address your reader sees, and checks whether the connecting IP is on the list.

An example SPF record for a domain that sends through Google Workspace and one email service:

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

Reading it left to right:

• v=spf1 marks it as an SPF record.
• Each include: pulls in another domain's list of servers. Your email provider tells you which one to add.
• ip4: and ip6: mechanisms list addresses directly, for example ip4:203.0.113.10.
• ~all means "anything else is probably not authorised" (softfail). -all means "anything else is not authorised" (fail).

Start with ~all while you are still finding all your senders. RFC 7208 says receivers shouldn't reject mail on a softfail alone, so it is forgiving. Move to -all once you are sure the list is complete.

The 10-lookup limit

RFC 7208 caps SPF evaluation at 10 DNS lookups. The include, a, mx, ptr and exists mechanisms and the redirect modifier each count, and so do lookups inside the records you include. ip4, ip6 and all don't count. Go over 10 and the result is permerror: SPF fails for every message, not just some.

The spec also says receivers should limit "void lookups" (lookups that return nothing) to two. An include: pointing at a provider you stopped using, whose record no longer exists, can trip this.

To stay under the limit, remove include:s for services you no longer use, avoid ptr entirely, and prefer ip4: ranges for your own servers. If you send through many providers, putting some of them on subdomains (each with its own SPF record) also helps.

DKIM: a signature on every message

DKIM (DomainKeys Identified Mail, RFC 6376) adds a cryptographic signature to each message. The sending server signs selected headers and the body with a private key. The receiver reads the DKIM-Signature header, finds the domain (d=) and selector (s=), and fetches the public key from DNS at selector._domainkey.domain.

An example DKIM record with the selector mail2026:

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

• p= is the public key. Your provider generates the key pair and gives you this value; never paste a private key into DNS.
• The selector lets you hold several keys at once, one per provider or one per rotation.

Many providers ask you to publish a CNAME instead, pointing your selector at a key they host:

s1._domainkey.example.com.  CNAME  s1.dkim.mail-provider.example.

That lets them rotate keys without asking you to edit DNS again.

On key size: Google requires DKIM keys of at least 1024 bits for mail to personal Gmail accounts and recommends 2048 bits where your DNS provider supports it. Yahoo recommends a minimum key length of 1024 bits. Long 2048-bit keys sometimes have to be split into several quoted strings in one TXT record; most DNS panels handle that for you.

DMARC: tying it to the From address

DMARC (Domain-based Message Authentication, Reporting and Conformance) does two jobs. It tells receivers what to do with mail that claims to come from your domain but fails authentication, and it asks them to send you reports about everything they see using your domain.

DMARC was first published as RFC 7489. In May 2026 the IETF replaced it with RFC 9989 (the core protocol), plus RFC 9990 for aggregate reports and RFC 9991 for failure reports. Records that start with v=DMARC1 keep working.

A DMARC record to start with:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

Alignment, explained with examples

A message passes DMARC if at least one of these is true:

• SPF passed, and the envelope domain it checked aligns with the From domain; or
• DKIM passed, and the signing domain (d=) aligns with the From domain.

With relaxed alignment (the default), "aligns" means the two domains share the same organisational domain. With strict alignment they must match exactly.

The third row is the classic trap. An email service sends with its own envelope domain and signs with its own DKIM domain. SPF and DKIM both pass, but for *its* domain, so DMARC fails for yours. The fix is to set up the provider's custom domain authentication, so it signs with d=example.com and, ideally, uses a bounce subdomain like bounce.example.com.

Google and Microsoft both recommend aligning SPF and DKIM, not just one. DKIM alignment matters most, because SPF breaks when mail is forwarded and DKIM usually survives.

How to set up DMARC without blocking your own mail

The goal is p=reject: receivers refuse mail that pretends to be you. Getting there in one jump risks rejecting your own invoices, help desk replies or newsletters from a tool you forgot about. Microsoft's guidance is to move gradually, from none to quarantine to reject, monitoring at each step. dmarc.org gives the same advice: start with a monitoring record that asks for reports.

Step 1: list every service that sends as you

Think beyond your marketing platform: Google Workspace or Microsoft 365, your store or billing system, help desk, CRM, invoicing, any outreach tool. Each needs to pass SPF or DKIM with alignment.

Step 2: publish p=none and collect reports

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

p=none changes nothing about delivery. It does make Gmail, Yahoo and Outlook's bulk-sender rules happy, since all three accept p=none as the minimum. Reports usually arrive about once a day from each receiver that sends them.

Step 3: read the aggregate reports

Aggregate (rua) reports are XML files listing, for each sending IP, how many messages it sent as your domain and whether SPF and DKIM passed and aligned. You are looking for:

• Legitimate sources that fail alignment. Fix these with custom DKIM or a custom bounce domain at that provider.
• Sources you don't recognise. Often a forgotten tool; sometimes someone spoofing you, which is exactly what enforcement will stop.

Raw XML is hard to read. Microsoft suggests a DMARC reporting service, or your own scripts, to turn reports into something you can scan. Use a dedicated mailbox for rua, not someone's personal inbox, and review reports weekly while you roll out.

If the report address is on a different domain from the one being monitored, that domain must publish an authorisation record, or receivers won't send the reports:

example.com._report._dmarc.reports-vendor.example.  TXT  "v=DMARC1;"

Most DMARC reporting services set this up on their side.

Step 4: move to quarantine

Once your legitimate sources pass and align consistently for a few weeks, change the policy:

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

Failing mail now goes to spam or junk. Keep watching the reports.

Step 5: move to reject

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]"

Microsoft suggests starting the whole process on a low-volume domain or subdomain and saving your main domain for last.

Domains that never send email

Parked domains are easy targets for spoofing. Publish a record that says no mail should come from them:

parked-example.com.         TXT  "v=spf1 -all"
_dmarc.parked-example.com.  TXT  "v=DMARC1; p=reject;"

Common mistakes

1. Two SPF records on one domain. RFC 7208 says that produces permerror. Merge them into one record with several include:s.
2. More than 10 DNS lookups in SPF. Also permerror. Count nested includes too.
3. Two DMARC records. RFC 9989 says receivers discard them all, so you have no policy at all.
4. DKIM signed with the provider's domain. DKIM passes, DMARC fails. Turn on custom domain signing.
5. Jumping straight to `p=reject`. Forwarded mail and forgotten tools get rejected. Monitor first.
6. Setting up SPF on the From domain only. SPF checks the envelope domain. If your provider uses its own bounce domain, your SPF record isn't even consulted.
7. Typos and stray quotes. A missing semicolon or a record published at _dmarc._dmarc.example.com (some DNS panels append your domain automatically) silently breaks things.
8. Sending from a free-mail address. You can't publish DNS for gmail.com. Google warns senders not to impersonate Gmail From headers and says Gmail will begin enforcing a DMARC quarantine policy on them, so always send from your own domain.

How to check your records

• Command line: dig TXT example.com, dig TXT _dmarc.example.com and dig TXT mail2026._domainkey.example.com (or nslookup -type=TXT on Windows) show what is actually published.
• Message headers: in Gmail, open a message you sent to yourself, click More (the three dots) and choose Show original. The summary at the top shows SPF, DKIM and DMARC results. The Authentication-Results header shows which domains were checked (smtp.mailfrom=, header.d=, header.from=), which is how you spot an alignment problem.
• Google Postmaster Tools has Authentication and Compliance status dashboards for domains you verify.

Our guide to why emails go to spam covers header inspection in more detail.

Where EterMail fits

EterMail is our product. When you add a sending domain, it shows the records to publish and checks that the domain is verified and has a DMARC record before campaigns can send. For cold outreach, it checks SPF, DKIM, DMARC and MX on every outreach domain. Outreach should run on separate domains from your newsletter, each with its own records; our cold email deliverability guide explains why.

Authentication is the entry ticket, not the whole game. For what each mailbox provider requires on top, see the Gmail, Yahoo and Outlook sender requirements, and for reputation and engagement, the email deliverability guide.

FAQ

What is the difference between SPF, DKIM and DMARC?

SPF lists the servers allowed to send for your envelope domain. DKIM signs each message so the receiver can verify the signing domain and that the message wasn't changed. DMARC checks that the domain your reader sees in the From line matches a domain that passed SPF or DKIM, tells receivers what to do when it doesn't, and sends you reports.

Do I need all three?

If you send in volume, yes. Gmail and Yahoo require bulk senders to use SPF, DKIM and DMARC, and Microsoft requires the same for domains sending more than 5,000 emails a day to Outlook.com addresses. Even at low volume, all three make your mail easier to trust and your domain harder to spoof.

What is a good DMARC record to start with?

v=DMARC1; p=none; rua=mailto:[email protected], published as a TXT record at _dmarc.example.com. It changes nothing about delivery but starts the reports flowing. Move to quarantine and then reject once the reports show all your legitimate mail passing and aligned.

How long should I stay at p=none?

There is no fixed period. Stay until the aggregate reports show every legitimate source passing with alignment over a normal sending cycle, including monthly invoices or seasonal campaigns. For many senders that is several weeks; Microsoft suggests reviewing reports weekly during rollout.

Can I have two SPF records?

No. RFC 7208 says a domain with more than one SPF record returns permerror, so SPF fails for all your mail. Combine every sender into one record with multiple include: mechanisms, and keep the total under 10 DNS lookups.

Why does DMARC fail when SPF and DKIM pass?

Because they passed for a different domain. If your email service uses its own bounce domain and signs DKIM with its own domain, neither aligns with your From domain. Set up custom domain authentication with the provider so it signs with your domain.