How to Fix Missing SPF and DMARC Records
Your domain is missing an SPF and/or DMARC DNS record. These records authenticate email sent from your domain. Without them, receiving servers can't verify your mail is legitimate, so messages land in spam and anyone can spoof your domain. The fix is publishing TXT records in DNS: SPF on the root domain, DMARC at _dmarc, and DKIM keys from each sending service.
What this means
SPF (Sender Policy Framework) and DMARC (Domain-based Message Authentication, Reporting and Conformance) are DNS TXT records that tell receiving mail servers how to verify email claiming to come from your domain.
SPF lists which servers are allowed to send mail for your domain. When Gmail or Outlook receives a message from you, it checks the sending server's IP against your SPF record. If the IP isn't listed, the message fails SPF.
DMARC ties SPF and DKIM together and tells receivers what to do when a message fails authentication: nothing, quarantine to spam, or reject. It also sends you reports showing who is sending mail as your domain.
The audit flags two related codes:
- no_spf: no
v=spf1TXT record found on your root domain. - no_dmarc: no
v=DMARC1TXT record found at_dmarc.yourdomain.com.
DKIM (DomainKeys Identified Mail) is the third leg of email authentication. It signs messages with a cryptographic key so receivers can confirm the mail wasn't altered and really came from an authorized sender. DMARC needs at least one of SPF or DKIM to pass with alignment before it can enforce a policy, so set up all three.
These records govern email sent from your domain, not your website's HTTP behavior. They still matter as a domain-level security and trust signal, which is why audits check them.
Why it matters
The most immediate impact is deliverability. Since February 2024, Google and Yahoo require SPF, DKIM, and DMARC for bulk senders (Google counts roughly 5,000+ messages a day to personal Gmail accounts), and mailbox providers increasingly treat unauthenticated mail as suspicious. Missing records mean your transactional and marketing email is more likely to land in spam or be rejected, which quietly hurts signups, password resets, and order confirmations.
The second impact is spoofing. Without SPF and an enforcing DMARC policy, anyone can send email that appears to come from your domain. Attackers use this for phishing your customers, invoice fraud, and brand impersonation. A DMARC record at p=reject shuts that down.
For classic SEO, email authentication is not a direct Google ranking factor. But a spoofed domain sending phishing can get flagged in Google Safe Browsing or on blocklists, which damages rankings and traffic. Clean authentication protects your domain's reputation.
For AI answer engines and trust checks, a domain with proper SPF, DKIM, DMARC, HTTPS, and a valid certificate reads as a legitimate, well-maintained entity. Security scanners and brand-safety tools cross-reference this kind of domain hygiene, and a domain that can be freely spoofed is a weaker entity signal than one that can't.
How to fix it
- 1
List every service that sends mail as your domain
Before writing an SPF record, gather the full list of authorized senders, or you'll break legitimate mail. Include your mailbox provider (Google Workspace, Microsoft 365) and every third party that sends on your behalf: transactional providers (SendGrid, Mailgun, Postmark, Amazon SES, Resend), marketing tools (Mailchimp, Klaviyo, HubSpot), your CRM, helpdesk, and invoicing apps. Each vendor documents the SPF
include:value or IP to add. Missing one here is the most common cause of email failing after you publish. - 2
Publish the SPF TXT record on your root domain
Add one TXT record at your root domain (host
@). For Google Workspace usev=spf1 include:_spf.google.com ~all; for Microsoft 365 usev=spf1 include:spf.protection.outlook.com ~all. Chain multiple senders into that single record, for examplev=spf1 include:_spf.google.com include:sendgrid.net ~all. You may have only ONE SPF record per domain, and SPF is capped at 10 DNS lookups, so consolidate rather than adding a second record. Use~all(softfail): with DMARC handling enforcement, softfail avoids bouncing forwarded mail. Reserve-all(hardfail) for domains that send no mail at all. - 3
Set up DKIM with each sending provider
DKIM signs your mail cryptographically and is required alongside SPF under the Gmail and Yahoo bulk-sender rules. In Google Workspace, go to Admin console > Apps > Google Workspace > Gmail > Authenticate email, generate the key, and add the provided TXT record at
google._domainkey. In Microsoft 365, enable DKIM in the Defender portal and add the two CNAME records it gives you (selector1._domainkeyandselector2._domainkey). Each third-party sender (SendGrid, Mailchimp, and so on) has its own DKIM setup that adds CNAME or TXT records. DKIM survives forwarding better than SPF, so it's the stronger signal for DMARC alignment. - 4
Publish a DMARC record in monitoring mode first
Add a TXT record at host
_dmarcwith valuev=DMARC1; p=none; rua=mailto:[email protected]; fo=1. Start atp=noneso you reject no legitimate mail while you learn who is sending as your domain. Theruaaddress receives aggregate reports, so point it at an inbox you'll read or a service that parses them. Wait one to two weeks, review the reports to confirm your legitimate senders pass SPF or DKIM with alignment, and fix any gaps. - 5
Tighten the DMARC policy to enforce
Once reports confirm your real mail authenticates cleanly, move from monitoring to enforcement in stages. Change
p=nonetop=quarantine(failing mail goes to spam), monitor for a week or two, then top=reject(failing mail is bounced). A strict final record looks likev=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s. Onlyp=rejectfully stops spoofing. Don't jump straight to reject without the monitoring phase, or you risk blocking your own newsletters and app notifications. - 6
Re-test and re-run the audit
Verify with a free checker (MXToolbox, Google Admin Toolbox, or dmarcian) that each record resolves and parses without syntax errors. Send a test message to a Gmail account, open it, choose Show original, and confirm SPF, DKIM, and DMARC all show PASS. DNS changes can take up to 24-48 hours to propagate, so allow time before re-running your audit to clear the no_spf and no_dmarc flags.
Example
; SPF - host: @ (root domain), type: TXT
; Combine every service that sends mail for you into ONE record.
@ IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"
; DMARC - host: _dmarc , type: TXT
; Start in monitoring mode (p=none), then step up to quarantine, then reject.
_dmarc IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"
; After 1-2 weeks of clean reports, tighten to enforcement:
_dmarc IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s"Two TXT records to publish: SPF on the root domain, DMARC at the _dmarc subdomain. Replace the includes with your actual senders and use your own reporting address.
Frequently asked
Use ~all (softfail) in almost all cases. It marks unauthorized mail as suspicious without hard-rejecting it, which keeps legitimate forwarded mail from bouncing. With a strict DMARC policy (p=reject) handling actual enforcement, softfail gives you the protection of a hardfail without the deliverability risk. Reserve -all (hardfail) for parked domains that never send email.
You can, but you shouldn't unless the domain sends no mail. Jumping to p=reject before every legitimate sender authenticates with alignment risks silently rejecting your own newsletters, receipts, and app notifications. Start at p=none, read the aggregate reports for one to two weeks, fix any senders that fail, then step up to p=quarantine and finally p=reject.
You need DKIM. Since February 2024, Gmail and Yahoo require SPF, DKIM, and DMARC for bulk senders, and DMARC itself needs at least one of SPF or DKIM to pass with alignment before it can enforce anything. DKIM also survives email forwarding, where SPF often breaks, so it's the more reliable signal. Set up all three.
Common causes: DNS hasn't finished propagating (allow up to 48 hours), a service you send through isn't in your SPF record, DKIM isn't configured for that service, or your DMARC is still at p=none so nothing is enforced. Send a test to Gmail, use Show original, and check which of SPF, DKIM, and DMARC failed. Poor content and list hygiene can also trigger spam filtering regardless of authentication.
Exactly one per domain. Publishing two SPF TXT records is a configuration error and makes SPF fail with a permerror. To authorize multiple senders, combine them into a single record with multiple include: mechanisms. Also stay within the 10-DNS-lookup limit; if you exceed it, use SPF flattening or drop unused includes.
Does your site have this issue?
Run a free, AI-powered audit and we’ll flag this and 150+ other checks in about a minute. No signup.