How to Test SPF DKIM DMARC and Secure Your Email Deliverability

Think of your email authentication setup as a three-legged stool. If one leg is wobbly, the whole thing comes crashing down. To keep your emails landing in the inbox, you need to regularly test SPF, DKIM, and DMARC using a combination of online tools, manual header checks, and DMARC report analysis.

This isn't just a technical chore; it's a critical process for protecting your domain, keeping your deliverability high, and ensuring your messages actually get read. Skipping these checks is like flying blind—you're leaving your brand open to spoofing and your emails at risk of being flagged as spam.

Why Email Authentication Is a Business Imperative

Let's be blunt: misconfigured email authentication is a direct threat to your bottom line. It's not some abstract IT problem. For any modern business, especially a SaaS company, the fallout is fast and painful.

Imagine your critical transactional emails—password resets, welcome messages, billing alerts—getting silently dumped into spam folders. The result? Frustrated new users who can't log in and angry customers who miss a payment notice. At the same time, your big marketing launch, the one you poured weeks of effort into, completely misses its audience. That's a whole lot of wasted budget and lost opportunity.

Even worse, without solid authentication, your domain is a sitting duck for phishing attacks. Scammers can easily impersonate your brand, tricking your customers with malicious emails. The damage to your brand's trust can be irreversible.

Understanding the Three Pillars of Protection

SPF, DKIM, and DMARC are the trifecta of email security. Each one has a specific job, but they work together to create a rock-solid defense for your domain.

• SPF (Sender Policy Framework): This is basically your domain's approved sender list. It's a DNS record that tells the world, "Only emails coming from these specific IP addresses are legitimate."

• DKIM (DomainKeys Identified Mail): Think of this as a digital, tamper-proof wax seal on your emails. It adds a cryptographic signature that receiving servers can verify, proving the message hasn't been altered on its way.

• DMARC (Domain-based Message Authentication, Reporting, and Conformance): This is the enforcer. DMARC tells receiving servers what to do if an email fails the SPF or DKIM checks. Should they let it through, stick it in quarantine, or reject it outright? It also provides invaluable reports on who is sending email from your domain.

When you test SPF, DKIM, and DMARC, you're doing more than just checking off a task. You're actively safeguarding your brand, making sure your messages get delivered, and maintaining the trust you've worked so hard to build. If you want to go deeper on this, check out our guide to email deliverability best practices.

The Real-World Impact of Neglect

Failing to properly configure and test these records has very real consequences. A messed-up SPF record can cause all the emails from your shiny new marketing platform to be blocked. One tiny error in your DKIM signature can make your beautifully designed newsletters look suspicious to Gmail's filters.

And without DMARC? You're flying completely blind. You have no idea if scammers are spoofing your domain or why your emails are suddenly failing authentication checks.

Ultimately, consistent testing is the bedrock of trustworthy communication. It's what proves to inbox providers like Google and Microsoft that you are who you say you are, dramatically boosting your chances of hitting the primary inbox. It's time to stop seeing authentication as just an IT task and start treating it as a core business function.

Your Pre-Flight Checklist for Authentication Testing

Before you can actually test SPF, DKIM, and DMARC, you need to know where these records live and how to get to them. I like to think of this as a pre-flight check. Getting these initial steps right makes the rest of the testing process a whole lot smoother.

All of your domain's email authentication settings are managed inside its Domain Name System (DNS) records. The DNS is basically your domain's public address book, telling the internet where to find your website and how to handle your email. To get started, you'll need the login details for your domain registrar (like GoDaddy) or your DNS provider (like Cloudflare).

Once you're in, you need to find the DNS management area. This is where you'll see a list of records like A, MX, and the ones we care about: TXT and CNAME. This is the control panel where you'll be adding, editing, and double-checking the values from your email sending platforms.

Locating Your DNS Settings in Common Providers

Finding the DNS management section can sometimes feel like a treasure hunt, as every provider has a slightly different layout. But they all lead to the same place.

• For Cloudflare users: Just log in and click on your domain. You'll see a big "DNS" icon on the left-hand menu. That's your destination.

• For GoDaddy users: After logging in, head to "My Products" and find your domain. Click the "DNS" button next to it to open the management page where you can see and change all the records.

The process is very similar for other popular services like Namecheap or Google Domains. Just keep an eye out for terms like "DNS Management," "Advanced DNS," or "Zone Editor." Getting comfortable in this dashboard is the first critical step.

Demystifying Key DNS Jargon

As you get ready to test SPF, DKIM, and DMARC, you're going to run into some technical terms. Let's clear them up now so the rest of this guide makes perfect sense.

Before diving in, here's a quick cheat sheet for the record types you'll be dealing with most.

Email Authentication Records Explained

These two record types are the foundation of your email authentication setup.

You'll also come across the term selector. This is just a unique name used in a DKIM record that helps receiving mail servers find the right public key to verify your emails. It's part of the DNS record's name (like s1._domainkey.yourdomain.com), and your email service will always give you the exact selector you need to use.

Finally, and this one is important, you'll hear about the SPF lookup limit. Your SPF record can only perform a maximum of 10 DNS lookups. This is a hard limit to prevent performance problems. Every time you add a new sending service, you're usually adding another lookup. Going over this limit is one of the most common reasons for SPF to fail.

Getting a handle on these fundamentals is key to properly interpreting the results from the various email deliverability tools you'll be using. Now that you have access to your DNS and a grasp of the terminology, you're ready to get your hands dirty with the actual testing.

How to Manually Verify Your SPF and DKIM Records

Alright, you've got your records published. Now for the most important part: seeing what the rest of the world sees. Manually checking your records isn't just a box-ticking exercise; it's a critical step to test SPF, DKIM, and DMARC because it gives you a real-time snapshot of how receiving mail servers interpret your setup.

This is all about making sure what you think is configured is actually correct, valid, and not causing sneaky deliverability issues.

For these kinds of on-the-spot checks, the industry pretty much runs on free and powerful tools like MXToolbox. Think of them as an external auditor for your DNS. They look up your domain from outside your network, giving you a clean, unbiased report on your configuration.

Using an Online SPF Checker

The most common point of failure I see in email authentication is, without a doubt, a broken SPF record. It's shockingly easy to mess up, especially as your company grows and you start using more sending services.

To check your SPF record, just pop your domain name into a dedicated online tool. It will immediately fetch and analyze your public SPF record. You're looking for a clear "pass" or a big green checkmark, which confirms the record's syntax is correct.

But hold on—a syntax "pass" doesn't mean you're in the clear. You absolutely have to pay attention to the warnings.

One of the most frequent (and damaging) warnings is "Too many DNS lookups." SPF has a hard limit of 10 DNS lookups. If you go over, your entire record is effectively useless to some mail servers, even if the syntax is perfect. This is a classic "gotcha" that manual testing is perfect for uncovering.

Common SPF Record Mistakes to Look For

When you get your results, don't just glance at the green light and move on. You need to put on your detective hat and actively hunt for these common pitfalls that can sink your deliverability.

• Multiple SPF Records: This is a big one. A domain must have only one SPF record. If a lookup tool finds two separate TXT records both starting with v=spf1, they'll conflict and cause authentication to fail.

• Incorrect Mechanisms: Check for typos. Are you using the right terms like include:, a:, or ip4:? One misplaced character can invalidate an entire entry.

• Missing Senders: This requires a bit of homework. Pull up your SPF record and compare the list of include mechanisms against every single service you use to send email (think Google Workspace, HubSpot, SMASHSEND, etc.). If a tool isn't on the list, its emails are going to fail SPF checks.

The end goal is simple: your SPF record needs to be a complete and accurate inventory of every authorized sender, all while staying under that crucial 10-lookup limit.

Verifying Your DKIM Record and Selector

Next up is DKIM. This one works a bit differently, relying on a public key published in your DNS. To test DKIM, you need two pieces of information: your domain and the DKIM selector.

The selector is just a unique name that your email sending service gives you. It acts like a signpost, telling receiving servers exactly where to find the correct public key for that service.

Most online DKIM checkers will ask for your domain and the selector. When you run the test, the tool performs a DNS lookup for a record that looks something like selector._domainkey.yourdomain.com.

A successful test will confirm two things:

1. The record actually exists and is published correctly.
2. The key's syntax is valid and readable.

If you get a "Record Not Found" error, it's almost always one of two things: you've either got a typo in the selector, or the record was never published to your DNS in the first place. This quick check confirms that the public key needed to validate your signatures is visible to the world. A missing key means every single one of your DKIM signatures will fail, making your emails look incredibly suspicious. It's a simple, essential step to properly test SPF, DKIM, and DMARC.

Alright, you've got your SPF and DKIM records in place. Now for the final piece of the puzzle: DMARC. This is where you graduate from individual record checks to having a strategic, bird's-eye view of your email security. Before you can test SPF, DKIM, and DMARC as a complete system, you need to make sure your DMARC record is published correctly and ready to start collecting data.

Checking the DMARC record itself is pretty simple. Using the same DNS lookup tools you used before, just query the _dmarc.yourdomain.com hostname. A successful lookup should return a TXT record that starts with v=DMARC1;. If you don't see it, double-check that you've got the hostname right and that it's published in the correct DNS zone. This little record is a big deal—it's your instruction manual for receiving mail servers and the beacon that tells them where to send reports.

But here's the thing: DMARC's real power isn't just in its policy. It's in the reports. Once your record is live, you'll start getting aggregate (RUA) reports, usually within 24-48 hours. These XML files are about to become your new best friends for understanding what's really going on with your domain's email.

Demystifying Your First DMARC Report

Let's be honest, opening a raw XML DMARC report for the first time can feel like you're trying to read the Matrix. It's a wall of code. The good news is you don't have to. I highly recommend using a free online parser to turn that XML into something a human can actually read.

Once it's readable, you'll want to focus on a few key data points:

• Source IP: The IP address of the server that sent the email. This is your number one clue for identifying who is sending on your behalf.

• Count: How many emails came from that IP address during the reporting period.

• Disposition: What the receiving server actually did with the messages, based on your DMARC policy (none, quarantine, or reject).

• DKIM Result: A simple pass or fail on DKIM authentication.

• SPF Result: A simple pass or fail on SPF authentication.

These five pieces of information are everything. They're the foundation for spotting misconfigurations and identifying threats. For instance, seeing a huge number of emails from some random IP, all with dkim=fail and spf=fail, is a massive red flag that someone is spoofing your domain.

A Practical Scenario Diagnosing a Report

Let's walk through a real-world situation I see all the time. You open up your first DMARC report and your heart sinks. You see a high volume of emails from an IP address you don't recognize, and every last one is failing both SPF and DKIM.

First, don't panic. Your job is to play detective. Do a quick reverse DNS lookup on the IP. You might find it belongs to a legitimate service. It happens—maybe the marketing department signed up for a new tool and forgot to tell IT. If that's the case, the fix is easy: you just need to get that service's SPF and DKIM info added to your DNS records.

But what if the IP has a history of spam, or it's coming from a country you do no business with? You're almost certainly looking at a spoofing attack. The report just handed you concrete evidence. Since your policy is still p=none, those malicious emails were delivered, but now you have the data you need to confidently move toward quarantine or reject. This is the core loop of how you test SPF, DKIM, and DMARC in a live environment—you monitor, you analyze, and you act. This process is fundamental to improving your email deliverability and locking down your domain.

Understanding DMARC Adoption and Enforcement

Setting up a p=none policy is a fantastic first step, but it's crucial to remember that it offers zero direct protection. It's purely a data-gathering tool. What's worrying is how many companies get stuck in this monitoring phase and never move forward.

The email world has seen a big push for DMARC, with adoption among top domains jumping from 27.2% to 47.7% between 2023 and 2025. That's great, right? But dig a little deeper, and the picture changes. Of the nearly 1.8 million top domains, only 350,513 have actually implemented an enforcement policy (p=quarantine or p=reject). For B2B SaaS companies, the numbers are even starker: 63% of those using DMARC are still stuck in monitoring-only mode, leaving their front door wide open to spoofing attacks. You can dive into the full breakdown in the DMARC Adoption Report 2025.

This data tells a critical story. The goal isn't just to have a DMARC record. The goal is to get to enforcement. By methodically using your reports to identify all your legitimate senders and fix their authentication, you can safely make the move to a policy that actively protects your brand, your customers, and your deliverability.

Moving from Monitoring to Full Enforcement

You've been diligently collecting DMARC reports with a p=none policy, and that's a fantastic start. But let's be honest: at this stage, you're just watching the attacks happen. You aren't stopping them. The real power of DMARC kicks in when you move to an enforcement policy that actively quarantines or rejects fraudulent emails.

Switching to enforcement isn't a blind leap of faith. It's a calculated, data-driven move. Those DMARC reports you've been gathering are your roadmap, clearly showing you which sending services are legitimate and which ones need attention. Rushing this can be disastrous—imagine critical password resets or customer invoices suddenly getting blocked.

The Phased Rollout Strategy

A safe rollout is all about incrementally tightening your security without breaking your email operations. The secret weapon here is the pct= (percentage) tag in your DMARC record. This nifty little tag tells receiving servers to apply your new, stricter policy to just a small, random fraction of emails that fail authentication.

This lets you test the real-world impact of a p=quarantine policy on a tiny slice of your email flow. You can spot any legitimate-but-misconfigured senders without causing a full-blown operational meltdown.

This gradual, percentage-based approach is the professional standard for a reason. It works.

Your Pre-Enforcement Checklist

Before you even dream of changing p=none to p=quarantine, you need to be absolutely certain all your legitimate email is authenticating perfectly. Dive into your DMARC aggregate reports and confirm a few things:

• All Known Senders Are Passing: Go through your reports and find every service you use to send email—Google Workspace, SMASHSEND, HubSpot, you name it. They should all show a consistent pass for both SPF and DKIM.

• No Legitimate Failures: If you see a known, trusted service failing authentication, you must stop and fix its SPF or DKIM setup. This is non-negotiable. Pushing ahead will cause those emails to be blocked.

• Investigate Unknown IPs: Are there unfamiliar IP addresses sending on your behalf? Track them down. It could be a forgotten marketing tool from years ago or, more ominously, an active spoofing attack.

Only when your reports show a clean bill of health should you even consider starting the move to enforcement.

Don't Forget to Protect Your Subdomains

Cybercriminals are clever. If they see your primary domain is locked down with a strong DMARC policy, they'll pivot to an unprotected subdomain. Think about an attacker sending phishing emails from billing.yourcompany.com when you only send mail from yourcompany.com.

To slam this door shut, use the sp= (subdomain policy) tag in your DMARC record. Setting sp=reject tells the world to reject mail from any of your subdomains that don't have their own specific DMARC record. It's a critical step for locking down your entire brand presence.

The impact of enforcement is undeniable. In the United States, where DMARC enforcement is now a standard for major domains, successful phishing delivery rates plummeted from 69% to just 14%—a stunning 81% reduction in vulnerability. In contrast, countries without such mandates, like the Netherlands, saw their vulnerability soar to 97%. This stark difference shows that monitoring-only policies just don't cut it.

This careful, data-first approach is exactly how you achieve full DMARC enforcement, protecting your brand's reputation without disrupting your business.

Common Questions About Email Authentication

As you start testing your SPF, DKIM, and DMARC records, you're bound to run into a few head-scratchers. These are the practical, real-world questions that pop up when you move from reading about authentication to actually implementing it. Let's walk through some of the most common points of confusion so you can keep your testing process moving forward.

First off, how often should you even be checking this stuff? It's definitely not a set-it-and-forget-it task. You need to re-verify your records any time you bring a new email sending service into the fold—think a new CRM, a new billing platform, or any tool that sends email on your behalf.

I always recommend doing a full audit of every sender listed in your SPF record at least quarterly. This helps you clean out old services you no longer use and, crucially, keeps you from hitting that dreaded 10 DNS lookup limit.

What If My Test Fails But Emails Still Deliver?

This one can really throw people for a loop. You see an authentication test fail, but your emails seem to be landing in inboxes just fine. What gives?

This happens because inbox providers like Gmail and Microsoft are looking at a whole constellation of signals to judge an email, not just one. Your sender reputation is a huge piece of that puzzle. If you have a strong, established reputation built up over time, a single authentication hiccup might not be enough to get your mail blocked outright.

But you absolutely should treat this as a flashing red warning light on your dashboard. It's a major red flag that slowly chips away at the trust you've built with inbox providers and seriously increases your risk of landing in spam down the road. Fix it. Fast.

Understanding DMARC Report Types

Once you get DMARC set up, you'll start hearing about two kinds of reports: RUA and RUF. Knowing the difference is critical to actually using them to protect your domain.

• RUA (Aggregate) Reports: Think of these as your daily XML summaries. They give you the big picture, showing which IP addresses sent mail for your domain, the volume of messages, and whether they passed or failed authentication checks. RUA reports are indispensable for getting a complete view of your sending sources.

• RUF (Forensic) Reports: These are entirely different. They're real-time, individual reports triggered by a specific authentication failure. They contain redacted copies of the email that failed and are incredibly valuable for digging into a potential spoofing attack. Not every email provider sends RUF reports due to privacy concerns, but RUA reports are standard.

Can I Have Multiple SPF or DMARC Records?

This is a hard no. It's one of the most common mistakes we see.

Your domain must have only one SPF record and only one DMARC record. Publishing multiple SPF records is a classic error that actually invalidates all of them, causing your authentication to fail across the board. If you're using several different services that send email for you, you have to merge all their requirements into a single SPF record string.

The same rule applies to DMARC—just one record is allowed in your DNS.

DKIM, however, is the exception. You can, and often will, have multiple DKIM records. This is because each sending service you use will typically generate its own unique public/private key pair, which means you'll need a distinct DKIM record with a unique selector for each one.

Juggling email authentication across all your sending platforms can get complicated, but it's a non-negotiable part of sending email today. SMASHSEND takes the headache out of it by automatically configuring and managing SPF, DKIM, and DMARC for you. This ensures your technical setup is always dialed in for maximum deliverability. Learn more at https://smashsend.com.