Email Authentication Setup: SPF, DKIM, DMARC Explained

Email arrives in the inbox or the spam folder based on decisions made by Gmail, Outlook, and other receivers before the recipient ever sees it. Those decisions lean heavily on three DNS records that tell receivers whether your mail is genuinely coming from you. Most small businesses set these up once, incorrectly, and never touch them again. Then they wonder why their open rates crater.

Why authentication records matter more than the copy

A message arrives at a receiver's mail server with your domain in the From field and an IP address in the technical headers. The receiver has to decide whether to trust that pairing. Are you actually you? Or is someone else sending from your domain? Authentication records are how you prove it.

Gmail started enforcing these in 2024. Google's bulk sender requirements now require SPF, DKIM, and DMARC to be working for any sender pushing more than 5,000 messages a day. But the real impact is earlier: receivers start applying stricter standards to everyone. A small business sending 200 emails a week without proper records may see the first 30 percent land in spam.

The fix costs nothing and takes 30 minutes. It is not optional.

SPF: declaring which servers can send for your domain

SPF (Sender Policy Framework) is a DNS record that lists the IP addresses and mail servers allowed to send email from your domain. A receiver checks it and asks: is the server that just sent me this message on that list?

The record looks like this: v=spf1 include:sendgrid.net ~all. It says: I am SPF version 1, I allow SendGrid's servers, and for everything else, soft-fail (the tilde means reject the mail but keep it in the inbox, not the spam folder).

• Include statements add other domains or services: Google Workspace adds include:google.com, Mailchimp adds include:mailchimp.com
• The ~all at the end is the default. Change it to -all (hard fail) only if you are certain nothing else is sending from your domain
• SPF does not sign the message. It just says whether the server is authorized

To set your SPF record: go to your DNS provider (GoDaddy, Namecheap, your hosting control panel), add a TXT record for your domain, and paste the value. Do not create an SPF record type — it is deprecated. TXT record only.

DKIM: cryptographic proof the message wasn't tampered with

DKIM (DomainKeys Identified Mail) is different. Instead of proving the server is authorized, DKIM proves the message itself is intact. The sending server signs each message with a private key. The receiver looks up the public key in your DNS and verifies the signature. If the signature checks, the message was not altered in transit.

DKIM is the hardest one to set up because you have to generate a key pair, put the public key in DNS, and configure your mail server to sign with the private key. Google Workspace users can auto-generate DKIM keys in the admin console. If you use Mailchimp, SendGrid, or another ESP (Email Service Provider), they do this for you automatically.

• DKIM records go into DNS as TXT records with a specific format, usually provided by your email service
• You do not need to manage the private key yourself if your ESP does the signing
• Multiple DKIM records are possible — useful when mail comes from different services

If you send from Google Workspace: Admin Console > Security > Authentication > Setup DKIM. If you send from your own server: generate a key pair, publish the public key, and configure your MTA (mail transfer agent) to sign outgoing messages. Postfix, Exim, and other MTAs have plugins for this.

DMARC: telling receivers what to do when things fail

DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM. It does two things: it tells receivers what policy to apply if SPF or DKIM fails, and it sends you daily reports on authentication results.

A DMARC record looks like this: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com. It says: I am DMARC version 1, if authentication fails, quarantine the message (send it to spam), and send reports to dmarc@example.com.

• p=none means monitor only — mail with failed authentication still reaches the inbox, but you get reports
• p=quarantine means failed mail goes to the spam folder
• p=reject means failed mail is rejected outright by the receiver — use this only after you have monitored for 30 days and confirmed everything is working

You should start with p=none and monitor for a week. MXToolbox's DMARC check decodes your DMARC record and shows your policy. Once you see that SPF and DKIM are passing 95+ percent, move to p=quarantine. Move to p=reject only after you have confirmed that all legitimate mail passes.

Setting up the records: step by step

1. Go to your DNS provider or hosting control panel and locate the DNS settings for your domain
2. Add the SPF TXT record provided by your email service or hosting provider
3. Generate or retrieve your DKIM public key from your email service and add it as a TXT record
4. Create a DMARC record. Start with v=DMARC1; p=none; rua=mailto:your-email@your-domain.com
5. Wait 15 minutes for DNS to propagate
6. Test with MXToolbox (free) or Google Admin Console

Troubleshooting when mail still goes to spam

You set up the records and mail is still landing in spam. Check these first:

• SPF failing: Use MXToolbox's SPF check. If it says soft-fail or fail, your server is not in the SPF record. Add it. If you use multiple services, make sure all are included
• DKIM failing: DKIM records can take 48 hours to propagate. Use MXToolbox's DKIM check to verify the public key is in DNS. If it is, ask your email service whether they are actually signing messages with your domain key
• DMARC failing but SPF and DKIM pass: DMARC requires alignment — the domain in the SPF or DKIM record must match the domain in the From field. If you send from alerts@yourco.com but your SPF lists mail.sendgrid.net, Google can pass the SPF check but still fail DMARC alignment
• No reports arriving: Check your rua email address in the DMARC record. Confirm it is correct and that the mailbox is not full or filtered

After fixing, test by sending a message from your domain to a Gmail or Outlook address you control. Open it in Gmail and click the three dots, then View original, then Authentication Results. You should see: spf=pass, dkim=pass, dmarc=pass.

DMARC reports tell you what is actually happening

Once you have DMARC set up with an rua email, you will receive daily aggregate reports showing how many messages passed or failed authentication. These reports are XML files that look dense, but they answer a critical question: is there mail leaving your domain that you do not know about?

A sudden spike in SPF-only passes might indicate someone is sending from your domain without DKIM enabled. A spike in failures might indicate a compromised account or a third-party tool that is not configured to sign messages. The reports are your early warning system.

The part most businesses skip

Setting up SPF, DKIM, and DMARC correctly is a one-time cost of 30 minutes. The ongoing cost is near zero. Yet most businesses never do it, and then they spend months wondering why their marketing emails are not being seen.

If you have ever had a client say they never received an important email, the authentication records are the first place to check. Fix them once and stop losing mail to spam.

Authentication records are not about following a technical checklist. They are about reaching the person you meant to reach.

← Back to all articles