SPF, DKIM and DMARC for a startup domain: the exact records
Copyable SPF, DKIM and DMARC records for Google Workspace, Microsoft 365 and sending services, and the order to tighten DMARC to reject safely.
LLaunchScaler·Published ·8 min read
A startup domain needs three DNS TXT records: one SPF record on the root domain listing every service that sends your mail, a DKIM key published at each provider's selector, and a DMARC record at _dmarc.yourdomain.com that starts at p=none with a report address. Once the reports show every legitimate sender passing, tighten DMARC to p=quarantine and then p=reject.
Google and Yahoo have required this of bulk senders since February 2024. Below are the exact records for Google Workspace, Microsoft 365 and a transactional sending service, and the order to tighten them without losing mail.
What do SPF, DKIM and DMARC each do?
SPF says which servers may send mail for your domain. DKIM signs each message so the receiver can check it was not altered and came from a key you published. DMARC ties them to the address people see in the From line and tells receivers what to do when neither passes.
Record
Where it lives
What it proves
Fails when
SPF
TXT on the domain in the envelope sender (the return path)
The sending IP is on your list
Mail comes from a server not in the record, or the record is invalid
DKIM
TXT (or CNAME) at
Questions, answered
What people ask about this
01
What is the difference between SPF, DKIM and DMARC?
SPF lists which servers may send mail for your domain, DKIM signs each message with a key published in your DNS, and DMARC tells receivers what to do when a message fails both and where to send reports. DMARC only passes when SPF or DKIM passes for a domain that matches the From address.
No signature, a wrong key, or the message changed in transit
DMARC
TXT at _dmarc.yourdomain.com
SPF or DKIM passed for a domain aligned with the From address
Neither passes with alignment
Alignment is the part people miss. Under RFC 9989, the DMARC standard published in May 2026, SPF and DKIM alignment default to relaxed (aspf=r, adkim=r), which means the passing domain only has to share your organisational domain. Mail signed by send.yourdomain.com aligns with a From address on yourdomain.com; mail signed by the sending service's own domain does not.
What is the correct SPF record?
Publish exactly one TXT record on your root domain that starts with v=spf1, lists every sender with include: or ip4:, and ends with ~all or -all. Two SPF records on the same name make SPF return a permerror, and so does a record that needs more than 10 DNS lookups to evaluate.
Google recommends ~all (soft fail) for Workspace. Microsoft recommends -all (hard fail), because with DKIM and DMARC in place DMARC decides what happens, and Microsoft notes that a DMARC policy is effectively ignored for ~all failures on messages that carry no DKIM signature. Either is fine once DKIM and DMARC are set up. Never end with +all: RFC 7208 says all always matches, so a pass qualifier on it approves every server on the internet.
The rules that break SPF most often:
A second SPF record added by a new tool's setup wizard. Merge its include: into the existing record and delete the extra one.
More than 10 lookups. RFC 7208 counts each include:, a, mx, ptr, exists and redirect, including those inside nested includes, while ip4:, ip6: and all are free. It also caps void lookups (names that return nothing) at two. Microsoft suggests moving extra services to their own subdomain, which gets its own 10-lookup budget.
Syntax slips such as include= instead of include:, a space after the colon, or a trailing period after the domain.
Many transactional services avoid the root record entirely by using a subdomain for the return path. Resend, for example, defaults the return path to send.yourdomain.com and generates the SPF and DKIM records for you to copy. Because SPF is checked against the return-path domain, that service's SPF record lives on the subdomain and your root record does not change.
How do you set up DKIM?
Turn on DKIM signing in each service that sends your mail, publish the public key it gives you at its selector, then switch signing on. Every provider uses its own selector, so a domain with three senders has three DKIM records, and they never conflict.
Google Workspace: in the Admin console go to Apps, Google Workspace, Gmail, Authenticate email, generate a 2048-bit key, and publish it as a TXT record at google._domainkey (the default selector). Then return and click Start authentication. Google allows up to 48 hours for it to take effect.
Microsoft 365: publish two CNAME records, selector1._domainkey and selector2._domainkey, pointing to the values the Defender portal shows for your domain (they have the form selector1-yourdomain-com._domainkey.<tenant>.<partition>-v1.dkim.mail.microsoft), then enable DKIM signing for the domain.
A sending service: copy the DKIM record from its domain settings exactly as shown. Resend's docs say the records must match what it generated and suggest pasting rather than typing.
To confirm a key is live, query it: dig +short TXT google._domainkey.yourdomain.com should return a value starting v=DKIM1; k=rsa; p=. Then send yourself a message and look for dkim=pass in the Authentication-Results header.
What DMARC record should you publish?
Start with a monitoring record and a mailbox for reports: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com, published as a TXT record at _dmarc.yourdomain.com. p=none changes nothing about delivery; it only asks receivers to send daily aggregate reports so you can see who sends mail as your domain.
The tags you will use, as RFC 9989 defines them:
Tag
Values
Default
What it does
v
DMARC1
Required, first
Marks the record as DMARC
p
none, quarantine, reject
none
Policy for mail that fails DMARC
rua
mailto: addresses
None
Where aggregate reports go; no reports without it
sp
none, quarantine, reject
Falls back to p
Policy for existing subdomains
np
none, quarantine, reject
Falls back to sp, then p
Policy for subdomains that do not exist
adkim, aspf
r (relaxed), s (strict)
r
Alignment mode for DKIM and SPF
t
y, n
n
Test mode: with t=y, receivers apply one level below your policy
RFC 9989 obsoletes RFC 7489 and removes the old pct tag, which let you apply a policy to a percentage of mail. Its replacement is t=y: p=reject; t=y asks receivers to quarantine instead, and p=quarantine; t=y asks them to take no action. Google's own example record still shows pct=100, so expect to see it in older guides.
Aggregate reports arrive daily as XML at the rua address, and Google warns large organisations can get hundreds or thousands a day. Use a dedicated mailbox or group, and read them with a DMARC report tool rather than by hand.
In what order should you tighten DMARC?
Move from p=none to p=quarantine to p=reject only after the reports show every service that legitimately sends as your domain passing SPF or DKIM with alignment. Each step makes receivers stricter, so an unlisted sender that was merely reported at p=none gets its mail sent to spam, then refused.
Publish SPF and DKIM for every sender you know about: your mailbox provider, your transactional email service, your newsletter tool, your billing and support tools.
Read the reports for at least a few weeks, covering every regular send such as invoices and monthly newsletters. List each source IP or service and whether it passes.
Fix every legitimate sender that fails: add its include:, turn on its DKIM, or move it to a subdomain with its own records.
Change to p=quarantine; t=y (receivers still take no action) and keep reading reports, then drop t=y.
Move to p=reject; t=y (receivers quarantine), then p=reject.
Keep rua on permanently. A new tool that starts sending as your domain shows up in the reports before its mail starts disappearing.
For domains you own but never send from, skip the ramp: publish v=spf1 -all and v=DMARC1; p=reject; straight away, so nobody can send as them.
What do Google and Yahoo require from senders?
Since February 2024 both require every sender to authenticate with SPF or DKIM, and bulk senders to have SPF, DKIM and a DMARC record of at least p=none with the From domain aligned. Google's threshold for bulk is 5,000 or more messages a day to Gmail accounts.
Google asks for below 0.10%, and never 0.3% or higher
Valid forward and reverse DNS for sending servers
Required
Required
Yahoo's list matches on authentication and adds that unsubscribe requests must be honoured within 2 days. A startup sending product mail through a transactional service can cross the bulk line on a single busy day, so set all three records up before launch rather than after.
How do you check your records?
Query each record with dig and read the result. Three commands cover the domain:
The first should print exactly one line. The second should print one v=DMARC1 record. The third, with your provider's selector in place of google, should print a v=DKIM1 key. Then send a test message to a Gmail account, open it, choose Show original, and confirm SPF, DKIM and DMARC each say PASS.
To check the DNS side of your domain in one pass, run the free scan on LaunchScaler. It needs only your URL and no account, and its free DNS checks read whether you publish exactly one SPF record and how it ends, whether a DKIM key answers at the common selectors (default, google, selector1, s1), whether your DMARC record has reached quarantine or reject with a rua address, plus your CAA records and DNSSEC. They run with 156 checks across 6 of its 7 categories.
What is the SPF record for Google Workspace?
Google's recommended record is v=spf1 include:_spf.google.com ~all, published as a TXT record on your root domain. Add other senders' include: values to that same record, because a domain may have only one SPF record.
03
What DMARC policy should I start with?
Start with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com so you receive reports without affecting delivery. Once the reports show every legitimate sender passing, move to p=quarantine and then p=reject.
04
Can I have two SPF records?
No. Multiple SPF records on the same name make SPF return a permerror, so receivers treat the check as failed. Merge every sender into one record.
05
Do I need DMARC to send email to Gmail?
If you send 5,000 or more messages a day to Gmail accounts, yes: Google's sender guidelines require SPF, DKIM and a DMARC record of at least p=none. Every sender needs SPF or DKIM at minimum.
