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 hard fail, meaning any server not listed should be rejected. For guidance on choosing between hard fail and soft fail, see 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.

DKIM for Microsoft 365

Microsoft 365 uses CNAME records rather than TXT records for DKIM. You need to create two CNAME records in your DNS:

Host: selector1._domainkey.yourdomain.com
Points to: selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com

Host: selector2._domainkey.yourdomain.com
Points to: selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.com

Replace yourdomain.com with your actual domain and yourtenant with your Microsoft 365 tenant name. After publishing the CNAME records, enable DKIM signing in the Microsoft 365 Defender portal under Email & collaboration > Policies & rules > Threat policies > DKIM.

DKIM for Google Workspace

Google Workspace provides a TXT record containing your DKIM public key. To generate it:

1. Open the Google Admin console and navigate to Apps > Google Workspace > Gmail > Authenticate email.
2. Select your domain and click “Generate new record”.
3. Choose your DKIM key bit length (2048-bit is recommended).
4. Copy the generated TXT record value.

Publish this as a TXT record in your DNS:

Host: google._domainkey.yourdomain.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ...

After the DNS record has propagated (this can take up to 48 hours), return to the Google Admin console and click “Start authentication”. You can use the DKIM Generator to verify your record is formatted correctly before publishing.

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:[email protected]; 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.

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.