How to set up SPF, DKIM and DMARC records (2026 guide)

A practical guide to SPF, DKIM and DMARC: what each record does, how to add it to DNS, what correct syntax looks like, and how to verify that it works.

If email goes out from your domain without properly configured SPF, DKIM and DMARC, one of these things is probably happening: messages land in spam, Gmail or Outlook may reject them, or someone can send emails that look like they came from you. Since 2024, Google and Yahoo require these records for bulk sending, so they are no longer just a "nice to have".

In this guide, we will go through what each record does, how to add it to DNS, and how to verify the whole setup.

What each record does

Think of an email as a letter. Then:

• SPF is the list of servers and services allowed to send letters with your return address.
• DKIM is the seal proving the letter was not opened and rewritten on the way.
• DMARC is the instruction for the recipient: what to do when the seal or the allowed-sender list does not match, and where to send a report.

All three are handled in your domain's DNS. SPF and DMARC are TXT records. DKIM depends on the provider - often TXT, but Microsoft 365 usually uses CNAME records. You do not need to change anything on your website or in your app.

SPF: who may send from your domain

SPF (Sender Policy Framework) is a TXT record on the root domain. It tells receiving mail servers which IP addresses and services may send email on behalf of your domain.

A typical SPF record for Google Workspace looks like this:

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

For Microsoft 365:

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

If you also send newsletters through another service, such as Mailchimp or Bento, add its include to the same record:

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

Watch out for these details:

• A domain may have only one SPF record. Two separate TXT records starting with v=spf1 are an error and receiving servers treat them as a permanent failure. Always add new services to the existing record.
• The limit is 10 DNS lookups. Every include counts. If you use many sending services, check whether you still need all of them.
• Ending with ~all vs -all. Softfail (~all) is the safer default. Use strict -all only after you are sure every legitimate sending service is included.

DKIM: a cryptographic signature for messages

DKIM (DomainKeys Identified Mail) adds a signature to every email header. The public key used to verify it is published in DNS at an address such as selector._domainkey.yourdomain.com.

The selector and DNS record type are chosen by the email provider, so follow exactly what its admin panel shows:

1. In your provider's admin area (Google Workspace, Microsoft 365, your hosting provider), generate a DKIM key.
2. The provider will show the record type, record name (for example google._domainkey or selector1._domainkey) and target value.
3. Add the record to DNS in exactly that form. Google Workspace and many hosting providers use a TXT value starting with v=DKIM1; p=..., while Microsoft 365 uses two CNAME records for custom domains: selector1._domainkey and selector2._domainkey.
4. In the provider's admin area, turn on signing.

Common selectors are google for Google Workspace, selector1 and selector2 for Microsoft 365, or default. If you do not know the selector, open the headers of a sent email and look for s= in the DKIM-Signature field.

DMARC: policy and reports

DMARC (Domain-based Message Authentication, Reporting and Conformance) connects SPF and DKIM into one policy. It is not enough for SPF or DKIM to pass technically - at least one of them also has to align with the domain the recipient sees in the From field. This matters especially for newsletters and external sending services.

DMARC is set as a TXT record on the _dmarc subdomain:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

What the parameters mean:

• p=none - monitoring only; recipients do not block anything. Good for the first few weeks.
• p=quarantine - suspicious messages should go to spam.
• p=reject - suspicious messages should be rejected. This is the target state for company domains.
• rua= - the address where recipients send aggregate reports.

The recommended path is to start with p=none, watch the reports for a few weeks, and once legitimate mail passes reliably, move to quarantine and later to reject. Long term, p=none is not protection - it basically tells recipients not to interfere with delivery.

How to verify the setup

DNS changes appear gradually based on TTL, usually within a few hours. After that, check the setup:

1. Open the domain DNS checker and enter your domain. The tool checks MX, SPF, DMARC, DNSSEC and nameservers, and it can also try common DKIM selectors automatically.
2. Send a test email to Gmail and use Show original to confirm that SPF, DKIM and DMARC all return PASS.
3. Watch DMARC reports - they will also reveal services you forgot to include in SPF.

Common mistakes

Most problems do not happen when the first DNS record is added. They happen later, when another service is connected and nobody checks the setup again. Typical cases:

• A new newsletter tool or CRM is added and a second SPF record appears. A domain should have only one record starting with v=spf1. Do not add the new service as another TXT record. Add its include to the existing SPF record.
• DKIM is in DNS, but the provider still does not sign messages. Adding the key or CNAME is not enough. After DNS is saved, email providers usually still need you to enable signing and let them verify the record.
• DMARC fails even though SPF or DKIM passes. Check alignment with the domain in the From field. With external sending services, you often need to set up a custom sending domain, not just verify the account.
• Reports go nowhere. Without rua, the policy can work, but you will not know which legitimate services are failing. Use an address or a tool where you can monitor DMARC reports at least during the first few weeks.
• Subdomains are forgotten. If you send mail from newsletter.yourdomain.com or mail.yourdomain.com, check those names too. Checking only the root domain is not enough.
• The change is tested too soon. DNS does not update instantly. If a checker still shows the old state, wait until the TTL expires and test again.

Properly configured SPF, DKIM and DMARC are basic domain hygiene today, much like HTTPS on a website. An hour spent on DNS records can improve deliverability and make life much harder for anyone trying to spoof your domain. If you manage several domains, run all of them through a DNS check - the weakest domain is usually the one nobody remembered.