SPF, DKIM, and DMARC explained

Anyone can send an email claiming to be from your domain. Without authentication, there's nothing stopping someone from sending emails as ceo@yourcompany.com to your customers or employees. This is called email spoofing, and it's the foundation of most phishing attacks.

Email authentication solves this with three DNS records that work together:

• SPF - declares which servers are allowed to send email for your domain
• DKIM - adds a cryptographic signature proving the email is genuine and unmodified
• DMARC - defines the policy for what happens when SPF or DKIM checks fail

Beyond security, these records directly affect whether your emails reach the inbox. Gmail, Yahoo, and Outlook all use SPF, DKIM, and DMARC to decide if an email is legitimate. Missing or misconfigured records means your emails land in spam - or get rejected entirely.

Think of SPF as a guest list. You publish a DNS record that says "these servers are allowed to send email on behalf of my domain." When a receiving server gets an email claiming to be from your domain, it checks this list. If the sending server isn't on it, the email fails SPF.

What an SPF record looks like

SPF is a TXT record on your domain's root (@):

Breaking this down:

• v=spf1 - version identifier (always spf1)
• include:_spf.google.com - authorizes Google's mail servers
• include:sendmailas.com - authorizes SendMailAs servers
• ~all - soft fail everything else (mark as suspicious but deliver)

How SPF verification works

1. Someone sends email from you@yourdomain.com
2. The receiving server looks up the SPF record for yourdomain.com
3. It checks if the sending server's IP is authorized by the SPF record
4. Result: PASS (authorized), FAIL (not authorized), or SOFTFAIL (suspicious)

If SPF is the guest list, DKIM is the wax seal on the envelope. It uses public-key cryptography to prove two things: the email really came from your domain, and nobody changed it in transit.

When you send an email, your mail server signs it with a private key. The corresponding public key lives in a DNS record on your domain. The receiving server uses the public key to verify the signature.

What a DKIM record looks like

DKIM records are TXT records with a specific naming pattern:

Breaking this down:

• selector1._domainkey - the selector name followed by ._domainkey. Each email service uses its own selector (e.g. google._domainkey, s1._domainkey)
• v=DKIM1 - version identifier
• k=rsa - the key type (RSA is standard)
• p=... - the public key itself (a long Base64-encoded string)

How DKIM verification works

1. Your mail server signs the email headers and body with your private key
2. The signature is added as a DKIM-Signature header in the email
3. The receiving server extracts the selector from the signature header
4. It looks up the public key at selector._domainkey.yourdomain.com
5. It uses the public key to verify the signature matches the email content
6. Result: PASS (signature valid) or FAIL (signature invalid or missing)

SPF and DKIM are checks. DMARC is the policy that says what to do when those checks fail. Without DMARC, receiving servers make their own decisions - and those decisions vary wildly between providers.

DMARC also introduces the concept of alignment: the domain in the From: header must match the domain checked by SPF or DKIM. This prevents attackers from passing SPF with their own domain while spoofing yours in the From field.

What a DMARC record looks like

Breaking this down:

• v=DMARC1 - version identifier
• p=quarantine - the policy. Three options:
  • none - monitoring only, no action taken (start here)
  • quarantine - send failures to spam folder
  • reject - reject failures outright (most secure)
• rua=mailto:... - where to send aggregate reports (daily summaries of authentication results)
• pct=100 - apply the policy to 100% of emails (you can start lower during rollout)

The right rollout strategy

Never jump straight to p=reject. Follow this progression:

1. Start with p=none - Monitor for 2-4 weeks. Read the DMARC reports to see if any legitimate email services are failing SPF or DKIM.
2. Move to p=quarantine; pct=25 - Quarantine 25% of failing emails. Watch for complaints about missing emails.
3. Increase to p=quarantine; pct=100 - Quarantine all failures. Run for 1-2 weeks.
4. Graduate to p=reject - Full protection. Spoofed emails are now rejected outright.

Here's what happens when someone receives an email claiming to be from your domain:

The key insight is that DMARC requires alignment - at least one of SPF or DKIM must pass and the domain must match the From: header. This is what prevents the "pass SPF with a different domain" attack.

Here's what full authentication looks like in email headers:

Most email authentication problems come from the same few mistakes. Here are the ones I see most often:

1. Multiple SPF records

The most common mistake. You add a new email service, it tells you to add an SPF record, and now you have two. SPF allows exactly one TXT record starting with v=spf1. Two records = PermError = all emails fail.

2. Too many DNS lookups in SPF

SPF has a 10-lookup limit. Each include: counts as a lookup, and nested includes count too. Google's SPF alone uses 4 lookups. Add a few more services and you hit the limit. Emails then fail with permerror.

3. Wrong DKIM selector

DKIM records are published under a selector name (e.g. s1._domainkey.yourdomain.com). If you copy the wrong selector or misspell it, DKIM will always fail. Double-check the selector your email service expects.

4. Jumping to p=reject too quickly

If you have email services that aren't properly authenticated yet, a p=reject DMARC policy will cause those legitimate emails to be rejected. Always start with p=none and monitor.

5. Forgetting about third-party senders

Your newsletter tool, CRM, helpdesk, and invoicing software all send email from your domain. Each needs to be included in your SPF record and have its own DKIM key configured. Audit every service that sends email as your domain.

6. Not monitoring DMARC reports

DMARC sends daily aggregate reports to the rua address. These XML reports show which emails pass and fail. Ignoring them means you won't notice when a legitimate service starts failing, or when someone is actively spoofing your domain.

Setting up SPF, DKIM, and DMARC correctly takes time and attention to detail. Maintaining them across domain and service changes takes even more. This is exactly the problem I built SendMailAs to solve.

When you add a domain to SendMailAs:

The whole process takes about 5 minutes. Point your domain's nameservers to Cloudflare, add the domain in SendMailAs, and authentication is handled. First domain is free forever.