SPF + DKIM + DMARC — the bootstrap for startups

Your boss asked you to “secure the company email.” A lawyer mentioned DMARC. A compliance checkbox wants proof. This guide cuts straight to what to do.

Time estimate: 30-60 minutes if you have DNS access and all email providers documented. Longer if you need to audit services from scratch.

Prerequisites:

• Access to your DNS provider (Cloudflare, AWS Route 53, etc.)
• Login credentials for every email service your company uses
• List of all email senders (see Step 1)

What the three records actually do

SPF (Sender Policy Framework) lists which mail servers are allowed to send email for your domain. It’s a DNS TXT record. If a message arrives from a server not on that list, receiving servers can treat it as suspicious.

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to outgoing messages. The receiving server checks that signature against a public key you publish in DNS. Forgery is detectable.

DMARC (Domain-based Message Authentication, Reporting & Conformance) is the policy layer. It tells receivers what to do when SPF or DKIM fail — ignore, quarantine, or reject — and where to send aggregate reports so you can see what’s happening.

Without all three, your domain is easy to spoof in phishing attacks.

Step 1 — Audit who actually sends email for your domain

Before touching DNS, list every service that sends email from your domain:

• Google Workspace / Microsoft 365 (transactional, internal)
• SendGrid / Amazon SES / Postmark (product emails)
• Mailchimp / Brevo / Klaviyo (marketing campaigns)
• Any third-party CRM or helpdesk that sends notifications

Each one needs to be authorized in SPF and should sign messages with DKIM. Miss one and you’ll see failures in your DMARC reports.

Step 2 — Publish an SPF record

SPF lives at the root of your domain as a TXT record. A typical record for a company using Google Workspace and SendGrid:

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

• include: authorizes the third-party sender’s IP ranges
• ~all means “soft fail” — treat unauthorized senders as suspicious but don’t hard reject yet

Validation: After adding your SPF record, verify it with:

dig TXT yourdomain.com +short | grep "v=spf1"

SPF limit: you can have at most 10 DNS lookups in one SPF record. If you use many senders, look into SPF flattening. DMARC Guardian’s hosted SPF feature handles this automatically.

Step 3 — Enable DKIM for each sender

Every email platform has a DKIM setup section. The process is always the same:

1. Generate a key pair in the platform’s settings
2. Publish the public key as a DNS TXT record at a selector subdomain (for example google._domainkey.yourdomain.com)
3. Verify in the platform dashboard

Validation: After adding each DKIM record, verify it with:

dig TXT selector._domainkey.yourdomain.com +short

Check Google Workspace, SendGrid, Postmark, and any other active sender. Skipping even one means DMARC failures for messages from that sender.

Step 4 — Start with a monitoring-only DMARC policy

Add this TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=1

• p=none — monitoring mode, no enforcement yet. Email still delivers.
• rua — where aggregate reports go (daily XML files from every major mail provider)
• ruf — forensic reports for individual failures (optional, privacy-sensitive)
• fo=1 — send forensic reports on any failure

Validation: After adding DMARC, verify it with:

dig TXT _dmarc.yourdomain.com +short

Do not jump to p=reject yet. You need to see what your legitimate senders are doing first. Give it two to four weeks of reports before tightening policy.

Step 5 — Read your reports without going blind

Raw DMARC reports are XML. Nobody reads XML. DMARC Guardian parses them automatically and shows you:

• Which senders pass and which fail
• Source IPs sending on behalf of your domain (including unauthorized ones)
• Daily volume and trend by sender

Once all legitimate senders pass, move the policy to p=quarantine, then eventually p=reject. DMARC Guardian alerts you if anything breaks after you tighten.

The reality check

The 30-minute estimate is optimistic if your senders are already on one or two platforms. It takes longer if you have many services or if DKIM is not yet available from older SaaS tools. Plan for 60 minutes to be safe.

After initial setup, the monitoring phase takes 2–4 weeks at p=none before you can safely move to enforcement.

What to watch in the first month

Open your DMARC Guardian dashboard weekly. Look for:

• Unknown senders — IPs you don’t recognize sending as your domain (potential spoofing or forgotten SaaS integration)
• Alignment failures — a service sends DKIM-signed mail but the signing domain doesn’t match your domain
• Volume drops — a sudden dip in authenticated traffic can mean a sender broke its DKIM config

Once the dashboard shows green for all your known senders, you’re ready to move to enforcement.

Start your 90-day free trial — no credit card required. Import your first domain in under two minutes.