SPF, DKIM, and DMARC: Set Up Email Authentication for a Custom Domain

If you send email from your own domain — [email protected] — three DNS records decide whether your mail lands in the inbox or the spam folder, and whether a stranger can send email that looks like it came from you. Those three records are SPF, DKIM, and DMARC.

This guide walks through what each one does and exactly how to set them up. It assumes you have a custom domain and access to its DNS settings (at your registrar or DNS host), and that you’re sending mail through a provider like ProtonMail, Tuta, Google Workspace, Fastmail, or a marketing platform.

Why These Records Exist

The original email protocol, SMTP, has no built-in way to verify that a sender is who they claim to be. Anyone can connect to a mail server and put any address in the “From” field. That’s why spoofing and phishing work so well.

SPF, DKIM, and DMARC are three layers that close that gap:

• SPF says which servers are allowed to send mail for your domain.
• DKIM cryptographically signs your outgoing mail so the recipient can verify it wasn’t tampered with and really came from your domain.
• DMARC ties the two together, tells receiving servers what to do when a message fails, and sends you reports.

You want all three. SPF or DKIM alone leaves gaps; DMARC is what actually instructs other mail servers to reject forgeries.

SPF: Sender Policy Framework

SPF is a single TXT record at the root of your domain. It lists the hosts authorized to send mail using your domain in the envelope sender. SPF is specified in RFC 7208 ↗.

A minimal record for a domain that sends only through one provider looks like this:

v=spf1 include:_spf.example-provider.com -all

Breaking it down:

• v=spf1 — declares this is an SPF record.
• include:_spf.example-provider.com — authorizes your provider’s sending servers. Each provider publishes the exact value to use; you copy it from their documentation. ProtonMail, Google Workspace, and others each have their own include string.
• -all — a “hard fail.” Anything not listed should be rejected.

A few practical notes:

Use -all, not ~all, once you’re confident. ~all is a “soft fail” (treat as suspicious but accept). It’s a reasonable starting point while you confirm everything legitimate is covered, but the goal is -all.

You get exactly one SPF record per domain. If you send through multiple services (your mail host plus a newsletter tool plus a CRM, for example), you combine them into a single record with multiple include: statements — you do not publish two separate SPF records.

Watch the 10-lookup limit. SPF allows a maximum of 10 DNS lookups during evaluation. Each include: can chain to more lookups. Stacking many services can exceed the limit and cause SPF to break (“permerror”). Keep the record lean.

DKIM: DomainKeys Identified Mail

DKIM adds a cryptographic signature to the headers of every message you send. The receiving server fetches your public key from DNS and verifies the signature, confirming the message body and key headers weren’t altered in transit and that the message is authorized for your domain. DKIM is specified in RFC 6376 ↗.

You don’t generate DKIM keys by hand for a hosted provider — the provider does it for you. The setup flow is almost always:

1. In your mail provider’s admin panel, find the DKIM or “email authentication” section for your domain.
2. The provider gives you one or more DNS records to publish. These are usually CNAME records (pointing to keys the provider manages) or TXT records containing the public key directly.
3. You add those records at your DNS host exactly as shown.
4. You return to the provider’s panel and click “verify.” It checks that the records resolve.

The hostname for a DKIM record includes a “selector” — something like selector1._domainkey.yourdomain.com. The selector lets a provider rotate keys and run more than one in parallel. Use the exact selector your provider specifies.

If your provider gives you CNAME records, the advantage is that they can rotate the underlying keys without you touching DNS again. Prefer that approach when offered.

DMARC: The Policy That Ties It Together

DMARC is the record that makes SPF and DKIM enforceable. It tells receiving servers what to do with mail that fails authentication, and it requests reports so you can see who is sending mail using your domain. DMARC is defined in RFC 7489 ↗.

A DMARC record is a TXT record published at _dmarc.yourdomain.com. A starter record looks like this:

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

The important tags:

• p= — the policy. This is the core of DMARC and has three values:
  • p=none — monitor only. Don’t change how failing mail is handled, just send reports. Always start here.
  • p=quarantine — send failing mail to spam/junk.
  • p=reject — refuse failing mail outright. This is the end goal — it’s what actually stops spoofing.
• rua= — the address that should receive aggregate (daily summary) reports.

DMARC also relies on alignment: the domain that passes SPF or DKIM has to match the domain shown in the visible “From” header. This is what prevents an attacker from passing SPF for their domain while displaying your domain to the recipient.

Roll Out DMARC in Stages

Do not jump straight to p=reject. If your SPF or DKIM setup is incomplete, you’ll start silently blocking your own legitimate mail. The standard, safe progression:

1. p=none for a couple of weeks. Collect aggregate reports and confirm that all your legitimate sending sources are passing SPF or DKIM with alignment.
2. p=quarantine once the reports look clean. Optionally with pct= to apply the policy to a percentage of mail first (for example pct=25).
3. p=reject once quarantine has run cleanly. This is the protective end state.

The aggregate reports arrive as XML and are not pleasant to read by hand. Several free and paid DMARC reporting services parse them into a dashboard; using one makes the rollout dramatically easier to manage.

Putting It All in Order

Here’s the sequence that avoids breaking your mail flow:

1. Publish SPF with all your sending sources included. Start with ~all if you’re unsure you’ve caught everything, tighten to -all once confirmed.
2. Enable DKIM in your provider’s panel and publish the records it gives you. Verify.
3. Send test messages to an account at a major provider (Gmail, Outlook). Open the message, view “show original” or headers, and confirm SPF and DKIM both show “pass.”
4. Publish DMARC at p=none with a reporting address. Watch reports for a couple of weeks.
5. Move to p=quarantine, then p=reject once the reports confirm everything legitimate authenticates correctly.

Common Mistakes

• Two SPF records. Only one is allowed. Merge into a single record with multiple includes.
• Forgetting a sending source. Your CRM, support desk, invoicing tool, or newsletter platform all send “as you.” Each must be authorized in SPF and ideally DKIM-signed, or DMARC at p=reject will block them.
• Jumping to p=reject too early. This is the most common way people break their own mail. Stage it.
• Ignoring the reports. The whole point of p=none is to read the reports before you enforce. Skipping that step defeats the safety of the staged rollout.
• Exceeding the SPF 10-lookup limit. Audit your includes if you send through several services.

What You Get When This Is Done

Properly configured SPF, DKIM, and DMARC give you two things. First, better deliverability — major mailbox providers increasingly require authentication, and aligned, authenticated mail is far more likely to reach the inbox. Second, anti-spoofing protection: with DMARC at p=reject, a phisher can no longer send mail that displays your domain in the From field and expect it to be delivered.

If you’re setting up a custom domain on an encrypted provider, your provider’s interface will walk you through these same records — see our ProtonMail setup guide for the Proton-specific flow, or our Tuta setup guide for Tuta. The protocols are identical regardless of provider; only the exact include strings and DKIM selectors differ.