How to Set Up SPF DKIM DMARC: Keep Business Email Out of Spam

How to set up SPF DKIM DMARC and what does each one do?

SPF, DKIM and DMARC are three DNS records that prove to receiving mail servers that an email from your domain really comes from you. To set them up, list every service that sends email for your domain, add SPF and DKIM records, publish DMARC at p=none, read the reports, and tighten the policy step by step.

Picture the door at a private event. First, SPF (Sender Policy Framework) is the guest list: it names the servers that may send for your domain. Next, DKIM (DomainKeys Identified Mail) is the seal on the envelope, so it shows that the message arrived unchanged and that your domain signed it. Finally, DMARC (Domain-based Message Authentication, Reporting and Conformance) is the instruction you give the doorman. It says what to do when the list or the seal fails, and it sends you a report.

This guide is for businesses whose email lands in spam or bounces. If Gmail already shows you an error code, start with our Gmail 550 5.7.26 error guide. This article covers the permanent setup instead. Also, every record example uses example.com, and we take the values from official documentation.

Why does your business email land in spam or get rejected?

A receiving server asks one question before it accepts a message: may this sender use this domain? It then looks for the answer in your DNS records. If the records are missing or wrong, the server treats the message as suspicious. As a result, even a clean, well-written email can end up in the spam folder.

Google's email sender guidelines are clear on this point. Everyone who sends to personal Gmail accounts needs SPF or DKIM, and high-volume senders need all three records. Likewise, Yahoo publishes similar requirements for bulk senders. However, check the official pages for the current volume thresholds, because they can change.

Unauthenticated messages go to spam or bounce with a code such as 5.7.26. In other words, the problem is often identity, not content. Other factors also affect inbox placement, and our email deliverability guide covers them. The reverse DNS (PTR) record of your sending IP is a separate requirement, and our PTR record article explains it.

What is the difference between SPF, DKIM and DMARC, and how do they work together?

The three records do not replace each other, because each one answers a different question. This table shows the differences at a glance. In it, TXT is the DNS record type that stores text, and CNAME is a record that points one name to another.

In short, SPF and DKIM produce evidence, and DMARC compares that evidence with the From address and decides. The receiving server follows this order:

1. First, it checks the SPF record of the envelope sender domain. SPF passes when the sending IP appears in the list.
2. Next, it verifies the DKIM signature with the public key in DNS.
3. Then it compares both results with the From domain. This comparison is called alignment.
4. Finally, DMARC passes if SPF or DKIM passes with alignment. Otherwise, your policy applies.

If you want to see how a message travels between servers, read our MTA and SMTP relay article.

How to set up SPF DKIM DMARC: what should you prepare first?

Before you touch DNS, settle two things: who sends email for your domain, and who manages your DNS. Once you know both, the rest is mechanical, because the remaining steps follow a fixed order. Follow this order:

1. List every service that sends email for your domain.
2. Find the panel where you manage DNS records.
3. Check the existing SPF, DKIM and DMARC records and write down their values.
4. Create one SPF record, or update the one you have.
5. Turn on DKIM for each sending service.
6. Publish a DMARC record with p=none and a report address.
7. Read the reports and fix legitimate sources that fail alignment.
8. When the reports are clean, raise the policy to quarantine, and to reject if it suits you.

For a domain that uses Google Workspace, the end result looks like this (the key is shortened):

@                 TXT  v=spf1 include:_spf.google.com ~all
google._domainkey TXT  v=DKIM1; k=rsa; p=MIIBIjANBgkq...
_dmarc            TXT  v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

In practice, the order matters. You open DMARC last because a strict DMARC policy on top of incomplete SPF and DKIM can block legitimate mail. Moreover, p=none does not change delivery, so you only collect reports at first. RFC 9989 is the current DMARC standard and replaces the older RFC 7489. It describes the same path: start at p=none, then study the reports.

How do you list every service that sends email for your domain?

Skipping this step leaves the setup incomplete. Above all, the most common problem we see is a forgotten service that quietly sends email in your name. Add these sources to your list:

• Your main mailbox provider: Google Workspace, Microsoft 365, or the mail server of your hosting company.
• The contact, quote and order forms on your website.
• Newsletter and marketing automation tools.
• CRM, quoting and invoicing software.
• Helpdesk and booking systems.
• Your online store platform and payment notifications.
• Devices such as scanners and printers, and old server scripts.

To complete the list, first ask every team. Then open the headers of a few recent messages and look at the bounce notices. Also write down three facts for each source: which domain it sends from, what it needs for SPF, and how you switch on DKIM. Still, if you miss a source, DMARC reports will reveal it later.

How do you find where your DNS records live?

Adding records to the wrong panel is the mistake that wastes the most time. The record sits there, but it does nothing. That is because receiving servers read only the records published on your domain's name servers. So whichever company your name servers point to is the place where you add records.

You can find out in two steps. First, use our DNS lookup tool to read the NS records of your domain. Then use our WHOIS lookup tool to see which registrar holds the domain.

In practice, the name servers may point to your registrar, your hosting provider, or a separate DNS service. For example, your website may run on one server while DNS lives somewhere else. In that case, the panel on the server misleads you, because receivers never query it. Also, if you have no login for the DNS panel, you must regain access first.

How do you create an SPF record?

An SPF record is a single TXT record at the root of your domain. It starts with v=spf1, lists the authorized sources, and ends with a rule. For example, the record in Google's help page for a business that sends only through Google Workspace looks like this:

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

The include term adds Google's list of sending servers, and the ~all rule marks every other source as probably unauthorized. When you add a new service, you do not create a second record. Instead, you add another include to the same record:

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

Here service.example.com is only a placeholder for the value your newsletter tool gives you. Remember the key rule: a domain must have exactly one SPF record. In fact, RFC 7208 forbids multiple records, and Microsoft's documentation says SPF returns a permanent error in that case.

When you add the record, most panels want @ in the name (host) field, while some want the domain itself. Some panels also expect the value in quotes, so check your panel's help page.

Watch for three typing mistakes: writing include= instead of include:, adding a space after the colon, and adding a dot after the domain. Also, a subdomain such as news.example.com needs its own SPF record, because the root record does not cover it.

What is the SPF limit of 10 DNS lookups?

RFC 7208 caps the number of DNS-querying terms in one SPF evaluation at 10. The standard counts include, a, mx, ptr, exists and redirect. Also, the terms ip4, ip6 and all do not count. Therefore a record that goes over the limit returns a permanent error (permerror), and SPF validation does not work.

However, the real trap is nested includes. One include can open several more, and every one of them counts. You may see only three includes in your record, yet the counter can sit far above three. Indeed, Microsoft's documentation warns that fewer includes do not guarantee fewer lookups. Receivers also read the record from left to right and stop when they find the sender. So the error may never show up at some receivers while others bounce your mail.

When you get close to the limit, try these steps:

• Delete the include lines of services you no longer use.
• Move heavy senders to a subdomain, because every subdomain has its own limit of 10.
• If a provider documents a stable IP range, you can write ip4 instead of include, but you must update the record when the provider changes the range.
• Never use the ptr term, because RFC 7208 says it should not be published.

Our free SPF DKIM DMARC checker also shows the lookup count as a numbered tree.

Should your SPF record end with ~all or -all?

Both are valid, and large providers give different advice. Google's help page recommends ~all (softfail). Microsoft's documentation recommends -all (hard fail) when you also use DKIM and DMARC.

However, RFC 9989 points out a risk. Some receivers reject a message at the SMTP stage when SPF fails, without ever looking at DMARC. As a result, a message that would have passed DMARC through an aligned DKIM signature can vanish, and it never appears in your reports.

So our practical advice is this: stay with ~all until you have verified every sender. After that, decide on -all by reading your reports. Domains that use forwarding rules should prefer ~all, because forwarded mail often fails SPF, and -all may bounce it before DKIM gets a chance.

Unused domains are a different case. For a domain that never sends email, you can publish v=spf1 -all, and Microsoft's documentation recommends it. Thus nobody can send in the name of that domain. Also, ?all (neutral) is only for testing, and Microsoft does not recommend it in production.

How do you generate a DKIM key and add it to DNS?

DKIM uses two keys. The sending system signs each message with a private key, and you publish the matching public key in DNS. The receiver uses that public key to verify the signature. You usually generate the key pair in your mail provider's panel, so you repeat the setup for every sending service.

1. Open the DKIM or domain authentication section in the sending service's panel and select your domain.
2. Copy the record name (host) and value the panel gives you. For example, Google gives you one TXT record, and Microsoft 365 gives you two CNAME records.
3. Then add the record exactly as shown in your DNS panel, without changing the text or the line breaks.
4. Wait for DNS to update, then switch on signing or click the verify button in the panel.
5. Finally, send a test message and look for dkim=pass in the headers.

In practice, the record name looks like selector._domainkey.example.com. A selector lets one domain publish several keys side by side, and RFC 6376 defines it to make key rotation easier. For example, Google's default selector is google. Choose the longest key length your provider supports. Google says longer keys are more secure. Moreover, when you rotate a key, publish a new selector and keep the old one until the switch is complete.

How do you fix a DKIM selector error?

If the DKIM record exists but the result is still a failure, the cause is usually the selector, the record name or the value. Check these points in order:

• Selector match: open a test message's headers, find the s= and d= values in the DKIM-Signature line, and confirm that DNS holds a record named exactly s._domainkey.d.
• Doubled domain: some DNS panels add your domain automatically. So if you type the full name, you create a wrong record such as google._domainkey.example.com.example.com. In that case, type only google._domainkey.
• Broken key: you may have lost the end of the long value while copying it, or added line breaks or extra quotes. Also, a single DNS string holds at most 255 characters, so long keys are split into parts. Some panels do this for you, and others ask you to enter the parts separately.
• Signing switched off: even with a correct record, you may have forgotten to turn on signing in the service's panel.
• Wrong signing domain: if the service signs with its own domain, DKIM passes but does not match your domain.
• Duplicate records: RFC 6376 expects one TXT record per selector.

After a fix, you may not see the result right away, because DNS caches keep the old value for a while. So do not edit the record again and again. Wait, then test once more.

How do you create a DMARC record, and what does p=none mean?

A DMARC record is a TXT record named _dmarc under your domain. First, prepare an address that will receive the reports. The report volume can be high, so Google recommends a dedicated mailbox or a group instead of a personal address. Then add the record:

Name: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

The v=DMARC1 tag must come first. The p tag sets the policy, and rua names the address for aggregate reports. Moreover, p=none means do not touch the mail, only report. RFC 9989 says a p=none policy must not change how receivers handle mail.

If the report address sits on another domain, that domain must publish a DNS record that approves receiving your reports. However, an address on your own domain needs no such step. Finally, wait until your SPF and DKIM records have propagated before you add DMARC.

What is DMARC alignment, and why does DMARC fail?

Alignment means that the domain verified by SPF or DKIM matches the From domain you see. In relaxed mode, the two domains only need to share the same organizational domain. For example, news.example.com and example.com match in relaxed mode. In strict mode, however, the domains must be identical. Relaxed is the default, and it is enough for most businesses.

Specifically, DMARC looks at the envelope sender (MAIL FROM) domain for SPF, not at the HELO name. For DKIM, it looks at the d= domain in the signature. As a result, one aligned pass from either method makes DMARC pass.

Example scenario: a newsletter goes out from info@example.com. The newsletter tool uses its own domain as the envelope sender and signs with its own domain too. SPF and DKIM each pass, but neither matches example.com, so DMARC fails.

The fix, however, is simple. Switch on custom domain authentication in the tool's panel. Then the service also signs with your domain, and DKIM aligns. Indeed, Microsoft's documentation says many hosted email services first sign with their own domain and sign again with the customer's domain after setup.

How do you read DMARC reports?

Aggregate reports are XML files that receiving mail systems send you. They usually arrive as small compressed attachments, and receivers generally send them once a day. You can read them by hand, but RFC 9989 recommends parsing them by machine. Report tools and services can do that job for you. Each report contains this information:

• Reporting organization name and date range.
• Source IP address and the number of messages from it.
• DMARC evaluation: the disposition, plus the aligned DKIM and SPF results.
• From domain shown to the reader.
• Raw authentication results: DKIM domain, selector and result, and SPF domain and result.

First, group the sources by IP address or by service. Then leave the known, passing sources alone. Next, fix the known sources that fail by adjusting alignment. Finally, watch for unknown sources with high volume, because they may be spoofing.

Failure reports are a separate topic. Gmail does not support them, and most receivers do not send them for privacy reasons. Moreover, even aggregate reports can reveal sending habits of a small business. So decide who may access the report mailbox. If a personal data question comes up, this article is not legal advice, and you should consult a specialist.

How do you move DMARC to quarantine and reject?

Do not rush the move. Follow this order:

1. Start with p=none and rua, then collect reports.
2. Watch the reports until every legitimate source passes with alignment.
3. Fix each legitimate source that does not align.
4. When the reports are clean, switch to p=quarantine and keep watching.
5. Move to p=reject only if you need it and understand the effect.

How long this takes depends on how often you send. RFC 9989 says it can take many months for some domains. So we give no calendar, because the real measure is clean reports, not elapsed time.

Some provider documents describe a pct tag for a gradual move. RFC 9989, however, removes that tag and adds a t tag for testing. Receivers may differ in what they support, so check your provider's current documentation.

Also, domains that never send email have it easy. Publish v=spf1 -all and set DMARC to p=reject.

Is p=reject right for every business?

Not always. RFC 9989 warns that p=reject can break indirect mail flows, such as mailing lists, role based aliases and forwarding rules. The reason is simple: forwarding often breaks SPF, while DKIM survives if the message stays unchanged.

The standard makes two clear points:

• A domain that publishes p=reject must not rely on SPF alone, and it must sign its messages with valid DKIM.
• A domain whose users may post to mailing lists should not publish p=reject. If it still wants to, RFC 9989 suggests at least a month at p=none, then an equal period at p=quarantine, to measure the effect.

In short, a domain that sends only order confirmations, forms and newsletters can consider reject. On the other hand, a general purpose domain where staff write to public lists is often better at quarantine. Decide by reading your reports.

How to set up SPF DKIM DMARC in Google Workspace?

In Google Workspace, you handle two of the three records entirely in DNS. The Admin console has no setting for SPF or DMARC, so you add those records where you manage your domain. DKIM, however, starts in the console. If you bought your domain from a Google partner, some records may already exist, so check the current records first.

1. SPF: if you send only through Google, publish v=spf1 include:_spf.google.com ~all in DNS. However, if you have other senders, add them to the same record.
2. DKIM: in the Admin console, open the Gmail email authentication section, select your domain and generate a new record. The default selector is google.
3. Then add the record name and value from the console to DNS. The name looks like google._domainkey, and the value starts with v=DKIM1; k=rsa; p=.
4. When the record has propagated, start authentication from the same section.
5. DMARC: add the _dmarc record from the previous section with p=none.

Do not test by emailing yourself, because Google says you cannot verify DKIM that way. Send to another Gmail or Workspace address instead. Also, if you just turned on Gmail, the DKIM key may take a while to appear in the console. The Google Workspace Admin Help page on DKIM has the details. If you have not chosen a provider yet, read our Google Workspace vs Microsoft 365 comparison.

How to set up SPF DKIM DMARC in Microsoft 365?

In Microsoft 365, neither the admin portal nor PowerShell manages SPF or DMARC records for custom domains. You create those two records at your registrar or DNS service. DKIM takes two stages.

1. SPF: if you send only through Microsoft 365, publish v=spf1 include:spf.protection.outlook.com -all in DNS. Microsoft uses -all in its example, and we discussed that choice in the SPF section. If you have other senders, add them to the same record.
2. DKIM: signing for custom domains does not start by itself. In the Microsoft Defender portal, open the email authentication settings, go to the DKIM tab and select your domain.
3. The portal shows two CNAME records: selector1._domainkey and selector2._domainkey. Copy the target values exactly and add them to DNS.
4. When the portal detects the records, switch signing on.
5. DMARC: add the _dmarc record with p=none in DNS.

Do not guess the target values. Microsoft's documentation says the CNAME target format for newly added domains can differ from older ones. Its examples are for illustration only. The Microsoft Learn page on DKIM has the details. Also remember that every sending subdomain needs its own DKIM setup.

How to set up SPF DKIM DMARC with cPanel or another hosting provider?

If your website runs on a cPanel server, the panel may offer an Email Deliverability screen. It shows the SPF, DKIM and DMARC status of your domains and suggests a value for problem records. A repair option, for instance, can install the suggested record. However, your hosting provider decides whether that screen is available.

Here is the critical point: the records only work if the server is the authoritative name server for your domain. The cPanel documentation on Email Deliverability states this clearly. Otherwise, the record stays local to the server and has no effect. In that case, copy the suggested record and add it where your DNS is managed.

In practice, mixed setups are common in the field. For example, your mailboxes may live in Google Workspace while your website sits on a cPanel server. Then your site forms send from the server, and your SPF record must include both sources. The reverse DNS record of the server's IP is your hosting provider's job, and our PTR record article explains it.

We are not a hosting or email provider. We set up, migrate and manage your website and business email on Google Workspace, Microsoft 365 or your hosting provider.

How do you authenticate newsletter tools, CRMs and website forms?

Third party services send in your name, so each one needs its own setup. Newsletter and CRM tools usually have a domain authentication section in their panel. There the service gives you DKIM records and sometimes asks for a custom envelope sender domain. Once you add those records to DNS, the service signs messages with your domain, and alignment follows. However, add an SPF include only if the service's help page asks for it.

Microsoft's documentation recommends a subdomain instead of your main domain for bulk services you do not control. For example, news.example.com protects the reputation of your main domain. In addition, every subdomain gets its own limit of 10 lookups.

Website forms are a separate trap. Forms often send through the server's own mail function, so they leave from a source that your SPF record does not list. A safer way works like this: put an address on your own domain in the From field, put the visitor's address in Reply-To, and send through an authenticated SMTP account at your mail provider. If you use WordPress, our WordPress email sending guide walks you through it.

How do you test your SPF DKIM DMARC setup?

Adding the records is only half the job. You see the real result in a test. Work through these steps:

1. Enter your domain in our SPF DKIM DMARC checker. It shows the SPF lookup tree, the DKIM selectors and the DMARC policy. If you do not know your selector, leave it blank and the tool scans common selectors.
2. Use the DNS lookup tool to see the raw records. Query selector._domainkey.example.com separately for DKIM, and confirm that the host names are exactly right.
3. Send a real message from each sending service to another Gmail address. Try the form, the newsletter tool and the CRM separately.
4. In Gmail, open the message and choose Show original. Look for pass results for SPF, DKIM and DMARC.
5. Paste the headers into the checker, and it will also show alignment.

If the result is not what you expected, do not change the record right away. That is because DNS changes depend on TTL values (how long caches keep a record) and on caches. Google's help pages also say that records can take time to become active. So wait, then test again.

Which SPF DKIM DMARC mistakes come up most often?

This table lists the mistakes we see most often in the field, with their symptoms and fixes.

Most of these mistakes break a few basic rules: one SPF record, exact host names and DKIM for every sender.

What should you check after setup, and when should you get help?

A setup is not something you finish once and forget. Records also go stale when you add a service or change providers. So run through this checklist regularly:

• Is your list of sending services written down and current?
• Does the domain have exactly one SPF record, with a lookup tree under 10?
• Does DKIM pass for every service, and does it align with your domain?
• Do you read your DMARC reports on a regular schedule?
• Did you delete the include and DKIM records of services you no longer use?
• Do domains that never send email carry v=spf1 -all?

For example, you can add this check to your monthly website maintenance checklist. When you change providers, our business email migration guide is a good reminder not to forget these records.

Expert help saves time if you manage several domains, if you do not hold the DNS login, or if you plan to move DMARC to reject. Request a quote for website and business email setup or migration.