SPF, DKIM and DMARC: What They Are and How to Set Them Up

SPF, DKIM and DMARC are three DNS records that prove your email really comes from your domain. SPF lists the servers allowed to send for you, DKIM adds a signature that inboxes check against a public key in your DNS, and DMARC tells inboxes what to do when those checks fail and sends you reports. To set them up, publish one SPF record that covers every sending service, turn on DKIM in each service, then add a DMARC record at p=none and tighten it to quarantine and reject once the reports show your real mail passing.

This guide is for business owners, office managers and developers who look after a domain's email. It gives the exact record formats, the limits that quietly break them, and the order to make changes so you never block your own invoices. If you want the background on why owning your domain and email matters first, read domain and business email setup.

#What each record does

Each record answers a different question a receiving inbox asks about your message. Together they let Gmail, Outlook and Yahoo tell your real mail apart from forgeries.

Two details explain most failures. First, SPF checks the envelope sender, also called the Return-Path or bounce address, not the From address people see. Many sending services use their own bounce domain, so SPF passes for them but says nothing about your domain. Second, DKIM signs with whatever domain the service puts in d=. If that is the service's domain rather than yours, the signature passes but does not help your DMARC. That is why alignment matters, and why each service needs to be set up on your domain.

#Step 1: list every service that sends as your domain

Before touching DNS, write down everything that sends email with your domain in the From address. Missing one is the most common reason DMARC later blocks real mail.

1. Your mailbox provider, for example Google Workspace or Microsoft 365.
2. Your website: contact forms, WooCommerce order emails, password resets. These should go through a proper SMTP service, not the web server's own mail function. See SMTP and transactional email setup if yours does not.
3. Marketing tools such as a newsletter platform.
4. Business software: invoicing, CRM, helpdesk, booking, payroll.
5. Any server or app you run yourself that sends notifications.

For each one, note whether it gives you an SPF include, DKIM records, and a custom bounce (Return-Path) domain option. Their setup pages list these.

#Step 2: publish one SPF record

SPF is a single TXT record on your domain that starts with v=spf1, lists allowed senders, and ends with an all rule. Google Workspace's documented record is:

v=spf1 include:_spf.google.com ~all

Microsoft 365's documented record is:

v=spf1 include:spf.protection.outlook.com -all

If you use both a mailbox provider and other services, merge them into one record. Google's own example for Workspace plus Mailchimp is v=spf1 include:_spf.google.com include:servers.mcsv.net ~all.

The rules that break SPF most often:

• Only one SPF record per domain. RFC 7208 says a domain must not have more than one, and Microsoft's documentation confirms that multiple SPF records return permerror. When a new tool tells you to "add an SPF record", edit the existing one instead.
• The 10 lookup limit. The include, a, mx, ptr and exists mechanisms and the redirect modifier each cost a DNS lookup, and includes inside includes count too. Over 10, SPF fails. ip4, ip6 and all cost nothing.
• Void lookups. RFC 7208 recommends failing after two lookups that return nothing, so remove includes for services you no longer use.
• Do not use ptr. The RFC says it should not be published.
• Syntax. No trailing dot, a colon not an equals sign after include, and no space after the colon.

On the ending: -all (fail) says unlisted servers are not allowed, ~all (softfail) says they probably are not. Google recommends ~all; Microsoft recommends -all because DMARC handles the final decision. Either works once DMARC is in place. Use ?all only for testing.

If you are near 10 lookups, Microsoft suggests moving bulk tools to a subdomain such as news.yourdomain.com, which gets its own SPF record and its own 10 lookups, or dropping unused services. Replacing includes with fixed IP addresses ("flattening") works only for providers whose IPs rarely change, and Microsoft warns never to flatten its own include.

#Step 3: turn on DKIM for each service

DKIM is switched on inside each sending service, which then gives you DNS records to publish. The public key lives at selector._domainkey.yourdomain.com, where the selector is a name chosen by the service. Selectors let several services sign for the same domain without clashing.

Google Workspace. In the Admin console, generate a key for each domain, choose 2048 bits if your DNS host accepts long TXT values (1024 if not), publish it at google._domainkey, then click Start authentication. Google notes the console can keep showing a warning for up to 48 hours.

Microsoft 365. Publish the two CNAME records shown in the Defender portal for your domain. Newer tenants point to a host ending in dkim.mail.microsoft; older ones point to your onmicrosoft.com domain. Copy the exact values from the portal, then enable signing.

Everything else. Use the records the tool gives you. Amazon SES, for example, signs with a 2048 bit key by default.

Key length matters: RFC 6376 requires at least 1024 bits, Google requires at least 1024 bits for mail to personal Gmail accounts and recommends 2048. To retire an old key, RFC 6376 allows publishing the selector with an empty p= value, which marks it revoked.

#Step 4: publish DMARC and understand alignment

DMARC is a TXT record at _dmarc.yourdomain.com. A safe starting record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

The main tags:

Alignment, in plain words. DMARC does not just ask "did SPF or DKIM pass?" It asks "did one of them pass for the same domain as the From address?" With relaxed alignment, the default, the organisational domains must match, so a DKIM signature for mail.yourdomain.com aligns with a From address at yourdomain.com. With strict alignment the names must be identical. A message passes DMARC if either SPF or DKIM passes and aligns. Google says relaxed is usually enough, and suggests strict only when other parties control your subdomains.

This is why each sending service must sign with your domain (DKIM) or use a bounce subdomain of yours (SPF). A service that signs as itself will pass its own checks and still fail your DMARC.

If your rua address is on a different domain, such as a reporting service, that domain must publish a record authorising it, in the form yourdomain.com._report._dmarc.reportingservice.com. Reporting services set this up for their customers.

#Step 5: move from p=none to reject safely

Do not jump straight to reject. Read the reports first, fix every real sender that fails, then tighten in stages.

1. Wait for SPF and DKIM. Google asks for SPF and DKIM to be running for at least 48 hours before you add DMARC.
2. Monitor at p=none. Google suggests about a week of daily review for a typical organisation. RFC 9989 is more cautious and describes p=none for at least a month before changing. With several sending tools, give it a few weeks so monthly invoices and newsletters show up.
3. Fix what fails. Every legitimate source in the reports must pass SPF or DKIM with alignment. How to read them is covered in DMARC reports and monitoring.
4. Quarantine. Failing mail goes to spam. Google's example starts small: v=DMARC1; p=quarantine; pct=5; rua=mailto:dmarc@example.com, then raises the percentage to 100.
5. Reject. Failing mail is refused. RFC 9989 suggests holding quarantine for about as long as you held p=none before this step.

Mailing lists are the main exception. RFC 9989 advises that domains whose staff post to mailing lists should not publish p=reject, because lists often change messages and break signatures.

#When to get help

You can do this yourself if one mailbox provider is the only thing sending as your domain: its own setup pages give you the exact records. Get help when several tools send as you, when your SPF record is near 10 lookups, when DMARC reports show sources you do not recognise, or when mail is already landing in spam. A wrong change at reject can bounce your own invoices without anyone noticing for days.

That audit and staged rollout is what my email deliverability service covers. If your website sends through the server's default mail function, fix that first with SMTP and transactional email setup, and if mail is already going to spam, start with why emails go to spam and how to fix it.