How to Create SPF, DKIM, and DMARC Records: Step-by-Step Setup

Before you start

Before creating any records, make sure you have the following ready:

• DNS access.You need the ability to add or edit TXT and CNAME records in your domain's DNS zone. This is usually managed through your domain registrar (such as Cloudflare, GoDaddy, or Namecheap) or your hosting provider's control panel.
• A list of every service that sends email as your domain. This includes your primary mail platform (Microsoft 365, Google Workspace), plus any third-party services such as marketing platforms, CRM tools, helpdesk systems, and invoicing software.
• A basic understanding of SPF, DKIM, and DMARC. If you are new to these protocols, read our guide on SPF vs DKIM vs DMARC first. For a broader overview, see What is DMARC?

Step 1: Create your SPF record

SPF (Sender Policy Framework) tells receiving mail servers which IP addresses and services are authorised to send email on behalf of your domain. It is published as a single TXT record on your root domain.

The easiest way to build a correct SPF record is to use our free SPF Generator. Enter your domain, select the services you use, and the tool will produce a valid record you can copy directly into your DNS.

If you prefer to build the record manually, here is the structure:

v=spf1 include:_spf.provider.com include:_spf.anotherprovider.com ~all

• v=spf1 declares this is an SPF record.
• Each include: mechanism authorises a specific sending service.
• ~all is a soft fail and is the correct qualifier on any active sending domain. Reserve -all for parked or non-sending domains. With DMARC at p=reject the policy decision is made by DMARC; tightening to -all on an active domain adds no extra protection and breaks legitimate forwarded mail. Full reasoning is in our guide on SPF hard fail vs soft fail.

SPF for Microsoft 365

Microsoft 365 uses a single include mechanism. Your SPF record should contain:

v=spf1 include:spf.protection.outlook.com -all

If you also use other services (for example, a marketing platform like Mailchimp), add their include mechanism before the -all:

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net -all

SPF for Google Workspace

Google Workspace uses the following include:

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

As with Microsoft 365, add any additional providers before the -all mechanism. Be mindful that SPF has a limit of 10 DNS lookups. If your record grows complex, our SPF Flattener can help you stay within that limit. For a deeper explanation of the lookup problem, read how to fix SPF too many DNS lookups.

Publishing and verifying your SPF record

Log in to your DNS provider and create a new TXT record with the following settings:

After saving, use the SPF Generator or our DMARC Checker to verify the record has propagated correctly.

Step 2: Set up DKIM signing

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email. The receiving server looks up your public key in DNS and verifies the signature. If the message was altered in transit, or the key does not match, DKIM fails.

Unlike SPF, DKIM requires two things: your email provider must sign outgoing messages (this is configured in your provider's admin console), and you must publish the corresponding public key as a DNS record. Our free DKIM Generator helps you build the correct DNS record once you have the public key from your provider.

Provider-specific DKIM setup

The exact steps depend on your sending provider. Microsoft 365 uses two CNAME records published to your DNS; Google Workspace uses a generated TXT record under the google._domainkey selector. Other providers (SendGrid, Mailchimp, Amazon SES, HubSpot) each use their own selector and record format.

For full provider-specific walkthroughs, see our DKIM setup guides by email provider, which cover every major sending platform with copy-ready DNS records and admin console steps. If you are setting up Microsoft 365 or Google Workspace specifically, the integrated guides walk through SPF, DKIM, and DMARC together: DMARC for Microsoft 365 and DMARC for Google Workspace.

Verifying your DKIM record

Once published, send a test email from your domain and inspect the email headers. Look for a line that reads dkim=pass in the Authentication-Results header. You can also use our DMARC Checker to confirm that a valid DKIM record exists for your domain.

Step 3: Create your DMARC record

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together. It tells receiving servers what to do when an email fails authentication checks, and it sends you reports so you can see who is sending email as your domain.

Use our free DMARC Generator to build your record. Select your policy, enter your reporting address, and the tool will produce a valid TXT record ready to publish.

For your first DMARC record, start with a monitoring-only policy. This lets you collect reports without affecting mail delivery:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; adkim=r; aspf=r;

Publish this as a TXT record in your DNS with the following settings:

The rua tag specifies where aggregate reports are sent. You can use your own email address, or point it to a monitoring service like ShieldMarc that parses the XML reports automatically and presents them as clear dashboards. The DMARC Generator will help you configure this correctly.

Step 4: Test everything

With all three records published, it is time to verify that everything works together. Follow these steps:

1. Run a full domain check. Use our DMARC Checker to verify that your SPF, DKIM, and DMARC records are all present and correctly formatted. For a broader assessment, try the Security Grade Check which scores your domain across multiple security dimensions.
2. Send test emails. Send emails from your domain to a Gmail, Outlook, and Yahoo account. Open the received messages and inspect the email headers. Look for spf=pass, dkim=pass, and dmarc=pass in the Authentication-Results header.
3. Check aggregate reports. Within 24 to 48 hours of publishing your DMARC record, you should start receiving aggregate reports from major mail providers. These XML files contain detailed information about every email sent using your domain. Use our DMARC Report Viewer to upload and inspect them, or read our guide on understanding DMARC reports for help interpreting the data.
4. Test third-party senders. If you use services like a CRM, marketing platform, or helpdesk that sends email as your domain, send test messages through each of them and verify they pass SPF and DKIM. Any service missing from your SPF record will fail.

Common mistakes to avoid

These are the errors we see most frequently when organisations set up email authentication for the first time:

• Forgetting third-party senders in SPF. Your SPF record must include every service that sends email using your domain. If your marketing platform, invoicing tool, or helpdesk is not listed, those emails will fail SPF and may be rejected once you enforce DMARC. Use the SPF Generator to make sure nothing is missed.
• Using the wrong DKIM selector. Each email provider uses a specific selector name (for example, selector1 for Microsoft 365 or google for Google Workspace). Publishing the record under the wrong selector means receiving servers cannot find the public key, and DKIM will fail. The DKIM Generator will help you get the selector right.
• Jumping straight to p=reject. Moving to full enforcement without monitoring first will block legitimate email from services you forgot to authorise. Always start with p=none and review your reports before progressing.
• Not monitoring aggregate reports. Publishing a DMARC record and never reading the reports defeats the purpose. The reports show you which senders are passing and failing. Without them, you cannot safely move to enforcement.
• Publishing multiple SPF records. A domain must have exactly one SPF TXT record. If you add a second one instead of editing the existing record, SPF will return a permanent error and all checks will fail. Always edit the existing record to add new includes.
• Exceeding the SPF 10-lookup limit. SPF allows a maximum of 10 DNS lookups. Each include: counts as at least one lookup, and nested includes add more. If you exceed the limit, SPF fails for all messages. Our SPF Flattener resolves this by converting includes to flat IP ranges.

Moving to enforcement

The goal of email authentication is to reach p=reject, where receiving servers block any email that fails DMARC. This is the only policy that fully prevents domain spoofing. However, getting there safely requires a phased approach. Our guide on moving from p=none to p=reject walks through the same progression in more detail once your records are live.

1. Phase 1: Monitor (p=none). Publish your DMARC record with p=none and point the rua= address at a reporting platform that parses aggregate reports for you. Actively work the report inbox as data arrives: identify every legitimate sender, fix any SPF or DKIM alignment issues, and authorise each source. Move on when the reports are clean, not when a calendar says so.
2. Phase 2: Quarantine (p=quarantine). Once all legitimate email is passing, update your DMARC record to p=quarantinewith pct=100 (or leave pct off entirely, as 100 is the default). Keep reading your reports. New senders appear as services are added and providers rotate IPs, and this is where you will notice them.
3. Phase 3: Reject (p=reject). When your quarantine reports are clean and no unresolved unauthorised senders remain, move to p=reject; sp=reject. This is full enforcement. Use the DMARC Generator to update your record at each stage.

How long the journey takes depends on how many senders your domain has and how quickly you work the reports, not on a fixed calendar. A clean, well-documented sender list can reach reject in weeks. We do not recommend ramping pct= as a rollout strategy: it hides real problems behind a probability and makes reports harder to interpret. Move when the data says it is safe.

Next steps

You now have all three records in place. Here is where to go from here:

• Verify your setup with our DMARC Checker to confirm all three records are live and correctly configured.
• Check your Security Grade for a comprehensive score covering SPF, DKIM, DMARC, TLS, and more.
• Read Understanding DMARC Reports to learn how to interpret the aggregate data you are now receiving.
• Use the DMARC Report Viewer to upload and visualise your aggregate XML reports.
• Explore our SPF vs DKIM vs DMARC guide for a deeper comparison of how the three protocols work together.