What Is Email Authentication? The SPF, DKIM, and DMARC Playbook

Audit your existing DNS records

Start by mapping the current state of your sending domains before launching new campaigns. Because many teams inherit domains with outdated security records, a messy DNS configuration causes immediate deliverability drops.

Identify which platforms currently have permission to send mail on your behalf so this audit prevents you from accidentally breaking existing mail flows.

1. Log into your domain registrar and open the advanced DNS management console for your domain.
2. Filter your existing records to show only TXT and CNAME entries to reduce visual noise.
3. Search for a TXT record starting with v=spf1 to locate your current SPF policy string.
4. Look for records containing _domainkey to identify active DKIM signatures tied to your domain.
5. Check the _dmarc subdomain to evaluate your current failure handling instructions and reporting address.

Publishing multiple SPF records on a single domain causes an immediate authentication failure at major providers, so you must consolidate conflicting rules into a single valid string. Stale DKIM keys pose a security risk because malicious actors can exploit abandoned vendor accounts. Document every record before making modifications so you can revert changes quickly if mail stops flowing. Done looks like a documented list of all active authentication records and the platforms they authorize.

Configure your SPF policy

The Sender Policy Framework restricts which IP addresses can send mail using your domain name. Receiving servers check your published list of approved IP ranges in your DNS records against the IP address of the incoming message.

If the sending IP does not appear in your SPF record, the message fails the check. Google email sender guidelines require a valid SPF setup for all bulk senders reaching their network. A standard SPF record starts with a version tag and ends with an enforcement rule, while the middle section contains specific include statements for your platforms. For example, a domain using Google Workspace and a separate outbound tool needs both platforms listed, separated by a single space to maintain proper DNS syntax.

The protocol imposes a strict limit of ten DNS lookups per individual SPF evaluation. Exceeding this limit causes a permanent error, so your outbound mail will bounce immediately. You must carefully count the nested lookups hidden inside your vendor include statements. When you hit the lookup limit, use an SPF flattening tool to resolve the includes into raw IP addresses. This technique reduces the total lookup count while maintaining platform authorization. Done looks like a single SPF record authorizing your infrastructure without exceeding the ten-lookup limit.

Example: Calculating your SPF lookup limit

Let us calculate the DNS lookups for a typical B2B sales stack to see how quickly you reach the ten-lookup limit. Suppose your base SPF record includes Google Workspace and a marketing automation tool.

1. The initial TXT query for your domain counts as one lookup.
2. The Google Workspace include resolves to three additional lookups.
3. The marketing tool include resolves to four additional lookups.
4. Your total is now eight lookups.
5. If you add a sales engagement platform requiring three lookups, your total hits eleven.
6. This configuration exceeds the limit and causes a permanent SPF failure.
7. To fix this, you must replace the nested includes with their flattened IPv4 addresses, which do not count against the DNS lookup limit.

Generate and publish DKIM keys

DomainKeys Identified Mail adds a secure cryptographic signature to all outgoing messages to prove the content remained unchanged during transit. Your sending platform generates a private key to sign the message headers and body, while you publish the matching public key in your DNS records. Receiving servers use the public key to decrypt the signature and verify the content hash. If the hashes match, the message passes the DKIM check and proceeds to the inbox.

Unlike SPF authentication, DKIM survives the auto-forwarding rules that typically break verification during complex server routing. This technical resilience makes it a reliable identifier for building long-term domain reputation.

1. Navigate to the domain settings inside your chosen email sending platform to locate the security tab.
2. Generate a new 2048-bit DKIM key pair for your specific sending domain to ensure maximum security.
3. Copy the provided public key data and the specific selector name assigned by the vendor.
4. Create a new TXT or CNAME record in your DNS using the exact selector string provided.
5. Wait for the DNS changes to propagate across global servers before sending live campaigns.

You should rotate your DKIM keys annually because old keys become vulnerable to brute-force attacks as global computing power increases. Some sending platforms require you to click a verification button after publishing the DNS record. The platform queries your DNS and activates the signing process once it detects the key. Done looks like a verified DKIM signature attached to the header of every outbound message.

Example: Verifying a DKIM signature in Gmail

You can manually verify your DKIM configuration by inspecting the raw email headers of a test message sent to a Gmail inbox.

1. Send a test email from your outbound platform to a personal Gmail address.
2. Open the email, click the three dots in the top right corner, and select the option to show the original message.
3. Locate the DKIM row in the summary table.
4. It should display a passing status with your sending domain listed.
5. Scroll down to the raw header text and find the signature block.
6. Verify that the domain tag matches your sending domain and the selector tag matches your specific selector.
7. If the signature is missing or the domains do not match, your sending platform is not attaching the cryptographic key correctly.

Enforce your DMARC policy

Domain-based Message Authentication, Reporting, and Conformance ties your separate security protocols together into one policy. It tells receiving servers how to handle messages that fail SPF or DKIM checks. DMARC requires strict identifier alignment to pass its evaluation, meaning the domain in the From address must match the domain validated by SPF or DKIM.

The enforcement phases

You must deploy DMARC in calculated stages to avoid blocking legitimate mail traffic by mistake. A sudden jump to strict enforcement often traps internal communications and automated transactional alerts.

1. Publish a DMARC record with a none policy to monitor global authentication traffic without blocking messages.
2. Configure the rua tag to send aggregated XML reports to a dedicated monitoring inbox daily.
3. Review the daily reports to identify any legitimate platforms failing alignment checks in the wild.
4. Upgrade the policy to quarantine once you verify all authorized mail passes the required checks.
5. Move the policy to reject to block all domain spoofing attempts permanently from reaching inboxes.

The reporting function provides visibility into who is attempting to use your domain name so you can spot configuration errors or malicious spoofing campaigns. Strict alignment requires an exact domain match, while relaxed alignment permits subdomains to pass. Most B2B senders use relaxed alignment to accommodate complex routing infrastructures and third-party tools. Done looks like a p=reject DMARC record that protects your domain reputation without blocking your own outbound campaigns.

Example: A 60-day DMARC enforcement schedule

Moving straight to a reject policy will block legitimate mail. You must follow a strict 60-day rollout schedule to reach full enforcement safely.

1. Publish a none policy to monitor traffic without blocking any messages.
2. You will receive XML reports showing which IP addresses send mail using your domain.
3. Upgrade to a quarantine policy sending 25 percent of failing messages to the spam folder.
4. Monitor your reports to ensure your primary sales tools maintain a perfect pass rate.
5. Increase the quarantine percentage so all failing messages go to spam.
6. If your open rates drop below 30 percent, revert the policy and audit your DKIM keys.
7. Deploy the final reject policy so receiving servers drop all failing messages before they reach the inbox.
8. This configuration stops domain spoofing entirely.

Align your From address with your return path

Identifier alignment is the core mechanism allowing DMARC to verify your sender identity. A message can pass SPF and DKIM independently but still fail DMARC if the domains do not match. The return path is the hidden email address where receiving servers send automated bounce notifications. Your sending platform usually configures this address to point to their own tracking servers.

DMARC offers two distinct modes for evaluating domain alignment across your outgoing outbound messages. You define this mode using the aspf and adkim tags in your DNS record.

1. Open your sending platform settings and locate the custom tracking domain configuration panel immediately.
2. Create a CNAME record pointing a specific subdomain to your vendor tracking infrastructure.
3. Configure your DMARC record to use relaxed alignment by setting the tags to relaxed mode.
4. Send a test message to a verification tool to confirm the return path matches your header domain.

Relaxed alignment allows a subdomain in the return path to match the root domain in the From address, whereas strict alignment requires an exact character-for-character match. For example, a return path of bounces.getle.ad aligns with a From address of efe@getle.ad under relaxed rules. Under strict rules, this exact configuration fails alignment and triggers an immediate DMARC penalty. Done looks like a custom tracking domain setup ensuring your return path aligns with your visible sender address.

Example: Configuring a custom tracking domain

A custom tracking domain ensures your return path aligns with your From address to pass DMARC evaluation.

1. Choose a subdomain for your tracking links.
2. Log into your domain registrar and create a new CNAME record.
3. Set the host field to your subdomain and the value to your sending platform tracking server.
4. Save the record and wait 24 hours for DNS propagation.
5. Enter the new subdomain into your sending platform custom tracking domain settings.
6. Send a test email and verify that the return path header now displays your custom subdomain instead of the vendor default domain.

Monitor authentication health

Authentication requires continuous monitoring to catch hidden infrastructure changes before they impact your active campaigns. Because vendors update their IP ranges and DNS records can get deleted during server migrations, you must check your domain DNS configuration immediately when your email says authentication error. These errors usually stem from syntax mistakes, expired DKIM keys, or missing include statements.

Microsoft 365 documentation explains how their composite authentication system evaluates these security signals together. Because a failure in one protocol can drag down your overall sender score at major providers, you must track your authentication metrics alongside your standard campaign performance data daily. Deliverability problems often begin with silent authentication failures weeks before your bounce rates actually spike.

1. Register every sending domain with Google Postmaster Tools to track authentication success rates accurately.
2. Process your DMARC XML reports through a visualization tool to spot alignment trends over time.
3. Run a manual header analysis whenever you add a new sending platform to your technology stack.
4. Audit your DNS records quarterly to remove include statements for deprecated software vendors immediately.

Active monitoring protects your investment in domain reputation by catching configuration errors early. A broken record can ruin a warmed-up domain in a matter of days if left unchecked. Done looks like a weekly routine confirming all sending platforms maintain passing authentication scores across major mailbox providers.

Sources and method

Google email sender guidelines dictate the baseline authentication requirements for reaching their users safely and consistently. We referenced their documentation to confirm the strict enforcement policies for bulk senders operating today.

Microsoft 365 documentation details how composite authentication evaluates SPF, DKIM, and DMARC together to determine spam placement. We used their technical specifications to explain identifier alignment and message failure handling mechanisms.

All external figures and platform requirements were checked in October 2026.

How do I authenticate my email?

You authenticate your email by publishing SPF, DKIM, and DMARC records in your domain DNS settings. These records authorize specific IP addresses and provide cryptographic signatures to verify your identity to receiving servers.

What to do when your email says authentication error?

You must check your DNS records for syntax errors or missing include statements. Use a deliverability testing tool to identify which specific protocol failed. Update the broken record and wait for DNS propagation.

Can you give me an example of authentication?

An example of authentication is a DKIM signature hidden in an email header. The sending server encrypts a hash of the message, and the receiving server decrypts it using a public key found in your DNS.

What does authentication email mean?

An authentication email refers to a message that has successfully passed SPF, DKIM, and DMARC checks. Receiving servers trust these messages more because the sender identity is cryptographically verified and aligned with the From address.

Why does SPF fail when an email is forwarded?

SPF fails during forwarding because the forwarding server sends the message from its own IP address. This new IP address is not listed in your original SPF record. DKIM survives forwarding because the cryptographic signature remains intact.

How long does DNS propagation take for authentication records?

DNS propagation for authentication records typically takes between one and twenty-four hours. You should wait a full day after publishing new SPF, DKIM, or DMARC records before sending live outbound campaigns to ensure global servers recognize the update.