Complete Email Security Setup: SPF, DKIM, DMARC, and BIMI in One Guide

Email authentication is the foundation of modern email security. Without it, anyone can send emails pretending to be from your domain, your legitimate emails may land in spam, and your brand is vulnerable to phishing campaigns that use your name. The full authentication stack — SPF, DKIM, DMARC, and BIMI — works together to prove that email claiming to be from you is actually from you.

This guide walks through setting up each layer in order, with the tools and verification steps you need to confirm each one is working before moving to the next.

Why This Matters More Than Ever: Google and Yahoo 2024 Requirements

In February 2024, Google and Yahoo began enforcing stricter requirements for bulk email senders (anyone sending more than 5,000 emails per day to Gmail or Yahoo accounts):

SPF or DKIM authentication is required — emails without either will be rejected
DMARC with at least p=none is required for domains sending bulk email
A one-click unsubscribe header is required for marketing email
Spam complaint rates must stay below 0.1%

Even if you are not a bulk sender, these requirements signal the industry direction. Gmail and Yahoo now visibly flag emails from domains without proper authentication. Getting the stack right is a prerequisite for reliable inbox delivery.

Step 1: SPF (Sender Policy Framework)

SPF tells the world which IP addresses and services are authorized to send email from your domain. It works by publishing a TXT record in DNS.

Audit Your Sending Sources First

Before writing an SPF record, list every service that sends email using your domain in the From: or Return-Path: header:

Your primary mail server (Google Workspace, Microsoft 365, Zoho, etc.)
Transactional email provider (SendGrid, Postmark, Amazon SES, Mailgun)
Marketing email platform (Mailchimp, HubSpot, Klaviyo, Brevo)
CRM notifications (Salesforce, HubSpot CRM)
Support desk emails (Zendesk, Freshdesk, Intercom)
HR systems (Workday, Gusto, BambooHR)
Monitoring and alerting tools
Internal applications that send email

Construct Your SPF Record

v=spf1 [mechanisms] [all qualifier]

Common mechanisms:

ip4:203.0.113.0/24 — authorize a specific IP range
ip6:2001:db8::/32 — authorize an IPv6 range
include:_spf.google.com — authorize all IPs in Google's SPF record
a — authorize the domain's A record IP(s)
mx — authorize the domain's MX record IP(s)

Example for Google Workspace + SendGrid + Amazon SES:

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

Keep the total DNS lookup count (from include:, a:, mx: mechanisms) under 10. Use ip4: and ip6: for known static IPs since they do not count toward the limit.

Publish the SPF Record

Add a TXT record to your DNS:

Name: @ (or your domain)
Type: TXT
Value: v=spf1 include:_spf.google.com include:sendgrid.net -all
TTL: 3600

You can have only one SPF record per domain. If you already have one, edit it rather than adding a second.

Verify SPF

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

Or use MXToolbox's SPF checker at mxtoolbox.com/spf.aspx. Look for green results and ensure the lookup count stays under 10.

Send a test email and check the Authentication-Results header:

spf=pass (google.com: domain of you@yourdomain.com designates 198.51.100.1 as permitted sender)

Step 2: DKIM (DomainKeys Identified Mail)

DKIM attaches a cryptographic signature to outgoing emails. The receiving server verifies the signature using a public key published in your DNS. Unlike SPF, DKIM survives email forwarding because the signature is part of the message itself.

Generate DKIM Keys

Most mail providers generate DKIM keys for you. The setup process varies by provider:

Google Workspace: Admin Console → Apps → Google Workspace → Gmail → Authenticate Email → Generate new record. Google generates a 2048-bit key and shows you the DNS record to publish.

Microsoft 365: Security & Compliance Center → Threat management → Policy → Anti-spam → DKIM. Enable DKIM for your domain and copy the CNAME records Microsoft provides.

SendGrid: Settings → Sender Authentication → Domain Authentication. Follow the wizard and publish the two CNAME records SendGrid provides.

Postmark: Settings → Sender Signatures → your domain → DKIM. Postmark shows you the TXT record to publish.

Amazon SES: Verified identities → your domain → DKIM → Enable. SES provides three CNAME records for DNS.

Publish the DKIM DNS Record

The DNS record looks like this (example for Google Workspace):

Name: google._domainkey.yourdomain.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0B...
TTL: 3600

The selector (google in the example above) is chosen by the sending service. You can have multiple DKIM records with different selectors — one per service.

Verify DKIM

dig TXT google._domainkey.yourdomain.com

Send a test email and check headers for:

dkim=pass header.i=@yourdomain.com header.s=google header.b=ABcDef12

The d= value in the DKIM signature must match your From: domain for DMARC alignment (this is called "aligned DKIM").

Step 3: DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC builds on SPF and DKIM by specifying what should happen when messages fail authentication, and instructing receiving servers to send reports back to you.

Start with p=none

Publish a monitoring-only record first:

Name: _dmarc.yourdomain.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=1
TTL: 3600

rua — where to send daily aggregate XML reports
ruf — where to send forensic failure reports (not all providers send these)
fo=1 — generate forensic reports on SPF or DKIM failure (not just both failing)

Analyze Reports Before Enforcing

Aggregate reports arrive as gzipped XML. Use a free DMARC analyzer tool (Postmark DMARC Digests, EasyDMARC, or Dmarcian) to visualize them. You are looking for:

All known sending IPs showing spf=pass or dkim=pass with alignment
Unknown IPs — investigate and either authorize them or confirm they are attackers spoofing your domain
The disposition field — under p=none this always shows none, meaning no enforcement is happening

Wait until all legitimate senders show aligned passes for at least two weeks before proceeding.

Move to p=quarantine with pct rollout

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@yourdomain.com

Increment pct over several weeks: 10%, 25%, 50%, 100%.

Advance to p=reject

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; sp=reject

The sp=reject extends enforcement to all subdomains that do not have their own DMARC records.

Verify DMARC

dig TXT _dmarc.yourdomain.com

Check Google's Postmaster Tools (postmaster.google.com) — it provides DMARC compliance rates for email delivered to Gmail, which gives you a real-world view of authentication performance.

Step 4: BIMI (Brand Indicators for Message Identification)

BIMI is the newest layer of the email authentication stack. It allows you to display your brand logo next to your emails in supporting mail clients — currently Gmail, Yahoo, Apple Mail, and Fastmail.

BIMI requires:

DMARC enforcement at p=quarantine or p=reject
A Verified Mark Certificate (VMC) for Gmail logo display (Apple Mail does not require a VMC)
Your logo in SVG Tiny PS format
An SVG file hosted at a stable HTTPS URL

VMC Requirements

A Verified Mark Certificate is a special type of digital certificate that proves your organization owns the trademark on the logo. VMCs are issued by Entrust or DigiCert. The process involves trademark verification and typically takes 1-4 weeks.

For domains that do not want to pay for a VMC yet, Apple Mail (and some other clients) will show your logo without a VMC if you just publish the BIMI record. Gmail requires a VMC.

Prepare Your SVG Logo

BIMI requires SVG Tiny PS (Portable/Secure) format, which is a restricted subset of SVG. Restrictions include:

No external references (no <image> tags pointing to external URLs)
No scripts
Must include a title element
Must have a square aspect ratio
Must have a background — transparent SVGs are not supported

Convert your logo using an online tool or Adobe Illustrator. Validate it at the SVG Tiny PS validator.

Publish the BIMI Record

Host your SVG at a stable HTTPS URL, for example https://yourdomain.com/bimi/logo.svg.

Name: default._bimi.yourdomain.com
Type: TXT
Value: v=BIMI1; l=https://yourdomain.com/bimi/logo.svg; a=https://yourdomain.com/bimi/certificate.pem
TTL: 3600

l= — URL of the SVG logo
a= — URL of the VMC certificate (leave out if not using a VMC; required for Gmail)

Verify BIMI

Send a test email from a DMARC-authenticated source to a Gmail account. Within 24-72 hours of BIMI record propagation, your logo should appear in Gmail's inbox view.

Use BIMI Group's BIMI Inspector (bimigroup.org/bimi-generator) to validate your BIMI record and SVG before publishing.

Common Mistakes and How to Avoid Them

Publishing Multiple SPF Records

Adding a second v=spf1 record instead of merging with the existing one causes permerror. Always check for existing SPF records before publishing:

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

Using ~all Instead of -all

~all (softfail) is appropriate during initial SPF setup, but once you have DMARC enforcement in place, use -all (hardfail). DMARC's enforcement policy is what actually blocks failing mail, but -all provides an additional signal.

Forgetting DKIM for All Sending Services

It is easy to configure DKIM for your primary mail provider and forget about your ESP or marketing tool. Check DMARC aggregate reports — any source showing dkim=fail that you recognize as a legitimate sender needs DKIM configured.

Skipping the Monitoring Phase

Jumping from p=none to p=reject without a monitoring period is how organizations break their email. Spend at least two weeks at each policy level reviewing aggregate reports.

BIMI Without VMC on Gmail

Publishing a BIMI record without a VMC will show your logo in Apple Mail but not Gmail. This is not an error — it just means the feature will not work on Gmail until you obtain a VMC.

Testing Tools Reference

Tool	What It Tests
mxtoolbox.com/spf.aspx	SPF record validity and lookup count
mxtoolbox.com/dkim.aspx	DKIM record lookup and validation
mxtoolbox.com/dmarc.aspx	DMARC record validation
mail-tester.com	Full authentication stack on a real email
Google Admin Toolbox Check MX	Google-specific authentication analysis
BIMI Group Inspector	BIMI record and SVG validation
Google Postmaster Tools	Real-world Gmail delivery statistics
EasyDMARC / Dmarcian	DMARC aggregate report visualization

Maintenance Schedule

Email authentication is not a one-time setup. Schedule these regular tasks:

Weekly — Review DMARC aggregate report summaries for new unknown sources
Monthly — Verify SPF lookup count has not increased due to new services
Quarterly — Audit all services in SPF record against currently used email tools; remove obsolete entries
When adding a new email service — Configure DKIM before the service goes live; update SPF
Annually — Rotate DKIM keys as a security hygiene measure

Getting the full stack in place — SPF, DKIM, DMARC at p=reject, and BIMI — takes time but provides the strongest available protection against domain spoofing and significantly improves email deliverability.