Email Authentication 101: Complete Guide to SPF, DKIM, and DMARC in 2025

If your marketing emails are landing in spam folders or your domain is being used for phishing attacks, the problem likely isn’t your content. It’s your email authentication.

In 2025, proper email authentication isn’t optional anymore. Major email providers like Gmail and Yahoo have made SPF, DKIM, and DMARC requirements mandatory for bulk senders. Without these protocols in place, your emails simply won’t reach your audience’s inbox.

This guide will walk you through everything you need to know about email authentication, from the basics to advanced implementation strategies.

What You’ll Learn

• What email authentication is and why it matters for your business
• How SPF, DKIM, and DMARC work together to protect your domain
• Step-by-step instructions to set up each authentication protocol
• Common mistakes that cause authentication failures
• How to monitor and maintain your email authentication
• Best practices for improving email deliverability in 2025

Why email authentication matters now more than ever

Email remains one of the most effective marketing channels, with an average ROI of $36 for every dollar spent. But there’s a catch: your emails actually need to reach the inbox to generate that return.

Email authentication solves three critical problems facing businesses today:

Protecting your brand reputation.

Cybercriminals send approximately 3.4 billion phishing emails every day, and many of these spoofed messages appear to come from legitimate businesses. When hackers use your domain to send scam emails, it damages your reputation and erodes customer trust. Email authentication prevents unauthorised senders from impersonating your domain.

Improving email deliverability.

Email providers use authentication as a key factor in their spam filtering algorithms. According to research from Validity, authenticated emails have significantly higher inbox placement rates compared to unauthenticated messages. In 2025, Gmail and Yahoo will require proper authentication for anyone sending over 5,000 emails per day.

Meeting compliance requirements.

Many industries now mandate email authentication as part of their security standards. Financial institutions, healthcare providers, and government contractors must implement these protocols to meet regulatory requirements and protect sensitive information.

The bottom line: without proper email authentication, you’re leaving money on the table and putting your brand at risk.

What is email authentication?

Email authentication is a set of technical standards that verify an email actually comes from the domain it claims to represent. Think of it like showing your ID at airport security. Just as the TSA verifies you are who your boarding pass says you are, email authentication protocols verify that messages really come from your organisation.

The email system was designed in the 1970s without built-in security measures. Anyone could send an email claiming to be from any address. This design flaw has been exploited for decades through spam, phishing, and email fraud.

Email authentication protocols fix this fundamental problem by adding verification layers to the email sending process. These protocols work together to create a comprehensive security framework that protects both senders and recipients.

Three main protocols work together:

SPF (Sender Policy Framework) creates a list of authorised mail servers for your domain. It answers the question: “Is this server allowed to send email for this domain?”

DKIM (DomainKeys Identified Mail) adds a digital signature to your emails. It answers the question: “Has this message been tampered with during transit?”

DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receiving servers what to do with emails that fail authentication checks. It answers the question: “What should happen to messages that don’t pass verification?”

Together, these three protocols create multiple verification checkpoints that dramatically reduce the chances of email fraud while improving legitimate email delivery.

How does SPF work

SPF (Sender Policy Framework) is the foundation of email authentication. It works by publishing a list of IP addresses and mail servers authorised to send email on behalf of your domain.

Here’s what happens when you send an email with SPF configured:

1. You send an email from your domain through your email service provider
2. The recipient’s email server receives your message
3. The server looks up your domain’s SPF record in your DNS settings
4. The server checks if the sending IP address matches any IP address listed in your SPF record
5. If there’s a match, the SPF check passes. If not, it fails.

The process happens in milliseconds and is entirely invisible to both sender and recipient.

Understanding SPF records

An SPF record is a special type of DNS TXT record that lists all the servers allowed to send email for your domain. A typical SPF record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0 ~all

Let’s break down what each part means:

v=spf1 declares this is an SPF version 1 record. This should always be the first element.

Include: statements that reference other domains’ SPF records. This is useful when you use third-party email services like Google Workspace or Mailchimp. In the example above, this domain uses Google’s mail servers and SendGrid.

ip4: or ip6: directly specify IP addresses authorised to send email. Use this for your own mail servers.

~all or -all is the enforcement policy. The tilde (~) means “soft fail”, where suspicious emails are marked but still delivered. The dash (-) means “hard fail”, where unauthorised emails are rejected. Most domains start with ~all while testing, then switch to -all once everything works correctly.

Setting up SPF for your domain

Follow these steps to implement SPF:

Step 1: Identify all your email sending sources.

Make a complete list of every service that sends email using your domain. This includes your email provider (Gmail, Outlook), email marketing platforms (Mailchimp, HubSpot), transactional email services (SendGrid, Postmark), CRM systems, help desk software, and any other applications.

Step 2: Gather SPF information from each service.

Contact each email service provider to get their SPF include statement or IP addresses. Most providers publish this information in their documentation. For example, Google Workspace uses “include:_spf.google.com” while Microsoft 365 uses “include:spf.protection.outlook.com”.

Step 3: Create your SPF record.

Combine all the SPF information into a single record. Start with v=spf1, add all your include statements and IP addresses, then end with your enforcement policy. Keep your SPF record under 255 characters and limit include statements to 10 or fewer to avoid lookup errors.

Step 4: Add the SPF record to your DNS.

Log in to your DNS provider (this might be your domain registrar, web hosting company, or a service like Cloudflare). Create a new TXT record for your root domain (@) with your SPF string as the value.

Step 5: Test your SPF record.

Use a free SPF checker tool to verify your record is formatted correctly and doesn’t have errors. Send test emails and check the email headers to confirm SPF is passing.

Common SPF mistakes to avoid

Many organisations make these SPF configuration errors:

Having multiple SPF records. You can only have one SPF record per domain. If you create multiple SPF TXT records, email servers won’t know which one to use, and authentication will fail.

Exceeding the 10 DNS lookup limit. Each include statement in your SPF record requires a DNS lookup. If your record requires more than 10 lookups, SPF checks will fail. To fix this, replace include statements with direct IP addresses when possible.

Forgetting to update SPF when changing email providers. If you switch email platforms or add new services, you must update your SPF record immediately. Outdated SPF records cause legitimate emails to fail authentication.

Using overly permissive policies. Some organisations use “+all”, which allows any server to send email for their domain. This defeats the entire purpose of SPF. Always use either “~all” or “-all”.

Not including all sending sources. That automated notification system your development team set up two years ago? It needs to be in your SPF record too. Audit all your systems regularly to ensure your SPF record is complete.

How does DKIM work

DKIM (DomainKeys Identified Mail) takes a different approach to email authentication. Instead of checking which servers can send email, DKIM verifies that the email content hasn’t been altered during transmission and confirms the domain owner authorised it.

Think of DKIM as a tamper-evident seal on your emails. Just like the security seal on a medicine bottle, DKIM lets recipients know if someone has tampered with the contents.

Here’s the DKIM process:

1. Your email server generates a unique digital signature for each outgoing message using a private cryptographic key
2. This signature is added to the email header as a DKIM-Signature field
3. The corresponding public key is published in your DNS records
4. When the recipient’s server receives your email, it retrieves your public key from DNS
5. The server uses this public key to verify the signature and confirm the message hasn’t been modified

If the signature verification succeeds, the email passes DKIM authentication. If the email was altered in any way during transit, the signature won’t match, and DKIM fails.

Understanding DKIM signatures

A DKIM signature contains several essential elements:

The selector identifies which DKIM key was used to sign the message. This allows you to rotate keys or use different keys for different sending streams. For example, you might use one key for marketing emails and another for transactional messages.

The domain specifies which domain’s public key should be used for verification. This is typically your primary domain.

The signature algorithm defines the cryptographic method used (usually RSA-SHA256).

The signed headers list which email headers are included in the signature. Standard headers include From, To, Subject, and Date.

The signature value is the actual cryptographic signature created from the message content and headers.

When you look at an email’s raw headers, the DKIM signature appears as a long string of characters that looks something like this:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=default;
c=relaxed/relaxed; q=dns/txt; t=1234567890;
h=from:to:subject:date:message-id;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSb…

Setting up DKIM for your domain

Implementing DKIM requires both your email service provider and your DNS provider:

Step 1: Generate DKIM keys through your email provider. Most modern email services handle DKIM key generation automatically. In Google Workspace, you enable DKIM through the Admin console. In Microsoft 365, you activate it through the Security & Compliance Centre. For dedicated email platforms like SendGrid or Mailgun, you’ll find DKIM settings in their domain authentication section.

When you generate keys, your provider will give you:

• A DKIM selector (often something like “default” or “s1”)
• A public key (a long string starting with “v=DKIM1”)
• Instructions for which DNS record to create

Step 2: Add DKIM records to your DNS. Create a new TXT record in your DNS settings. The record name will be your selector followed by “._domainkey” and your domain. For example: “default._domainkey.yourdomain.com”. The record value will be the public key provided by your email service.

Step 3: Enable DKIM signing. Return to your email provider’s settings and activate DKIM signing. This tells the service to start adding DKIM signatures to all outgoing emails.

Step 4: Verify DKIM is working. Send test emails to different email addresses. Check the email headers to confirm the DKIM-Signature field is present and that the signature validates correctly. Many email clients allow you to view full headers, or you can forward test emails to a DKIM validator service.

DKIM best practices

Use 2048-bit keys instead of 1024-bit keys. Longer keys provide better security. While both are currently accepted, 2048-bit keys are more resistant to future attacks and are recommended by M3AAWG’s Email Authentication Recommended Practices.

Rotate your DKIM keys periodically. Change your DKIM keys every 6 to 12 months as a security precaution. This limits the damage if a private key is ever compromised. Use selectors to maintain multiple active keys during rotation periods.

Sign all outbound emails. Don’t just sign marketing emails. Sign everything: transactional emails, automated notifications, and personal messages from your email client. Consistent DKIM signing builds trust with email providers.

Keep your private keys secure. The private key used to sign emails must be protected like any other critical security credential. Never share it or store it in publicly accessible locations.

Monitor for DKIM failures. Set up alerts to notify you when DKIM authentication starts failing. A sudden spike in DKIM failures might indicate a configuration error, a key rotation that didn’t complete properly, or even a security incident.

How does DMARC work

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the final layer of email authentication. While SPF and DKIM verify different aspects of an email, DMARC creates a policy framework that tells receiving email servers what to do when those checks fail.

DMARC also provides something SPF and DKIM can’t: detailed reporting about who is sending email using your domain and whether those emails are passing authentication.

Here’s how DMARC fits into the authentication process:

1. An email claiming to be from your domain arrives at a recipient’s server
2. The server performs SPF and DKIM checks
3. The server then checks for a DMARC policy in your DNS records
4. The server verifies that either SPF or DKIM passed AND that the domain aligns with the From address
5. Based on your DMARC policy, the server either delivers, quarantines, or rejects the message
6. The server sends a report back to you about the authentication results

The alignment requirement is critical. Even if SPF and DKIM pass, DMARC can still fail if the authenticated domain doesn’t match the visible From address. This prevents sophisticated spoofing attacks that pass individual checks but still use your brand deceptively.

Understanding DMARC policies

A DMARC record is another DNS TXT record that looks like this:

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

Let’s decode each component:

v=DMARC1 indicates this is a DMARC version 1 record.

p= sets your policy, which tells receiving servers what to do with emails that fail DMARC. There are three options:

• None means monitor only. Failed emails are delivered normally, but you receive reports. Use this when first implementing DMARC.
• Quarantine means suspicious emails should go to spam/junk folders.
• Reject means failed emails should be blocked entirely. This is the strongest protection.

pct= specifies what percentage of failed messages your policy applies to. Setting pct=25 means your policy only affects 25% of failing messages, while the other 75% are delivered regardless. This is useful for gradual rollouts.

rua= provides an email address for aggregate reports. These daily reports show overall authentication statistics.

ruf= provides an email address for forensic reports. These detailed reports include examples of specific messages that failed authentication.

fo= controls when forensic reports are generated. Different values trigger reports for different failure scenarios.

Setting up DMARC step by step

DMARC implementation should be gradual and carefully monitored:

Step 1: Ensure SPF and DKIM are working. DMARC builds on top of SPF and DKIM, so both must be configured appropriately before implementing DMARC. Send test emails and verify that SPF and DKIM checks are passing consistently.

Step 2: Create a monitoring-only DMARC record. Start with a policy of “none” to collect data without affecting email delivery. Your initial record might look like:

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

Create this as a TXT record with the name “_dmarc.yourdomain.com” in your DNS settings.

Step 3: Set up email addresses for reports. Create dedicated email addresses or mailboxes for receiving DMARC reports. These reports can be voluminous, so don’t use a personal inbox. Many organisations use specialised DMARC monitoring services to process and analyse these reports.

Step 4: Monitor reports for 2 to 4 weeks. Review your aggregate reports to understand your email authentication landscape. Look for:

• Which sources are sending emails for your domain
• What percentage of messages pass or fail authentication
• Any legitimate sources that aren’t properly authenticated
• Evidence of spoofing or phishing attempts

Step 5: Fix any authentication issues. Use the insights from DMARC reports to identify and fix authentication problems. This might mean updating SPF records, fixing DKIM configuration, or discovering forgotten email sending services that need proper authentication.

Step 6: Gradually increase policy enforcement. Once you’re confident that a legitimate email is authenticating correctly, strengthen your DMARC policy. Move from “none” to “quarantine” first, continuing to monitor reports. If everything looks good after another few weeks, you can move to “reject” for maximum protection.

You can also use the pct parameter to roll out a stricter policy gradually. For example, you might set p=quarantine with pct=10, then increase to 25, 50, 75, and finally 100 over several weeks.

Step 7: Implement DMARC for subdomains. Don’t forget about subdomains. Attackers often use subdomains for phishing (like secure.yourdomain.com or account-verify.yourdomain.com). You can either create individual DMARC records for each subdomain or use the “sp=” tag in your main DMARC record to set a subdomain policy.

Reading DMARC reports

DMARC aggregate reports arrive in XML format and can be intimidating at first. Here’s what to look for:

Source IP addresses show which servers are sending email for your domain. Compare these against your known email sources. Unknown IP addresses might indicate spoofing attempts or forgotten email systems.

Volume statistics tell you how many messages were sent from each source and what percentage passed authentication. Sudden changes in volume or new sending sources warrant investigation.

Authentication results break down SPF and DKIM pass rates. If a legitimate email is failing authentication, you’ll see it here and can take corrective action.

Disposition shows what receiving servers did with messages based on your policy. This helps you understand the impact before enforcing stricter policies.

Many free and paid tools can parse DMARC reports and present them in readable dashboards. Services like Postmark’s DMARC Digests, Dmarcian, and Valimail offer report analysis and ongoing monitoring.

Common email authentication problems and solutions

Even with careful setup, you might encounter authentication issues. Here are the most common problems and how to fix them:

Problem: Emails forwarded to other addresses fail DMARC

Email forwarding breaks SPF because the forwarding server’s IP address won’t match your SPF record. When someone forwards your email from Gmail to their work address, the work server sees an email claiming to be from your domain but coming from Gmail’s servers.

Solution: This is actually expected behaviour and not something you can fix from your end. DKIM usually survives forwarding (as long as the forwarding service doesn’t modify the email content), so ensure you have DKIM properly implemented. You might also consider a less strict DMARC policy if forwarding is standard among your audience. Some organisations use p=quarantine instead of p=reject specifically to handle forwarding scenarios more gracefully.

Problem: Mailing list software modifies messages and breaks DKIM

Traditional mailing lists often modify email content by adding footers, changing subject lines, or altering headers. These modifications invalidate DKIM signatures.

Solution: Modern mailing list software should support DKIM signing for messages sent through the list. If you run a mailing list, configure it to sign messages with its own DKIM key. If you’re sending to mailing lists, there’s unfortunately little you can control, but proper SPF and DMARC implementation still provides some protection.

Problem: Third-party services send email on your behalf without proper authentication

Many businesses use multiple platforms that send email: CRM systems, support desk software, LMS platforms, and more. Each one needs to be properly authenticated.

Solution: Create a comprehensive inventory of every service that sends email using your domain. For each service, either add its servers to your SPF record and configure DKIM, or have the service send from a subdomain (like noreply.yourdomain.com) with its own authentication setup. Many SaaS platforms provide detailed setup guides for email authentication.

Problem: SPF record exceeds the 10 DNS lookup limit

Each “include” statement in your SPF record requires a DNS lookup. If you use many email services, you can easily exceed the 10 lookup limit, causing SPF to fail.

Solution: Replace include statements with direct IP addresses where possible. For services with static IP ranges, manually list the IP addresses instead of using include. You can also use SPF flattening services that periodically convert includes to IP addresses, though this requires ongoing maintenance. Another approach is to move some email sending to subdomains with their own SPF records.

Problem: DMARC reports show legitimate email failing authentication

If your DMARC reports indicate that real, legitimate email from your organisation is failing authentication checks, you have a configuration problem that needs immediate attention.

Solution: Examine the reports to identify which specific sources are failing. Check that these sources are included in your SPF record and that DKIM is appropriately configured. Look at the authentication failure reasons provided in the reports. “SPF alignment failure” means the Return-Path domain doesn’t match the From domain. “DKIM alignment failure” means the d= domain in the DKIM signature doesn’t match the From domain. Work with your email service provider to correct alignment issues.

Testing your email authentication

Before fully deploying email authentication, thorough testing is essential. Here’s how to verify everything is working:

Manual testing methods

Check email headers. Send test emails to addresses you control at different email providers (Gmail, Outlook, Yahoo). View the full headers of received emails and look for:

• SPF: pass
• DKIM: pass
• DMARC: pass

Most email clients let you view full headers. In Gmail, open the email, click the three dots menu, and select “Show original.” In Outlook, open the email and select File > Properties.

Use dedicated testing tools. Several free services let you send an email to a special address and receive a detailed authentication report. Mail-tester.com provides a comprehensive analysis of authentication, content, and deliverability factors. Simply send an email to the address they provide, then check your score and detailed results.

Test from different sending sources. Don’t just test from one platform. Send emails from every service that sends mail for your domain: your email client, marketing platform, transactional email service, automated systems, etc. Each source needs to pass authentication independently.

Automated monitoring

Set up ongoing monitoring rather than just one-time testing:

Configure DMARC reports. Once DMARC is active, you’ll receive daily aggregate reports showing authentication success rates. Monitor these reports for any decline in pass rates or unexpected sending sources.

Use third-party monitoring services. Services like DMARC Analyser, Postmark’s DMARC monitor, and similar tools provide dashboards, alerts, and trend analysis. They can notify you immediately when authentication starts failing so you can fix problems before they impact deliverability.

Monitor email deliverability metrics. Track your inbox placement rates, bounce rates, and spam complaint rates. A sudden change might indicate an authentication issue even if you’re not seeing obvious errors.

Set up alerts for authentication failures. Many DNS providers and email platforms can send alerts when DNS records are modified or when authentication failure rates exceed thresholds. Configure these alerts to catch problems quickly.

Best practices for email authentication in 2025

Follow these guidelines to maintain strong email authentication:

Start with monitoring, then enforce gradually. Never jump straight to a strict DMARC policy. Begin with p=none, analyse reports for several weeks, fix issues, then move to p=quarantine, monitor more, and finally implement p=reject. This gradual approach prevents you from accidentally blocking your own legitimate emails.

Document your configuration. Create clear documentation that lists all your email sending sources, your SPF record components, DKIM selectors and keys, and your DMARC policy. When team members change or you switch service providers, this documentation will be invaluable.

Review authentication quarterly. Set a recurring calendar reminder to review your email authentication setup every three months. Check that your SPF record includes all current sending sources, verify DKIM keys are still valid, and analyse DMARC reports for any new patterns or concerns.

Use subdomains for different email types. Consider sending marketing email from marketing.yourdomain.com, transactional email from transactional.yourdomain.com, and using your main domain only for person-to-person email. This makes authentication simpler to manage and limits the impact if one subdomain’s reputation is damaged.

Implement authentication on all domains. Don’t forget about domains you’re not actively using. Attackers love to spoof dormant domains because they’re often unprotected. Even if you don’t send email from a domain, publish SPF, DKIM, and DMARC records that explicitly reject all mail to prevent spoofing.

Keep up with provider requirements. Major email providers regularly update their requirements. In 2024, Gmail and Yahoo implemented new mandatory authentication standards. Subscribe to announcements from major email providers to stay informed about policy changes that might affect your email delivery.

Consider BIMI for enhanced brand visibility. Brand Indicators for Message Identification (BIMI) is an emerging standard that displays your logo next to authenticated emails in supporting email clients. BIMI requires DMARC enforcement and a verified trademark, but it can increase brand recognition and trust. While not essential for authentication, it’s worth considering for mature email programs.

Protect against subdomain abuse. Attackers often use subdomains for phishing because organisations forget to protect them. Either set individual DMARC policies for important subdomains or use the sp= tag in your main DMARC policy to set a default subdomain policy.

The future of email authentication

Email authentication continues to evolve. Here’s what’s coming:

Mandatory authentication is becoming universal. Following Gmail and Yahoo’s lead, more email providers are requiring authentication for bulk senders. By 2025, authenticated email will be effectively mandatory for anyone sending significant volumes. Providers that don’t authenticate will see increasingly poor deliverability.

BIMI adoption is growing. More email clients now display brand logos for authenticated emails. As BIMI becomes standard, authenticated emails with verified brand indicators will stand out more clearly in crowded inboxes, increasing open rates and trust.

Enhanced reporting and visibility. DMARC reporting tools are becoming more sophisticated, offering real-time alerts, trend analysis, and threat intelligence. Organisations can now detect and respond to spoofing attempts within hours instead of days.

Integration with broader security frameworks. Email authentication is increasingly integrated with other security measures like MTA-STS (Mail Transfer Agent Strict Transport Security) and TLS-RPT (TLS Reporting), creating comprehensive email security ecosystems.

AI-powered authentication monitoring. Machine learning tools are beginning to analyse DMARC reports automatically, identifying anomalies and potential threats that human reviewers might miss. These tools can predict authentication issues before they impact deliverability.

The trend is clear: email authentication is moving from an optional best practice to a fundamental requirement for email delivery.

Taking action on email authentication

Email authentication isn’t a “set it and forget it” task. It requires initial setup, ongoing monitoring, and periodic maintenance. However, the investment is worthwhile: properly authenticated emails enjoy significantly higher deliverability, protect your brand from impersonation, and demonstrate professionalism to your recipients.

Start with the basics. Implement SPF and DKIM first, ensuring they’re working correctly before adding DMARC. Begin DMARC in monitoring mode, analyse the reports, fix any issues you discover, then gradually enforce stricter policies.

Remember that email authentication is ultimately about trust. By properly authenticating your emails, you’re telling the world that you care about security and that emails from your domain can be trusted. In an era where phishing and email fraud are rampant, that signal of trustworthiness has never been more valuable.

The authentication protocols we’ve covered (SPF, DKIM, and DMARC) have been around for years, but 2025 marks a turning point where they’ve transitioned from nice-to-have to must-have. If you haven’t implemented email authentication yet, now is the time to start. If you have, make sure it’s properly configured and maintained.

Your emails, your brand, and your recipients will all benefit from the investment in proper email authentication.