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

If your emails are landing in spam, chances are your domain authentication isn't set up correctly. SPF, DKIM, and DMARC are the three pillars of email authentication, and getting them right is the single most impactful thing you can do for your email deliverability.

Why Email Authentication Matters

Every time you send an email, the receiving server (Gmail, Outlook, Yahoo, etc.) asks three questions:

1. Is this server allowed to send emails for this domain? (SPF)

2. Was this email actually sent by who it claims to be from? (DKIM)

3. What should I do if authentication fails? (DMARC)

If you can't answer these questions convincingly, your emails are treated as suspicious. That means spam folder, or worse, outright rejection.

Think of it like showing up at a building entrance. SPF is the guest list. DKIM is your ID badge. DMARC is the security policy that tells the guard what to do when someone doesn't have proper credentials.

Part 1: SPF (Sender Policy Framework)

What SPF Does

SPF lets you publish a list of servers that are authorized to send emails on behalf of your domain. When a receiving server gets an email claiming to be from yourdomain.com, it checks your SPF record to see if the sending server is on the list.

How to Set Up SPF

SPF is a TXT record added to your domain's DNS. Here's the basic structure:

v=spf1 include:amazonses.com ~all

Breaking this down:

• v=spf1 tells the server this is an SPF record

• include:amazonses.com authorizes Amazon SES servers (which AutoSend uses) to send on your behalf

• ~all tells receiving servers to treat any other sender as suspicious (soft fail)

If you're sending from a subdomain (e.g., mail.yourdomain.com), add the SPF record to that specific subdomain, not the root domain.

If you also use another email provider (like Google Workspace for internal email), your root domain SPF might look like:

v=spf1 include:_spf.google.com include:amazonses.com ~all

SPF Qualifier Reference

The qualifier at the end of your SPF record controls what happens to emails from unauthorized servers:

Start with ~all and move to -all after a few weeks of confirmed clean delivery.

Common SPF Mistakes

Mistake 1: Multiple SPF records on the same domain

This is probably the most common SPF mistake, and it's a silent killer. If your domain has two TXT records that both start with v=spf1, SPF will return a permerror and fail completely. That's worse than having no SPF at all.

Wrong:

v=spf1 include:amazonses.com ~all
v=spf1 include:_spf.google.com ~all

Correct:

v=spf1 include:amazonses.com include:_spf.google.com ~all

Merge all your authorized senders into a single SPF record.

Mistake 2: Exceeding the 10 DNS lookup limit

SPF has a hard limit of 10 DNS lookups. Every include: triggers one or more lookups, and nested includes count too. If you exceed 10, SPF returns permerror and fails.

For example, include:_spf.google.com alone uses up 3-4 lookups because Google's SPF record includes further nested records.

How to check: Use a tool like MXToolbox SPF Lookup to see your total lookup count.

How to fix: If you're close to the limit, consider using ip4: or ip6: mechanisms for services with static IPs, as these don't count toward the lookup limit.

Mistake 3: Using +all

This authorizes every server on the internet to send email from your domain. It's the equivalent of leaving your front door wide open with a sign that says "come on in." Inbox providers like Gmail view +all as a negative reputation signal.

Mistake 4: Including unnecessary domains

Every include: costs you a DNS lookup (and you only have 10). Don't include your root domain's SPF in your subdomain's SPF record unless the subdomain actually needs those same servers authorized.

For example, if you send marketing emails from mail.yourdomain.com through AutoSend, the SPF for that subdomain only needs:

v=spf1 include:amazonses.com ~all

Don't add include:yourdomain.com just because it exists. That pulls in all the root domain's authorized senders, which is unnecessary and wastes lookups.

Mistake 5: Forgetting subdomain SPF

SPF records don't cascade down to subdomains. If you have SPF on yourdomain.com but send emails from mail.yourdomain.com, you need a separate SPF record on the subdomain. The root domain's SPF won't cover it.

Part 2: DKIM (DomainKeys Identified Mail)

What DKIM Does

DKIM adds a cryptographic signature to every outgoing email. The receiving server uses a public key published in your DNS to verify that the email wasn't tampered with in transit and that it genuinely came from your domain.

Think of it as a wax seal on a letter. If the seal is intact, you know the letter hasn't been opened or modified since it was sent.

How to Set Up DKIM

DKIM setup involves two parts:

1. The private key stays on the sending server (AutoSend handles this for you). It's used to sign every outgoing email.

2. The public key gets published in your DNS as a TXT or CNAME record so receiving servers can verify the signature.

Option A: CNAME record (recommended for AutoSend)

Type: CNAME
Name: autosend._domainkey
Content: autosend._domainkey.yourdomain.com.d.autosend.email

The CNAME approach is preferred because if we ever rotate keys, the update happens on our end automatically. You don't have to touch your DNS.

Option B: TXT record (manual key)

Type: TXT
Name: autosend._domainkey
Content: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN...

If you go with a TXT record, make sure you include the full record with v=DKIM1; k=rsa; before the p= value. Just pasting the raw key starting with p= can cause verification failures with some email providers.

Common DKIM Mistakes

Mistake 1: Missing the v=DKIM1 tag

A proper DKIM TXT record should start with v=DKIM1; k=rsa; before the public key. While technically optional per the spec, some receiving servers are strict about this. Missing it can cause intermittent DKIM failures that are hard to debug.

Wrong:

p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN...

Correct:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN...

Mistake 2: Using a TXT record when you should use CNAME

If your email provider (like AutoSend) gives you a CNAME to add, use the CNAME. Don't copy the public key and paste it as a TXT record. The CNAME approach means key rotations are handled automatically. With a TXT record, if the signing key changes on the provider's end, your DNS still has the old key, and every email will fail DKIM silently.

Mistake 3: Truncated key in DNS

Some DNS providers have character limits on TXT records. If your DKIM public key gets cut off, DKIM verification will fail every time. After adding the record, always verify it using a tool like MXToolbox DKIM Lookup to make sure the full key is present.

Mistake 4: DKIM alignment failure

DKIM can pass verification but still fail DMARC alignment. This happens when the d= domain in the DKIM signature doesn't match (or isn't a subdomain of) the From address domain. For example, if your From address is [email protected] but DKIM signs with d=yourdomain.com, that's fine in relaxed alignment mode. But if DKIM signs with d=senderprovider.com, alignment fails even though the signature itself is valid.

Part 3: DMARC (Domain-based Message Authentication, Reporting & Conformance)

What DMARC Does

DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication fails. It also gives you reporting so you can see who's sending email from your domain and whether authentication is passing or failing.

Without DMARC, even if SPF and DKIM fail, the receiving server has no guidance on what to do. DMARC is the policy layer that makes everything actionable.

How DMARC Lookup Works

This is important to understand. When a receiving server gets an email from [email protected], it checks for DMARC in this order:

1. _dmarc.mail.yourdomain.com (exact match on the sending subdomain)

2. _dmarc.yourdomain.com (fallback to the organizational/root domain)

If it finds a record at step 1, it uses that. If not, it falls back to step 2. This means a single DMARC record at the root domain covers all subdomains automatically. You don't need to add DMARC to every subdomain unless you want different policies for different subdomains.

How to Set Up DMARC

Add a TXT record to your root domain:

Type: TXT
Name: _dmarc
Content: v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:[email protected]; pct=100; adkim=r; aspf=r;

Breaking this down:

The DMARC Policy Progression

Don't jump straight to p=reject. Follow this progression:

Week 1-2: Monitor mode

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

This doesn't affect delivery but starts sending you reports. Use this time to identify all legitimate email sources and make sure SPF/DKIM are passing.

Week 3-4: Quarantine mode

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

Failed emails go to spam. Monitor reports to make sure nothing legitimate is getting caught.

Week 5+: Reject mode

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

Failed emails are outright rejected. This is the strongest protection and gives the best deliverability signal to inbox providers.

The sp= Tag for Subdomain Control

The sp= tag lets you set a different policy for subdomains than the root domain. This is useful during transition:

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

This rejects failures from the root domain but only quarantines failures from subdomains, giving you a safety net while you're still setting up authentication on newer subdomains.

Common DMARC Mistakes

Mistake 1: Staying on p=none forever

This is the most common mistake we see. p=none is monitoring mode only. It tells receiving servers "don't do anything about authentication failures." It provides zero deliverability benefit. It's meant to be temporary while you get SPF and DKIM sorted out. Staying on p=none is like installing a security camera but telling the guards to never actually stop anyone.

Gmail, Yahoo, and other major providers have explicitly stated that a p=none DMARC policy is not sufficient for good deliverability. Move to p=quarantine as soon as your reports show clean results.

Mistake 2: No rua= tag (no reporting)

Without the rua= tag, you get no DMARC reports. That means you have no visibility into whether authentication is passing or failing, who's sending email from your domain, or whether someone is spoofing you. Always include a rua= tag and actually monitor the reports.

Make sure the email address in rua= actually exists and can receive mail. Setting up [email protected] and never creating the mailbox is a common oversight.

Mistake 3: Misunderstanding alignment

DMARC doesn't just check if SPF and DKIM pass. It checks if they pass and align with the From domain. This is a critical distinction.

For example:

• SPF passes for the envelope sender [email protected]

• DKIM passes with d=esp.com

• But the From header says [email protected]

Both SPF and DKIM passed, but neither aligns with the From domain. DMARC fails.

For DMARC to pass, you need at least one of:

• SPF to pass AND the envelope sender domain to match the From domain

• DKIM to pass AND the DKIM d= domain to match the From domain

With relaxed alignment (adkim=r; aspf=r;), subdomain matching counts. So DKIM signing with d=mail.yourdomain.com aligns with a From address of [email protected].

Mistake 4: Adding DMARC to every subdomain

You don't need a separate DMARC record for every subdomain. A single record at _dmarc.yourdomain.com covers all subdomains automatically via the fallback mechanism. Only add subdomain-level DMARC if you need a different policy for a specific subdomain.

Putting It All Together: A Complete Setup Checklist

Here's the step-by-step process for a clean email authentication setup:

Step 1: Set up SPF on your sending domain

If you're sending through AutoSend from a subdomain:

Type: TXT
Name: mail (or whatever your sending subdomain is)
Content: v=spf1 include:amazonses.com ~all

If your root domain also sends email (e.g., through Google Workspace):

Type: TXT
Name: @ (root domain)
Content: v=spf1 include:_spf.google.com ~all

Remember: one SPF record per domain/subdomain. Never two.

Step 2: Set up DKIM

Add the CNAME or TXT record provided by AutoSend:

Type: CNAME
Name: autosend._domainkey
Content: (value provided by AutoSend)

Step 3: Set up DMARC on the root domain

Type: TXT
Name: _dmarc
Content: v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r;

Step 4: Send a test email

Use Mail Tester or check the raw headers in Gmail. Look for:

• spf=pass

• dkim=pass

• dmarc=pass

If all three show "pass," you're in good shape.

Step 5: Monitor DMARC reports for 1-2 weeks

Check your DMARC reports to make sure there are no legitimate emails failing authentication. You can use free tools like DMARC Analyzer to parse the XML reports into something readable.

Step 6: Tighten your policies

Once reports are clean:

1. Upgrade DMARC from p=none to p=quarantine

2. After another 2 weeks, upgrade to p=reject

3. Upgrade SPF from ~all to -all

Quick Reference: DNS Records at a Glance

Here's what a properly configured domain looks like in DNS:

Root domain (yourdomain.com):

Sending subdomain (mail.yourdomain.com):

Clean, minimal, and effective.

Need Help?

If you're an AutoSend customer and your emails are still landing in spam after following this guide, reach out to us. We'll check your DNS records, review your sending patterns, and help you get to the inbox.