If your emails are landing in spam folders, there's a good chance your domain authentication is broken or missing. Email authentication is the set of DNS records that tell inbox providers you're a legitimate sender. Without it, Gmail, Outlook, and other providers have no way to verify that emails claiming to be from your domain actually came from you. They'll either block your messages outright or quietly shuffle them into spam where nobody sees them.

The good news is that setting up email authentication isn't particularly difficult. It's mostly a matter of adding the right DNS records and understanding what each one does. The bad news is that there are three separate protocols you need to configure, and each one serves a different purpose. This guide walks through all three: SPF, DKIM, and DMARC. By the end, you'll have all the records you need for proper email authentication.

Why Email Authentication Actually Matters

Before diving into the technical setup, it's worth understanding why inbox providers care so much about authentication. The short answer is spam and phishing. Every day, billions of emails are sent pretending to be from domains they have no connection to. Without authentication, there's no way to distinguish between a legitimate email from your company and a phishing attempt that spoofs your domain.

When you set up proper authentication, you're essentially proving that your emails are legitimate. SPF tells providers which servers are authorized to send email on your behalf. DKIM adds a cryptographic signature that proves the email hasn't been tampered with. DMARC ties everything together and tells providers what to do when emails fail authentication checks.

For SaaS companies, authentication affects more than just deliverability. Your transactional emails need to reach users reliably for password resets, account notifications, and purchase confirmations. Your marketing campaigns need to land in inboxes to drive engagement and revenue. Poor authentication undermines all of it. According to our SaaS email benchmarks, companies with proper authentication consistently see 10-20% better inbox placement compared to those without it.

Understanding SPF: Who Can Send on Your Behalf

SPF stands for Sender Policy Framework, and it answers a simple question: which mail servers are allowed to send email using your domain? When you send an email from your.company.com, the receiving server looks up your SPF record to see if the sending server was authorized. If the server isn't on the list, the email is treated with suspicion.

Think of SPF like a guest list for a party. You publish a list of who's allowed in, and the bouncer (the receiving mail server) checks each guest against that list. Anyone not on the list gets turned away or at least scrutinized more carefully.

Your SPF record is a TXT record in your domain's DNS that lists all the services and servers permitted to send email for your domain. A typical SPF record might include your email hosting provider (Google Workspace, Microsoft 365), your email marketing platform (Mailchimp, SendGrid), your SaaS application's sending service, and any other tools that send email on your behalf.

The tricky part is that you can only have one SPF record per domain. If you need to authorize multiple services, you combine them all into a single record using include statements.

Setting Up Your SPF Record

To create or update your SPF record, log into your DNS provider (Cloudflare, Route53, Namecheap, or wherever you manage your domain). You'll add or modify a TXT record for your root domain.

Here's what a typical SPF record looks like:

v=spf1 include:_spf.google.com include:sendgrid.net include:mail.yourapp.com -all

Let's break down each part. The v=spf1 declaration identifies this as an SPF record. Each include: statement adds a service that's allowed to send email for your domain. The -all at the end is important because it tells receiving servers to reject emails from any server not explicitly listed. You might also see ~all (softfail) which treats unauthorized emails with suspicion but doesn't reject them outright. For maximum protection, -all is preferable once you've verified all your legitimate sending sources are included.

To find the correct include statement for any service, check their documentation. Every email service provider publishes what you need to add to your SPF record. Google Workspace uses include:_spf.google.com. SendGrid uses include:sendgrid.net. Postmark uses include:spf.mtasv.net. If you're not sure what to include, search for "[service name] SPF record" and you'll find it.

After adding your SPF record, wait for DNS propagation (usually a few minutes to a few hours) and then test it. You can use our SPF checker tool or sites like MXToolbox to verify your record is configured correctly.

Understanding DKIM: Proving Email Authenticity

DKIM stands for DomainKeys Identified Mail, and it works differently than SPF. While SPF checks if the sending server is authorized, DKIM verifies that the email content hasn't been modified in transit and that it genuinely originated from your domain.

DKIM uses public-key cryptography. Your email sending service has a private key that it uses to sign every outgoing email. The corresponding public key is published in your DNS. When a receiving server gets an email claiming to be from your domain, it retrieves your public key from DNS and uses it to verify the signature. If the signature matches, the server knows the email is authentic and unmodified.

This matters because email travels through multiple servers before reaching its destination. Without DKIM, any of those intermediate servers could theoretically modify the content. With DKIM, any tampering would invalidate the signature and alert the receiving server that something is wrong.

Setting Up DKIM Records

Setting up DKIM is slightly more involved than SPF because you need to generate a key pair for each service that sends email on your behalf. The good news is that most email providers handle the key generation for you.

Here's the general process. First, go to your email service provider's settings and find the DKIM or domain authentication section. Generate a DKIM key pair through their interface. They'll provide you with a DNS record to add (usually a TXT or CNAME record). The record typically looks something like this:

selector._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqG..."

The "selector" is a name that identifies which key to use (since you can have multiple DKIM keys). Different services use different selectors. Google might use something like google, while SendGrid might use s1 or s2. The long string of characters after p= is your public key.

Copy the record exactly as provided by your email service. Add it to your DNS as a TXT record (or CNAME if they specify). Wait for DNS propagation, then use your provider's verification tool to confirm it's working. Repeat this process for each service that sends email on your behalf.

Unlike SPF where everything goes in one record, DKIM uses separate records for each service. This means you can have multiple DKIM records for the same domain without conflict.

Understanding DMARC: The Policy Layer

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It builds on top of SPF and DKIM by adding two things: a policy that tells receiving servers what to do with emails that fail authentication, and a reporting mechanism that sends you data about authentication failures.

Think of DMARC as the decision-maker. SPF and DKIM provide the evidence about whether an email is legitimate. DMARC tells the receiving server what verdict to render. Should it deliver the email to inbox? Send it to spam? Reject it outright? DMARC also requires alignment, meaning the domain in the visible "From" address must match the domain verified by SPF or DKIM.

Without DMARC, each receiving server makes its own decision about what to do with SPF or DKIM failures. With DMARC, you specify exactly how you want failures handled. This gives you control over how aggressively to protect your domain from spoofing.

Setting Up DMARC: Start with Monitoring

The key to DMARC is starting gradually. You don't want to immediately reject all emails that fail authentication because you might accidentally block legitimate emails from services you forgot to configure. Instead, you start with a monitoring policy, review the reports, fix any issues, and then move to a stricter policy.

Your DMARC record is a TXT record at _dmarc.yourdomain.com. Here's a monitoring-only policy to start with:

v=DMARC1; p=none; rua=mailto:[email protected]

This tells receiving servers to send authentication reports to your email address without taking any action on failing emails. The p=none means "don't do anything special, just report what you find." The rua specifies where to send aggregate reports (daily summaries of authentication results).

After adding this record, you'll start receiving DMARC reports within a day or two. These reports are XML files that can be difficult to read directly, so you might want to use a DMARC report analyzer service. The reports will show you which servers are sending email using your domain and whether they're passing SPF and DKIM checks. If you see legitimate services failing, go back and fix their authentication before tightening your policy.

Moving to DMARC Enforcement

Once you've monitored your DMARC reports for a few weeks and confirmed that all legitimate email sources are passing authentication, it's time to move to a stricter policy. The progression typically goes like this.

First, try a quarantine policy with a small percentage:

v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]

This sends 10% of failing emails to spam while the rest still get delivered normally. Monitor for problems. If everything looks good after a week, increase to 50%, then 100%.

Eventually, you want to reach a reject policy:

v=DMARC1; p=reject; rua=mailto:[email protected]

With p=reject, emails that fail authentication are blocked entirely. This provides the strongest protection against spoofing but requires confidence that you've configured all legitimate sending sources correctly.

Some additional DMARC options worth knowing about include ruf which specifies an address for forensic reports (detailed information about individual failing emails, though not all providers send these), adkim and aspf which control how strictly the domains must match (strict or relaxed), and sp which sets a separate policy for subdomains.

Testing Your Complete Configuration

After setting up all three records, you need to verify everything works together. Send test emails from each service that uses your domain and check the authentication results. Most email clients let you view the raw email headers, where you'll find lines like:

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

You want to see "pass" for all three. If you see "fail" or "none" for any of them, there's still configuration work to do.

For more comprehensive deliverability testing, see our complete email deliverability guide. Beyond authentication, it covers sender reputation, content optimization, and other factors that affect inbox placement.

Common Mistakes and How to Fix Them

The most common SPF mistake is having multiple SPF records. You can only have one, so if you've added separate records for different services, you need to combine them. Look for multiple TXT records starting with v=spf1 and merge all the includes into a single record.

Another SPF issue is exceeding the DNS lookup limit. SPF allows a maximum of 10 DNS lookups, and each include: statement can trigger multiple lookups. If you're using many services, you might hit this limit. The solution is to use an SPF flattening service that converts includes into direct IP addresses, or consolidate your sending through fewer services.

For DKIM, the most common mistake is using the wrong selector or making typos in the DNS record. DKIM records contain long strings of characters, and a single wrong character breaks the whole thing. Always copy and paste rather than typing manually, and use your provider's verification tool to confirm the record is correct.

DMARC mistakes usually involve jumping to enforcement too quickly. If you set p=reject before confirming all legitimate sources pass authentication, you'll block your own emails. Always start with p=none and monitor the reports before tightening the policy.

Another issue is forgetting about subdomains. By default, DMARC applies only to the exact domain in the record. If you send email from subdomains, you need to either add separate DMARC records for each subdomain or use the sp= option to set a subdomain policy.

Ongoing Maintenance

Email authentication isn't a set-it-and-forget-it task. Your configuration needs maintenance as your email infrastructure evolves.

When you add a new service that sends email on your behalf, update your SPF record to include it and add the appropriate DKIM records. When you stop using a service, remove it from your SPF record and consider removing its DKIM records (though leaving them doesn't cause problems).

Continue monitoring your DMARC reports, especially after making changes. Sudden increases in authentication failures might indicate a new service you forgot to configure or a spoofing attack against your domain.

Periodically audit your SPF record to make sure every include statement is still needed. Over time, companies accumulate references to services they no longer use, which wastes DNS lookups and adds unnecessary complexity.

If you're rotating DKIM keys (which some security teams recommend doing annually), coordinate the timing carefully. Add the new key to DNS before starting to sign with it, and keep the old key in DNS for a while after switching to ensure emails in transit can still be verified.

The Authentication Checklist

To summarize everything, here's what you need for complete email authentication.

For SPF, you need one TXT record at your root domain containing v=spf1, include statements for every service that sends email on your behalf, and ending with -all or ~all. Verify it with an SPF checker tool.

For DKIM, you need one TXT or CNAME record per sending service, each at selector._domainkey.yourdomain.com. The records contain your public keys. Verify each one through your email provider's dashboard.

For DMARC, you need one TXT record at _dmarc.yourdomain.com. Start with p=none for monitoring, then progress to p=quarantine and eventually p=reject. Include a rua= address to receive reports.

With all three configured correctly, you've done what you can on the authentication side. Your emails will be cryptographically signed, your authorized senders will be explicitly listed, and you'll have policies in place for handling unauthorized emails. This won't guarantee inbox placement (that also depends on content, engagement, and sender reputation), but it removes one of the biggest obstacles to deliverability and protects your domain from spoofing.