Superkabe LogoSuperkabe
TL;DR

Configure SPF, DKIM, and DMARC for every sending domain: SPF authorizes your sending sources (include Google / Microsoft / custom SMTP as appropriate), DKIM signs outbound messages (rotate keys periodically), and DMARC aligns the two with an enforcement policy (start at p=none, graduate to p=quarantine).

DNS Setup Guide

How to configure SPF, DKIM, DMARC and MX records for your sending domains.

Quick Answer

Every sending domain needs four DNS records to pass authentication and stay deliverable: SPF (authorizes which servers can send), DKIM (signs emails cryptographically), DMARC (tells receivers what to do with unauthenticated mail), and MX (lets your domain receive replies, bounces and unsubscribes). Superkabe checks all four during infrastructure assessment and flags any that are missing or misconfigured. The DNS Authentication card on each domain's detail page also includes a Check now button that runs the same checks on demand.

Use our free tools: SPF Lookup | DKIM Lookup | DMARC Lookup

Where do these records live?

All four records are configured at your DNS provider (the place you registered or manage your domain — GoDaddy, Cloudflare, Namecheap, Route 53, etc.) — not at Superkabe and not at any sequencing/sending tool.

What goes inside each record depends on which mailbox provider you use to actually send the email (Google Workspace, Microsoft 365, or a custom SMTP provider). The examples below cover the common providers; pick the one that matches your setup.

1. SPF (Sender Policy Framework)

SPF tells receiving mail servers which IP addresses and services are authorized to send email on behalf of your domain. Missing or misconfigured SPF is one of the most common reasons cold email lands in spam.

Where to add it

  1. Open your DNS provider's admin panel for the sending domain (the domain in your From: address).
  2. Add a TXT record for the root domain (host @ or your bare domain — e.g. yourdomain.com). There must be exactly one SPF record per domain.
  3. Set the value to whichever record matches your sending infrastructure (see below). End with ~all while warming up and only move to -all once your authentication is fully stable across all sources.
  4. Save the record and verify with the SPF Lookup tool or the Check now button on the domain detail page.

Google Workspace

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

Use this when your sending mailboxes are Google Workspace accounts (the most common Superkabe setup).

Microsoft 365 / Outlook

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

Use this when your sending mailboxes are Microsoft 365 / Outlook accounts.

Custom SMTP / dedicated IPs

v=spf1 ip4:<your.smtp.ip> ~all

Use this when you connect mailboxes via raw SMTP credentials and own the sending IP (or a small pool of IPs).

Multiple sources

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

Combine includes when more than one infrastructure sends from this domain. Stay under 10 DNS lookups total (each include: counts as one).

Common Mistakes

  • Multiple SPF records — only one TXT record starting with v=spf1 is allowed per domain. If you need multiple senders, merge them into a single record using extra include: mechanisms.
  • Too many DNS lookups — SPF allows a maximum of 10 DNS lookups during evaluation. Each include: counts. Use ip4: for static IPs to save lookups.
  • Using -all too early — a hard-fail can cause legitimate emails to be rejected during warmup or while a new sender is added. Stick with ~all until your authentication is stable across every source.

2. DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to every outgoing email, proving the message was authorised by your domain and hasn't been modified in transit. Receivers use this signature to verify legitimacy.

How to set it up

  1. Generate the DKIM key pair at your mailbox provider:
    • Google Workspace: Admin Console → Apps → Google Workspace → Gmail → Authenticate Email. Select the domain and click Generate new record.
    • Microsoft 365: Defender Portal → Email & collaboration → Policies → DKIM. Enable DKIM signing for your domain and copy the two CNAME records that appear.
    • Custom SMTP / dedicated infrastructure: generate a 2048-bit RSA key pair (openssl genrsa) and publish the public key as a TXT record at the selector subdomain.
  2. Add the TXT (or CNAME) record at your DNS provider with the selector as a subdomain — e.g. google._domainkey.yourdomain.com for Google, selector1._domainkey.yourdomain.com for Microsoft 365.
  3. Wait 10–30 minutes for DNS to propagate, then go back to your mailbox provider and click the Activate / Start authentication button.
  4. Verify using the DKIM Lookup tool with your selector. Superkabe's assessment also probes the common selectors (default, google, selector1, selector2) during the periodic sweep.

Common Mistakes

  • Wrong selector name — the selector you publish must match exactly what the mailbox provider uses to sign outgoing mail. Copy the exact name from the provider's setup screen.
  • Forgot to activate — Google Workspace and Microsoft 365 both require an explicit Activate click after the DNS record is published. Until then, signed mail will fail DKIM.
  • Single record split across lines — some DNS providers wrap long TXT values. Make sure the value renders as one contiguous string after publication.

3. DMARC (Domain-based Message Authentication)

DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication fails. It also enables aggregate reporting so you can see who is sending mail as your domain.

Recommended record for cold email

Add a TXT record at _dmarc.yourdomain.com with this value:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100
  • p=none — monitoring only. Recommended for new domains. Move to p=quarantine after 30 days of clean reports and to p=reject once you're fully confident in your authentication.
  • rua= — email address to receive aggregate reports. Use a dedicated address or sign up for a DMARC reporting service like Postmark, dmarcian, or Easydmarc.
  • pct=100 — apply the policy to 100% of messages.

Superkabe scores DMARC passing for p=quarantine or p=reject, and weak for p=none — the latter is monitoring only and doesn't actually protect against spoofing. A missing DMARC record scores as failing.

4. MX (Mail Exchange)

MX records tell the rest of the internet where to deliver mail addressed to your domain. For sending domains, MX is what allows replies, bounce notifications and unsubscribe responses to reach you. A domain with no MX records can send mail but cannot receive any — which means you lose visibility into bounces and replies entirely.

How to set it up

  1. Find your mailbox provider's MX records. Each provider publishes them publicly:
    • Google Workspace: a single record smtp.google.com at priority 1 (modern setup), or the legacy 5-record set aspmx.l.google.com + four ALT records.
    • Microsoft 365: <tenant>-com.mail.protection.outlook.com at priority 0. Find the exact value in Microsoft 365 Admin → Domains.
    • Custom mail host: use whatever MX value your host provides (e.g. mx1.your-host.com at priority 10).
  2. Add the MX record(s) at your DNS provider for the root domain. Each record needs a priority (lower = preferred) and an exchange hostname.
  3. Verify with the Check now button on the domain's detail page. Superkabe will list every published MX record with its priority directly in the DNS Authentication card.

Common Mistakes

  • No MX records at all — common for "sending-only" domains where the user assumed they didn't need to receive. Replies, bounces and unsubscribes will silently disappear, breaking the entire feedback loop Superkabe relies on for healing.
  • Wrong priority order — receiving mail servers try the lowest priority first, then fall back. If you publish a placeholder MX at priority 1 and your real provider at priority 10, mail will be lost.
  • Mixing providers — don't mix MX hosts from Google Workspace and Microsoft 365 on the same domain. Pick one and route everything to it.

What Superkabe Checks

During the periodic infrastructure assessment (and whenever you click Check now on a domain's detail page), Superkabe verifies all four records:

CheckPass criteriaImpact if missing
SPFValid v=spf1 TXT record with ≤10 lookups.Emails may land in spam or be rejected outright.
DKIMValid public key at any common selector (default, google, selector1, selector2).Emails can be spoofed; reputation damage compounds over time.
DMARCValid v=DMARC1 TXT record at _dmarc. subdomain. p=quarantine or p=reject passes; p=none warns.No policy enforcement; phishing and spoofing protections off.
MXAt least one MX record published at the root domain.Domain can't receive replies, bounces or unsubscribes — breaks the feedback loop Superkabe needs to heal mailboxes.

Related Help Articles

→ How is the Infrastructure Score Calculated?→ Understanding Status Labels→ Free SPF, DKIM, DMARC Lookup Tools

Frequently Asked Questions

Why does SPF fail after I add a new sending source?

+

SPF has a 10-DNS-lookup limit. Adding a new `include:` often pushes you over. Fix by flattening includes using a subdomain delegation or SPF flattening service, not by removing legitimate senders.

What's the right DMARC policy for cold outreach?

+

Start at p=none with rua= reports pointed at a DMARC aggregator. After confirming alignment is clean for 2–4 weeks, graduate to p=quarantine. Most cold email teams do not need p=reject.