SPF, DKIM and DMARC setup for small business email

To authenticate business email sent as your domain, publish one SPF record for each sending domain, enable DKIM signing where supported, and add a DMARC record at _dmarc. Start with p=none while you inventory mail streams. Test representative messages with Gmail's Show original, investigate the reports, and tighten the policy only after legitimate senders are aligned. Authentication can reduce spoofing, but it does not guarantee inbox placement.

A common troubleshooting pattern is a domain used by a mailbox provider, an invoicing app and a newsletter platform. Each stream needs its own authentication checks. Finding a missing DMARC record is one clue, not proof of why a message reached spam; reputation, message content, consent and recipient filtering also matter.

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.

As a rough analogy, SPF is a guest list and DKIM is a tamper-evident seal. DMARC connects an authenticated domain to the visible From address, then publishes the owner's requested handling for failures and reporting destinations. The receiver still decides how to handle the message.

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."

Even if you send relatively little mail, configure the authentication your providers support. Inventory every legitimate sender first. The work may be quick for one mailbox provider or much longer for several services, and DMARC cannot prevent lookalike domains, display-name impersonation or abuse of an authorized sender.

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 depend on the number of senders and who controls DNS. Start with p=none to avoid requesting rejection through DMARC while you inventory and test mail streams. Receivers may still filter or reject mail under their own policies.

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: the sender is probably not authorised). Microsoft recommends -all (fail: the sender is not authorised) when DKIM and DMARC are also configured. Follow your provider's guidance after inventorying legitimate senders; the receiver determines final handling. Do not use +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 at the same name produce a permanent error rather than an SPF pass. If a newsletter tool needs authorization, merge its documented mechanism into the existing record instead of adding another v=spf1 record.
• 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 requests no DMARC-specific enforcement. With rua configured, receivers can report on passing and failing mail; they may still filter messages under their own policies. Gmail, Yahoo and Outlook.com accept p=none as the minimum DMARC policy for bulk senders.
• rua=mailto:... identifies where you request aggregate reports. Report generation, delivery and timing depend on the receiver, so absence of a report does not prove that no one used your domain.

Other tags include sp for a subdomain policy and adkim and aspf for relaxed (r) or strict (s) alignment. RFC 9989, published in May 2026, supersedes RFC 7489 and removes the legacy pct percentage tag. Some provider documentation still describes pct; do not treat it as a reliable cross-provider percentage safety control.

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 investigate senders

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.

Check the following across your sending cycle, including infrequent business mail; two to four weeks may not cover every legitimate stream:

• Your real services failing alignment. Typical culprits include website forms, invoicing tools and CRMs. Configure the provider's custom-domain DKIM signing, or its documented SPF setup with an envelope-sender domain aligned to your From domain. Adding an SPF include alone does not establish alignment.
• Unknown senders. Unrecognised sources can be forgotten services, forwarders or spoofing. Investigate them against your sender inventory; do not authorise an address merely because it appears in a report.
• 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: Decide whether enforcement fits your domain

After checking legitimate mail streams, assess whether quarantine is appropriate. Reject is not an automatic final step: RFC 9989 section 7.4 advises against p=reject for domains whose users may post to Internet mailing lists. If considering it despite that risk, the RFC recommends at least a month at p=none and an equally long quarantine period, comparing report dispositions and addressing user impact. Rare senders may require longer observation. Keep a tested rollback plan.

This example requests quarantine treatment for DMARC-failing mail; it does not specify a fraction. RFC 9989 removed the old pct tag because nontrivial percentages were not applied consistently. Receiver policy still determines final handling:

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

Only if rejection is appropriate for the domain and the interoperability risks have been addressed, an example policy is below. RFC 9989 requires domains publishing p=reject to apply valid DKIM signatures, not rely solely on SPF for DMARC passage:

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

p=reject asks receivers to reject messages that fail DMARC alignment, but the receiving system makes the final handling decision. It does not eliminate lookalike-domain fraud, display-name impersonation or abuse of an authorised or compromised sender. Inventory legitimate senders and resolve alignment failures before enforcement so you do not request rejection of your own business mail.

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 representative message from each service to a Gmail address, open it, click More (the three dots) next to Reply, and choose Show original. The header summary lists SPF, DKIM and DMARC results. Confirm DMARC pass because at least one successful SPF or DKIM identifier aligns with the visible From domain. Inspect both mechanisms and improve the failing path when feasible. A forwarded message can fail SPF yet pass aligned DKIM and therefore pass DMARC. Do not infer inbox placement from these results alone.

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"

Multiple SPF records are one possible cause of PermError. If the same domain name has two v=spf1 TXT records, merge the legitimate mechanisms into one, including the needed include: entries, then remove the duplicate. If only one SPF record exists, inspect its syntax and DNS-lookup limits instead.

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

Neither passing SPF nor passing DKIM domain aligns with the visible From domain. Configure the service to use an aligned DKIM signing domain or an aligned SPF-authenticated envelope-sender domain, then retest representative messages.

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 inventory every service sending as us, publish one valid SPF record for each relevant sending domain, and enable aligned DKIM signing where supported. Start DMARC at p=none with aggregate reports requested at dmarc-reports@example.com. Send representative tests from each service to Gmail and confirm DMARC PASS through aligned SPF or DKIM. Inspect both authentication paths, meet any stricter bulk-sender requirements, and review occasional senders, forwarding and mailing-list use before considering enforcement."

The takeaway: inventory senders, configure SPF and aligned DKIM, start DMARC at p=none, and combine representative message checks with report review. One passing test is not proof of every mail stream, inbox placement or protection from every impersonation attempt.