Email Authentication Setup Checklist: SPF, DKIM, DMARC Step by Step

Here is the entire job in one sentence. List every service that sends mail as your domain, publish one SPF record, switch on DKIM inside each of those services, add a DMARC record at _dmarc with a reporting address, send a test to Gmail and read the headers, then re-check the set whenever you add a tool. That is the email authentication setup checklist start to finish, and most of it is typing short text entries into your DNS panel.

The thinking part is step one. Almost everyone skips it, which is why so many setups look finished and still fail.

This is the hands-on companion to our explainer on what SPF, DKIM, and DMARC actually do. If the three names still feel fuzzy, read that first. Everything below assumes you have the idea and want the order of operations.

Before you touch anything

Four things on the desk:

• Access to your DNS. DNS (Domain Name System) is the public address book for your domain, and where you publish the small text entries called TXT records that receiving mail servers look up. It lives wherever your name servers do: your registrar, your host, or a service like Cloudflare.
• Admin access to every tool that sends email for you. Not just your mailbox provider.
• A plain text file for notes. Future you will need it.
• A copy of your current records before you overwrite anything.

A bad DNS edit can interrupt mail for the whole domain. Panels also differ in how they want a host name entered, so if a screen does not match the examples below, check your provider’s documentation. Changes usually appear within minutes, depending on the TTL (the cache lifetime on the record).

Step 1: List every service that sends mail as your domain

This step decides whether the rest works. Write down every system that puts your domain in the From address:

• Your mailbox provider (Google Workspace, Microsoft 365, or whoever hosts your mail)
• Your marketing or newsletter platform
• Your CRM, if sales people send sequences from it
• Your helpdesk or shared support inbox
• Your website: contact forms, password resets, order confirmations, invoices
• Billing, scheduling, and e-signature tools

To catch the ones you forgot, search your own inbox for mail from your domain you did not personally write. A form plugin that quietly sends receipts counts as much as the newsletter platform.

If messages are already bouncing back with error text, that is a delivery problem rather than an authentication one, and our guide to mailer daemon bounce messages covers those.

Step 2: Publish one SPF record

One record. At the root of your domain. Type TXT.

That first rule matters most: a domain gets exactly one SPF record. Publish a second and the check fails outright, which is worse than having no record at all. When you add a sender, you edit the record that already exists.

The record starts with v=spf1, lists the senders you approve, and ends with ~all. Each service publishes the exact mechanism it wants you to add, usually something like include:_spf.theirdomain.com. Copy that from their documentation rather than from someone else’s blog, because every provider has its own and they do change.

A working record, with your own senders in the middle:

v=spf1 include:_spf.example-mailhost.com include:servers.example-sender.net ~all

Two details catch people out.

The 10 lookup limit. SPF allows a maximum of 10 DNS lookups while a receiving server expands your record. A lookup is one query that server has to make to find out more, and every include:, a, mx, exists, and redirect mechanism costs at least one, with nested includes adding their own. Go over 10 and the check returns a permanent error, so your record stops helping. Five or six senders is usually fine. Stack more and you want a lookup checker before assuming it passes.

The ending. ~all is a soft fail: mail from anywhere else is suspect but should not be discarded. -all is a hard fail. Start with ~all while you are still finding forgotten senders.

Step 3: Turn on DKIM in each sending service

DKIM is not one record you write yourself. Each service generates its own key and hands you the record to publish, so this step repeats once per tool from your list.

The pattern is the same everywhere. In the tool, find the domain or sending settings and enable DKIM. It gives you one or two records, usually CNAMEs pointing at the provider, sometimes a TXT record holding the public key. Publish them exactly as given, then click the tool’s verify button.

The word you need is selector. A selector is a short label in the host name that tells receivers which key to fetch, so records look like selector1._domainkey.yourdomain.com. Every service uses its own, which is why two tools can sign mail for the same domain without stepping on each other. Write each selector next to the tool that owns it.

The most common failure: switching DKIM on in the dashboard and never publishing the record. Half-done DKIM looks done and signs nothing.

Step 4: Publish DMARC, starting at p=none

One TXT record, on the host _dmarc (so _dmarc.yourdomain.com), and start it deliberately weak:

v=DMARC1; p=none; rua=mailto:[email protected]

p=none asks receivers to report what they see without changing how they handle anything. The rua address is where those reports arrive. Use a mailbox you will actually open, and expect XML files rather than readable summaries; they get useful once fed into a report viewer.

Now the concept that makes DMARC work: alignment. DMARC does not only ask whether SPF or DKIM passed. It asks whether the domain that passed matches the domain your reader sees in the From line. A message can pass SPF perfectly for a sending platform’s own domain while showing your brand in the From field, and DMARC still fails it.

Leave the policy at p=none for a few weeks and read the reports. You want a stable picture where the senders you recognize are passing and nothing legitimate is failing. Then move to p=quarantine, which sends unaligned mail to spam. Only after that consider p=reject, which tells receivers to refuse the message outright. There is no prize for reaching reject quickly. The forgotten invoice system will find you at that moment.

Step 5: Test with a real message

Send a genuine message from each sending tool to a Gmail address you control. Not one from your mailbox plus an assumption about the rest.

In Gmail, open the message, click the three-dot menu, and choose Show original. The panel at the top lists SPF, DKIM, and DMARC with a PASS or FAIL beside each.

Read the domain next to each result, not just the word PASS. This is where alignment problems surface: if DKIM passes for your marketing platform’s domain rather than yours, the header says so plainly. Repeat for every tool, since a helpdesk and a website form can behave differently from the same address.

Three passes still do not guarantee inbox placement. Content, sending history, and complaint rates decide the rest, covered in why emails go to spam.

Step 6: Keep the setup current

Authentication is not a one-time task, because your sending stack keeps changing. Put these on a recurring note:

• Someone adds a tool that sends email? Update SPF and enable DKIM before the first campaign, not after.
• Skim your DMARC reports monthly, watching for sources you do not recognize and senders that started failing.
• Keep the selector log current: tool name, selector, date added.
• Cover your subdomains. SPF is not inherited, so a subdomain that sends needs its own record. DMARC at your root domain does apply to subdomains unless you override it with an sp= tag.
• Re-check after a migration. New mailbox providers, DNS hosts, or marketing platforms break records quietly.

If you send cold outreach, our cold email deliverability checklist covers the rest.

The email authentication setup checklist at a glance

Every value below is an example. Replace yourdomain.com with your domain, and swap the mechanisms for the exact strings your providers publish.

What	Record type	Host name	Example value
SPF	TXT	@ (the root domain)	v=spf1 include:_spf.example-mailhost.com ~all
DKIM (per service)	CNAME or TXT, as the service specifies	selector1._domainkey	provided by the sending service, copy exactly
DMARC	TXT	_dmarc	v=DMARC1; p=none; rua=mailto:[email protected]
SPF for a sending subdomain	TXT	mail (or the subdomain in use)	v=spf1 include:_spf.example-sender.net ~all

Some panels want the host typed as _dmarc and others want the full _dmarc.yourdomain.com. Getting that wrong in a panel that appends your domain gives you _dmarc.yourdomain.com.yourdomain.com, which silently does nothing.

Mistakes that break otherwise correct setups

• Two SPF records. Caused by adding a new tool with a fresh record instead of editing the existing one. The result is a permanent error.
• Blowing past 10 lookups. Symptoms are inconsistent: some receivers still let mail through, and no dashboard flags it.
• Forgetting the marketing platform. Your highest-volume sender, filed mentally as separate from company email.
• DKIM enabled but never published. The toggle is green, the record never reached DNS, nothing is signed.
• Jumping straight to p=reject. Your own invoices and password resets get refused.
• Leaving subdomains uncovered. Transactional mail often goes out from a subdomain nobody listed.

What Google actually requires

Google’s sender guidelines set a baseline for everyone and a stricter bar above a volume threshold. For all senders, the requirement is to “Set up SPF or DKIM email authentication for your sending domains.”

For anyone sending 5,000 or more messages per day to personal Gmail accounts, Google raises it to all three: “Set up SPF and DKIM email authentication for your domain” and “Set up DMARC email authentication for your sending domain. Your DMARC enforcement policy can be set to none.” On alignment, the requirement reads: “For direct email, the domain in the sender’s From: header must be aligned with either the SPF domain or the DKIM domain.”

Read that last line next to step four: alignment deserves the careful check. Notice too that p=none satisfies the DMARC rule. Yahoo introduced comparable requirements, and we covered both in our piece on the Gmail and Yahoo bulk sender rules. Requirements get revised, so confirm the current text on Google’s sender guidelines page.

Authentication settles identity, your list settles reputation

Once the six steps are done, you have proven that mail claiming to come from your domain really does. That is the smaller half of deliverability.

The other half is who you send to. A perfectly authenticated campaign fired at a list full of dead addresses still produces bounces, still trips spam traps, and still drags your sender reputation down, because receiving providers watch those signals far more closely than your DNS. Authentication earns you a fair hearing. It does not decide the verdict.

That is where running a list through email verification before a send pays for itself: invalid addresses, disposable domains, and known complainers come out before they reach a mailbox provider. To see what your list looks like, Reoon gives you free daily credits when you register, no card required.

FAQ