Dkim spf dmarc explained with real examples

Key takeaways

DKIM adds a cryptographic signature that receiving servers can verify, so your domain doesn't look forged.
SPF publishes which IP addresses are allowed to send mail from your domain, blocking spoofers.
DMARC tells receivers what to do when DKIM and SPF don't align, and gives you feedback reports.
Most deliverability failures are actually alignment problems, not record syntax errors.
Get all three records right and your inbox placement climbs; get one wrong and you're fighting an uphill battle forever.

Open up your email platform after sending a batch, check the stats, and see that 40 percent of your messages are sitting in the spam folder. You double‑check the copy, the subject line, and the send time, but the numbers don’t lie: something is blocking delivery. More often than not, the culprit isn’t the content at all—it’s that your domain’s authentication setup is broken or missing entirely. If you’ve ever wondered why your carefully crafted outreach ends up in the junk pile, you’re in good company. Most outbound teams I’ve worked with have stared at a blank DNS portal, felt the panic of a failed send, and wished someone would just walk them through the actual fixes instead of throwing acronyms at them.

What DKIM Actually Does and Where It Lives

DKIM, or DomainKeys Identified Mail, is the first piece of the authentication puzzle. It works by slapping a cryptographic signature on every email you send. That signature is generated using a private key held by your mail server, and a public key is published in your DNS as a TXT record. When the receiving server gets your message, it pulls that public key, verifies the signature, and decides whether the message really came from you or if someone forged the From address.

I learned this the hard way when a client’s domain suddenly started landing every message in spam. The copy was fine, the domain reputation was solid, but the DKIM signature was expired. The private key had rotated and the public DNS record was never updated. Receiving servers couldn’t verify the signature, so they treated the email as suspicious. The fix was simple: rotate the key, update the TXT record, and within 24 hours the inbox placement rebounded. If you’re looking at your DNS and see a selector name like google or default, that’s your DKIM selector. Make sure it matches what your sending platform expects; mismatch there is the most common setup error I see.

Why SPF Matters and How to Get It Right

SPF, or Sender Policy Framework, is the second pillar. It answers a simple question: “Which IP addresses are allowed to send email on behalf of this domain?” You publish an SPF record in DNS that lists your mailing servers, your marketing platform’s IPs, and maybe a third‑party service like Mailchimp or SendGrid. When a recipient server receives your email, it checks the sender’s IP against that list. If the IP isn’t allowed, the SPF check fails.

The trap most teams fall into is over‑packing the SPF record or using the wrong mechanism. I’ve seen companies jam every possible IP into a single record, which hits the DNS lookup limit of 10 and causes the whole check to fail silently. Instead, keep your SPF lean: use include: statements for each legitimate sender, and if you have more than a handful of services, consider moving to a managed authentication service that aggregates those includes for you. Also, always end your record with either ~all (soft fail, which many marketers use as a transition) or -all (hard fail, which is stricter but can cause legitimate forwards to bounce). I typically recommend starting with ~all while you verify every sender is properly included, then graduate to -all once you’re confident nothing legitimate will break.

DMARC the Policy That Ties It All Together

DMARC, or Domain-based Message Authentication, Reporting, and Conformance, is the policy layer that tells receivers what to do when DKIM and SPF don’t align. It also gives you a feedback loop: aggregate reports sent to an email address you specify, showing you who is sending mail that claims to be from your domain. Without DMARC, you have two independent checks (DKIM and SPF) that receiving servers handle differently, and you have no visibility into abuse.

Setting up DMARC starts with a policy of p=none. This tells receivers to just log the result and send you reports, but not to take any action on the mail itself. I always tell clients to start here for at least two weeks. During that window, you’ll get a flood of data: which of your own systems are passing, which third‑party services are failing, and maybe even that rogue third party you forgot you added last year. Once the reports look clean and you’ve added any missing include: mechanisms to SPF, you can bump the policy to p=quarantine, which pushes suspicious mail to the spam folder. Move to p=reject only when you’re certain everything is aligned and you can afford the occasional false positive. The alignment piece is worth repeating: DKIM alignment means the domain in the signature matches the From domain; SPF alignment means the envelope sender domain matches the From domain. Miss that alignment and even a perfectly formatted DKIM signature won’t save you.

Common Mistakes That Blow Up Deliverability

One of the biggest mistakes I see is treating these records as “set it and forget it.” DNS changes can take time to propagate, and sending volume can spike before you’ve warmed up the new policy. Another frequent error is having a DKIM key length under 1024 bits. Modern spam flags short keys as weak, and some providers are already moving to require 2048‑bit keys. If you’re still on a legacy provider that only offers 512‑ or 1024‑bit options, consider upgrading or switching platforms.

SPF mechanisms also trip people up. Using +all effectively opens your domain to anyone sending mail claiming to be you—that’s a recipe for phishing and will get you blacklisted quickly. Conversely, using -all without having every legitimate sender locked in will cause your own legitimate mail to bounce, which tanks your sender reputation. And DMARC? The most common fumble is moving to p=reject too early. I’ve had teams lose 15 percent of their outreach overnight because they didn’t spend enough time in the p=none and p=quarantine phases collecting data. Patience here isn’t optional; it’s the difference between a smooth‑running program and a deliverability crisis.

Benchmarking Your Setup Against Industry Standards

How do you know if your DKIM, SPF, and DMARC are actually doing their job? Look at your inbox placement rates over a 30‑day window after you’ve stabilized the records. Most healthy outbound programs see 80 percent or higher primary inbox placement when all three are aligned and enforced at p=reject. If you’re sitting at 60 percent or below, odds are at least one leg of the stool is wobbling.

I like to run a quick audit using a free tool like MXToolbox or DMARCian’s lookup. Type in your domain, and it will tell you the current status of each record: whether DKIM is publishing, if SPF has the 10‑lookup limit issue, and what your DMARC policy is set to. Pay attention to the “alignment” column—that’s the hidden killer. If alignment shows “fail” even though the individual checks pass, you have a domain mismatch problem. Fix the domain alignment (usually by ensuring the envelope sender or the signature domain matches the From address), and placement typically climbs within a send cycle or two.

Step‑by‑Step: Fixing a Broken DKIM SPF DMARC Chain

Let’s say you’ve just inherited a domain that has zero authentication, or you’ve noticed a sudden drop in deliverability. Here’s the exact sequence I run through with every client who’s been burned by this before.

Log into your DNS provider. Locate the TXT records for default._domainkey.yourdomain.com (DKIM), yourdomain.com (SPF), and _dmarc.yourdomain.com (DMARC). If any are missing, that’s your first fix.
Generate a new DKIM key. Most email platforms (HubSpot, Outreach, Salesforce Marketing Cloud) have a “rotate DKIM key” button. Click it, copy the new public key record, and paste it into DNS. Wait at least an hour for propagation, then send a test email and check the header for the DKIM=-pass line.
Audit your SPF record. Pull the current record into a text editor. List every service you send through—your CRM, your automation tool, any third‑party newsletter platform. Add include: for each one. Remove any +all and replace with ~all if you’re in the verification phase, or -all if you’re confident. Keep the total DNS lookups under 10; if you exceed that, use a service like AuthSMTP that consolidates includes.
Set DMARC to p=none. Create a TXT record at _dmarc.yourdomain.com with the value v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com. The rua tag tells receivers where to send aggregate reports. Send a small batch of emails and check those reports daily for the first week.
Review the DMARC reports. Look for pass and fail statuses under the dkim and spf columns. If you see failures from your own systems, dig into DNS propagation or key rotation. If third‑party services are failing, add their include: to SPF or configure their DKIM selector correctly.
Graduate the DMARC policy. After two weeks of clean reports and no unexpected failures, change the policy to p=quarantine. Monitor for another seven days. If everything still looks good, flip to p=reject. Keep an eye on your inbox placement metrics during each transition; if you see a dip, pause the policy move and go back one step.

Follow those steps and you’ll move from a guessing game to a repeatable process that keeps your email out of the junk folder.

The Alignment Deep‑Dive: Why Passing Checks Still Land in Spam

You can have DKIM, SPF, and DMARC all set to p=reject and still find your emails routing to the spam folder. Why? Because alignment is the invisible gatekeeper that most audit tools gloss over. Let me walk you through a real scenario that happens more often than you’d think.

Last quarter I worked with a B2B SaaS company that had just migrated their sending from an on‑premise Exchange server to a cloud-based platform. They had diligently set up DKIM on the new platform, published a clean SPF record that included the new cloud IPs, and set DMARC to p=reject. On paper, everything passed. But their inbox placement hovered at 62 percent.

The problem was SPF alignment. Their old Exchange server was still sending occasional internal notifications using the domain as the envelope sender, but the From address in the email client was the new cloud platform’s address. When the receiving server checked SPF, it looked at the envelope sender—which was the old Exchange IP—and saw a pass because that IP was still in the SPF record. But the domain in the envelope sender didn’t match the From domain. That’s a fail on the alignment check, even though the SPF syntax itself was valid.

DMARC sees that misalignment and, because the policy is p=reject, it flags the message as unauthenticated. The fix wasn’t to change any records; it was to configure the new platform to strip the old envelope sender or to use a consistent envelope sender domain across both systems. Once we aligned the envelope sender with the From address, placement jumped to 81 percent within two sends. This is why I always tell people: verify alignment before you raise the policy. A passing DKIM or SPF check means nothing if the domains don’t shake hands.

Comparing Self‑Hosted vs. Managed Authentication Services

When I talk to teams about SPF and DKIM, the conversation often turns to whether they should manage these records in-house or pay for a managed service. There’s no universal right answer, but there are trade-offs worth mapping out.

Self‑hosted authentication gives you total control. You generate the keys, you publish the records, you decide when to rotate them. For a small team sending a few thousand emails a month, this is usually fine. But as volume scales, the administrative overhead adds up. I’ve seen companies with five different marketing tools, each with its own DKIM selector, and nobody on staff who remembers which selector belongs to which platform. The result is a DNS TXT record soup that’s prone to errors and nearly impossible to troubleshoot during a deliverability crisis.

Managed services like AuthSMTP, 250ok, or even built‑in features within platforms like HubSpot can aggregate your includes, enforce key rotation schedules, and give you a dashboard that tells you at a glance whether your alignment is healthy. The cost is usually a few hundred dollars a month, but when you factor in the hour a week your team spends debugging DNS issues, the math often tips toward the managed route. If you have more than three legitimate senders, I’d at least peek at what a managed service offers for SPF consolidation. For DKIM, most modern platforms handle key rotation automatically, so the managed benefit there is mostly about visibility rather than mechanics.

Real‑World Examples of Deliverability Wins and Fails

Let’s look at two hypothetical but grounded scenarios so the patterns stick.

The win: A consulting firm was sending 10,000 emails a month from a brand-new domain. Their first batch landed 35 percent in spam. I asked them to check their DNS, and sure enough, there was no DKIM record, the SPF had +all, and DMARC was absent. We generated a 2048‑bit DKIM key, published it, rewrote the SPF to include only their CRM and mailing platform with ~all, and set DMARC to p=none for two weeks. During that window, the DMARC reports showed a third‑party analytics tool was sending mail without an include: clause. Once we added that include:, we moved DMARC to p=quarantine for a week, then to p=reject. Four weeks later, their inbox placement was 84 percent. The key takeaway: the DKIM and SPF were technically there, but the DMARC feedback loop revealed the hidden sender they forgot about.

The fail: An e‑commerce brand I consulted with had been sending for years with p=reject on DMARC and a 512‑bit DKIM key. They had a high‑volume ESP that rotated keys automatically, but the key length never changed from the legacy setting. One day, their open rates dropped 20 percent almost overnight. A deliverability audit revealed that major inbox providers had started flagging 512‑bit keys as weak security. We rotated the key to 2048 bits, updated the DNS record, and within 48 hours, placement stabilized. They also had been using -all in SPF for years, which had started bouncing legitimate receipt emails from their payment processor because the processor’s IP changed and nobody told them. We switched to ~all and added the processor’s IP back in. Two weeks later, they were back to their baseline open rates. The lesson here: key length matters, and -all needs a living sender list.

Step‑by‑Step: Fixing a Broken DKIM SPF DMARC Chain (Expanded Walk‑Through)

Log into your DNS provider. Locate the TXT records for default._domainkey.yourdomain.com (DKIM), yourdomain.com (SPF), and _dmarc.yourdomain.com (DMARC). If any are missing, that’s your first fix. I’ve seen brands wait three weeks because they thought the records were there when actually the DNS provider had failed to propagate the TXT entry after a failed edit. Screenshot your records before you edit, and keep a text file backup of the old values.
Generate a new DKIM key. Most email platforms (HubSpot, Outreach, Salesforce Marketing Cloud) have a “rotate DKIM key” button. Click it, copy the new public key record, and paste it into DNS. Wait at least an hour for propagation, then send a test email and check the header for the DKIM=-pass line. If you’re using a platform that doesn’t have a one‑click rotate, you can generate a key pair with OpenSSL: openssl genrsa -out private.key 2048 followed by openssl rsa -in private.key -pubout -out public.txt. Publish the public part as a TXT record named selector._domainkey.yourdomain.com. The selector can be anything you want, as long as your sending platform references the same string.
Audit your SPF record. Pull the current record into a text editor. List every service you send through—your CRM, your automation tool, any third‑party newsletter platform. Add include: for each one. Remove any +all and replace with ~all if you’re in the verification phase, or -all if you’re confident. Keep the total DNS lookups under 10; if you exceed that, use a service like AuthSMTP that consolidates includes, or consider a “spf flattening” tool that replaces multiple include: statements with a single ip4: or ip6: directive. I once had a client with 12 include: statements; after flattening, their SPF record went from 300 characters to 85, and their deliverability stabilized immediately because the 10‑lookup limit stopped being hit.
Set DMARC to p=none. Create a TXT record at _dmarc.yourdomain.com with the value v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com. The rua tag tells receivers where to send aggregate reports. Some people also add ruf=mailto:dmarc-forensic@yourdomain.com for forensic reports, which show the actual email that failed authentication. I usually start with just rua because the forensic emails can flood your inbox quickly if you have high volume. Send a small batch of emails—say 50 to 100—and check those reports daily for the first week. If you’re using a platform like Google Postmaster Tools, you can see some of this data there too, but DNS‑level reports give you the full picture.
Review the DMARC reports. Look for pass and fail statuses under the dkim and spf columns. If you see failures from your own systems, dig into DNS propagation or key rotation. Sometimes it’s as simple as the TTL (time to live) on your DNS record being too high; lower it to 300 seconds a few hours before you make changes so the new value propagates faster. If third‑party services are failing, add their include: to SPF or configure their DKIM selector correctly. I had a client whose ESP was using a subdomain for sending, and the DKIM selector was set to mail but the ESP expected s1._domainkey. Fixing that selector name solved their 15 percent spam placement in one send cycle.
Graduate the DMARC policy. After two weeks of clean reports and no unexpected failures, change the policy to p=quarantine. Monitor for another seven days. If everything still looks good, flip to p=reject. Keep an eye on your inbox placement metrics during each transition; if you see a dip, pause the policy move and go back one step. I typically advise clients to keep a spreadsheet tracking send volume, policy state, and placement rate for each send cycle during this ramp. It makes the data pattern obvious and prevents the “I thought we were at reject” confusion.

Follow those steps and you’ll move from a guessing game to a repeatable process that keeps your email out of the junk folder.

The Alignment Deep‑Dive: Why Passing Checks Still Land in Spam (Expanded)

Comparing Self‑Hosted vs. Managed Authentication Services (Expanded)

Real‑World Examples of Deliverability Wins and Fails (Expanded)

Let’s look at two hypothetical but grounded scenarios so the patterns stick.

Conclusion: Make Authentication Your Default, Not an Afterthought

I’ve lost count of how many times a client has called me in a panic because half their outreach vanished into spam, only to find out the DKIM key had expired three months ago or the SPF record was missing the new marketing platform’s IP. The good news is that once you have these three records dialed in and aligned, the technical heavy lifting is done. You can shift your energy toward crafting better copy and targeting the right prospects, instead of chasing deliverability gremlins. If you’re currently staring at a DNS portal feeling overwhelmed, start with the p=none DMARC policy, collect data for two weeks, and then move through the steps above. Your future self—and your inbox placement stats—will thank you.

For more on building a repeatable outbound engine that doesn’t trip over authentication, check out OutboundLeadPro; we handle the DKIM, SPF, and DMARC setup so you can focus on the conversation.

Frequently asked questions

How do I find my DKIM selector?

Check your email platform's DNS setup page or look at the header of a sent email for the 'v=DKIM' line and the selector name before the domain.

What's the difference between p=none and p=reject?

p=none tells receivers to just log the result, p= quarantine puts mail in spam, and p=reject tells them to bounce it entirely.

Can I run DMARC without SPF?

Yes, but only if DKIM is aligned; DMARC checks either SPF or DKIM alignment, so dropping SPF leaves DKIM as your sole authenticator.

How long until DMARC reports show data?

Most platforms start aggregating data within 24 to 48 hours, but you need a policy of p=none first to collect enough feedback before moving to quarantine or reject.