This SPF DKIM DMARC setup guide covers authorising your sending services in DNS, enabling DKIM signing, then starting DMARC monitoring. Move to enforcement only after legitimate messages pass with domain alignment.
For a small business, missing a sender can disrupt invoices, client updates or website enquiries. Correct records help protect your domain against email spoofing and phishing, but they don’t guarantee inbox placement.
A reliable email authentication setup starts with identifying everything that sends email using your domain.
Key takeaways
- Inventory business mailboxes, contact forms, email marketing platforms and automated systems before changing DNS.
- Publish one SPF policy per hostname, and enable DKIM signing separately in each sending service.
- Begin DMARC with
p=none, inspect reports and received messages, then tighten the policy once legitimate traffic passes.
What SPF, DKIM and DMARC each check
SPF authorises servers; DKIM verifies signatures
SPF (Sender Policy Framework) checks whether the sending server’s IP address is authorised for the envelope sender domain. That’s the MAIL FROM domain, usually reflected in Return-Path. The Return-Path domain can differ from the visible From address, which SPF doesn’t authenticate.
DKIM (DomainKeys Identified Mail) signs outgoing messages with a private key held by the sending service. Receivers verify the DKIM signature with a public key in DNS at selector._domainkey.yourdomain.com. The matching public key confirms that the private key created the signature and helps verify message integrity.
SPF and DMARC use DNS TXT records. DKIM public keys also use TXT records, although some providers require CNAME records that point to a provider-managed public key.
DMARC requires an aligned authentication pass
DMARC (Domain-based Message Authentication, Reporting, and Conformance) passes when SPF or DKIM passes and the passing domain aligns with the domain in the visible From header. This match is DMARC alignment. Both protocols don’t need to pass for DMARC itself.
For SPF, alignment concerns the envelope sender domain. For DKIM, it concerns the signature’s d= domain. Under default relaxed alignment, subdomains can align with their organisational domain.
The DMARC specification defines this relationship. A platform can pass authentication using its own domain whilst failing DMARC for yours.
Prepare your sender inventory and DNS access
Identify every legitimate sending service
List business mailboxes, CRM follow-ups, booking notifications, invoicing tools and email marketing platforms. Include website contact forms and any separate systems and automation services.
For each sender, record its owner, sending domain and authentication settings. A web development team may manage form notifications separately from your mailbox administrator.
Treat this inventory as part of website care and maintenance. New integrations can introduce new sending routes long after the original setup.
Find the active DNS service
DNS may sit with your registrar, web hosting provider or another supplier. Our domain ownership checklist helps establish account access and control.
Export existing DNS records before editing. Leave MX records alone unless you’re changing inbound email routing.
DNS panels often append your domain automatically. Entering a complete hostname into such a field can create a duplicated domain name, so inspect the resulting hostname before saving.
Publish one SPF record for each sending hostname
In your active DNS panel, find the TXT record beginning v=spf1. Edit that policy rather than adding another SPF record at the same hostname. Duplicate policies cause authentication errors.
These provider-specific DNS TXT record examples apply only when the named provider is the hostname’s sole authorised sender:
| Provider | Host | TXT value |
|---|---|---|
| Google Workspace | @ | v=spf1 include:_spf.google.com -all |
| Microsoft 365 | @ | v=spf1 include:spf.protection.outlook.com -all |
The include mechanism incorporates the provider’s authorised sending systems. The final -all declares other sources unauthorised.
If both providers genuinely send for that hostname, combine their mechanisms into one policy. Preserve other legitimate senders rather than copying these examples blindly or replacing existing entries. Google’s SPF setup guidance covers its provider-specific configuration.
SPF permits 10 DNS-querying terms per evaluation, including nested includes. This DNS lookup limit is defined in RFC 7208. An evaluation that exceeds the limit returns permerror.
Don’t add services indiscriminately. Some third-party platforms use their own envelope domain, so adding their include to your root SPF record won’t create alignment.
Enable DKIM in your email provider
Google Workspace: generate and activate the key
In the Google Admin console, open Apps, Google Workspace, Gmail, then Authenticate email. Select your domain and generate a DKIM record, preferably using a 2048-bit key.
Google displays the selector hostname and complete TXT value. A selector named google creates google._domainkey.yourdomain.com. Paste the supplied value, including its p= public key, into DNS.
After publication, return to the console and start authentication. Publishing the key alone doesn’t activate signing.
Gmail’s sender guidelines require keys of at least 1024 bits and recommend 2048 bits.
Microsoft 365: publish both selector records
Open your domain’s DKIM settings in the Microsoft Defender portal. Microsoft supplies two CNAME records, normally using selector1._domainkey and selector2._domainkey as their hostnames.
Publish both with the exact destinations generated for your tenant, then enable DKIM signing. Don’t copy another organisation’s CNAME targets.
Configure each additional sending platform separately. Distinct selectors allow multiple providers to sign for the same domain. The private key stays with the signing service; never publish it in DNS.
Start DMARC monitoring with a reporting address
Create a TXT record at _dmarc.yourdomain.com. Some DNS panels need only _dmarc in the host field.
Use this monitoring example, replacing the domain with yours:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
Before publishing the rua address in your DMARC record, make the reporting mailbox operational so it can receive DMARC reports. Aggregate reports are usually XML files, so a report viewer helps interpret sending IPs, volumes and authentication results.
The DMARC policy sets the treatment receivers are asked to apply. p=none monitors without requesting special handling. p=quarantine asks receivers to treat failures as suspicious, often by placing messages in the spam folder. p=reject requests rejection. Receivers retain discretion over handling.
Optional forensic or failure reports use ruf, rather than rua. Support varies, and these reports can contain message-related personal information. Aggregate reports are the practical starting point for most businesses.
Validate DNS and received message headers
Check publication and propagation
Use a DNS lookup tool to query TXT records for your domain, _dmarc.yourdomain.com and the DKIM selector hostname.
For example, dig TXT google._domainkey.yourdomain.com +short queries the public key for Google’s google selector. For Microsoft 365, query the selector’s CNAME and its destination.
Confirm there’s one SPF policy and one DMARC record at their respective hostnames. Existing DNS answers can remain cached until their previous TTL expires, so a saved change may not appear everywhere immediately.
Read Authentication-Results field by field
Send a fresh message from every service to an external mailbox. In Gmail, choose Show original; elsewhere, open the full email headers and locate Authentication-Results.
With a visible From address at yourdomain.com, interpret the fields together:
spf=pass smtp.mailfrom=bounces.yourdomain.com means the sending IP passed SPF for that envelope domain.
Next, dkim=pass header.d=yourdomain.com means the signature verified using that signing domain.
Finally, dmarc=pass header.from=yourdomain.com confirms an aligned authentication pass.
A pass under a provider’s unrelated domain doesn’t establish alignment with yours. Also inspect inbox, junk and quarantine placement.
A receiving server accepting a message doesn’t prove it reached the recipient’s inbox.
Fix third-party senders and contact form failures
When a service fails, compare the published records with its exact authentication settings. Then inspect a newly received message to establish whether it signs outgoing mail.
If SPF passes under the platform’s own domain, configure its custom return-path feature where available. Otherwise, enable DKIM signing aligned with your domain.
For website enquiries, use your authorised business address as From and the visitor’s address as Reply-To. Using a visitor’s Gmail address as From impersonates a domain your website doesn’t control. Our guide to troubleshooting WordPress form emails covers this sending route.
Forwarding often breaks SPF because the sending IP changes. DKIM can survive unchanged forwarding, but mailing lists or forwarding services can invalidate signatures by altering signed headers or message content.
Move towards enforcement after reviewing reports
Review aggregate reports across a complete business sending cycle, including less frequent invoices and campaigns. Resolve legitimate sources with failed authentication or alignment before tightening policy.
Move to DMARC enforcement only after reports show legitimate sending services pass consistently. Change p=none to p=quarantine, then review reports and delivery failures before moving to p=reject. Base each change on observed traffic, not a fixed deadline.
Google requires SPF, DKIM and DMARC for bulk senders. Microsoft’s high-volume sender requirements also require all three for domains sending over 5,000 messages daily to its consumer services. These provider rules can be stricter than DMARC’s own pass condition.
Assign an owner to email authentication changes. Re-test whenever you add a CRM, replace a sending platform or change website forms. Otherwise, an enforced policy can block a newly introduced legitimate service.
Frequently asked questions
Do I need DMARC if SPF and DKIM already work?
Yes. DMARC adds alignment with your visible From domain, reporting and a handling policy for failures. SPF and DKIM alone don’t provide that combined protection against domain spoofing.
You can publish DMARC before completing authentication, but remain in monitoring mode while fixing legitimate senders.
Will passing authentication guarantee delivery?
No. Content, complaints, sending reputation and recipient filtering also affect delivery.
Use permission-based mailing lists rather than purchased contacts. Authentication confirms aspects of a message’s origin; it doesn’t establish that recipients wanted it or that its content is safe.
Keep business email working as your systems change
Reliable email authentication depends on complete sender coverage. Publish provider-specific records, prove alignment with received messages and use reports before enforcing rejection.
Keep the sender inventory current whenever your website or follow-up systems change. That protects legitimate client communication whilst giving receivers clearer instructions for unauthorised mail.
