SPF, DKIM, DMARC: The Small Team’s Setup Guide

You’ve built your product. You’re ready to send emails at scale—welcome sequences, password resets, revenue notifications. But before you hit send on anything, you need to prove to the internet that you actually own your domain.

This is where SPF, DKIM, and DMARC come in. They’re not optional. They’re not nice-to-have. They’re the foundation that keeps your emails out of spam folders and your domain safe from impersonation. And yes, they sound intimidating if you’ve never touched DNS records before.

We’re going to walk through exactly what each one does, why you need all three, and how to set them up in under an hour. No MBA-speak. No hand-waving. Just the concrete steps your small team needs to ship authenticated email.

Why Email Authentication Matters for Small Teams

Let’s start with the problem. When you send an email from your domain, mail servers on the receiving end have no way to know if you actually own that domain. Anyone could claim to be hello@yourcompany.com. That’s a security nightmare—for you, for your customers, and for the inbox providers trying to keep spam out.

Email authentication is how you solve that. You’re essentially saying: “I control this domain. I’m authorizing these mail servers to send email on my behalf. If you get an email claiming to be from me, here’s how you verify it’s real.”

For small teams, this matters for three concrete reasons:

Deliverability. Gmail, Outlook, and other major providers are increasingly strict about authentication. If you don’t have SPF, DKIM, and DMARC set up, your emails land in spam. That means your welcome sequences don’t work. Your password resets disappear. Your revenue notifications never arrive. You’re invisible.

Domain reputation. Every email you send builds a track record tied to your domain. If you’re unauthenticated, spammers can impersonate you and tank your reputation. Once that happens, it takes months to recover. Authentication keeps you in control.

Compliance and trust. If you’re sending transactional email, lifecycle campaigns, or anything touching customer data, you need to be able to prove the email came from you. Authentication is table stakes for any team taking email seriously.

The good news: setting up SPF, DKIM, and DMARC is a one-time task. Once it’s done, it’s done. And Mailable makes it even simpler—you can generate production-ready email templates and sequences without worrying about the infrastructure underneath.

What SPF Does (and Why It’s Not Enough)

SPF stands for Sender Policy Framework. Think of it as a whitelist. You’re telling mail servers: “Here are the IP addresses and mail servers authorized to send email from my domain.”

When someone receives an email claiming to be from hello@yourcompany.com, their mail server checks your SPF record. It says: “Is the server that sent this email on the whitelist?” If yes, it passes. If no, it fails.

Here’s what an SPF record looks like:

v=spf1 include:sendgrid.net ~all

Breaking that down:

• v=spf1 — This is version 1 of SPF. Always start with this.
• include:sendgrid.net — You’re authorizing SendGrid’s servers to send mail on your behalf. If you use a different email service, you’d include their domain instead.
• ~all — This is a “soft fail.” It says “if an email comes from an unauthorized server, treat it skeptically but don’t reject it outright.” (You can use -all for a hard fail, which rejects unauthorized mail entirely.)

The problem with SPF alone: it’s easy to spoof. An attacker can forge the “From” address on an email. SPF checks the sending server’s IP, not whether the actual From address is legitimate. That’s where DKIM comes in.

DKIM: Cryptographic Proof Your Email Is Real

DKIM stands for DomainKeys Identified Mail. Unlike SPF, which checks the sending server, DKIM cryptographically signs the email itself. It’s proof that the email came from you and hasn’t been tampered with.

Here’s how it works:

You generate a public-private key pair. The private key stays with your mail server. The public key goes in your DNS records. When you send an email, your mail server signs it with the private key. The receiving mail server uses the public key to verify the signature. If the signature is valid, the email is definitely from you. If someone modifies the email in transit, the signature breaks.

Setting up DKIM requires two steps:

Step 1: Generate the key pair. Your email service provider (SendGrid, Postmark, Mailable’s integration partners, etc.) handles this for you. You don’t generate keys manually.

Step 2: Add the public key to DNS. Your provider gives you a DKIM record that looks like this:

default._domainkey.yourcompany.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Once that’s in DNS, you’re done. Every email from your authorized servers gets signed automatically.

DKIM is stronger than SPF because it’s tied directly to the email content. But here’s the catch: DKIM only works if the domain in the DKIM signature matches the domain in the From address. If you’re sending from hello@yourcompany.com but your DKIM is signed with a different domain, it fails. That’s why alignment matters—and that’s what DMARC enforces.

DMARC: The Policy Layer That Ties It All Together

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It’s the traffic cop that says: “Here’s my SPF policy. Here’s my DKIM policy. If an email claims to be from my domain but fails both, here’s what you should do with it.”

DMARC is where you actually set the rules. A basic DMARC record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com

Breaking it down:

• v=DMARC1 — Version 1. Always this.
• p=none — This is your policy. none means “don’t reject mail, just monitor.” Other options are quarantine (send to spam) and reject (block entirely).
• rua=mailto:dmarc@yourcompany.com — Send aggregate reports to this email address. These reports tell you what’s passing and failing authentication.

DMARC has three critical features:

Authentication enforcement. You decide whether to monitor, quarantine, or reject unauthenticated mail. Start with p=none to see what happens. Gradually move to quarantine and reject as you gain confidence.

Reporting. You get daily reports showing which emails passed SPF, which passed DKIM, and which failed. This tells you if there’s a configuration problem or if someone’s trying to spoof your domain.

Alignment. DMARC requires that either SPF or DKIM (or both) align with the From domain. If you’re sending from hello@yourcompany.com, the SPF or DKIM domain must match. This closes the loophole that SPF alone leaves open.

For small teams, DMARC setup is where you get real visibility into your email infrastructure. You’ll see exactly what’s happening with every email sent from your domain.

The Three-Step Setup Process

Now let’s get practical. Here’s how to set up SPF, DKIM, and DMARC for a small team.

Step 1: Set Up SPF

First, log into your domain registrar or DNS provider. This is usually where you bought your domain (GoDaddy, Namecheap, Route 53, etc.) or where you manage DNS records (Cloudflare, etc.).

Find the DNS records section. You’re looking for a place to add a TXT record.

Create a new TXT record with:

• Name/Host: @ (this means the root domain)
• Value: v=spf1 include:sendgrid.net ~all (replace sendgrid.net with your actual email service provider’s domain)

If you’re using Mailable or another email platform, they’ll tell you exactly what to include. Common examples:

• SendGrid: include:sendgrid.net
• Postmark: include:postmarkapp.com
• Mailgun: include:mailgun.org
• Braze: include:braze.com

If you use multiple email services, combine them:

v=spf1 include:sendgrid.net include:postmarkapp.com ~all

Save the record. DNS changes take 15 minutes to a few hours to propagate. You can check if it’s live by running a DNS lookup:

dig yourcompany.com TXT

You should see your SPF record in the output.

Step 2: Set Up DKIM

DKIM setup varies slightly depending on your email provider. Here’s the general process:

1. Log into your email provider’s dashboard. This could be SendGrid, Postmark, Braze, or another service.

2. Find the authentication or domain settings section. Different providers name this differently, but look for “Authentication,” “Domain Verification,” or “Sending Domain.”

3. Add your domain. Enter the domain you want to send from (e.g., hello@yourcompany.com).

4. Generate DKIM keys. The provider generates a public-private key pair. You don’t touch the private key. You copy the public key.

5. Add the DKIM record to DNS. The provider gives you a record that looks like:

default._domainkey.yourcompany.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3..."

Go back to your DNS provider and add this as a new TXT record. The hostname is default._domainkey (or sometimes a selector like selector1._domainkey—your provider will specify).

6. Verify the domain. Once DNS propagates, your email provider should automatically verify the DKIM record. Some require you to click a “Verify” button.

Once verified, every email from that domain gets signed with DKIM automatically. You don’t need to do anything else.

Step 3: Set Up DMARC

DMARC is the simplest of the three because you control it entirely. No third-party provider involved.

1. Create a DMARC record in DNS. Add a new TXT record with:

   • Name/Host: _dmarc
   • Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com

2. Set up a DMARC reporting email. The rua field points to where you want aggregate reports sent. Create an email address like dmarc-reports@yourcompany.com (or use an existing one). This address will receive daily reports.

3. Save and verify. Once DNS propagates, mail servers will start checking your DMARC policy.

Start with p=none for at least a week. This tells mail servers to monitor but not reject. During this time, you’ll get reports showing what’s passing and failing. Once you’re confident everything is aligned, move to p=quarantine (sends failing mail to spam) or p=reject (blocks it entirely).

Here’s a step-by-step guide to DMARC, DKIM, and SPF setup that covers common scenarios and service-specific configurations.

Common Setup Scenarios for Small Teams

Sending from a Single Email Service

If you’re using one provider (SendGrid, Postmark, etc.) for all your email:

• SPF: Include that provider’s domain.
• DKIM: Use the provider’s DKIM keys.
• DMARC: Set p=none initially, then gradually move to reject as you gain confidence.

This is the simplest setup. Everything aligns perfectly.

Sending from Multiple Services

If you’re using SendGrid for transactional email and Mailchimp for campaigns:

• SPF: Include both providers: v=spf1 include:sendgrid.net include:mailchimp.com ~all
• DKIM: Both providers sign with your domain. Both signatures are valid.
• DMARC: Set p=none. As long as SPF or DKIM passes for each email, DMARC passes.

The key: keep your SPF record short. If you have too many includes (more than 10), you’ll hit the DNS lookup limit and SPF will fail. If that happens, you need to consolidate providers or use a DMARC-compliant service that handles SPF aggregation.

Sending from Your Own Mail Server

If you’re running your own mail server (less common for small teams, but possible):

• SPF: Include your server’s IP address: v=spf1 ip4:203.0.113.0 ~all
• DKIM: Generate keys on your server and add the public key to DNS.
• DMARC: Set your policy based on your confidence level.

This gives you full control but requires more maintenance.

Troubleshooting: What Goes Wrong and How to Fix It

Even with a step-by-step guide, things sometimes don’t work. Here’s what to watch for.

SPF Failures

Problem: SPF check fails, emails go to spam.

Likely cause: You didn’t include your email provider’s domain, or you included the wrong one.

Fix: Double-check your provider’s SPF include. SendGrid is sendgrid.net, not sendgrid.com. Postmark is postmarkapp.com. Get it exactly right.

Also check: If you have too many SPF includes, you’ll hit the DNS lookup limit. Consolidate to fewer providers or use a service that aggregates SPF records.

DKIM Failures

Problem: DKIM signature is invalid, emails fail DKIM checks.

Likely cause: The DKIM record wasn’t added to DNS correctly, or DNS hasn’t propagated yet.

Fix: Wait 15 minutes to an hour for DNS to propagate. Then verify the record is in DNS:

dig default._domainkey.yourcompany.com TXT

You should see your public key in the output.

Also check: Make sure your email provider generated the DKIM keys for your specific domain. If you’re sending from hello@yourcompany.com, the DKIM must be for yourcompany.com, not a subdomain.

DMARC Failures

Problem: DMARC policy is not being enforced, or you’re seeing unexpected failures in reports.

Likely cause: SPF and DKIM are not aligned with your From domain.

Fix: Check your DMARC reports (you should be getting them daily). Look for the “alignment” section. If SPF or DKIM fails, it means the signing domain doesn’t match the From domain. Make sure your email provider is signing with your actual domain.

Also check: If you’re using a subdomain (e.g., mail.yourcompany.com), make sure your DMARC record is on the right domain. If you send from hello@yourcompany.com, your DMARC record should be at _dmarc.yourcompany.com, not _dmarc.mail.yourcompany.com.

Monitoring and Ongoing Maintenance

Once SPF, DKIM, and DMARC are set up, you’re not done. You need to monitor them.

Check your DMARC reports daily. These tell you what’s passing and failing. If you suddenly see a spike in failures, something changed. Maybe you added a new email service and forgot to update SPF. Maybe someone’s trying to spoof your domain. The reports let you catch problems early.

Use a DMARC monitoring service. If you’re getting hundreds of emails a day, manually parsing DMARC reports is tedious. Services like Valimail or Mimecast aggregate and visualize the data for you.

Gradually increase your DMARC policy. Start with p=none. After a week, move to p=quarantine. After another week, move to p=reject. This gradual approach lets you catch alignment issues before they start bouncing your legitimate mail.

Keep your SPF record clean. Every time you add a new email service, add it to SPF. Every time you stop using one, remove it. A clean SPF record is easier to troubleshoot.

Document your setup. Write down what you’ve done. Which providers are you using? What SPF includes do you have? When did you enable DMARC reject? This documentation will save you hours when something breaks or when a team member needs to troubleshoot.

Why This Matters for Small Teams Using Mailable

If you’re using Mailable to generate email templates and sequences, authentication is the invisible layer that makes everything work. You can build beautiful, high-converting emails with AI. But if your domain isn’t authenticated, those emails never arrive.

Mailable handles the hard part—generating production-ready templates from a prompt, building drip sequences, automating sales funnels. You handle authentication. Together, you get Braze-level power without the Braze-level overhead.

And because Mailable supports API, MCP, and headless workflows, you can integrate authentication into your larger email infrastructure. Whether you’re embedding transactional email in your product, running lifecycle campaigns, or managing sales funnels, authentication is the foundation.

The Mailable terms of service and privacy policy outline how we handle your email data. But the authentication is yours to control. You own the domain. You control the DNS records. You decide the DMARC policy. That’s the small-team advantage.

Advanced: Subdomain Isolation and Sending Domain Strategy

Once you’re comfortable with the basics, there’s a more sophisticated approach: using subdomains for different email types.

Instead of sending everything from hello@yourcompany.com, you might send:

• Transactional email from transactional@yourcompany.com
• Marketing campaigns from marketing@yourcompany.com
• Sales outreach from sales@yourcompany.com

Each subdomain gets its own SPF, DKIM, and DMARC records. This gives you several advantages:

Isolation. If one subdomain’s reputation tanks, it doesn’t affect the others. If a marketing campaign gets flagged as spam, your transactional email still delivers.

Granular policies. You can set p=reject for transactional (where you want zero failures) and p=quarantine for marketing (where you’re more tolerant of edge cases).

Cleaner SPF. Each subdomain has a shorter SPF record with fewer includes, reducing the risk of hitting DNS lookup limits.

To set this up:

1. Create SPF, DKIM, and DMARC records for each subdomain. Use the subdomain in the record name (e.g., _dmarc.transactional.yourcompany.com).

2. Configure your email provider to send from each subdomain. Most providers let you add multiple sending domains.

3. Monitor each subdomain separately. You’ll get separate DMARC reports for each, making it easier to spot problems.

This is advanced, but it’s worth considering if you’re sending high volumes of email or managing multiple email programs.

Key Takeaways: What Every Small Team Needs to Know

Here’s what to remember:

SPF is the first line of defense. It whitelists the servers authorized to send mail from your domain. Set it up first, and include your email provider’s domain.

DKIM adds cryptographic proof. It signs each email so the receiving server can verify it came from you and hasn’t been tampered with. Your email provider handles this automatically once you add the public key to DNS.

DMARC is the policy layer. It tells mail servers what to do if SPF or DKIM fails. Start with p=none, monitor for a week, then move to p=reject for maximum security.

All three are required for deliverability. Major providers like Gmail and Outlook increasingly reject unauthenticated mail. If you’re not set up, your emails disappear.

Setup takes an hour, one time. Once it’s done, it’s done. Monitor your DMARC reports, but you won’t need to touch DNS records again unless you change email providers.

Small teams have an advantage. You’re not managing enterprise email infrastructure. You can set up authentication cleanly, with clear policies, and full control. Use that advantage.

For comprehensive guidance on email authentication configuration, including alignment and troubleshooting, refer to detailed protocol guides. And if you need help generating the email templates and sequences themselves, Mailable is built exactly for this—AI-powered email design that ships production-ready, authenticated, and deliverable.

Getting Started: Your Next Steps

Don’t overthink this. Here’s your action plan:

1. Log into your DNS provider. You have 15 minutes.

2. Add the SPF record. Copy the value from your email provider. Paste it into DNS. Done.

3. Add the DKIM record. Your email provider generates this. Copy it to DNS. Wait for verification.

4. Add the DMARC record. Create the _dmarc TXT record with p=none. Save it.

5. Wait 24 hours. Let DNS propagate and mail servers start checking your records.

6. Check your DMARC reports. You should be getting them daily. Look for alignment issues.

7. Move to p=reject after one week. Once you’re confident, enforce the policy.

That’s it. You’ve authenticated your domain. Your emails are now provably yours. Your deliverability goes up. Your domain reputation is protected.

Now go build something. Mailable is here to help you ship email sequences and sales funnels without the designer overhead. But the authentication? That’s on you. And you’ve got this.