SPF, DKIM, and DMARC: How to Set Up Email Authentication (Step-by-Step)

If someone can send emails that look like they come from your domain — your company name, your email address, your brand — without you knowing, you have a serious problem. Email spoofing is one of the oldest tricks in the attacker's playbook, and it is still devastatingly effective. Fraudsters impersonate CEOs to redirect wire transfers. Scammers spoof vendor emails to trick accounts payable teams. Phishing campaigns use your trusted domain to hit your customers. The technical defenses against all of this are SPF, DKIM, and DMARC — and a surprising number of businesses still have not set them up properly.

This guide explains what each protocol does, how they work together, and gives you a clear step-by-step process to implement them for your domain. Whether you are on Microsoft 365, Google Workspace, or a custom mail server, the principles are the same. Getting this right protects your brand reputation, improves email deliverability, and blocks a major attack vector — all at once.

What SPF, DKIM, and DMARC Actually Do

These three protocols form a layered email authentication framework. Each does something slightly different, and together they give receiving mail servers the tools to verify that an email claiming to be from your domain was actually authorized and sent by you.

SPF (Sender Policy Framework)

SPF is a DNS record that lists the IP addresses and mail servers authorized to send email on behalf of your domain. When a receiving server gets an email from your domain, it checks your SPF record to see if the sending server is on the approved list. If it is not, the email can be flagged or rejected. SPF is the first line of defense against simple domain spoofing.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to outgoing emails. Your mail server signs each email with a private key; the receiving server verifies the signature using the corresponding public key published in your DNS. This confirms two things: the email was actually sent by your domain, and the content was not altered in transit. DKIM is the integrity check that SPF cannot provide.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC ties SPF and DKIM together and tells receiving servers what to do with emails that fail authentication: deliver them anyway (p=none), send them to spam (p=quarantine), or reject them outright (p=reject). DMARC also enables forensic and aggregate reporting, so you receive daily reports showing which servers are sending email on your behalf — legitimate and otherwise. This visibility is invaluable for catching misconfigured services and active spoofing campaigns.

Step 1: Set Up Your SPF Record

Log into your domain registrar or DNS management console (GoDaddy, Cloudflare, Route 53, Namecheap, etc.) and navigate to DNS records for your domain. You will add a TXT record.

The format for a basic SPF record is:

v=spf1 [include statements] [ip4 or ip6 entries] -all

Common examples:

• Microsoft 365: v=spf1 include:spf.protection.outlook.com -all
• Google Workspace: v=spf1 include:_spf.google.com ~all
• Multiple sending services: v=spf1 include:spf.protection.outlook.com include:sendgrid.net include:mailchimp.com -all

Key rules:

• You can only have one SPF record per domain. If you need to authorize multiple services, include them all in a single record.
• The -all suffix means strict fail (recommended). ~all is soft fail — better than nothing, but less authoritative. Avoid +all (allows anyone to send).
• SPF has a DNS lookup limit of 10. If you use many email services, use an SPF flattening tool to stay within the limit.

After adding the record, verify it with an online SPF checker such as MXToolbox or DMARCIAN's SPF survey tool. Allow up to 48 hours for DNS propagation, though changes typically take effect within minutes to a few hours.

Step 2: Enable DKIM Signing

DKIM setup varies by mail platform, but the process is consistent: generate a key pair in your mail platform, then publish the public key as a DNS TXT record on your domain.

Microsoft 365 DKIM Setup

Go to the Microsoft Defender portal at security.microsoft.com. Navigate to Email and Collaboration > Policies and Rules > Threat Policies > Email Authentication Settings > DKIM. Select your domain and click Enable. Microsoft generates the key pair and shows you two CNAME records to add to your DNS. Add both CNAME records in your DNS management console, then return to the Defender portal and enable DKIM signing. Verification may take a few minutes.

Google Workspace DKIM Setup

In the Google Admin Console, go to Apps > Google Workspace > Gmail > Authenticate Email. Select your domain and click Generate New Record. Choose a 2048-bit key. Copy the TXT record value and add it to your domain's DNS under the host name provided (typically something like google._domainkey.yourdomain.com). Return to the Admin Console and click Start Authentication once DNS propagation is complete.

Custom or Third-Party Senders

If you send email through Mailchimp, SendGrid, HubSpot, Klaviyo, or any other platform, each platform has its own DKIM setup process — usually under account settings or email authentication settings. Follow each provider's documentation to add their DKIM records. Every legitimate sending service you authorize should have DKIM configured.

Step 3: Create Your DMARC Record

DMARC is a DNS TXT record published at _dmarc.yourdomain.com. Start with a monitoring-only policy, review the reports for two to four weeks, then gradually tighten to enforcement.

Phase 1: Monitor (p=none)

Your first DMARC record should look like this:

v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1;

This tells receiving servers to take no action on failing emails (your mail flow is unaffected), but to send aggregate reports to your designated email address. The rua tag is for aggregate reports; ruf is for forensic (per-message) reports. Many businesses use a dedicated inbox or a DMARC reporting platform like Postmark (dmarcdigests), DMARCIAN, or EasyDMARC to parse and visualize these reports.

Phase 2: Quarantine (p=quarantine)

After reviewing reports and confirming all legitimate sending sources are authenticated, move to quarantine: p=quarantine; pct=25. The pct tag applies the policy to a percentage of failing messages — start at 25% and increase to 100% over several weeks as confidence grows.

Phase 3: Reject (p=reject)

Full enforcement: p=reject. Any email failing DMARC is rejected by the receiving server — it never reaches the inbox. This is the goal. It completely blocks spoofing of your domain, protects your brand, and is required by many organizations and governments before they will accept email from external partners.

Reading DMARC Reports and Fixing Issues

DMARC aggregate reports arrive as XML files, which are not human-friendly. Use a DMARC reporting tool to turn them into dashboards. Free and low-cost options include DMARCIAN, EasyDMARC, Postmark DMARC digests, and Google's free Postmaster Tools (for Gmail deliverability insights).

What to look for in your reports:

• Unknown sending sources: IP addresses you do not recognize sending email as your domain. These could be misconfigured internal services, forgotten marketing tools, or active spoofing attempts.
• SPF or DKIM failures from known services: A sending service that is not properly authenticated. Add their SPF include or DKIM record to fix it before moving to p=reject.
• Volume spikes from unexpected locations: A sudden surge of email failing DMARC from IPs in unexpected countries may indicate your domain is being actively spoofed in a phishing campaign. Report it to the abuse contacts for those IP ranges and notify your customers if there is risk of confusion.

The reporting phase (p=none) is not optional — it is how you discover all the legitimate services you forgot to authenticate before enforcement breaks your mail flow. Do not rush to p=reject. Four weeks of reviewing reports is a reasonable minimum.

Common Mistakes and How to Avoid Them

Email authentication errors are common and easy to make. Here are the most frequent mistakes and how to avoid them:

• Multiple SPF records: Only one TXT record with v=spf1 is allowed per domain. Having two causes SPF to fail. Combine everything into one record.
• Forgetting subdomains: If you send email from subdomains (newsletters.yourdomain.com, invoices.yourdomain.com), each needs its own SPF, DKIM, and DMARC configuration. DMARC subdomains inherit the parent domain policy by default, but you can override with a separate _dmarc.subdomain.yourdomain.com record.
• Jumping straight to p=reject: Skipping the monitoring phase often breaks legitimate email flows. Use p=none first, always.
• Ignoring DMARC reports: Setting up DMARC and never reading the reports defeats the purpose. Schedule a monthly review of your DMARC dashboard.
• Not updating SPF when adding new tools: Every new email sending service (a new CRM, a new support helpdesk, a new invoicing tool) needs to be added to your SPF record and configured with DKIM. Build this into your software procurement checklist.

Getting email authentication right is one of the most impactful things a small business can do for both security and deliverability. If you want expert help setting this up correctly — or auditing what you have already — send us a message or explore our IT consultation services.

Frequently Asked Questions

Do I need all three — SPF, DKIM, and DMARC?

Yes. Each protocol serves a different purpose and they are most effective together. SPF authorizes sending servers, DKIM proves the email was not tampered with, and DMARC defines what to do when authentication fails and provides visibility through reporting. SPF and DKIM alone without DMARC do not prevent spoofing — an attacker can still send from a different domain that superficially looks like yours. DMARC with p=reject is the only way to fully block domain impersonation.

Will setting up DMARC affect my email deliverability?

Done correctly, DMARC improves deliverability. Major inbox providers like Gmail, Outlook, and Yahoo give higher trust scores to authenticated domains. The risk to deliverability comes from rushing to p=reject before properly configuring SPF and DKIM for all your sending sources. Follow the phased approach: p=none for monitoring, then quarantine, then reject — only advancing when your DMARC reports show clean alignment.

How long does it take to fully implement SPF, DKIM, and DMARC?

Initial setup of SPF and DKIM for your primary mail platform can be done in an hour. The timeline to full DMARC enforcement (p=reject) is typically 4 to 8 weeks, depending on how many legitimate sending services you have to audit and authenticate. The monitoring phase should not be skipped — it surfaces legitimate services you had forgotten about.

Can someone still spoof my email address even with DMARC set to p=reject?

With DMARC at p=reject, spoofing your exact domain in the From header is effectively blocked — receiving servers that honor DMARC (which includes Gmail, Outlook, and most major providers) will reject those emails. Attackers may still use lookalike domains (e.g., yourdomain-invoice.com) or display name spoofing. Protecting against those requires user training and additional email security tools.

My business uses multiple email services (CRM, marketing, support). Does each one need to be configured?

Yes. Every service that sends email on behalf of your domain needs to be included in your SPF record and should have DKIM configured. Most major platforms (Mailchimp, HubSpot, Salesforce, Zendesk, Klaviyo) have detailed documentation for DKIM setup. Before moving DMARC to p=reject, verify that all your legitimate services are authenticating correctly in your DMARC reports.