How to Set Up SPF, DKIM, and DMARC: A 10-Minute Guide

Why Your Email Lands in Spam — and How to Fix It Permanently

If your business emails are landing in spam folders, or if someone else is sending emails that appear to come from your domain, the cause is almost always the same: missing or misconfigured SPF, DKIM, and DMARC records. These three DNS-based email authentication standards work together to prove that mail claiming to come from your domain actually came from your servers, and to tell receiving mail servers what to do when that proof fails.

The good news is that setting them up requires no special software. You need access to your domain's DNS records and about ten minutes. This guide walks through each record in order, explains what it does at a technical level, and gives you the exact syntax to use for Google Workspace, Microsoft 365, and generic SMTP servers.

How Email Authentication Works: The Problem These Standards Solve

SMTP — the protocol email runs on — was designed in 1982 with no built-in sender authentication. Any mail server anywhere in the world can send an email with a From: header claiming to be ceo@yourcompany.com. This is why phishing and business email compromise (BEC) attacks are so effective: the email genuinely appears to come from a trusted domain.

SPF, DKIM, and DMARC solve this by attaching verifiable claims to DNS — a global, cryptographically delegated naming system that only authorized domain owners can update. Receiving mail servers check these DNS records before accepting mail, and DMARC provides a policy that governs what to do when checks fail.

Step 1: SPF — Authorize Your Sending Servers

Sender Policy Framework (SPF) is a DNS TXT record that lists the IP addresses and mail services authorized to send email on behalf of your domain. When a receiving mail server gets a message claiming to be from your domain, it checks your SPF record and compares the sending server's IP against your authorized list. If the IP is not listed, the message fails SPF.

To create your SPF record, log into your DNS provider (GoDaddy, Namecheap, Cloudflare, Route 53, etc.) and add a TXT record to your root domain (@ or yourdomain.com).

The value depends on which email platform you use:

• Google Workspace: v=spf1 include:_spf.google.com ~all
• Microsoft 365: v=spf1 include:spf.protection.outlook.com ~all
• Generic SMTP server by IP: v=spf1 ip4:203.0.113.10 ~all
• Multiple services: v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

Critical rules for SPF:

1. You can only have one SPF TXT record per domain. If you add a second, both records will be ignored. Combine all includes into a single TXT record.
2. The ~all vs -all choice matters. ~all (softfail) marks unauthenticated mail as suspicious. -all (hardfail) instructs receiving servers to reject it. Start with ~all until you have verified all your legitimate sending sources.
3. SPF has a 10-DNS-lookup limit. Each include: mechanism can trigger recursive lookups. If your record exceeds 10 total lookups, it fails with a permanent error. Flatten your SPF record if you hit this limit.

Step 2: DKIM — Sign Your Outgoing Mail

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to every outgoing email. The signature is generated using a private key held by your mail server and can be verified by any receiver using the corresponding public key published in your DNS. This proves that the message content has not been altered in transit and that the signing domain authorized the message.

DKIM requires generating a key pair. Most hosted email platforms do this for you:

• Google Workspace: In the Admin Console, go to Apps > Google Workspace > Gmail > Authenticate email. Select your domain and click Generate New Record. Google will show you a TXT record to add to DNS, typically with a host name like google._domainkey.yourdomain.com. After adding the record, click Start Authentication.
• Microsoft 365: In the Microsoft 365 Defender portal, go to Email & Collaboration > Policies & Rules > Threat Policies > Email Authentication Settings > DKIM. Select your domain and enable DKIM signing. Microsoft will provide two CNAME records to add to DNS.
• Self-hosted mail server (Postfix/Exim with OpenDKIM): Generate keys with opendkim-genkey -t -s mail -d yourdomain.com. This produces a private key file and a TXT record file. Publish the TXT record at mail._domainkey.yourdomain.com.

A DKIM public key DNS record looks like this:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB...

The selector (the part before ._domainkey) identifies which key was used for a given signature. You can have multiple active selectors simultaneously, which is useful during key rotation.

Step 3: DMARC — Set Your Policy and Get Reports

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is the policy layer. It tells receiving mail servers what to do when SPF or DKIM checks fail, and it enables reporting so you can see who is sending mail using your domain.

DMARC alignment requires that either the SPF check passes and the domain in the Mail From address aligns with the From: header domain, or the DKIM signature passes and the signing domain aligns with the From: header domain.

Add a TXT record at the host _dmarc.yourdomain.com. Start with a monitoring-only policy:

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

Key DMARC tag reference:

• p=none — Monitor only, take no action on failing messages. Use this during the initial deployment phase.
• p=quarantine — Route failing messages to the spam/junk folder.
• p=reject — Refuse delivery of failing messages entirely. This is the target state for most domains.
• rua= — Aggregate report destination. Receiving servers send daily aggregate reports to this address, summarizing all mail that claimed to be from your domain.
• ruf= — Forensic/failure report destination. Individual failure reports for each failing message. These can be high volume on large domains.
• pct= — Percentage of mail to apply the policy to. Useful for gradual rollout: start with pct=10 before moving to pct=100.

Progressing to Reject: The Deployment Timeline

The typical deployment sequence over four to eight weeks:

1. Week 1: Deploy SPF, DKIM, and p=none DMARC. Set up a DMARC report parser (free services like dmarcian, Postmark DMARC, or Google Postmaster Tools display aggregate reports in readable form).
2. Weeks 2–3: Review aggregate reports. Identify any legitimate mail sources not covered by your SPF record. Add missing sources. Confirm DKIM is signing correctly for all sending services.
3. Week 4: Change to p=quarantine; pct=10. Monitor bounce reports and user complaints. Increase pct gradually to 100%.
4. Week 6–8: Change to p=reject; pct=100. This is your final hardened state.

Comparison: SPF vs. DKIM vs. DMARC

Common Misconceptions

Misconception 1: 'Setting SPF is enough to prevent spoofing'

SPF validates the envelope sender — the address used in SMTP session communication, not the From: header that email clients display. A phisher can pass SPF by sending from their own domain in the envelope while spoofing your domain in the visible From: header. DMARC's alignment requirement closes this gap by requiring that the domain in the visible From: header matches the authenticated envelope or DKIM domain.

Misconception 2: 'I can have multiple SPF TXT records'

Only one SPF TXT record is valid per domain per the SPF specification. If you have two TXT records that both start with v=spf1, mail servers encountering both records are required to return a permanent error (PermError), which means all your outgoing mail may fail SPF validation entirely. Combine all mechanisms into a single record.

Misconception 3: 'DMARC p=reject means my employees can't send email anymore'

DMARC only rejects mail that fails authentication checks. If your employees send mail through Google Workspace or Microsoft 365 and you have correctly configured SPF and DKIM for those services, their mail will pass authentication and be delivered normally. Rejection only affects mail that cannot be authenticated — which is exactly the spoofed or unauthorized mail you want to reject.

Misconception 4: 'DMARC reports are only for security teams'

DMARC aggregate reports reveal every mail stream using your domain — including third-party marketing tools, CRM systems, and transactional email services that your marketing team set up without telling IT. These reports are often the first time an organization discovers shadow IT mail services sending under the corporate domain without proper authentication.

Pro Tips

• Use a free DMARC report parser from day one. Raw DMARC XML reports are difficult to read manually. Services like Google Postmaster Tools, Postmark DMARC, or dmarcian parse these into readable dashboards that show which sources are sending on your behalf and whether they are passing or failing.
• Rotate DKIM keys annually. Long-lived keys are a risk if a key is compromised. Most hosted email platforms provide a key rotation workflow that keeps the old selector active during the transition period so in-flight messages are not invalidated.
• Create a separate email address for DMARC reports rather than using your main inbox. Aggregate reports from all receiving mail servers worldwide can amount to significant volume on domains with high traffic.
• Check your SPF record lookup count using an online SPF validator before publishing. If you exceed 10 DNS lookups, the record will fail with a PermError. Flattening SPF — replacing include: mechanisms with the literal IP ranges they resolve to — is the fix, though it requires updating when those third-party IP ranges change.
• After reaching p=reject, consider implementing BIMI. Brand Indicators for Message Identification (BIMI) is an emerging standard that displays your company logo in email clients for messages from properly authenticated domains with a p=quarantine or p=reject DMARC policy. It requires a valid DMARC policy as a prerequisite.
• Document every authorized mail sender in your SPF record and maintain that documentation as an internal asset. When you add a new marketing automation tool or transactional email service, check whether it requires an SPF include and add it before sending begins.

Run a full email authentication health check on your domain