- © 2026 Mailsoftly Inc. The name "Mailsoftly" and the Mailsoftly logo are registered trademarks of Mailsoftly Inc.
Email Deliverability Fundamentals
The protocols that prove your emails are legitimate, protect your brand from spoofing, and keep your messages out of the spam folder.
by Alkan Balkaya · Last updated: 2026-05-08Email authentication is the set of technical protocols that verify whether an email was genuinely sent by the domain it claims to come from. Without it, anyone can forge your sending address and deliver phishing emails to your customers, your partners, or thousands of strangers. Authentication solves that problem by giving inbox providers the evidence they need to trust your messages.
If you run any kind of email marketing program, authentication is not optional. Google, Yahoo, and Microsoft now enforce strict authentication requirements for bulk senders. Fail to comply and your campaigns land in spam, or get rejected outright. This guide covers the three core protocols (SPF, DKIM, DMARC), how they work together, and the exact steps to set them up for your domain.
New here? Start with our primer on What Is Email Deliverability? for the fundamentals, then come back to this guide.
Quick context: Mailsoftly offers transparent pricing, free hands-on migration, and human support. 500 contacts and 2,000 emails per month, no credit card.
Start free with Mailsoftly →
Key Takeaways
Email was designed in the early 1980s without any built in identity verification. The SMTP protocol, which still powers email delivery today, allows any server to claim any sending address. That design flaw is the reason phishing, spoofing, and email fraud became such persistent problems.
Email authentication closes that gap by adding verification layers on top of SMTP. When you publish authentication records in your domain’s DNS, you give receiving mail servers the information they need to answer three questions:
Each protocol handles one piece of the puzzle. Together, they create a chain of trust that inbox providers rely on to separate legitimate email from fraudulent messages.
How the Authentication Chain Works
Read enough? Try Mailsoftly free with 500 contacts and 2,000 emails per month, no credit card.Start free with Mailsoftly →
SPF is the first layer of email authentication. It works by publishing a list of IP addresses and servers that are authorized to send email on behalf of your domain. That list lives in a TXT record in your DNS.
When a receiving server gets an email claiming to be from your domain, it looks up your SPF record and checks whether the sending server’s IP address appears on the authorized list. If it does, SPF passes. If not, SPF fails.
Example SPF Record
v=spf1 include:mailsoftly.com include:_spf.google.com ~allThis record authorizes Mailsoftly’s servers and Google Workspace to send email for your domain. The ~all tag means all other sources get a soft fail.
SPF limitations. SPF only validates the envelope sender (the Return-Path address), not the “From” header that recipients actually see. It also breaks when emails are forwarded, because the forwarding server’s IP is not in the original SPF record. These limitations are exactly why SPF alone is not enough.
DKIM adds a cryptographic signature to every outgoing email. The sending server signs specific parts of the message (headers, body) with a private key. The corresponding public key is published in your DNS as a TXT record. Receiving servers use that public key to verify the signature.
If the signature checks out, the receiving server knows two things: the message genuinely came from your domain, and it was not modified in transit. Unlike SPF, DKIM survives forwarding because the signature travels with the message itself.
Example DKIM Record
Host: ms._domainkey.yourdomain.com
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNA...The selector (ms) identifies which key pair to use. Your email platform generates this record for you.
Key rotation. DKIM keys should be rotated periodically (every six to twelve months is a reasonable cadence). Most email platforms, including Mailsoftly, handle key rotation automatically. If you manage your own infrastructure, set a calendar reminder.
DMARC ties SPF and DKIM together and adds a critical missing piece: a policy that tells receiving servers what to do when authentication fails. Without DMARC, inbox providers make their own judgment calls about failed SPF or DKIM checks. With DMARC, you control the outcome.
DMARC also introduces “alignment,” which requires that the domain in the From header matches the domain validated by SPF or DKIM. This closes the gap that SPF leaves open (where the envelope sender and the visible From address can differ).
DMARC Policy Levels
| Policy | DNS Value | What Happens on Failure |
|---|---|---|
| None | p=none | Monitor only. No action taken. Use this to collect data before enforcing. |
| Quarantine | p=quarantine | Failed emails go to spam/junk. Good intermediate enforcement. |
| Reject | p=reject | Failed emails are blocked entirely. Strongest protection. |
You can use our DMARC Record Lookup Tool to check whether your domain has a valid DMARC record and which policy level is currently active.
Example DMARC Record
v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100The rua tag specifies where aggregate reports are sent. The pct=100 means the policy applies to all messages.
The recommended rollout. Start with p=none and enable reporting. Review your DMARC reports for two to four weeks to identify all legitimate sending sources. Add those sources to your SPF record and configure DKIM for each. Then move to p=quarantine, and finally to p=reject once you are confident that all legitimate email passes authentication.
Authentication is not just a technical checkbox. It has direct, measurable impact on whether your emails reach the inbox, how recipients perceive your brand, and whether bad actors can weaponize your domain.
Deliverability
Authenticated domains consistently see higher inbox placement rates. Gmail and Yahoo explicitly penalize unauthenticated senders in their filtering algorithms.
Brand Protection
DMARC with a reject policy prevents anyone from sending phishing emails that impersonate your domain. Your customers never see a forged message from your address.
Domain Reputation
Authentication is a foundational signal in how inbox providers calculate your domain reputation. Learn more about how email domain reputation works.
The enforcement shift. Google and Yahoo both rolled out mandatory authentication requirements for bulk senders. Any domain sending more than 5,000 messages per day must have SPF, DKIM, and DMARC configured. Even senders below that threshold benefit from the improved deliverability and security that authentication provides.
Without authentication, your sending domain is essentially an open door. Spammers and phishers can forge your address freely. When victims report those forged messages as spam, the reputation damage lands on your domain. Authentication closes that door.
The exact steps vary slightly depending on your email platform and DNS provider, but the process follows the same pattern for every domain. You can explore our email authentication protocols guide for protocol specific details and advanced configuration options.
Setup Checklist
Step 1: Audit Your Sending Sources
List every service that sends email from your domain. Common sources include your email marketing platform, transactional email service, CRM, helpdesk, and Google Workspace or Microsoft 365 for internal email.
Step 2: Configure SPF
Create a single TXT record at your root domain. Include each legitimate sending service using include: directives. End with ~all (softfail) or -all (hardfail). Note: you can only have one SPF record per domain. Multiple records will cause validation failures.
Step 3: Configure DKIM
Generate a DKIM key pair in your email platform’s settings. Copy the public key and create a TXT record at the selector subdomain provided (e.g., ms._domainkey.yourdomain.com). Repeat for each sending service that supports DKIM.
Step 4: Publish a DMARC Record
Create a TXT record at _dmarc.yourdomain.com. Start with p=none and a reporting address. Review reports, fix any alignment issues, then escalate to p=quarantine and eventually p=reject.
Step 5: Validate and Monitor
Send test emails and check headers for SPF, DKIM, and DMARC pass results. Monitor DMARC aggregate reports weekly for the first month, then monthly. Fix any new sending sources that appear in failure reports.
If you use Mailsoftly, the platform generates your DKIM keys and provides exact SPF and DMARC records to copy into your DNS. You can set up email authentication with Mailsoftly in under 15 minutes using the guided setup wizard.
Authentication configuration is straightforward, but small errors can silently undermine everything. These are the most common mistakes that cause authentication to fail.
Mistakes That Break Authentication
| Mistake | Why It Happens | How to Fix |
|---|---|---|
| Multiple SPF records | Each new service adds its own SPF record instead of merging into one. | Consolidate all include: statements into a single TXT record. |
| Exceeding the 10 DNS lookup limit | Too many include: directives in your SPF record. | Use SPF flattening or remove unused services. |
| DKIM key mismatch | Copy/paste error when adding the public key to DNS. | Regenerate and carefully repaste. Verify with a DKIM checker tool. |
| Jumping straight to p=reject | Skipping the monitoring phase blocks legitimate email. | Always start with p=none, review reports, then escalate gradually. |
| Forgetting subdomain policies | DMARC applies to the root domain by default. Subdomains need sp= or their own records. | Add sp=quarantine or sp=reject to your DMARC record. |
DNS propagation delays. After adding or modifying DNS records, changes can take up to 48 hours to propagate globally (though most propagate within one to four hours). Do not assume a failed test means a broken record. Wait at least a few hours and test again before troubleshooting.
Third party services. Every SaaS tool that sends email on your behalf needs to be included in your authentication setup. This includes helpdesk platforms, CRM systems, billing tools, and any service that sends automated notifications from your domain. Missing even one service creates a gap that can trigger DMARC failures.
Authentication is not just about security. It is the foundation of email deliverability. When inbox providers evaluate whether to place your message in the inbox, spam folder, or reject it entirely, authentication status is one of the first signals they check.
Authentication Impact on Deliverability
The relationship works both ways. Strong authentication builds domain reputation over time, which further improves deliverability. Poor or missing authentication erodes reputation, creating a downward spiral that becomes progressively harder to reverse.
BIMI: the visual payoff. Brand Indicators for Message Identification (BIMI) is a newer standard that displays your brand logo next to authenticated emails in supporting inboxes (Gmail, Yahoo, Apple Mail). BIMI requires a DMARC policy of p=quarantine or p=reject, making full authentication a prerequisite. It is a tangible, visible reward for doing authentication right.
If you use an email marketing platform like Mailsoftly, much of the technical work is handled for you. But there are still actions only the domain owner can take, and decisions that affect your results.
Custom sending domain vs. shared domain. Most platforms let you send from their shared domain out of the box. This works for testing, but for production email marketing you should always authenticate your own domain. Shared domains mean your reputation is pooled with other senders, some of whom may have poor sending practices.
What your platform handles. DKIM signing (automatic on every outgoing message), Return-Path configuration for SPF alignment, and bounce processing. What you handle: adding SPF includes and DKIM public keys to your DNS, publishing a DMARC record, and monitoring DMARC reports.
Pro Tip: Test Before Every Major Campaign
Send a test email to a personal Gmail, Outlook, and Yahoo address before launching any major campaign. Check the message headers (look for “Authentication-Results”) to confirm SPF, DKIM, and DMARC all show “pass.” A five minute check can prevent thousands of emails from landing in spam.
Subdomain strategy. Some organizations use a subdomain (e.g., mail.yourdomain.com) for marketing email to isolate its reputation from transactional or internal email. This is a valid approach, but remember that each subdomain needs its own SPF and DKIM records, and your DMARC record should include a sp= policy that covers subdomains.
For the broader picture on deliverability, see our complete guide on What Is Email Deliverability?, which covers strategy, fundamentals, and advanced playbooks beyond authentication.
Yes. Each protocol addresses a different aspect of email authentication, and they are designed to work together. SPF verifies the sending server, DKIM verifies message integrity, and DMARC enforces a policy when either check fails. Major inbox providers now expect all three to be in place for bulk senders.
The DNS configuration itself takes 15 to 30 minutes if you have access to your domain’s DNS settings and your email platform provides the records to add. DNS propagation may take one to 48 hours after that. The DMARC monitoring phase (starting at p=none) should run for two to four weeks before you escalate to an enforcement policy.
Authentication is necessary but not sufficient for inbox placement. It establishes trust at the domain level. Inbox providers also evaluate content quality, engagement metrics, complaint rates, and sending patterns. Think of authentication as the prerequisite that makes everything else possible.
Without DMARC, receiving servers rely on their own internal heuristics to handle SPF and DKIM failures. You have no visibility into who is sending email on behalf of your domain, and no control over what happens when authentication fails. Your domain remains vulnerable to spoofing, and you miss out on the deliverability benefits of a published DMARC policy.
Authentication prevents attackers from spoofing your exact domain (e.g., sending as [email protected]). It does not prevent lookalike domain attacks (e.g., y0urdomain.com with a zero instead of the letter o). For full phishing protection, combine authentication with employee security training and domain monitoring services that detect lookalike registrations.
Ready to switch?Start free with Mailsoftly →
500 contacts, 2,000 emails per month. Free hands-on migration. No credit card.
Ready to boost your email marketing?
Start sending beautiful, targeted emails that convert — free to get started.
Try Mailsoftly FreeNo credit card required