How to Set Up SPF, DKIM, and DMARC for Your Domain

Receiving mail servers need some way to tell whether a message really came from your domain. SPF, DKIM, and DMARC give them that evidence through DNS. Set up together, they reduce domain spoofing and can improve delivery to Gmail, Outlook, Yahoo, and other providers.

The short version

Publish the SPF record supplied by your email provider. Then enable DKIM in the provider’s administration console and add the selector records it gives you. Finally, create a DMARC TXT record at _dmarc.yourdomain.com.

Start with a monitoring policy such as p=none. Give the reports a proper review before moving to quarantine or reject.

And don’t copy records from somebody else’s domain. Microsoft 365, Google Workspace, Amazon SES, Mailchimp, and other sending services use different SPF mechanisms and DKIM selectors.

What each standard does

For DMARC to pass, at least one aligned authentication method has to pass. That can be SPF with an aligned envelope domain, or DKIM with an aligned signing domain. You don’t need both SPF and DKIM to pass.

What you’ll need

• Access to the domain’s authoritative DNS settings
• Administrative access to every service that sends mail for the domain
• A list of the transactional, marketing, support, invoicing, and employee email platforms in use
• A mailbox or reporting service that can receive DMARC aggregate reports

Take inventory before touching DNS. It’s easy to forget an old billing platform or website mailer, and a strict policy applied too soon can block perfectly legitimate messages.

Step 1 — Publish one SPF record

Get the required SPF value directly from your email provider. A basic record that authorizes one provider might look like this:

Type: TXT
Name: @
Value: v=spf1 include:spf.provider.example -all

The include mechanism delegates authorization to the provider’s SPF policy. At the end, -all says that servers not covered by the record are unauthorized.

Combining several senders

A domain mustn’t publish multiple SPF records. If two services send mail, put both mechanisms into the same record:

v=spf1 include:spf.mail-provider.example include:spf.marketing-provider.example -all

There’s also a limit of 10 DNS-based lookups during SPF evaluation. Go past it and you can get a permanent error, even though the record may look valid at first glance. Don’t keep stacking includes forever. Remove services you no longer use.

Step 2 — Turn on DKIM signing

1. Open the administration console for your email service.
2. Find the DKIM or domain authentication settings.
3. Generate a DKIM key if the service doesn’t create one automatically.
4. Add the supplied TXT or CNAME records to DNS.
5. Go back to the provider and select Verify or Enable signing.

A public key stored in a TXT record often looks something like this:

Type: TXT
Name: selector1._domainkey
Value: v=DKIM1; k=rsa; p=PUBLIC_KEY_PROVIDED_BY_YOUR_SERVICE

Some platforms give you CNAME records instead. Use the exact record type, host, and target shown in the platform. One small trap: if your DNS control panel appends the root domain automatically, don’t add it again.

Choose 2048-bit DKIM keys where they’re supported. The private key stays inside the sending platform. Only the public key belongs in DNS.

Step 3 — Start DMARC in monitoring mode

Create a TXT record at _dmarc, using a monitoring policy first:

Type: TXT
Name: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100

Those DMARC reports are machine-readable XML files, and they can arrive in large volumes. A personal inbox gets messy fast. Use a dedicated mailbox or a reputable DMARC analysis service instead.

Step 4 — Move toward enforcement

Keep monitoring until you’ve identified every legitimate sender. If SPF or DKIM alignment is failing, fix that before tightening the policy.

Quarantine is the usual next step:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=100

Once legitimate mail is consistently passing, change the policy to reject:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; pct=100

With p=reject, receiving systems are asked to reject messages that fail DMARC. It offers stronger protection against spoofing, but don’t switch it on until your authorized senders are aligned correctly.

Checking the DNS records

DNS changes may take time to propagate. On macOS or Linux, query the records with dig:

dig TXT example.com
dig TXT selector1._domainkey.example.com
dig TXT _dmarc.example.com

For Windows PowerShell, use:

Resolve-DnsName example.com -Type TXT
Resolve-DnsName selector1._domainkey.example.com -Type TXT
Resolve-DnsName _dmarc.example.com -Type TXT

Then send a message to an external mailbox and inspect the original headers. You’re looking for an authentication summary along these lines:

spf=pass
dkim=pass
dmarc=pass

Check the domain shown beside each result, not just the word pass. A message may pass SPF or DKIM on its own and still fail DMARC because the authenticated domain doesn’t align with the address visible in the From header.

Mistakes that cause trouble

• Publishing two SPF records. Merge every authorized source into a single record.
• Going over the SPF lookup limit. Audit the includes and remove services that aren’t used anymore.
• Using the wrong DKIM selector. Copy the selector generated for the correct service and domain.
• Publishing DKIM without enabling it. Adding the key to DNS doesn’t always turn on message signing.
• Repeating the domain name. Check whether your DNS panel adds the zone name automatically.
• Starting with DMARC reject. Monitor first, or you may reject valid business email.
• Missing third-party senders. Your audit should cover ticketing, CRM, newsletter, billing, and website email systems.

Practices to keep

• Use separate DKIM selectors for different services where possible.
• Rotate provider-managed DKIM keys when the platform supports rotation.
• Review DMARC aggregate reports regularly, not just during the initial setup.
• Delete SPF mechanisms and DKIM records that belong to retired services.
• Use a subdomain for high-volume marketing or transactional mail if operational separation would help.
• Document every authorized sender and the authentication method it uses.

Keep watching the reports after enforcement goes live. Email infrastructure changes, sometimes quietly, and a newly added service can start failing authentication if nobody checks its DNS alignment.