The Complete Guide to Email Authentication: SPF, DKIM, and DMARC

A Calgary roofing company came to us last fall with a problem they couldn't figure out. Their Google Ads were performing well, their landing pages were converting, and their CRM was full of new leads. But when the sales team followed up by email, half the replies were landing in spam. Prospects weren't ghosting them. Gmail was.

They'd been losing leads for months before anyone thought to check the email setup.

This is what happens when your domain doesn't have proper email authentication. Your messages look suspicious to receiving mail servers, so they get flagged, quarantined, or silently dropped. You never get a bounce notification. You just... don't get replies.

The fix isn't complicated. Three DNS records — SPF, DKIM, and DMARC — tell the world that emails from your domain are actually from you. Setting them up takes an afternoon. Ignoring them costs you money every single day.

What Email Authentication Actually Does

When you send an email from your domain, the receiving server has to make a decision: is this message real, or is someone pretending to be you? Without authentication records, the server has nothing to go on except the email's content and your IP address. That's not much.

SPF, DKIM, and DMARC each solve a different part of this trust problem. They work together (you need all three) but they do different things.

Think of it like sending a registered letter. SPF is the list of approved couriers you've authorized to carry your mail. DKIM is the tamper-evident seal on the envelope. DMARC is your standing instruction to the post office about what to do if a letter shows up claiming to be from you but fails either check.

None of this is new technology. SPF has been around since 2006. But adoption has been inconsistent, and too many businesses, including ones spending thousands on email campaigns that aren't converting, have never checked whether these records exist for their domain.

SPF: Who's Allowed to Send on Your Behalf

SPF stands for Sender Policy Framework. It's a DNS TXT record that lists every server and service authorized to send email using your domain name.

Here's what an actual SPF record looks like:

v=spf1 include:_spf.google.com include:sendgrid.net include:spf.protection.outlook.com -all

Breaking that down:

• v=spf1 declares the SPF version.
• Each include: entry authorizes a third-party service. In this case, Google Workspace, SendGrid, and Microsoft 365.
• -all at the end means "reject anything not on this list." This is the strict enforcement flag, and you should use it. The softer ~all (tilde) tells servers to accept unauthorized mail but mark it as suspicious. That's better than nothing, but -all is what you want in production.

The most common mistake we see is a missing or outdated SPF record. You signed up for Mailchimp two years ago, added their include: to your SPF, then switched to ActiveCampaign without updating the record. Now ActiveCampaign emails fail SPF checks because the sending server isn't listed.

There's also a 10-DNS-lookup limit baked into the SPF spec. Every include: triggers additional lookups behind the scenes, and if your record chains more than 10, the entire check fails. This catches businesses that use a lot of SaaS tools: your CRM, your marketing platform, your helpdesk, your transactional email service. You can hit 10 fast. Tools like MXToolbox's SPF lookup will show you exactly how many lookups your record triggers.

How to Check Your SPF Record

Open a terminal and run:

nslookup -type=txt yourdomain.com

Or use MXToolbox's online checker. You're looking for a single TXT record starting with v=spf1. If you see two SPF records, that's a problem. The spec only allows one per domain, and having two causes unpredictable failures.

DKIM: Proving the Message Wasn't Tampered With

DKIM — DomainKeys Identified Mail — adds a cryptographic signature to every outgoing email. The sending server signs the message with a private key. The receiving server looks up the matching public key in your DNS and verifies the signature. If the message was altered in transit, the signature won't match and the check fails.

A DKIM DNS record looks like this:

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

That p= value is your public key, a long base64-encoded string. The selector1 part is a label chosen by your email provider so you can have multiple DKIM keys active simultaneously (useful when rotating keys or using different providers for different purposes).

You don't generate DKIM keys yourself. Your email provider (Google Workspace, Microsoft 365, Mailchimp, whatever) gives you the record to add to your DNS. The setup process is always the same: go to your provider's admin panel, find the DKIM settings, copy the DNS record they give you, and add it as a TXT record through your domain registrar or DNS host.

Where things go wrong: DKIM records are long. Really long. Some DNS hosts have character limits on TXT records, and the key gets silently truncated. The record looks like it's there, but verification fails because the key is incomplete. If you've added a DKIM record and checks are still failing, this is the first thing to investigate.

Google Workspace uses google._domainkey as the selector. Microsoft 365 uses selector1._domainkey and selector2._domainkey. If you're checking DKIM for a specific provider, you need to know which selector they use, because a generic lookup won't find it.

DMARC: The Policy That Ties It Together

SPF and DKIM validate whether an email is legitimate. DMARC — Domain-based Message Authentication, Reporting, and Conformance — tells receiving servers what to do when those checks fail. It also gives you reporting so you can see who's sending email as your domain.

A DMARC record lives at _dmarc.yourdomain.com and looks like this:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100; adkim=r; aspf=r"

The tags:

• p= is the policy. This is the part that matters. It can be none, quarantine, or reject.
• rua= is where aggregate reports get sent. You'll receive XML reports showing all email activity for your domain.
• pct= is the percentage of messages the policy applies to (useful for gradual rollout).
• adkim=r and aspf=r set alignment mode to "relaxed," meaning subdomains can pass checks against the parent domain.

Now, here's where we have a strong opinion.

Setting your DMARC policy to p=none is essentially the same as not having DMARC at all. It tells receiving servers "check SPF and DKIM, but if they fail, deliver the message anyway." You get reports, which is useful during initial setup, but you're not protecting your domain from spoofing. We see businesses that set up DMARC years ago with p=none as a "temporary" measure and never moved past it.

If your DMARC policy is still set to p=none, you've done the paperwork but left the door unlocked. Move to quarantine or reject — your domain's reputation depends on it.

The right approach: start with p=none for two to four weeks while you monitor the reports and make sure all your legitimate sending sources pass SPF and DKIM. Then move to p=quarantine (failed messages go to spam). Once you're confident everything is clean, move to p=reject (failed messages get blocked entirely). Don't stay on none.

What Failure Looks Like

When authentication fails, the evidence shows up in email headers. If you open a message in Gmail and click "Show original," you'll see something like this for a passing message:

Authentication-Results: mx.google.com;
    dkim=pass [email protected] header.s=google header.b=abc123;
    spf=pass (google.com: domain of [email protected] designates 209.85.220.41 as permitted sender)
    dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com

And this for a failing one:

Authentication-Results: mx.google.com;
    dkim=fail (signature verification failed);
    spf=softfail (google.com: domain of [email protected] does not designate 192.168.1.100 as permitted sender)
    dmarc=fail (p=NONE dis=NONE) header.from=yourdomain.com

That softfail on SPF means the sending IP isn't in the SPF record but the policy uses ~all instead of -all. The dkim=fail means either the DKIM record is missing, the key is wrong, or the message was modified after signing. And dmarc=fail with p=NONE means the domain owner hasn't told anyone to do anything about it.

DMARC aggregate reports are XML files sent to the rua= address you specified. They're unreadable in raw form. Use a tool like DMARC Analyzer, Postmark's free DMARC monitoring, or Google Postmaster Tools to parse them into something useful. These reports show you every IP address that sent email claiming to be from your domain, whether SPF and DKIM passed, and what the receiving server did with the message. If someone is spoofing your domain, the reports will show it.

The Setup Order

Getting this right is sequential. Do it out of order and you'll create problems. If you're starting a new business in Alberta, email authentication should be on your setup checklist from day one.

Common Mistakes and How to Fix Them

Multiple SPF records. Your domain can only have one SPF TXT record. If two exist, SPF evaluation becomes undefined. Some servers will use the first, some the last, some will fail the check entirely. Merge them into a single record.

Forgetting a sending service. You added Mailchimp to your SPF but forgot that your invoicing software also sends email as your domain. When you move DMARC to quarantine, those invoice emails start landing in spam. The DMARC reports will reveal this, which is exactly why the monitoring phase matters.

DKIM key truncation. Some DNS providers (especially older ones with web-based control panels) have a 255-character limit per TXT record string. DKIM keys are often longer. The fix is to split the key into multiple quoted strings within a single TXT record:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A" "MIIBCgKCAQEA2pmMnCbBsBqq0dMEW..."

Most modern DNS providers handle this automatically. If yours doesn't, it might be time to move your DNS to something like Cloudflare.

Using ~all instead of -all in SPF. The tilde (~) is a softfail. It tells receiving servers "this probably isn't authorized, but let it through." The hyphen (-) is a hard fail. Use the hyphen. Softfail was a reasonable default in 2010 when everyone was still figuring SPF out. It's not 2010 anymore.

Never checking DMARC reports. Setting up rua= and then ignoring the reports defeats the purpose. You don't need to read them daily, but check monthly at minimum. We recommend a dedicated reporting tool like DMARC Analyzer or Postmark's free option rather than trying to parse raw XML from your inbox.

Why This Matters Beyond Spam Filters

Email authentication isn't just about deliverability. It's about protecting your brand.

Without DMARC enforcement, anyone can send email that looks like it comes from your domain. Phishing attacks that spoof business domains are still one of the most effective attack vectors in 2026. Your clients and partners trust email from your domain. If a bad actor sends a convincing phishing email from what appears to be your address, the damage lands on your reputation.

Google and Yahoo both started requiring SPF, DKIM, and DMARC for bulk senders in February 2024. If you send more than 5,000 emails per day to Gmail addresses, you must have all three configured with DMARC at p=quarantine or higher. But even if you're a small business sending 50 emails a day, the same authentication signals affect whether your messages reach the inbox.

This connects to a broader pattern we see across web presence management: the technical infrastructure behind your brand matters as much as the visible parts. The same principle applies to structured data and AI search visibility — machines need explicit, verifiable signals to trust your content, whether that's a search engine reading your schema markup or a mail server reading your DNS records.

Tools We Recommend

MXToolbox — The standard for checking SPF, DKIM, DMARC, and general DNS health. Free for basic lookups. Run the SuperTool check on your domain right now; it takes 30 seconds.

Google Postmaster Tools — If any meaningful portion of your audience uses Gmail (they do), this shows you exactly how Google views your domain's reputation, spam rate, and authentication results.

DMARC Analyzer — Parses those unreadable XML aggregate reports into dashboards and alerts. Paid tiers exist, but several tools (including Postmark's) offer free DMARC monitoring.

mail-tester.com — Send a test email to their disposable address and get a score with specific issues flagged. Good for a quick health check after making changes.

Your own email headers. In Gmail, click the three dots on any message and select "Show original." In Outlook, open message properties. The Authentication-Results header tells you exactly what passed and failed. This is free and always available.

When to Call in Help

If your business runs on email — and in 2026, whose doesn't — and you're not confident your authentication is set up correctly, this is worth getting right the first time. Misconfigured records can cause more deliverability problems than having no records at all, because a failing SPF or DKIM check is actively worse than a missing one in some server configurations.

We set up email authentication as part of our web development and email marketing work. It's one of those things that takes an experienced person an hour and saves months of "why aren't people getting our emails" troubleshooting.

The single thing to remember: SPF, DKIM, and DMARC are not optional. They are the minimum standard for sending email from a business domain. If you haven't checked yours this year, open MXToolbox right now and type in your domain. What you find might explain a lot.

Sources

• RFC 7208: Sender Policy Framework (SPF) — The IETF specification for SPF, including the 10-DNS-lookup limit (Section 4.6.4) and record syntax
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures — The IETF specification for DKIM cryptographic signing and verification
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — The IETF specification for DMARC policy, alignment, and aggregate reporting
• DMARC Overview — dmarc.org — Official DMARC project site with deployment guides and specification resources
• Google Email Sender Guidelines — Google's official requirements for all senders and bulk senders (5,000+ messages/day), including SPF, DKIM, and DMARC mandates effective February 2024
• Yahoo Sender Best Practices — Yahoo's official sender requirements for email authentication and bulk sending
• MXToolbox SPF Check & Lookup — Free SPF record lookup, DNS lookup counter, and validation tool
• Google Postmaster Tools — Google's dashboard for monitoring domain reputation, spam rate, and authentication results for Gmail delivery
• DMARC Analyzer (Mimecast) — DMARC aggregate report parsing, monitoring dashboards, and domain authentication management
• mail-tester.com — Free email spam scoring tool that checks SPF, DKIM, DMARC, content, and blacklist status