How to Set Up Professional Email for Your Domain: SPF, DKIM & DMARC Explained

A customer forwards you an email. It came from “[email protected]”, it asks them to pay an invoice to a new bank account, and you did not send it.

Anyone in the world can put your address in the From field of an email. That is not a bug, it is how email was designed in 1982, back when everyone on the network knew everyone else. The three records below are the patch we bolted on afterwards. They cost nothing, and without them your domain is an open microphone.

Three Records, Three Different Jobs

People lump SPF, DKIM and DMARC together, which makes them sound like one thing you either have or don’t. They are three separate mechanisms answering three separate questions:

  • SPF answers: which servers are allowed to send mail for this domain?
  • DKIM answers: was this specific message really signed by that domain, and did anyone tamper with it in transit?
  • DMARC answers: if a message fails both checks above, what should the receiving server actually do about it?

All three are published as TXT records in your DNS zone, the same zone holding the MX records that route your incoming mail. If DNS zones are unfamiliar territory, our guide on how DNS works covers the ground first.

The First Record: SPF

SPF is a public list of servers permitted to send email on your behalf. A receiving server checks the list, and if the message came from somewhere else, it knows something is off.

v=spf1 mx a ip4:203.0.113.10 include:_spf.google.com -all

Reading that record from left to right:

  • mx permits whatever servers your MX records point to
  • a permits the server your domain’s A record resolves to
  • ip4:203.0.113.10 permits one specific IP
  • include:_spf.google.com permits Google Workspace to send as you
  • -all means everything else fails, hard. Use ~all instead while you’re still testing, since that only marks failures as suspicious rather than rejecting them outright

One rule catches out almost everybody: a domain may have exactly one SPF record. Not two. If you already have an SPF record and you add a second one for a new email provider, you have not authorized that provider, you have broken SPF for your entire domain. Merge everything into a single record with multiple include: statements instead.

The Second Record: DKIM

SPF vouches for the server. DKIM vouches for the message itself.

Your mail server signs every outgoing email with a private key. The matching public key sits in your DNS. A receiving server pulls the public key, checks the signature, and now knows two things: the message genuinely came from your domain, and nobody altered a single character of it along the way.

Your mail platform generates the key pair for you. You publish the public half at a selector, which looks like this:

default._domainkey.yourdomain.com   TXT   "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

In cPanel and DirectAdmin this is usually generated automatically when you switch DKIM on in the domain’s email settings. The trap: if your DNS is hosted somewhere else, say Cloudflare, generating the key on the mail server does nothing on its own. You still have to copy that TXT record into the zone where your DNS actually lives. This catches people constantly.

The Third Record: DMARC

Now you have two checks running. DMARC is the instruction telling receiving servers what to do when a message fails them, and asking those servers to report back to you.

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

The p= tag is the whole game:

  • p=none takes no action, it only reports
  • p=quarantine pushes failing messages into spam
  • p=reject refuses failing messages at the door

Do not start at p=reject. That is not caution, it is arithmetic: if you have forgotten a single legitimate sending source, and almost everyone has, you will silently destroy your own email. Your invoicing system, your CRM, your newsletter tool. Gone, and you won’t find out until a customer mentions they never got anything.

A Three-Week Rollout That Actually Works

  1. Week 1. Publish SPF and DKIM. Set DMARC to p=none. Nothing is blocked yet. You are just switching the lights on
  2. Week 2. Read the aggregate reports arriving at your rua address. They are XML, they are ugly, and any free DMARC report parser will turn them into something readable in seconds. You are hunting for one thing: a legitimate service of yours that is failing authentication. Mailchimp, SendGrid, your helpdesk software, that ancient contact form on the old site nobody remembers
  3. Week 3. Once the reports are clean, move to p=quarantine. Watch for another week or two, then go to p=reject

The single most common failure with DMARC is not a wrong record. It is publishing p=none, never opening a single report, and believing the domain is protected. It is not. p=none protects nobody. It is a listening post, and it only has value if somebody actually listens.

Where to Put These Records

Wherever your DNS is managed, not necessarily wherever your email lives:

  • cPanel or DirectAdmin: DNS Zone Editor → Add Record → TXT
  • Registrar DNS (GoDaddy, Namecheap): DNS Management → Add Record → TXT
  • Cloudflare: DNS tab → Add Record → Type TXT

Changes can take anywhere from a few minutes to 48 hours to propagate, so a record that doesn’t verify immediately isn’t necessarily wrong. It might just be early.

Proving It Works

Send yourself an email at a Gmail address. Open the message, click the three dots, choose “Show original”. Gmail will tell you plainly:

SPF:   PASS
DKIM:  PASS
DMARC: PASS

Three PASS lines and your domain now speaks with a verified voice. Anything less and one of the three records needs another look.

The Payoff Most People Miss

Gmail and Yahoo now require bulk senders to authenticate. That alone is reason enough. But there is a second, quieter benefit that shows up months later: a domain with a long, clean authentication history simply lands in inboxes more often than one without. Reputation compounds.

And once you are enforcing DMARC at quarantine or reject, you unlock BIMI, which puts your company logo beside your emails in supporting inboxes. It requires an SVG logo and one more DNS record. Small effort, and it turns all this invisible plumbing into something your customers can actually see.

Setting up a new domain from scratch and want to get this right from day one? Our guide to choosing a domain name is the sensible place to start.