DEV Community

GlitchGuard profile image GlitchGuard
GlitchGuard for GlitchGuard

Posted on • Originally published at getglitchguard.com

SPF, DKIM and DMARC: A Practical Email Authentication Guide

#email #security #dns #webdev

SPF, DKIM and DMARC: A Practical Email Authentication Guide

Modern businesses rarely send email from only one system.

A typical domain may send mail through:

  • Google Workspace or Microsoft 365
  • a CRM
  • an ecommerce platform
  • a marketing automation tool
  • a support desk
  • a booking system
  • a transactional email provider
  • password reset infrastructure
  • billing software
  • website contact forms

All of those systems may send messages that appear to come from the same business domain.

So how does a receiving mail server determine whether those messages are legitimate?

That is where SPF, DKIM, and DMARC come in.

They are related technologies, but they solve different problems.

A useful mental model is:

SPF   = Is this sending infrastructure authorized?

DKIM  = Does this message contain a valid cryptographic signature?

DMARC = Does successful authentication align with the domain
        visible to the recipient?
Enter fullscreen mode Exit fullscreen mode

DMARC then adds policy and reporting on top of those authentication results.

Let's break down how the three systems work.

1. SPF: Sender Authorization

SPF stands for Sender Policy Framework.

It is published as a DNS TXT record and describes which mail infrastructure is authorized to send on behalf of a domain.

A simplified SPF record might look like this:

v=spf1 include:_spf.examplemail.com -all
Enter fullscreen mode Exit fullscreen mode

A receiving mail server can evaluate the SPF policy when it receives a message.

At a high level, it asks:

Is the system delivering this message included in the sending policy for the relevant domain?

If yes, SPF can pass.

If not, SPF may fail.

Common SPF mechanisms

An SPF record may contain mechanisms such as:

ip4:
ip6:
a
mx
include:
exists:
Enter fullscreen mode Exit fullscreen mode

It also ends with a qualifier such as:

-all
~all
?all
Enter fullscreen mode Exit fullscreen mode

The correct policy depends on the organization's mail architecture.

Do not copy an SPF record from another domain without understanding what it authorizes.

2. Common SPF Problems

SPF configurations often become messy as businesses add more email providers.

Common problems include:

  • no SPF record at all
  • multiple SPF records
  • old providers that were never removed
  • missing current sending services
  • malformed syntax
  • excessive DNS lookups
  • unnecessary nested include mechanisms
  • misunderstanding what SPF actually authenticates

Multiple SPF records

One common mistake is creating a second SPF record whenever a new provider is added.

For example:

v=spf1 include:_spf.google.com -all
Enter fullscreen mode Exit fullscreen mode

and separately:

v=spf1 include:mail.exampleprovider.com -all
Enter fullscreen mode Exit fullscreen mode

Publishing multiple independent SPF policies for the same hostname can cause SPF evaluation problems.

The legitimate services should normally be represented within one valid policy.

3. SPF Does Not Authenticate the Visible From Address by Itself

This is an important distinction.

Consider an email displaying:

Enter fullscreen mode Exit fullscreen mode

The recipient sees:

example.com
Enter fullscreen mode Exit fullscreen mode

But SPF does not simply inspect that visible From header.

SPF evaluates the domain associated with the SMTP envelope.

That means SPF can technically pass while the domain authenticated through SPF differs from the domain visible to the recipient.

This is one reason DMARC exists.

4. SPF and Forwarding

SPF can also be affected by forwarding.

Imagine:

Sender
  ↓
Original Mail Server
  ↓
Forwarding Server
  ↓
Recipient
Enter fullscreen mode Exit fullscreen mode

The recipient may see the forwarding server as the infrastructure delivering the message.

That server may not be authorized by the original sender's SPF record.

The result can be an SPF failure even though the original sender was legitimate.

DKIM often survives forwarding more effectively when the message is not modified in a way that breaks its signature.

5. DKIM: Cryptographic Message Authentication

DKIM stands for DomainKeys Identified Mail.

Instead of primarily checking the sending infrastructure, DKIM adds a cryptographic signature to the email.

The sending system has a private key.

The corresponding public key is published in DNS.

A receiving server can use the public key to verify the message signature.

The architecture looks roughly like this:

Sending System
     |
     | Private Key
     v
Create DKIM Signature
     |
     v
Email Message
     |
     v
Receiving Server
     |
     | DNS lookup
     v
Public DKIM Key
     |
     v
Verify Signature
Enter fullscreen mode Exit fullscreen mode

If the verification succeeds, DKIM passes.

6. DKIM Selectors

DKIM uses something called a selector.

A DNS lookup may look like:

selector1._domainkey.example.com
Enter fullscreen mode Exit fullscreen mode

The selector allows a domain to maintain multiple DKIM keys.

This is useful for:

  • key rotation
  • multiple sending providers
  • different applications
  • migration between email systems

An email's DKIM-Signature header tells the receiving server which signing domain and selector to query.

A simplified header may contain fields such as:

d=example.com;
s=selector1;
Enter fullscreen mode Exit fullscreen mode

Where:

d = signing domain
s = selector
Enter fullscreen mode Exit fullscreen mode

7. Common DKIM Problems

Typical DKIM failures include:

  • DKIM was never enabled
  • the public key is missing from DNS
  • the selector is incorrect
  • the public/private keys no longer match
  • a provider rotated its key but DNS was not updated
  • the message was modified after signing
  • the DKIM signature is malformed
  • the signing domain does not align for DMARC

DKIM configuration should therefore be verified publicly rather than assuming that clicking "Enable DKIM" inside an email provider completed the DNS configuration correctly.

8. DKIM Can Pass While DMARC Still Fails

This surprises many people.

Suppose the recipient sees:

Enter fullscreen mode Exit fullscreen mode

But the message carries a valid DKIM signature from:

d=emailprovider.net
Enter fullscreen mode Exit fullscreen mode

The DKIM signature itself may be completely valid.

DKIM therefore passes.

But the signing domain:

emailprovider.net
Enter fullscreen mode Exit fullscreen mode

does not necessarily align with:

example.com
Enter fullscreen mode Exit fullscreen mode

That particular DKIM authentication result may therefore fail to satisfy DMARC.

Again, this is where domain alignment becomes important.

9. DMARC: Alignment, Policy and Reporting

DMARC stands for:

Domain-based Message Authentication, Reporting and Conformance

DMARC builds on SPF and DKIM.

Its major contribution is connecting technical authentication with the domain that the recipient actually sees.

Suppose a message displays:

Enter fullscreen mode Exit fullscreen mode

The visible From domain is:

example.com
Enter fullscreen mode Exit fullscreen mode

DMARC asks whether successful SPF or DKIM authentication aligns with that domain.

The simplified logic is:

                 Email arrives
                       |
                       v
              Check SPF authentication
                       |
                       v
              Does SPF domain align?
                    /      \
                  Yes       No
                   |         |
                   |         v
                   |    Check DKIM
                   |         |
                   |         v
                   |   Does DKIM align?
                   |       /     \
                   |     Yes      No
                   |      |        |
                   v      v        v
                 DMARC PASS      DMARC FAIL
Enter fullscreen mode Exit fullscreen mode

A message does not necessarily require both SPF and DKIM alignment.

One valid aligned authentication path can be enough for DMARC to pass.

10. SPF Alignment

For SPF to satisfy DMARC:

  1. SPF must pass.
  2. The SPF-authenticated domain must align with the visible From domain.

Example:

Visible From:
example.com

SPF-authenticated domain:
example.com
Enter fullscreen mode Exit fullscreen mode

That is aligned.

A subdomain relationship may also align depending on the DMARC alignment mode.

11. DKIM Alignment

For DKIM to satisfy DMARC:

  1. The DKIM signature must pass.
  2. The DKIM signing domain must align with the visible From domain.

Example:

Visible From:
example.com

DKIM d=:
example.com
Enter fullscreen mode Exit fullscreen mode

Aligned.

Another example:

Visible From:
example.com

DKIM d=:
emailvendor.net
Enter fullscreen mode Exit fullscreen mode

DKIM may still pass technically.

But that signature may not satisfy DMARC alignment.

12. DMARC Alignment Modes

DMARC supports relaxed and strict alignment.

Relaxed alignment

A subdomain can align with the organizational domain.

For example:

mail.example.com
Enter fullscreen mode Exit fullscreen mode

may align with:

example.com
Enter fullscreen mode Exit fullscreen mode

Strict alignment

The domains must match exactly.

DMARC records can control this with settings such as:

aspf=s
adkim=s
Enter fullscreen mode Exit fullscreen mode

Where:

aspf = SPF alignment mode
adkim = DKIM alignment mode
Enter fullscreen mode Exit fullscreen mode

Most organizations should understand the consequences before changing alignment modes.

13. A Basic DMARC Record

A simple DMARC record could look like:

v=DMARC1; p=none; rua=mailto:dmarc@example.com
Enter fullscreen mode Exit fullscreen mode

The record is normally published at:

_dmarc.example.com
Enter fullscreen mode Exit fullscreen mode

Important fields include:

v=
Enter fullscreen mode Exit fullscreen mode

Protocol version.

p=
Enter fullscreen mode Exit fullscreen mode

Policy.

rua=
Enter fullscreen mode Exit fullscreen mode

Aggregate report destination.

Other options may control subdomain policy, alignment behavior, percentages, and additional reporting behavior.

14. DMARC Policies

There are three main policy levels.

p=none

Example:

v=DMARC1; p=none; rua=mailto:dmarc@example.com
Enter fullscreen mode Exit fullscreen mode

This is primarily a monitoring policy.

DMARC authentication is evaluated, but the domain is not requesting quarantine or rejection of failing messages.

This is often useful when deploying DMARC initially.

p=quarantine

Example:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
Enter fullscreen mode Exit fullscreen mode

The domain asks receiving systems to treat DMARC-failing mail with greater suspicion.

Depending on the receiver, that may mean spam-folder placement or other restricted handling.

p=reject

Example:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Enter fullscreen mode Exit fullscreen mode

The domain requests rejection of messages that fail DMARC.

This provides stronger protection against certain forms of domain spoofing.

However, moving immediately to p=reject without understanding every legitimate sender can disrupt real email.

15. Why DMARC Reporting Matters

DMARC reporting can help reveal who is sending mail associated with your domain.

Reports may show infrastructure belonging to:

  • Google Workspace
  • Microsoft 365
  • CRM systems
  • ecommerce platforms
  • marketing tools
  • support platforms
  • transactional providers
  • old forgotten vendors
  • unauthorized senders

That visibility is extremely useful.

A business may discover that an application installed three years ago is still sending mail.

Or that a legitimate provider was never configured correctly.

Or that unknown infrastructure is attempting to use the domain.

16. Inventory Every Email Sender

Before making major authentication changes, build an inventory.

For example:

Corporate email
Google Workspace

Marketing
Klaviyo

CRM
HubSpot

Transactional email
Amazon SES

Support
Zendesk

Website forms
Application backend

Billing
Stripe-related notifications

Ecommerce
Shopify
Enter fullscreen mode Exit fullscreen mode

Then determine how each service uses:

  • SPF
  • DKIM
  • custom return paths
  • custom DKIM domains
  • DMARC alignment

This is much safer than editing DNS reactively.

17. Authentication Flow Example

Consider this message:

From: orders@example.com
Enter fullscreen mode Exit fullscreen mode

The business sends through an ecommerce email provider.

SPF

The provider's infrastructure is authorized.

Result:

SPF: PASS
Enter fullscreen mode Exit fullscreen mode

DKIM

The provider signs with:

d=example.com
Enter fullscreen mode Exit fullscreen mode

Result:

DKIM: PASS
Enter fullscreen mode Exit fullscreen mode

DMARC

Visible From:

example.com
Enter fullscreen mode Exit fullscreen mode

DKIM signing domain:

example.com
Enter fullscreen mode Exit fullscreen mode

Aligned.

Result:

DMARC: PASS
Enter fullscreen mode Exit fullscreen mode

Now consider another message:

From: orders@example.com
Enter fullscreen mode Exit fullscreen mode

DKIM signs using:

d=vendor-mail.net
Enter fullscreen mode Exit fullscreen mode

Result:

DKIM: PASS
Enter fullscreen mode Exit fullscreen mode

But that domain may not align with:

example.com
Enter fullscreen mode Exit fullscreen mode

If SPF also fails alignment:

DMARC: FAIL
Enter fullscreen mode Exit fullscreen mode

This illustrates why checking only "DKIM passed" is not enough.

18. Common Authentication Mistakes

Multiple SPF records

Combine legitimate sending sources into one valid SPF policy instead of publishing multiple independent SPF records.

Missing DKIM selectors

Verify that every configured selector actually resolves in public DNS.

Passing SPF but failing DMARC

Inspect the SPF-authenticated domain and compare it with the visible From domain.

Passing DKIM but failing DMARC

Inspect the DKIM d= domain and check alignment.

Publishing DMARC and ignoring reports

DMARC provides visibility only when the organization actually monitors its sending environment.

Enforcing too early

Do not jump directly from no DMARC to aggressive rejection without identifying legitimate senders.

Forgetting application email

Authentication audits often focus only on employee mailboxes.

Do not forget:

  • password resets
  • invoices
  • order receipts
  • shipping notifications
  • support replies
  • booking confirmations
  • website forms
  • CRM automation

19. SPF, DKIM and DMARC Do Not Guarantee Inbox Placement

Passing all three is important.

But email authentication is not equivalent to deliverability.

Mailbox providers may also consider:

  • sender reputation
  • IP reputation
  • domain reputation
  • complaint rates
  • spam reports
  • recipient engagement
  • list quality
  • bounce rates
  • sending volume
  • sending consistency
  • message content
  • unsubscribe behavior

Think of authentication as identity verification.

It gives receiving systems stronger evidence that the message legitimately relates to the claimed domain.

It does not force the receiving system to place the message in the inbox.

20. Practical Email Authentication Checklist

Use this when reviewing a business domain:

  • [ ] Inventory every email sending service
  • [ ] Confirm an SPF record exists
  • [ ] Confirm only one valid SPF policy exists
  • [ ] Remove obsolete SPF senders
  • [ ] Check SPF DNS lookup complexity
  • [ ] Enable DKIM for each supported provider
  • [ ] Verify DKIM selectors publicly
  • [ ] Check DKIM signing domains
  • [ ] Publish a valid DMARC record
  • [ ] Configure aggregate reporting
  • [ ] Verify SPF alignment
  • [ ] Verify DKIM alignment
  • [ ] Monitor before increasing enforcement
  • [ ] Review transactional email systems
  • [ ] Review marketing platforms
  • [ ] Review support systems
  • [ ] Remove providers that are no longer used
  • [ ] Retest after DNS or provider changes

21. Useful GlitchGuard Checks

You can inspect individual authentication components using:

SPF Checker:

https://getglitchguard.com/tools/spf-checker

DKIM Checker:

https://getglitchguard.com/tools/dkim-checker

DMARC Checker:

https://getglitchguard.com/tools/dmarc-checker

MX Lookup:

https://getglitchguard.com/tools/mx-lookup

The tools are useful for inspecting what DNS currently publishes before changing records.

Final Takeaway

SPF, DKIM, and DMARC become much easier to understand when each technology has a separate job.

SPF
→ Which infrastructure is authorized?

DKIM
→ Is there a valid cryptographic signature?

DMARC
→ Does valid authentication align with the visible From domain?

DMARC Policy
→ What should receivers do when authentication fails?

DMARC Reporting
→ What sending activity should the domain owner know about?
Enter fullscreen mode Exit fullscreen mode

The biggest mistake is treating email authentication as a checkbox.

A modern business may have many legitimate sending systems.

You need to understand the entire sending environment.

Then authenticate it deliberately.

Original GlitchGuard guide:

https://getglitchguard.com/blog/spf-dkim-dmarc-explained?utm_source=devto&utm_medium=syndication&utm_campaign=email_authentication

Check your SPF record:

https://getglitchguard.com/tools/spf-checker

Check your DKIM record:

https://getglitchguard.com/tools/dkim-checker

Check your DMARC policy:

https://getglitchguard.com/tools/dmarc-checker

Top comments (0)