How to Set Up SPF, DKIM, and DMARC (Step-by-Step)

You'll add three DNS TXT records to authenticate your sending domain: SPF lists who can send on your behalf, DKIM cryptographically signs each message, and DMARC tells receivers what to do with mail that fails either check. This guide walks through each record with example values and a staged DMARC rollout that won't break legitimate mail.

Since February 2024, Google and Yahoo have required SPF, DKIM, and DMARC on every domain sending more than 5,000 messages a day to their users (Google Email Sender Guidelines, 2024). Unauthenticated bulk mail lands in spam or gets rejected at the door; if your inbox placement rate fell off a cliff sometime after that date, this is the first thing to check.

Before you start

Four things need to be in front of you:

1. Admin access to your domain's DNS zone (Cloudflare, GoDaddy, Route 53, Namecheap; wherever your nameservers point).
2. Credentials for your sending platform (Mailneo, Google Workspace, Microsoft 365, or whatever else you send through).
3. A test inbox on a major provider. Gmail and Outlook.com both work.
4. About 45 minutes. Most of that is waiting for propagation; the edits themselves take under ten.

One warning before you touch anything. If your domain already has an SPF record, do not add a second one. RFC 7208 §4.5 is unambiguous, and a domain with two SPF records is treated as having none (RFC 7208, IETF). Check what is there first; you will be merging, not duplicating. A quick primer on TXT and the other record types helps if DNS is unfamiliar territory.

Step 1: set up SPF

SPF, the Sender Policy Framework, is a TXT record listing the IP addresses and hostnames allowed to send email for your domain. Receivers look it up, compare the sending IP against the list, and decide whether the mail is authorized. The full explainer on SPF covers the theory; this section is the configuration.

Start by inventorying every service that sends mail from your domain. Typical culprits are your marketing platform, your transactional provider, Google Workspace or Microsoft 365, your CRM, your support desk, and whatever else quietly reaches customer inboxes. Missing one here is the single most common cause of DMARC failures three weeks later.

For a domain sending through Google Workspace plus Mailneo, the record looks like this:

v=spf1 include:_spf.google.com include:spf.mailneo.co ~all

Each include: pulls in that provider's authorized IPs. ~all softfails anything outside the list; start there rather than -all, which rejects outright, and tighten once you are confident nothing legitimate lives outside the record. Our SPF generator covers the 40 most common ESP include strings if you don't know yours.

Now the gotcha that breaks SPF for larger senders. RFC 7208 caps DNS lookups during evaluation at ten; exceed it and the record returns PermError, which DMARC treats as a failure (RFC 7208 §4.6.4). Every include:, a, mx, ptr, and exists counts, and nested includes count too. include:_spf.google.com chains to three more includes on its own, so you have burned four lookups before adding anything of your own. If you are up against the ceiling, strip unused includes first. SPF flattening services will collapse the chain into a static IP list, but then you own the job of refreshing that list every time an ESP rotates IPs.

Publish the record as a TXT entry at the root of your domain (@, or a blank name field, depending on the interface). On Cloudflare that's DNS → Records → Add record → TXT, with proxy status off, since the proxy doesn't apply to TXT records. On GoDaddy it's DNS Management → Add → TXT with Host set to @. Route 53 wants the value wrapped in double quotes. Namecheap puts it under Advanced DNS → Add New Record.

Then wait. Propagation usually takes 5 to 15 minutes, though Cloudflare documents up to 48 hours in edge cases. Verify with dig TXT example.com +short or MXToolbox's SPF check.

Step 2: set up DKIM

DKIM signs message headers and body with a private key; receivers fetch your public key from DNS and verify the signature hasn't been tampered with in transit. RFC 6376 is the spec (IETF, 2011), and the DKIM overview explains the cryptography in plain English.

Each platform generates its own keypair. You never handle the private key, which stays on the platform's servers; you publish only the public half. In Mailneo it lives under Settings → Sending Domains → Add Domain. In Google Workspace it's Admin console → Apps → Google Workspace → Gmail → Authenticate email.

Pick 2048-bit keys whenever the platform offers a choice. M3AAWG's Sender Best Common Practices treats 2048 as the minimum, and some receivers flag 1024-bit keys as weak. If a provider left you on a 1024-bit legacy key, rotate inside six months.

DKIM records live at a selector subdomain, which is what lets you rotate keys without invalidating old signatures. The record name looks like selector1._domainkey.example.com:

selector1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw2... (base64-encoded public key, usually 200+ chars)"

Most DNS interfaces split values over 255 characters into multiple quoted strings automatically; the standard allows it. Our DKIM generator outputs both the selector name and the TXT value for your domain.

Verify end to end before moving on. Send a test message to a Gmail address you control, open it, and pick the three-dot menu → Show original. Under "DKIM:" you want PASS with domain example.com. NEUTRAL or FAIL means the public key didn't match, which is almost always a paste problem: a trailing newline, or a value the DNS interface truncated without telling you.

Step 3: set up DMARC

DMARC ties SPF and DKIM together and tells receivers what to do with failing mail. Without it, receivers guess. RFC 7489 defines it (IETF, 2015); for the side-by-side view, see SPF vs DKIM vs DMARC.

Never start with enforcement. Start with p=none, which tells receivers to deliver as normal and send you aggregate reports. The record name is _dmarc.example.com:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1; adkim=r; aspf=r; pct=100"

p=none monitors without enforcing. rua is where the aggregate XML reports go, so point it at a mailbox somebody actually reads. ruf collects forensic reports on individual failures and is optional; Gmail doesn't send them at all. pct=100 applies the policy to all mail, which you'll adjust during the ramp.

Alignment is the part that trips people up, so it's worth slowing down on. Relaxed alignment (adkim=r, aspf=r) means mail.example.com counts as aligned with example.com; strict (s) requires an exact match. If you send transactional mail from notifications.example.com and marketing from the root domain, relaxed keeps both under one policy. Strict forces each subdomain to authenticate separately, which is useful when you're isolating brands and painful the rest of the time. RFC 7489 defaults to relaxed precisely because most real senders need it.

Read the reports for two to four weeks before touching the policy. Aggregate reports arrive daily as XML attachments from every major receiver and are miserable to read raw, so pipe them into a visualizer. You're looking for three things: sources you recognize passing at volume, sources you don't recognize failing, and legitimate sources failing because their include never made it into step 1. Fix that third category before enforcing anything. Skipping this step is how companies null-route their own payroll notifications.

The monitoring phase has an underrated side effect, which is that it surfaces shadow IT. A scheduling tool somebody signed up for two years ago will appear in your reports failing authentication, and now is the moment to either add it to SPF or close the account.

Once legitimate sources are passing at roughly 99%, step up gradually with the pct= tag:

# Week 3-4: 10% of failing mail goes to spam
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com; adkim=r; aspf=r

# Week 5-6: 50%
v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@example.com; adkim=r; aspf=r

# Week 7+: 100% quarantine
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com; adkim=r; aspf=r

# Week 10+: full reject, only after quarantine has been clean for two weeks
v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@example.com; adkim=r; aspf=r

At p=reject, receivers bounce failing mail at the SMTP layer and there is no spam folder to recover it from. That's the goal, but only once you're sure nothing legitimate will fall through. Plenty of domains publish a DMARC record and then stall at p=none forever, because publishing the record is the easy half and reading the reports is the half that takes attention. Our DMARC generator has the tag reference built in, and the DMARC glossary entry covers the vocabulary.

Step 4: verify everything is working

Three checks. Run all three before calling it done.

Start with DNS. On mxtoolbox.com/SuperTool.aspx, run spf:example.com, dkim:selector1._domainkey.example.com, and dmarc:example.com. Each should return the record you published with no warnings, and MXToolbox flags SPF lookup counts over ten with a yellow banner that's easy to scroll straight past.

Then send and score. mail-tester.com hands you a disposable address; send a real campaign to it from your platform and you get a score out of ten with per-check breakdowns. Authentication problems show up in red. Anything under 9/10 is worth reading line by line.

Finally, inspect the headers yourself. Send a test to your own Gmail account, open Show original, and look near the top:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com;
       spf=pass (google.com: domain of sender@example.com designates 192.0.2.1 as permitted sender);
       dmarc=pass (p=QUARANTINE sp=QUARANTINE) header.from=example.com

Three pass results and you're finished. Any fail, temperror, or neutral sends you back to the relevant step.

Google's Postmaster Tools and Microsoft's SNDS give you ongoing visibility once you verify domain ownership; check weekly for the first month, then monthly. Authentication is the entry ticket rather than the whole game. Once the records pass, watch delivery rate alongside inbox placement and move on to the parts of sender reputation that no DNS record can fix. The email deliverability guide is the pillar for this cluster, and how to avoid the spam folder picks up where the DNS work ends.