How to set up SPF, DKIM, and DMARC for email security

Every week, security teams field the same incident: a lookalike domain sends invoices to a customer's finance department, or an attacker spoofs your own domain to phish your employees. In most of these cases, the root cause isn't a compromised mail server — it's a DNS record that was never configured. If you want to set up SPF, DKIM, and DMARC correctly, you need more than three TXT records; you need a rollout sequence that avoids breaking legitimate mail while you close the door on forgery.

This is a complete email authentication setup guide you can follow end to end: publishing SPF, generating and rotating DKIM keys, phasing in a DMARC policy from monitoring to enforcement, and verifying that everything actually works before you flip the switch on rejection. By the end, you'll have a domain that's measurably harder to spoof and a monitoring pipeline that tells you when something's wrong before your customers do.

Step 1: Inventory Every System That Sends Mail On Your Behalf

Before you touch DNS, build a complete list of everything that sends email using your domain — your primary mail provider (Google Workspace, Microsoft 365), transactional email services (SendGrid, Postmark, SES), marketing platforms (HubSpot, Mailchimp), and any internal scripts or CRM tools that send from @yourdomain.com. This step gets skipped constantly, and it's the single biggest cause of SPF and DMARC rollouts breaking production mail.

Check application configs, billing records for email vendors, and ask every team (sales, support, marketing, engineering) what sends mail. Missing even one sender means their mail will fail authentication once you enforce a strict policy.

Step 2: Publish an SPF Record

SPF (Sender Policy Framework) tells receiving mail servers which IP addresses and services are authorized to send mail for your domain. Add a single TXT record at your domain's root:

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

A few rules that matter in practice:

• You can only have one SPF record per domain. If you already have one, add new include: mechanisms to it rather than creating a second record — a second v=spf1 TXT record invalidates SPF entirely.
• SPF allows a maximum of 10 DNS lookups. Each include:, a, mx, ptr, and exists mechanism counts. Exceeding this returns a permerror, and most receivers will treat that as a fail. Flatten includes or trim unused ones if you're close to the limit.
• End with ~all (soft fail) while testing, and move to -all (hard fail) once you've confirmed every legitimate sender is accounted for.

Verify the record propagated with:

dig TXT yourdomain.com +short

Step 3: Configure DKIM Signing for Every Sending Service

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to outgoing mail, letting receivers verify the message wasn't altered in transit and genuinely originated from a server you authorized. Unlike SPF, DKIM is configured per sending service, and each one generates its own key pair.

For most providers, you enable DKIM in their admin console and they hand you a CNAME or TXT record to publish. For example, a typical DKIM TXT record looks like this:

selector1._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

If you're signing mail yourself (e.g., via Postfix with OpenDKIM), generate a key pair first:

opendkim-genkey -b 2048 -d yourdomain.com -s selector1

This produces selector1.private (keep this on the mail server, never in DNS) and selector1.txt (publish the public key portion in DNS exactly as generated).

Repeat this for every sending service from your Step 1 inventory — Google Workspace, your transactional provider, your marketing platform. Use a distinct selector per service (google._domainkey, sendgrid._domainkey, and so on) so you can rotate or revoke one without affecting the others. Rotate DKIM keys at least annually, or immediately if a signing key may have been exposed.

Step 4: Set Up DMARC in Monitoring Mode

This is the step most guides rush, and it's the one most likely to cause an outage if you skip it. DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together and tells receivers what to do when a message fails both. Start in report-only mode so you can see what's happening before you enforce anything:

_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; pct=100; fo=1"

Key tags explained:

• p=none — take no action on failing mail; just collect reports. This is the correct starting point for any dmarc policy configuration.
• rua — where aggregate (daily/weekly) reports get sent. These are XML files summarizing pass/fail counts by source.
• ruf — where forensic reports (individual failing message samples) get sent, if the receiver supports them.
• pct — percentage of mail the policy applies to; leave at 100 during monitoring.

Let this run for at least two to three weeks. Aggregate reports arrive daily from major receivers (Google, Microsoft, Yahoo) and will surface every sending source you missed in Step 1.

Step 5: Read the Reports and Fix Alignment Gaps

DMARC aggregate reports are XML and not pleasant to read by hand — use a parser (many are free and open source, or your provider may offer a dashboard) to turn them into a readable table of source IP, sending volume, and SPF/DKIM pass/fail status.

Two failure modes show up constantly at this stage:

1. Alignment failures: SPF or DKIM technically passes, but the domain in the From: header doesn't match the domain authenticated by SPF or DKIM closely enough (DMARC requires either exact or organizational-domain alignment, depending on the aspf/adkim tags). This is common when a vendor sends "on behalf of" your domain using their own return-path.
2. Missing senders: a source shows up sending real mail with no SPF or DKIM coverage at all — usually a forgotten internal tool or a legacy system nobody remembered.

Fix each gap by adding the sender to SPF, enabling DKIM for it, or adjusting alignment mode, then keep monitoring until reports show consistent full authentication across all legitimate sources.

Step 6: Move to Enforcement Gradually

Once reports are clean, tighten the policy in stages rather than jumping straight to full rejection:

_dmarc.yourdomain.com TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com"

Increase pct over successive weeks (25 → 50 → 100) while watching reports for new failures, then move from p=quarantine to p=reject:

_dmarc.yourdomain.com TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@yourdomain.com; adkim=s; aspf=s"

p=reject is what actually stops spoofed mail from reaching inboxes — this is the step that matters most to prevent email spoofing of your domain, since receivers will drop forged messages outright instead of delivering them to a junk folder where a target might still open them.

How to Verify You Set Up SPF, DKIM, and DMARC Correctly

Before and after each change, confirm your records resolve and validate correctly:

dig TXT yourdomain.com +short
dig TXT selector1._domainkey.yourdomain.com +short
dig TXT _dmarc.yourdomain.com +short

Send a test message to a mail-tester or similar authentication-checking address and review the resulting report — it will show pass/fail status for SPF, DKIM, and DMARC individually, plus alignment results.

Common issues and fixes:

• SPF permerror from too many lookups: count include, a, mx, ptr, and exists mechanisms; consolidate or remove unused vendor includes.
• DKIM fails despite a correct-looking record: check for line-wrapping or truncation in the TXT record — long RSA keys often get split incorrectly by DNS management UIs, and any broken character sequence invalidates the signature.
• DMARC reports show a legitimate source failing: check alignment mode first; a service sending "as" you but authenticating under its own domain needs relaxed alignment (aspf=r) or its own DKIM signing.
• No aggregate reports arriving: some inbox providers only send reports for lower-volume domains after a delay, or don't support ruf at all — treat missing forensic reports as normal and rely on aggregate data.
• Mail suddenly rejected after moving to p=reject: roll back to p=quarantine; pct=<lower value> immediately, identify the failing source from reports, fix its authentication, then resume the rollout.

How Safeguard Helps

Getting SPF, DKIM, and DMARC right is a DNS and mail-configuration exercise, but the underlying risk — a spoofable domain — is a supply chain security problem. Attackers who impersonate your domain are exploiting the same trust relationships your customers and partners extend to your legitimate infrastructure, vendors, and build pipelines.

Safeguard helps security and platform teams keep visibility over exactly this kind of drift across their environment: which domains, subdomains, and third-party senders are tied to your organization, whether authentication controls are actually enforced (not just configured once and forgotten), and where new or shadow senders appear that were never part of your original inventory. Instead of discovering a misconfigured or abandoned sending source from a phishing complaint, teams using Safeguard get continuous monitoring that flags authentication gaps and configuration drift as part of their broader software supply chain security posture — the same discipline applied to dependencies, build systems, and third-party integrations, extended to the infrastructure that sends mail on your behalf.

If you're rolling out DMARC enforcement across a large organization with many sending domains and subdomains, that continuous visibility is what turns a one-time setup project into a durable security control.