SPF, DKIM and DMARC setup for small business email

To get business email into the inbox, publish exactly one SPF record that lists every service sending as your domain, turn on DKIM signing in each of those services, and add a DMARC record that starts at p=none. Then test with Gmail's Show original, read the reports for a few weeks, and only tighten the policy once everything legitimate passes.

Here is the scene this guide is written for (a made-up example). Priya runs a small bakery. Her invoices started landing in customers' spam folders, so she asked a developer why. The reply was one line: "Your domain has no DMARC record." By the end of the week she had fixed it, and it took less than an hour of real work. The surprising part, which you will meet further down, was that her first attempt made things worse: she added a second SPF record, and it quietly broke the first one.

By the end of this guide you will know what each record does, have the exact records and clicks for Google Workspace, Microsoft 365 and cPanel hosting email, know how to check your work from a terminal or a browser, and know how to fix the mistakes that catch nearly everyone.

What SPF, DKIM and DMARC actually are

When an email arrives, the receiving server asks three questions about it. Each record answers one of them.

• SPF (Sender Policy Framework): "Is this server allowed to send mail for this domain?" It is a list of approved senders, published as a TXT record on your domain.
• DKIM (DomainKeys Identified Mail): "Was this message really signed by the domain, and was it changed on the way?" Your mail service signs every message with a private key, and you publish the matching public key in DNS.
• DMARC (Domain-based Message Authentication, Reporting and Conformance): "If those checks fail, what does the domain owner want me to do, and where should I send reports?" It is a TXT record at _dmarc.yourdomain.

Think of it like a delivery to an office building. SPF is the guest list at reception, DKIM is the tamper-proof seal on the parcel, and DMARC is the note from the building manager: "If someone is not on the list and the seal is broken, turn them away, and send me a daily summary."

DMARC adds one more idea that trips people up: alignment. The domain people see in the From line must match the domain that passed SPF or DKIM. In the default relaxed mode, the organisational domains only need to match (so mail.example.com aligns with example.com); strict mode needs an exact match. A newsletter tool that passes SPF for its own domain, not yours, does not help your DMARC at all.

Do Gmail, Yahoo and Outlook really require this?

Yes. At the time of writing (3 October 2026), the big mailbox providers publish clear rules, and they are stricter for high-volume senders.

• Gmail, everyone sending to personal Gmail accounts (since 1 February 2024): set up SPF or DKIM, have valid forward and reverse DNS for your sending servers, use a TLS connection, and keep the spam rate shown in Postmaster Tools below 0.3%.
• Gmail, senders of 5,000 or more messages a day: all of the above plus SPF and DKIM together, a DMARC record, alignment between the From domain and the SPF or DKIM domain, and one-click unsubscribe on marketing and subscribed messages.
• Yahoo: all senders need at least SPF or DKIM and a low spam rate; bulk senders need SPF and DKIM, a DMARC policy of at least p=none, alignment, one-click unsubscribe, and must honour unsubscribes within 2 days.
• Outlook.com and other Microsoft consumer mail: domains sending 5,000 or more messages to Microsoft consumer services must pass SPF and DKIM and publish a DMARC policy of at least p=none that passes with alignment. Mail that fails can be rejected with "550 5.7.515 Access denied, sending domain does not meet the required authentication level."

If you send a few hundred emails a month, you are far below the bulk lines. Set up all three anyway. It is the same hour of work, and it stops strangers from sending convincing fake invoices in your name.

Before you start

Collect these first so you are not hunting halfway through.

• Access to your DNS. Your records live wherever your domain's nameservers point: your registrar, your hosting panel, or a service like Cloudflare. If you are not sure where that is, our guide on connecting a domain to hosting shows how to find out.
• Admin access to every service that sends email as your domain. Your mailbox provider (Google Workspace, Microsoft 365, or your hosting email), plus your website contact form, invoicing or accounting tool, booking system, and newsletter platform. Write the list down. It is the most important hour you will spend on this.
• An inbox for reports. A mailbox or alias such as dmarc-reports@example.com, because DMARC reports arrive as XML files and can be frequent.
• A test address at Gmail, and ideally one at Outlook.com too.
• Time and risk. About an hour of work, then a few weeks of watching reports. Low risk if you start with p=none, which never blocks anything.

Step 1: Build one SPF record

SPF is a single TXT record on your root domain (example.com, written as @ in most DNS panels). It starts with v=spf1, lists your senders, and ends with an all rule that says what to do with everyone else.

If only Google Workspace sends your mail

Google's recommended record is:

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

If only Microsoft 365 sends your mail

Microsoft's documented record is:

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

If several services send as you

Combine them into the same single record, one include: per service, using the exact value each service publishes in its own help pages. Google's own example adds Amazon SES next to Workspace like this:

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

A fixed server address goes in with ip4: (or ip6:). This made-up example covers Microsoft 365 plus one office server at a documentation address:

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

Soft fail or hard fail?

The ending is a judgement call, and the two big providers word it differently. Google recommends ~all (soft fail: mark unlisted senders as suspicious). Microsoft recommends -all (hard fail: unlisted senders are not authorised) when you also run DKIM and DMARC, because DMARC then decides what happens. Either is fine for a small business. What is never fine is +all, which authorises the whole internet.

The two SPF rules you must not break

• Only one SPF record per domain. RFC 7208 says a domain "MUST NOT have multiple records that would cause an authorization check to select more than one record". Two v=spf1 records give a permanent error, which means SPF fails for everyone. This is exactly what happened to Priya: she added a second record for her newsletter tool and broke both. The fix was to merge them into one.
• No more than 10 DNS lookups. The standard limits SPF evaluation to 10 lookup terms. include, a, mx, ptr, exists and the redirect modifier count; ip4, ip6 and all do not. Includes can contain more includes, so three or four services can quietly blow the budget. Remove services you no longer use, and consider a subdomain such as news.example.com for bulk tools, which Microsoft suggests because each subdomain gets its own 10-lookup budget.

Quick tip: subdomains that send email need their own SPF record. A record on example.com does not cover news.example.com.

Step 2: Turn on DKIM for every sender

DKIM has two halves: a public key you publish in DNS, and signing that you switch on inside the sending service. Publishing the key alone does nothing.

Google Workspace

1. In the Google Admin console, go to Menu > Apps > Google Workspace > Gmail, then click Authenticate email.
2. Select your domain and generate a new record. Choose a 2048 bit key if your DNS host supports it (otherwise 1024), and keep the default selector prefix google.
3. Copy the DNS host name (it will be google._domainkey) and the long TXT value, and add them as a TXT record at your DNS host.
4. Wait. Google says it can take up to 48 hours for DKIM to start working.
5. Back on the same page, click Start authentication. The status should change to Authenticating email with DKIM.

Microsoft 365

1. In the Microsoft Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings, and open the DKIM tab.
2. Select your custom domain. The details panel shows two CNAME records to publish, named selector1._domainkey and selector2._domainkey.
3. Create both CNAME records at your DNS host, copying the target values exactly from the portal.
4. Wait a few minutes, return to the domain, and choose Sign messages for this domain with DKIM signatures. The status should read Signing DKIM signatures for this domain.

Heads up: Microsoft changed the format of the CNAME targets for domains added from May 2025 (new targets end in dkim.mail.microsoft instead of onmicrosoft.com). Do not copy a value from an old blog post. Always take it from your own portal.

cPanel hosting email

If your mailboxes live on cPanel hosting, open Email > Email Deliverability in cPanel (your host has to have this tool enabled). It checks DKIM, SPF and the reverse DNS (PTR) record for each domain. Repair applies the suggested records for you when cPanel runs your DNS. If your DNS is somewhere else, such as Cloudflare, click Manage, copy the suggested record names and values, and add them at your DNS provider.

Everything else that sends as you

Your newsletter platform, invoicing tool and website form plugin almost always have a "domain authentication" or "custom domain" page with their own DKIM records. Set it up in every one of them. This is what makes DMARC alignment pass for mail you did not send from your own mailbox.

Step 3: Add DMARC in monitoring mode

DMARC is one TXT record at the host name _dmarc (meaning _dmarc.example.com). Start with a policy that only observes:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Here is what the parts mean, in plain words:

• v=DMARC1 says this is a DMARC record. It must come first.
• p=none asks receivers to take no special action on failures, only to report them. This is the safe starting point, and Gmail, Yahoo and Outlook.com all accept it for bulk senders.
• rua=mailto:... is where daily summary reports go. RFC 7489 sets the default reporting interval to 86400 seconds, which is one day.

Other tags you will see later: sp sets a separate policy for subdomains (if absent, subdomains follow p), pct applies the policy to only a percentage of failing mail (default 100), and adkim and aspf choose relaxed (r, the default) or strict (s) alignment.

Heads up: if the report address is on a different domain from the one you are protecting, the receiving domain has to publish a small authorisation record before reports are delivered. Keeping the report mailbox on your own domain avoids that extra step.

Step 4: Read the reports and fix every sender

Aggregate reports arrive as zipped XML files listing which servers sent mail as your domain and whether each passed SPF, DKIM and alignment. Raw XML is painful to read, so most people forward them to a DMARC report viewer (several offer a free tier) or open them in a parser.

What to look for over two to four weeks:

• Your real services failing alignment. Typical culprits: a website contact form sending through the web server, an invoicing tool, a CRM. Fix them with that tool's domain authentication (DKIM), or by adding it to SPF if it sends from your servers.
• Unknown senders. Servers you do not recognise sending as your domain are either forgotten tools or spoofing. Ask around before you assume either.
• Forwarding. Mail forwarded through another server can fail SPF, because that server is not on your list. A DKIM signature usually survives as long as the message is not changed on the way, which is one more reason DKIM matters.

Step 5: Tighten the policy, slowly

Once every legitimate source passes for a few weeks, move gradually. Google's guidance is to go from none to quarantine with a partial pct, then to reject at 100% once you are confident.

This record sends a quarter of failing mail to spam and reports on the rest:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com

When reports stay clean at pct=100, the final step is:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

Why this matters: p=reject is what actually stops criminals from spoofing your domain. But it also blocks your own forgotten invoicing tool. That is why the reports come first. Moving to enforcement is optional and your decision; p=none already meets the published bulk-sender rules.

How to check it worked

From a terminal

These commands show what the world sees. On Windows, use the nslookup lines instead.

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT google._domainkey.example.com
dig +short CNAME selector1._domainkey.example.com

You should see exactly one line starting with v=spf1, one starting with v=DMARC1, and your DKIM key (Google) or CNAME target (Microsoft).

nslookup -type=TXT example.com
nslookup -type=TXT _dmarc.example.com

In Gmail

Send a message from your domain to a Gmail address, open it, click More (the three dots) next to Reply, and choose Show original. The full headers open in a new window, and the summary at the top lists the SPF, DKIM and DMARC results. You want PASS on all three. Repeat the test from every tool that sends as your domain, not only your mailbox.

Free checkers

Google's Admin Toolbox Check MX tool tests a domain's mail setup, including SPF and an optional DKIM selector. For the long view, add your domain to Google Postmaster Tools (add the domain, then verify it with the TXT or CNAME record it gives you); its dashboards show your spam rate, reputation, authentication results and delivery errors for Gmail.

Troubleshooting

"SPF: PermError" or "multiple SPF records"

You have two v=spf1 TXT records. Merge them into one record with all the include: entries, then delete the extra.

SPF fails with "too many DNS lookups"

Your record, including all nested includes, needs more than 10 lookups. Remove unused services, replace an include with ip4: addresses where the provider documents fixed ranges, or move a bulk sender to a subdomain with its own record.

DKIM shows "neutral" or "no key" even though you added the record

Either signing is not switched on in the service yet, the host name is wrong (many DNS panels add your domain automatically, so google._domainkey.example.com typed in full becomes google._domainkey.example.com.example.com), or the record has not reached the internet yet. Check with dig, fix the name, and wait.

DMARC fails although SPF and DKIM both pass

That is an alignment failure. The passing domain belongs to the sending service, not to you. Set up the service's custom domain authentication so its DKIM signature uses your domain.

Outlook.com rejects mail with 550 5.7.515

Microsoft is saying your domain does not meet its authentication requirements for high-volume senders. Confirm SPF and DKIM pass and that a DMARC record of at least p=none exists and passes with alignment.

Changes in the registrar do nothing

Your nameservers point somewhere else, so the registrar's DNS page is not live. Edit records where the nameservers point. Our guide on Hostlelo nameservers and changing them safely shows how to check.

Website contact form emails go to spam

The form is probably sending through the web server with your address in the From line, unsigned. Switch the form to send through your real mailbox or a transactional email service with DKIM on your domain, then test it with Show original.

The one message worth forwarding

Send this to whoever manages your DNS or IT:

"Please check that example.com has exactly one SPF record that includes every service sending as us, that DKIM signing is switched on in Google Workspace or Microsoft 365 and in our newsletter and invoicing tools, and that a DMARC record starting at p=none with reports to dmarc-reports@example.com is in place. Then send a test to Gmail and confirm Show original says PASS for SPF, DKIM and DMARC."

The takeaway: one SPF record, DKIM switched on everywhere, DMARC at p=none with reports, and Show original as your proof, today.