How to set up SPF, DKIM and DMARC

By the Olvane team · Updated

Three DNS records decide whether the rest of the internet believes your email is really from you: SPF, DKIM and DMARC. Without them, Gmail, Outlook and Yahoo have no way to tell your messages apart from someone pretending to be you, so they treat both with suspicion. With them, your mail starts from a position of trust.

This guide explains what each record does, shows the exact records to add, and ends with a checklist. You'll need access to your domain's DNS settings, usually where you bought the domain.

The short version

RecordWhere it goesWhat it proves
SPFTXT on your domainThe sending server is allowed to send for your domain.
DKIMTXT on selector._domainkeyThe message was signed by your domain and wasn't changed in transit.
DMARCTXT on _dmarcWhat to do when the first two fail, and where to report it.

You set them up in that order: SPF and DKIM first, then DMARC, because DMARC builds on the other two.

Step 1: Make a list of everything that sends as you

Before touching DNS, write down every service that sends email using your domain. People usually remember their mailboxes and forget the rest:

  • Your mailbox provider (Google Workspace, Microsoft 365, Olvane, Zoho…)
  • Your website or shop, for order confirmations and contact forms
  • Newsletter and marketing tools
  • Invoicing, CRM and help desk software

Each of these needs to be covered by SPF or DKIM, or your own mail will start failing once DMARC is enforced.

Step 2: Add SPF

SPF is a single TXT record on your domain that lists the servers allowed to send for it. Each service tells you what to add, usually an include: value. Combine them all into one record:

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

Three rules matter more than anything else:

  1. One record only. Two SPF records on the same domain make SPF fail for every message. If you already have one, edit it.
  2. At most 10 lookups. Each include, a and mx costs at least one DNS lookup, including the ones nested inside providers' records. Over 10, SPF fails.
  3. End with ~all or -all. Never +all, which allows anyone to send as you.

Some providers, including Olvane, Amazon SES and Postmark, send with their own bounce address on a subdomain such as send.yourdomain.com, and ask you to put the SPF record there instead. That's fine: SPF is checked against the bounce address, not the From address. Follow the provider's instructions exactly.

The SPF generator builds the record for you, and the SPF checker counts its lookups.

Step 3: Add DKIM

DKIM signs every message with a private key held by your email provider. You publish the matching public key in DNS so receivers can verify the signature. Your provider generates the key and shows you a record like this:

Name:  selector1._domainkey
Type:  TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…

The part before ._domainkey is the selector. Each service that sends for you can have its own selector, so unlike SPF, you add a separate DKIM record per service. Some providers give you a CNAME instead of a TXT record so they can rotate the key for you. Add exactly what they show.

Two things often go wrong:

  • The name gets doubled. Many DNS panels append your domain automatically. If you type the full selector1._domainkey.yourdomain.com, you end up with …yourdomain.com.yourdomain.com. Type only selector1._domainkey.
  • Signing isn't switched on. With some services, publishing the key isn't enough: you also have to click "verify" or "enable DKIM" in their settings.

Use 2048-bit keys where you have the choice. Check the result with the DKIM checker.

Step 4: Add DMARC in monitoring mode

DMARC connects SPF and DKIM to the address people see in the From line. A message passes DMARC if it passes SPF or DKIM and the domain that passed matches the From domain. Start with a policy that only monitors:

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

p=none changes nothing about delivery. What it gives you is reports: every day, large mailbox providers send an XML summary to the rua address listing each server that sent mail as your domain and whether it passed. The raw files are hard to read, so most people forward them to a free DMARC report service.

The DMARC generator builds the record with the right options.

Step 5: Move to enforcement

After two to four weeks of reports, you'll know whether all your real mail passes. Fix anything that doesn't, then tighten the policy:

  1. p=quarantine: failing mail goes to the spam folder. Add pct=25 if you want to apply it to a quarter of failing mail at first.
  2. p=reject: failing mail is refused outright. This is the setting that actually stops people from spoofing your domain.

Since February 2024, Gmail and Yahoo have required DMARC from anyone sending more than 5,000 messages a day to their users. Even if you send far less, an enforced policy is one of the clearest signals that a domain is well run.

Checklist

  • Exactly one SPF record, under 10 lookups, ending in ~all or -all.
  • A DKIM key published for every service that sends as you, 2048 bits where possible.
  • A DMARC record with a rua address you actually read.
  • A plan to move from p=none to p=reject.
  • An MX record, even for domains that only send, so replies and bounces have somewhere to go.

Run your domain through the email DNS checker to confirm everything at once. If you use Olvane for business email, the dashboard generates each record for your domain and checks your DNS automatically until they're all in place.

Keep reading

Business email on your own domain, free to start.

The free plan needs no card. Most of the setup is copying five DNS records.

Create your account