"SPF, DKIM, and DMARC Setup: A Practical Guide for 2026"

Your domain is sending email into the void. Messages bounce, land in spam folders, or trigger recipient filters — and you have no idea whether it is because of content, reputation, or something simpler like missing authentication records.

Email authentication sounds dry. It is DNS configuration, after all. But getting SPF, DKIM, and DMARC right is one of the highest-leverage things you can do for deliverability. Receivers like Gmail, Microsoft, and Yahoo use these records as a primary signal when deciding whether to accept your mail. Get them wrong, and even good content gets rejected. Get them right, and you build a foundation that every other deliverability tactic depends on.

This guide walks through each record type, shows you the exact DNS syntax, explains common failure modes, and lays out the path from testing to enforcement. You do not need to be a DNS expert. You just need to follow the steps in order.

What SPF actually does (and why it matters)

Sender Policy Framework exists to answer one question: is this IP address allowed to send email claiming to be from my domain? You publish an SPF record in DNS that lists your authorized sending IPs and services. When a receiver gets a message, it checks the domain in the envelope-from address against that record. If the IP is not listed, the message fails the SPF check.

The record lives in DNS as a TXT record starting with v=spf1. From there you add mechanisms that tell receivers what to do. The most common ones are mx, a, include, and ip4. Here is what they mean:

• mx — allows any IP listed in your domain's MX records to send mail
• a — allows IPs associated with your domain's A records
• include — delegates the check to another domain's SPF record (used for third-party senders like Mailgun, SendGrid, or Postmark)
• ip4 — allows a specific IPv4 address range
• -all — hard fail; reject messages that do not match any mechanism above

A typical SPF record for a business using a transactional email provider looks like this:

v=spf1 mx include:sendgrid.net include:postmarkapp.com ip4:192.0.2.0/24 -all

The -all at the end is critical. Without it, receivers treat unknown sends as neutral rather than failed. Neutral gives spammers room to operate using your domain. Hard fail (-all) tells receivers to reject unauthorized sends outright.

There is one major gotcha: SPF has a hard limit of 10 DNS lookups. Each include, mx, and a mechanism counts as one lookup. If your record exceeds 10 lookups, DNS stops evaluating additional mechanisms, and some of your authorized sending sources get silently ignored. This is one of the most common reasons SPF fails for growing businesses. You can check your lookup count by running dig TXT yourdomain.com and counting the includes manually.

Google's Email Sender Guidelines, updated for 2026, explicitly require bulk senders to maintain valid SPF records with proper alignment. Their public documentation states that domains failing SPF checks face increased filtering and lower inbox placement rates.

DKIM: proving your message was not tampered with

SPF only checks the sending IP. It does not verify that the actual message content survived intact from sender to receiver. That is where DomainKeys Identified Mail comes in. DKIM adds a cryptographic signature to each outgoing message header. The signature is generated using a private key stored on your sending server. Receivers verify the signature using a public key you publish in DNS.

Here is the workflow:

1. Your email system generates a hash of the message headers and body
2. That hash is encrypted with your private DKIM key
3. The resulting signature is added to the message header as DKIM-Signature
4. The receiver fetches your public key from DNS and decrypts the signature
5. If the decrypted hash matches a freshly computed hash of the received message, the signature validates

The DNS record for DKIM looks different from SPF because it lives under a subdomain selector. A typical record looks like this:

selector1._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA..."

You get the p= value from your email service provider. Mailgun, SendGrid, Postmark, and similar platforms generate the key pair during setup and give you the public key to paste into your DNS. Your sending infrastructure holds the private key automatically.

DKIM alignment works alongside SPF alignment under DMARC. A message passes DKIM alignment when the domain in the DKIM signature matches the domain in the user-visible From address. If someone spoofs your brand but uses a different domain for the DKIM signing, the alignment check catches it.

Microsoft Learn's official guidance on DMARC configuration emphasizes that DKIM is the most reliable authentication method because it survives forwarding and replying. Unlike SPF, which breaks when a message passes through an intermediate relay, DKIM signatures remain intact unless the message content itself is modified.

DMARC: telling receivers what to do when authentication fails

SPF and DKIM are diagnostic tools. They tell you whether a message passed or failed. DMARC turns those diagnostics into action. You publish a DMARC record in DNS that specifies:

1. Which policy to enforce when SPF or DKIM fails (none, quarantine, or reject)
2. Where to send aggregate reports about authentication results (rua tag)
3. Where to send forensic reports about failures (ruf tag, optional)
4. Whether SPF and DKIM must align with the From domain (adkim and aspf tags)

The DMARC record lives at _dmarc.yourdomain.com:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=100"

The policy progression is important. Start with p=none so you collect data without affecting delivery. Monitor your aggregate reports for a week or two. Once you see that legitimate traffic passes authentication, move to p=quarantine (messages go to spam). Finally, move to p=reject (messages are dropped entirely).

Jumping straight to reject without testing is risky. If you have misconfigured SPF or DKIM, or if a partner sends mail on your behalf without proper authentication, those messages will bounce. Always start in monitoring mode.

Google's 2024 bulk sender requirements make DMARC enforcement effectively mandatory. Any domain sending more than 5,000 messages per day must have a DMARC policy of quarantine or reject with a functioning reporting URI. Microsoft enforces the same threshold for Outlook.com and Hotmail recipients. These rules exist because unauthenticated email accounts for the vast majority of spam, phishing, and Business Email Compromise attacks.

Common SPF mistakes and how to fix them

SPF is simple in theory and messy in practice. Here are the mistakes that show up most often:

Using ~all instead of -all — Soft fail (~all) tells receivers to mark suspicious mail as spam but still deliver it. Hard fail (-all) is stricter and preferred once you know your sending infrastructure is correct. Keep ~all only while actively troubleshooting.

Including too many third parties — Every include: mechanism consumes one of your 10 DNS lookups. If you use five different email platforms, you have burned half your budget before you even add your MX and A records. Consolidate where possible, or use SPF flattening services that resolve all includes into a single record.

Missing a new sending source — You add a new marketing automation tool or a regional ESP and forget to update SPF. Those messages fail SPF and land in spam. Audit your sending infrastructure quarterly.

Duplicate SPF records — DNS allows only one SPF record per domain. If you accidentally create two TXT records both starting with v=spf1, receivers ignore both. Merge them into a single record.

Common DKIM mistakes and how to fix them

DKIM problems usually come down to one of three issues:

Wrong selector or missing record — Your email provider gives you a selector name like s1._domainkey or mail._domainkey. Paste the record exactly as provided. A typo in the selector name means the public key never resolves, and every message fails DKIM verification.

Signing the wrong headers — Some configurations sign only message headers but not the body, or vice versa. Full signing covers both. Check your provider's documentation for the recommended signing scope.

Key rotation delays — DKIM keys should rotate periodically for security. During rotation, both old and new keys must be active in DNS simultaneously, or messages sent between rotations will fail verification. Coordinate key updates with your email provider.

Common DMARC mistakes and how to fix them

Starting with p=reject — As mentioned above, always begin with p=none. Jumping straight to rejection will cause deliverability incidents if you have any misconfiguration.

No reporting URI — Without a rua tag, you get zero visibility into who is authenticating as your domain and who is spoofing it. Aggregate reports contain breakdowns by source IP, pass/fail status, and alignment results. They are your primary diagnostic tool.

Ignoring the reports — Receiving thousands of DMARC reports daily is overwhelming. Use a DMARC analysis platform or a simple script to parse the XML reports. Look for patterns: which IPs are failing, which domains are being spoofed, and whether legitimate sends are passing.

Weak alignment settings — By default, both SPF and DKIM use relaxed alignment (relaxed). This means subdomain.yourdomain.com can pass SPF or DKIM alignment for yourdomain.com. For maximum protection, switch to strict alignment (adkim=s; aspf=s) once you are ready for enforcement.

Your DMARC rollout checklist

Follow this sequence to deploy DMARC safely:

1. Audit your current SPF and DKIM records. Verify that all authorized sending sources appear in SPF and that DKIM signatures validate on test messages.
2. Publish a DMARC record with p=none and a rua reporting URI. Start collecting data immediately.
3. Monitor aggregate reports for one to two weeks. Identify any legitimate sends that fail authentication. Fix SPF or DKIM issues as they surface.
4. Move to p=quarantine once all legitimate traffic passes. Messages that fail will route to spam folders instead of being delivered to the inbox.
5. Move to p=reject when you are confident. This is the strongest policy and blocks unauthorized sends entirely.
6. Continue monitoring. Even after enforcement, keep reviewing reports. New sending partners, compromised accounts, and configuration changes happen regularly.

Getting started

Authentication is not a one-time setup task. It is ongoing maintenance that pays dividends in inbox placement and sender reputation. BlacklistGuard monitors blacklist status and deliverability signals across your campaigns so you can catch authentication failures before they damage your reputation.

If you want to dive deeper into deliverability fundamentals, our deliverability guides cover sender warming, list hygiene, and engagement-based ranking factors. For hands-on blacklist detection and removal workflows, explore our blacklists section.

This article was researched, written, and published end to end by an autonomous BlacklistGuard agent, as a working demonstration of the platform's capabilities. Read more at BlacklistGuard.

Common questions