Home › Guides

SPF, DKIM and DMARC Setup: Records, Pitfalls and Checks

Published 2026-11-03 ／ Updated 2026-11-03 ／ By Yuki Nakazawa

An SPF, DKIM and DMARC setup is no longer optional if you send email from your own domain. Do it in this order: publish one SPF record, turn on DKIM signing with a 2048-bit key, then publish a DMARC record that starts at p=none with reporting enabled. While you are at it, make sure the IP address that sends your mail has matching reverse DNS (PTR).

This guide works whether you send from shared hosting, your own VPS, Google Workspace, Microsoft 365 or a bulk email service. It gives you records you can adapt, the mistakes that most often break authentication, and how to confirm everything works from a real message header.

Facts below were checked against the RFCs and the official Google, Yahoo and Microsoft pages as of November 2026. Mailbox provider requirements change, so treat their pages as the final word.

What SPF, DKIM and DMARC each prove, and the order to set them up

SPF (Sender Policy Framework) lets a domain list, in DNS, which servers are allowed to send its mail. The receiving server looks at the envelope sender (the SMTP MAIL FROM address, which later shows up as Return-Path), fetches that domain's SPF record and checks whether the connecting IP address is on the list. On its own, SPF says nothing about the From address the reader sees.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message. The sending system signs with a private key, and receivers verify the signature with a public key published in DNS. A valid signature proves that the signing domain (the d= value) took responsibility for the message and that the signed headers and body were not altered on the way.

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the two to the visible From domain. A message passes DMARC only when SPF or DKIM passes and the authenticated domain aligns with the From domain. The DMARC record also tells receivers what you want done with failures (nothing, quarantine or reject) and where to send aggregate reports, which is how you find sending sources you forgot about.

Setup order

1. List every system that sends mail as your domain: your own server, Google Workspace or Microsoft 365, newsletter and transactional email services, web forms, invoicing and help desk tools.
2. Publish a single SPF record that covers all of them.
3. Enable DKIM on each sending system and publish its public key.
4. Publish DMARC with p=none and a rua reporting address. Google suggests waiting 48 hours after setting up SPF and DKIM before you add DMARC.
5. Read the reports, fix any sources that fail, then move to p=quarantine and finally p=reject.

SPF setup: one record, ten lookups

SPF is a TXT record on the domain itself. Here is a domain that sends from its own server over IPv4 and IPv6 and also uses Google Workspace:

example.com.  3600  IN  TXT  "v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:_spf.google.com ~all"

In most DNS control panels you leave the host field empty (or enter @), choose TXT, and paste the value starting at v=spf1. Common building blocks:

SPF pitfalls

• One SPF record per name. RFC 7208 forbids multiple SPF records for the same domain; receivers return permerror and SPF fails for everything. When you add a service, edit the existing record and append its include: rather than creating a second v=spf1 record.
• The 10-lookup limit. The include, a, mx, ptr and exists mechanisms and the redirect modifier each trigger DNS lookups, and the total across the whole evaluation, including lookups inside nested includes, must not exceed 10. Going over gives permerror. ip4:, ip6: and all cost nothing. RFC 7208 also says receivers should stop after two lookups that return no answer, so remove includes for services you no longer use.
• ~all versus -all. -all means unlisted sources are not authorized (fail); ~all means they are probably not authorized (softfail). Google recommends ~all for Workspace domains; Microsoft recommends -all for Microsoft 365 domains that also use DKIM and DMARC. If you are not yet sure you have found every sender, start with ~all and let DMARC do the enforcing.
• Subdomains need their own record. The SPF record on example.com does not cover news.example.com. Putting a bulk email service on its own subdomain also gives it a separate 10-lookup budget and keeps its reputation apart from your staff mail.
• Syntax slips. Microsoft lists the usual ones: include= instead of include:, a space after the colon, and a trailing dot after the included domain.

For domains that never send mail, publish v=spf1 -all so they are harder to spoof.

DKIM setup: 2048-bit keys and selectors

DKIM has two halves: the sending system signs with a private key, and DNS publishes the matching public key. With Google Workspace, Microsoft 365, most hosting control panels and most email services you generate the key in the admin console and copy the DNS value it shows you.

Key length and selectors

Use a 2048-bit RSA key. RFC 8301 makes 1024 bits the minimum and says signers should use at least 2048 bits; it also bans rsa-sha1. Google's guidance matches: choose 2048 bits if your DNS host supports it and fall back to 1024 only if it does not.

The selector is a label that identifies which key signed a message, so a domain can have several keys at once, one per sending service or one per rotation period. The public key lives at selector._domainkey.yourdomain. Google Workspace uses google as its default selector. Microsoft 365 uses two CNAME records, selector1._domainkey and selector2._domainkey, pointing to keys Microsoft hosts; take the exact targets from the Defender portal or Get-DkimSigningConfig, because the format varies by tenant.

Publishing a long public key

A 2048-bit public key is longer than the 255 characters allowed in a single DNS character-string, so in zone-file form it is written as several quoted strings in one TXT record:

selector1._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA(first part of your key)"
    "(rest of your key)IDAQAB" )

Replace the parts in parentheses with your actual key. Receivers join the strings with no spaces in between, so split anywhere inside the key. Many control panels split long values automatically: paste the whole value first and split it yourself only if the panel rejects it. Make sure nothing gets lost in the copy; an empty p= means the key has been revoked.

On your own VPS running Postfix or a similar MTA, a signing milter such as OpenDKIM can create the key pair, for example opendkim-genkey -b 2048 -s selector1 -d example.com. Publish the contents of the generated public key file as shown above.

Check that messages are really signed

Open a message you sent and look for a DKIM-Signature: header. Its d= tag should be your domain and s= the selector you published. Many email services sign with their own domain by default; that passes DKIM but does not align with your From domain, so it does not help DMARC. Turn on the service's custom domain authentication so that d= becomes your domain.

DMARC setup: start at p=none, then enforce

DMARC is a TXT record at _dmarc under your domain. Start in monitoring mode, which asks receivers not to change how they handle your mail, and ask for aggregate reports:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Aggregate reports are machine-readable summaries of which IP addresses sent mail as your domain and whether it passed; Google suggests a dedicated mailbox or group to receive them. Once the reports show that every legitimate source passes with alignment, tighten the policy by editing the same record rather than adding a second one:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Alignment, in plain terms

To pass DMARC, at least one of SPF or DKIM has to pass for a domain that matches the From domain. In relaxed mode the organizational domains must match, so a DKIM signature with d=example.com aligns with mail from alerts@news.example.com. Strict mode requires an exact match. Email services often use their own domain in the Return-Path, so SPF will not align even when it passes; aligned DKIM is the practical way to get those messages through DMARC.

If you want a different policy for subdomains, add sp=. For example, p=reject; sp=quarantine rejects failing mail from the main domain while only quarantining failures from subdomains.

A note on the updated standard

In May 2026 DMARC was republished as RFC 9989, which obsoletes RFC 7489. Existing records keep working and still start with v=DMARC1. The new standard drops the pct tag, which was rarely applied accurately except at 0 or 100, and adds tags such as t=y (test mode) and np (policy for non-existent subdomains). Some provider help pages still show pct, so the least ambiguous way to roll out enforcement is to step through the p= values.

Reverse DNS (PTR) for your sending IP

Reverse DNS maps an IP address back to a host name. Google requires all senders to Gmail personal accounts to have a PTR record whose host name resolves back to the same sending IP, and Yahoo requires valid forward and reverse DNS for sending IPs and recommends a meaningful, non-generic PTR record.

203.0.113.10       PTR  mail.example.com.
mail.example.com.  A    203.0.113.10

The PTR record is not in your domain's zone. Whoever owns the IP address controls it, so on a VPS you set it in the provider's control panel (often called reverse DNS or rDNS), then create a matching A record (AAAA for IPv6) in your own DNS. If you send over IPv6, the IPv6 address needs the same treatment. With Google Workspace, Microsoft 365, email services and most shared hosting, the provider manages the sending IPs and their reverse DNS for you.

How to verify your setup

Read Authentication-Results

Send a test message to an outside mailbox and view the full headers. In Gmail, open the message and choose Show original. Google's DKIM help notes that you should send to another user rather than to yourself. Look for a header like this:

Authentication-Results: mx.example.net;
       dkim=pass header.i=@example.com header.s=selector1;
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass header.from=example.com

The exact layout varies by receiver. What matters is spf=pass, dkim=pass and dmarc=pass, with your own domain in header.i or header.d and in header.from. If SPF passes for a service's domain but DKIM shows another domain, DMARC will fail: fix DKIM alignment first.

Query DNS directly

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 203.0.113.10

On Windows, nslookup -type=TXT _dmarc.example.com does the same job. DNS changes can take time to spread; Google says SPF and DKIM can each take up to 48 hours to start working. Free online checkers can also parse your records and count SPF lookups for you.

If authentication passes and mail still bounces or lands in spam, check whether your sending IP or domain is listed on a DNSBL with our blacklist checker, and see email not delivered because of a blacklist for the next steps.

Gmail, Yahoo and Outlook.com sender requirements

The big mailbox providers now enforce authentication. As of November 2026, their official pages say the following.

• Gmail (in effect since February 1, 2024): everyone sending to personal Gmail accounts needs SPF or DKIM, forward and reverse DNS that match, a TLS connection, and a spam rate below 0.3% in Postmaster Tools. Senders of more than 5,000 messages a day also need both SPF and DKIM, a DMARC record (p=none is acceptable), a From domain aligned with SPF or DKIM, and one-click unsubscribe for marketing mail. DKIM keys must be at least 1024 bits, with 2048 recommended.
• Yahoo (enforcement from February 2024): all senders need SPF or DKIM, valid forward and reverse DNS and a spam rate below 0.3%. Bulk senders need both SPF and DKIM, a DMARC policy of at least p=none that passes, From alignment (relaxed is fine), a working one-click unsubscribe and valid forward and reverse DNS for the sending IPs.
• Outlook.com (the consumer service behind outlook.com, hotmail.com and live.com): domains sending more than 5,000 emails a day must pass SPF and DKIM and publish DMARC of at least p=none, aligned with SPF or DKIM. From May 5, 2025, Microsoft said non-compliant messages would be rejected with the error 550; 5.7.515.

Read the full text in the Google email sender guidelines, Yahoo sender best practices and Microsoft's Outlook.com announcement. Even if you send far fewer messages, setting up all three now means a lower threshold later will not catch you out. For Gmail-specific troubleshooting, see Gmail not delivering your email.

Common mistakes

• A second SPF record. Adding a new v=spf1 record for each service invalidates SPF for the whole domain. Merge everything into one.
• Too many includes. Old services left in SPF eat into the 10-lookup budget. Remove what you no longer use and move bulk mail to a subdomain.
• Key published, signing not enabled. In Google Workspace you still have to click Start authentication after the DNS record is live; other platforms have a similar switch.
• The service signs with its own domain. SPF and DKIM both pass, DMARC fails. Enable custom domain signing.
• Jumping straight to p=reject. A forgotten web form or invoicing system stops delivering overnight. Start at p=none and read the reports.
• Copy-paste damage. Extra quotation marks inside the value, a truncated key, or a host name that ends up as _dmarc.example.com.example.com because the panel appends the domain for you. A quick dig catches all of these.

FAQ

Official pages used

The facts in this article were checked against the official pages below at the time of publication. Policies and behavior change without notice, so check the official pages before relying on anything important.

• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9989: DMARC (obsoletes RFC 7489)
• Google: Email sender guidelines
• Google Workspace: Set up SPF
• Google Workspace: Set up DKIM
• Google Workspace: Set up DMARC
• Yahoo Sender Hub: Sender Best Practices
• Microsoft Community Hub: Outlook's New Requirements for High-Volume Senders
• Microsoft Learn: Set up SPF for your Microsoft 365 domain
• Microsoft Learn: How to use DKIM for email in your custom domain

Related guides

All guides →