How to Set Up SPF, DKIM and DMARC for Your Sending Domain

If you send email from your own domain, three DNS records decide whether mailbox providers believe it is really you: SPF, DKIM and DMARC. Since 2024, Gmail and Yahoo require all three from anyone sending in bulk, and in practice every sender benefits from them — unauthenticated mail is the first thing spam filters distrust.

This guide walks through each record in the order you should publish them, with exact examples, the mistakes that break them, and how to check your work from the command line. The examples use example.com; replace it with your domain.

How the three records fit together

Each record answers a different question for the receiving server:

• SPF — is the server that connected to me allowed to send for the envelope sender’s domain?
• DKIM — does the message carry a valid signature from a key the signing domain published?
• DMARC — did SPF or DKIM pass for the domain in the visible From: header, and if not, what does the domain owner want me to do?

SPF and DKIM prove something about a domain. DMARC ties that proof to the domain your recipient actually sees, which is why it is the record that stops spoofing.

Step 1: Publish one SPF record

SPF (RFC 7208) is a TXT record on the domain used as the envelope sender. It lists who may send, usually by including your email provider’s record, and ends with a rule for everything else:

example.com. TXT "v=spf1 include:_spf.your-provider.example ~all"

~all (softfail) tells receivers to treat unlisted senders as suspicious; -all (fail) tells them to reject. Start with ~all while you confirm every service that sends as you is listed, then tighten it.

If you use several services, they all go in the same record:

example.com. TXT "v=spf1 include:_spf.provider-a.example include:_spf.provider-b.example ~all"

SPF mistakes that break delivery

• Two SPF records. A domain may have only one TXT record starting with v=spf1. Publishing a second one — the most common mistake when adding a new provider — makes SPF return permerror for all of them. Merge them into one record.
• More than 10 DNS lookups. Every include, a, mx, ptr, exists and redirect costs a lookup, including the ones nested inside the records you include. Over 10 and the result is permerror. Remove services you no longer use, or move some senders to a subdomain with its own record.
• SPF on the wrong domain. SPF checks the envelope sender (the return-path), not the From: header. If your provider sends with a return-path such as bounce.example.com, that is the name that needs SPF, and most providers handle it with a CNAME to their own host.

Step 2: Publish your DKIM key

DKIM (RFC 6376) signs each message with a private key held by your email provider. You publish the matching public key under a selector — a label that lets you have more than one key at a time:

selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh…IDAQAB"

Your provider generates the key and tells you the selector and value; copy them exactly. Use 2048-bit RSA keys where possible. A 2048-bit key is longer than the 255-character limit for a single TXT string, so it is published as several quoted strings in one record — most DNS panels split it for you, but a panel that adds its own quotes or line breaks inside the key will break the signature.

DKIM mistakes to avoid

• Truncated or altered keys. One missing character invalidates every signature. Compare what DNS returns with what your provider shows.
• The wrong host name. Some DNS panels append your domain automatically, so entering the full name produces selector1._domainkey.example.com.example.com. Check with dig after publishing.
• Deleting the old key during rotation. Publish the new selector, switch signing to it, and remove the old key only after mail signed with it has stopped arriving.

Step 3: Add a DMARC policy

DMARC (RFC 7489) is a TXT record at _dmarc on your domain. It sets a policy for mail that fails authentication and asks receivers to send you aggregate reports:

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

• p= is the policy: none (report only), quarantine (treat as suspicious, usually spam folder) or reject (refuse).
• sp= is the policy for subdomains. Without it, subdomains inherit p=; setting it explicitly makes your intent clear.
• rua= is where aggregate reports go — daily XML summaries of who sent mail as your domain and whether it passed.
• adkim= and aspf= set alignment to relaxed (r, the default: subdomains of the same organisational domain match) or strict (s: exact match).

Alignment is what DMARC actually checks

DMARC passes if SPF or DKIM passes and the domain it authenticated aligns with the From: domain. A message from you@example.com signed with d=provider.example passes DKIM but not DMARC. This is the usual reason a domain with “working” SPF and DKIM still fails: the provider is signing or sending with its own domain. Make sure DKIM signs with d=example.com and, ideally, that the return-path is on your domain too, so you have two independent routes to a pass.

Don’t leave p=none forever

p=none changes nothing about delivery — a forged message from your domain is treated exactly as if you had no DMARC at all. It is useful for a short period to discover every service that sends as you, but domains often stay there for years. Read the reports, fix any legitimate sender that fails, then move to p=quarantine and eventually p=reject.

Verify your records with dig

Check each record against what your DNS actually serves:

dig +short TXT example.com | grep spf1
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com

The SPF query should return exactly one line starting with v=spf1. To see what a receiver concluded, send a message to a mailbox you control, open the original source and find the Authentication-Results header:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=selector1;
       spf=pass smtp.mailfrom=bounce.example.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

You want dmarc=pass, with header.i or smtp.mailfrom on your own domain. If DNS changes do not show up, remember that resolvers cache the old answer until its TTL expires; query your authoritative nameserver directly with dig @ns1.your-dns.example to see the current value.

Beyond the three records

Once SPF, DKIM and DMARC pass, the next layers are MTA-STS to protect mail coming in to your domain, and BIMI to show your logo once DMARC is at enforcement. Authentication gets your mail considered; whether it reaches the inbox then depends on reputation, which is covered in why emails go to spam.

Doing this with PostStack

When you add a domain to PostStack, it generates a 2048-bit DKIM key and lists every record to publish: an SPF record, the DKIM key, a DMARC record at p=quarantine with relaxed alignment, and a bounce. CNAME so the return-path is on your domain. It checks them against your authoritative nameservers and tells you which one is missing or wrong. The free plan covers 3,000 emails a month if you want to try it on a real domain.