SPF, DKIM and DMARC: A Practical Email Authentication Guide

GlitchGuard — Sun, 09 Aug 2026 16:48:19 +0000

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?

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

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:

It also ends with a qualifier such as:

-all
~all
?all

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

and separately:

v=spf1 include:mail.exampleprovider.com -all

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:

From: sales@example.com

The recipient sees:

example.com

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

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

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

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;

Where:

d = signing domain
s = selector

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:

From: support@example.com

But the message carries a valid DKIM signature from:

d=emailprovider.net

The DKIM signature itself may be completely valid.

DKIM therefore passes.

But the signing domain:

emailprovider.net

does not necessarily align with:

example.com

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:

From: billing@example.com

The visible From domain is:

example.com

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

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:

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

Example:

Visible From:
example.com

SPF-authenticated domain:
example.com

That is aligned.

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

11. DKIM Alignment

For DKIM to satisfy DMARC:

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

Example:

Visible From:
example.com

DKIM d=:
example.com

Aligned.

Another example:

Visible From:
example.com

DKIM d=:
emailvendor.net

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

may align with:

example.com

Strict alignment

The domains must match exactly.

DMARC records can control this with settings such as:

aspf=s
adkim=s

Where:

aspf = SPF alignment mode
adkim = DKIM alignment 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

The record is normally published at:

_dmarc.example.com

Important fields include:

v=

Protocol version.

p=

Policy.

rua=

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

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

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

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

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

The business sends through an ecommerce email provider.

SPF

The provider's infrastructure is authorized.

Result:

SPF: PASS

DKIM

The provider signs with:

d=example.com

Result:

DKIM: PASS

DMARC

Visible From:

example.com

DKIM signing domain:

example.com

Aligned.

Result:

DMARC: PASS

Now consider another message:

From: orders@example.com

DKIM signs using:

d=vendor-mail.net

Result:

DKIM: PASS

But that domain may not align with:

example.com

If SPF also fails alignment:

DMARC: FAIL

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?

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

DEV Community: GlitchGuard

SPF, DKIM and DMARC: A Practical Email Authentication Guide

SPF, DKIM and DMARC: A Practical Email Authentication Guide

1. SPF: Sender Authorization

Common SPF mechanisms

2. Common SPF Problems

Multiple SPF records

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

4. SPF and Forwarding

5. DKIM: Cryptographic Message Authentication

6. DKIM Selectors

7. Common DKIM Problems

8. DKIM Can Pass While DMARC Still Fails

9. DMARC: Alignment, Policy and Reporting

10. SPF Alignment

11. DKIM Alignment

12. DMARC Alignment Modes

Relaxed alignment

Strict alignment

13. A Basic DMARC Record

14. DMARC Policies

p=none

p=quarantine

p=reject

15. Why DMARC Reporting Matters

16. Inventory Every Email Sender

17. Authentication Flow Example

SPF

DKIM

DMARC

18. Common Authentication Mistakes

Multiple SPF records

Missing DKIM selectors

Passing SPF but failing DMARC

Passing DKIM but failing DMARC

Publishing DMARC and ignoring reports

Enforcing too early

Forgetting application email

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

20. Practical Email Authentication Checklist

21. Useful GlitchGuard Checks

Final Takeaway

`p=none`

`p=quarantine`

`p=reject`