SPF, DKIM and DMARC for a startup domain: the exact records

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.

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.

Copyable records for the common setups:

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:

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.

1. 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.
2. Publish v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com.
3. 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.
4. Fix every legitimate sender that fails: add its include:, turn on its DKIM, or move it to a subdomain with its own records.
5. Change to p=quarantine; t=y (receivers still take no action) and keep reading reports, then drop t=y.
6. Move to p=reject; t=y (receivers quarantine), then p=reject.
7. 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.

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:

dig +short TXT yourdomain.com | grep spf1
dig +short TXT _dmarc.yourdomain.com
dig +short TXT google._domainkey.yourdomain.com

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.

Email authentication is one part of a domain's security setup; the security headers checklist covers the web side, and the vibe-coded app security checklist covers what AI-built apps most often leave open. For tools that check these records alongside everything else, see the comparison of website security scanners.

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.