SPF, DKIM, and DMARC: The Complete Setup Guide

What do you need before configuring email authentication?

Gather this information before creating any DNS records:

1. All services that send email for your domain. This includes your primary email provider (Google Workspace, Microsoft 365), marketing platforms (Mailchimp, HubSpot), transactional email services (SendGrid, Postmark, Resend), helpdesk software (Zendesk, Intercom), and any internal applications that send email.

2. DNS management access. You need the ability to create and modify TXT records for your domain. This is typically in your domain registrar or DNS hosting provider (Cloudflare, Route 53, etc.).

3. DKIM selector information. Your email provider will give you the DKIM selector and public key. Check their documentation for setup instructions specific to your provider.

How do you configure SPF?

SPF tells receiving servers which IP addresses and mail servers are allowed to send email for your domain.

Create the SPF record

Add a TXT record at your root domain with the following format:

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

Replace the include: entries with your actual sending services:

Service	SPF include
Google Workspace	include:_spf.google.com
Microsoft 365	include:spf.protection.outlook.com
SendGrid	include:sendgrid.net
Mailchimp	include:servers.mcsv.net
Postmark	include:spf.mtasv.net
Amazon SES	include:amazonses.com
HubSpot	include:hubspot.com

SPF rules to follow

End with -all, not ~all. The -all mechanism tells receivers to reject email from unlisted servers. The ~all (softfail) mechanism says “this probably should not be allowed” - but most receivers deliver softfail messages anyway, which defeats the purpose.

Stay under 10 DNS lookups. SPF allows a maximum of 10 DNS lookups (each include:, a:, mx:, and redirect= counts as one). Exceeding this limit causes the entire SPF evaluation to return “permerror” and your email may be rejected or treated as unauthenticated.

If you have too many senders, consider using IP addresses directly (ip4:203.0.113.0/24) instead of include: for services with static IPs, or consolidate senders through a single relay.

Only one SPF record per domain. Multiple SPF records cause parsing failures. If you need to add a sender, modify the existing record - do not create a second one.

Verify SPF

Check your record is published correctly:

dig example.com TXT | grep spf

You should see your SPF record returned. Test with an SPF validation tool to confirm it parses without errors and stays under the 10-lookup limit.

How do you configure DKIM?

DKIM adds a cryptographic signature to your outgoing emails, proving they were sent by an authorised system and were not modified in transit.

Get your DKIM key

Your email provider generates a DKIM key pair for you. The process varies by provider:

• Google Workspace: Admin Console > Apps > Google Workspace > Gmail > Authenticate email
• Microsoft 365: Exchange Admin Centre > Mail flow > DKIM
• SendGrid: Settings > Sender Authentication > Domain Authentication

Your provider will give you a DKIM selector (e.g., google, selector1, s1) and a public key value.

Publish the DKIM record

Add a TXT record at selector._domainkey.example.com with the public key your provider gave you:

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

Some providers use CNAME records instead of TXT records for DKIM, pointing to their hosted key. Follow your provider’s specific instructions.

Verify DKIM

Send a test email to a Gmail or Outlook account and view the message headers. Look for dkim=pass in the Authentication-Results header. Alternatively, use a service like mail-tester.com to check your DKIM configuration.

How do you deploy DMARC in monitoring mode?

DMARC ties SPF and DKIM together with a policy. Start in monitoring mode to collect data before enforcing.

Create the DMARC record

Add a TXT record at _dmarc.example.com:

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

This record says:

• p=none - do not take action on failing emails (monitoring only)
• rua= - send aggregate reports to this address
• ruf= - send forensic (failure) reports to this address
• fo=1 - generate forensic reports if either SPF or DKIM fails

Process DMARC reports

DMARC aggregate reports are XML files sent daily by receiving servers. They contain data about every email sent from your domain - who sent it, whether it passed SPF/DKIM, and what action was taken.

These reports are not human-readable in raw form. Use a DMARC reporting service to parse and visualise them:

• Free options: Postmark DMARC, EasyDMARC free tier
• Paid options: Valimail, Agari, dmarcian

Review reports for 2-4 weeks. Look for:

• Legitimate senders failing SPF or DKIM (add them to your SPF record or configure DKIM)
• Unauthorised senders using your domain (this is the spoofing you are trying to stop)
• High volumes of failed authentication from specific sources

How do you move from monitoring to enforcement?

Once your DMARC reports show that all legitimate email passes authentication, escalate your policy:

Gradual enforcement path

1. Start with quarantine at 10%: p=quarantine; pct=10 - quarantine 10% of failing email. Monitor for delivery problems.

2. Increase to quarantine at 100%: p=quarantine; pct=100 - quarantine all failing email. Continue monitoring.

3. Move to reject: p=reject; pct=100 - reject all failing email outright. This is the end state.

At each stage, wait 1-2 weeks and review DMARC reports before escalating. If legitimate email starts failing, pause enforcement and fix the authentication issue before proceeding.

Our detailed guide on DMARC enforcement covers this process in depth, including common problems and how to resolve them.

What are the most common email authentication mistakes?

Forgetting a sending service. When you add a new email tool (a marketing platform, a helpdesk, a transactional sender), you must update your SPF record and configure DKIM. Otherwise, email from that service will fail authentication when you enforce DMARC.

Never moving past p=none. Monitoring without enforcement provides visibility but no protection. Your domain can still be spoofed. DMARC enforcement is where the security value comes from.

Ignoring subdomains. By default, DMARC applies to the root domain. Subdomains without their own DMARC record inherit the parent’s policy, but subdomains without SPF or DKIM configured will fail authentication. Use sp=reject in your DMARC record to enforce policy on subdomains too.

SPF record too long. Exceeding the 10-lookup limit silently breaks SPF for your entire domain. Review your record quarterly and remove services you no longer use.