SPF, DKIM and DMARC

We set these records up for you. When you order, our team adds SPF, DKIM, DMARC and the other records your domains need, before your inboxes go live. You don’t have to touch them. This page explains what they are, so the words make sense when you see them.

Why they matter

Before Gmail or Outlook delivers an email, it checks a few public notes attached to the sender’s domain. These notes are DNS records: small lines of text stored with your domain at your registrar. If they’re missing or wrong, your emails are treated as suspicious and can land in spam or be rejected outright.

The records, in plain words

Record	Think of it as	What it does	Without it
SPF	The guest list	Says which servers are allowed to send email for your domain	Emails look suspicious
DKIM	A wax seal	Adds a hidden signature to every email, proving it came from you and wasn’t changed on the way	Emails fail integrity checks
DMARC	Instructions for the bouncer	Tells receivers what to do if SPF or DKIM fails, and where to send reports	You can’t see delivery problems
MX	Your postal address	Tells the world where to deliver email sent to your domain, such as replies	Replies can’t reach you

SPF: the guest list

SPF (Sender Policy Framework) is one line that lists who may send as your domain. For an Outlook domain it looks like this:

v=spf1 include:spf.protection.outlook.com -all

For a Google Workspace domain:

v=spf1 include:_spf.google.com ~all

A domain must have only one SPF record. If two services need to send for the same domain, their entries are merged into one line:

v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all

DKIM: the wax seal

DKIM (DomainKeys Identified Mail) signs each email with a key that only your mail service holds. The receiver checks the signature against a public key stored in your DNS. For Outlook, DKIM is two CNAME records (a CNAME is a record that points to another address), named selector1._domainkey and selector2._domainkey. Their values are unique to each Microsoft 365 tenant, so there is no example worth copying.

DMARC: instructions for the bouncer

DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM. A starting record looks like this, with your own domain in place of yourdomain.com:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

p=none means “just monitor and send me reports”. Once delivery is clearly healthy, it can be tightened to p=quarantine or p=reject.

MX: your postal address

MX records tell other mail servers where to deliver email addressed to your domain. They’re what make replies to your cold emails arrive. For Outlook domains they point at Microsoft; for Google Workspace, at Google.

What about forwarding?

Many people want a sending domain like getyourbrand.com to send website visitors on to their main site. The Cold Email Bible warns that domain forwarding is a known sign of “domain farming” and can hurt reputation, especially with Google. Its recommendation is to put a copy of your website on each sending domain instead.

How to check your records

You don’t need to, but if you’re curious:

MXToolbox (mxtoolbox.com) checks SPF, DKIM and DMARC for any domain, free.
From a terminal: nslookup -type=txt yourdomain.com shows your TXT records, including SPF.

When to ask for help

If a record still isn’t passing 48 hours after setup, message the team in your private Slack channel or through the chat bubble in the app, and include the domain name.

Inbox warmup What happens after the records are in place.

Common errors DNS, bounce and spam problems, and what to do.

Connect your registrar How we get access to set these records.

Glossary Every term, in one line.