Blog · Business Email · Deliverability
Virtual PracharOmicron III, Greater Noida, Uttar Pradesh 201310 · 15 min read · Nov 2026
Picture a Tuesday morning. Your team sends a quotation to a new enquiry, an invoice to a long-standing client and an offer to your newsletter list. Your email tool reports all three as sent. Two days later the client asks why nobody replied. The quotation is in spam, the invoice was rejected, and the offer reached only part of the list.
That gap between "sent" and "seen" is email deliverability: whether your messages are accepted by the receiving server and placed in the inbox instead of spam. This guide to email deliverability in 2026 explains what SPF, DKIM and DMARC do, how to set them up in the right order, what Gmail, Yahoo and Microsoft expect, and what else decides inbox placement.
Authenticate every service that sends for your domain with SPF and DKIM, publish a DMARC record that starts at p=none, and confirm the results align with your visible From domain. Then protect your reputation with permission-based lists, clean data, relevant content and low complaint rates. Authentication is necessary, but it does not guarantee inbox placement.
Basics
Email delivery means the receiving server accepted your message during the SMTP conversation. Email deliverability is the bigger question: after acceptance, did the message reach the inbox, the spam folder or a promotions tab, or was it silently dropped? A message can be delivered and never seen, which is why a "98% delivered" report can sit beside weak replies.
Providers decide using reputation built over time. Domain reputation follows your brand wherever you send from. IP reputation depends on the address that sends your mail, and on everyone else using it if it is shared.
Authentication links your mail to your domain, so your good (or bad) history attaches to you and not to someone impersonating you. But authentication proves identity, not quality. A properly authenticated message to an unengaged or purchased list can still land in spam.
That is why this guide treats SPF, DKIM and DMARC as the foundation, and list quality, content and engagement as what you build on top.
| Term | What it means | What it tells you |
|---|---|---|
| Delivered | The receiving server accepted the message. | Nothing about folder placement. |
| Inbox placement | The message appears in the main inbox. | The real goal of deliverability. |
| Spam placement | Accepted, but filed in spam or junk. | A trust, content or engagement problem. |
| Hard bounce | Permanent failure, such as an address that does not exist. | Remove the address from your list. |
| Soft bounce | Temporary failure, such as a full mailbox or a busy server. | Retry; remove if it keeps happening. |
| Rejection | The server refused the message during sending. | Often authentication, policy or reputation. |
| Sender reputation | The provider's trust score for your domain and IP. | Shaped by complaints, bounces, engagement and consistency. |
Why it matters now
Large mailbox providers now treat authentication as a baseline. Gmail and Yahoo tightened their rules for bulk senders from February 2024, and Microsoft added requirements for high-volume senders to its consumer domains in 2025. The details are in the provider table later in this guide. For a business, the practical meaning is simple: unauthenticated mail is easier to filter, easier to spoof and harder to trust.
A DNS list of the servers and services allowed to send mail for a domain.
A cryptographic signature that lets the receiver verify the message came from the signing domain and was not changed.
A policy that ties SPF and DKIM to the visible From address and asks receivers how to treat failures.
| Standard | Main purpose | What it verifies | Where it is configured |
|---|---|---|---|
| SPF | Authorised sending sources | Sending infrastructure | DNS TXT record |
| DKIM | Message authentication | Cryptographic signature | DNS TXT record and the sending platform |
| DMARC | Policy and alignment | SPF/DKIM authentication alignment | DNS TXT record |
The three work as a chain. SPF and DKIM each produce a result. DMARC checks whether at least one of them passed and matched the domain in the visible From address, then publishes your preferred policy for failures.
Receiving providers also weigh reputation, content, engagement and anti-abuse signals. Authentication is one important input, not the whole verdict.
Step 1
SPF lets a domain owner publish, in DNS, which servers may send mail using that domain. A receiving server looks at the connecting IP address, finds the SPF record for the sender's domain and checks whether the IP is on the list. It exists because email by default lets anyone claim any sender address.
Two details trip people up. First, SPF checks the envelope sender (the Return-Path or MAIL FROM domain), not simply the From address people see. Second, for DMARC, the SPF domain must also align with the visible From domain. Relaxed alignment accepts a matching organisational domain; strict requires an exact match.
SPF has a known weakness: when a message is forwarded, the forwarding server's IP is not on your list, so SPF can fail. DKIM usually survives forwarding, which is one reason you need both.
v=spf1 include:_spf.example-provider.com ~all
Your real record depends on the services that send for your domain. Take the exact include value from each provider's own setup instructions.
Step 2
DKIM adds a digital signature to each outgoing message. Your sending platform holds a private key and signs selected headers and a hash of the body. You publish the matching public key in DNS. The receiver fetches that key and checks the signature. If the message was altered in transit, the check fails.
The signature header carries a few tags that matter. d= is the signing domain, s= is the selector, and the receiver looks up the key at s._domainkey.d. The selector is just a label, so one domain can have several keys, for example one per sending service or one per rotation.
For DMARC, the d= domain must align with the visible From domain. A platform signing with its own domain can pass DKIM yet fail DMARC alignment. Custom-domain authentication fixes that.
selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=<PUBLIC_KEY_FROM_YOUR_PROVIDER>"
Use 2048-bit RSA keys where your provider supports them, since 1024-bit keys are weaker. Some providers instead ask for CNAME records that point to keys they manage, so follow their format.
Plan for key rotation. Publish the new selector, switch signing to it, and retire the old one only after mail signed with it is no longer in transit.
Step 3
DMARC was created to close a gap. SPF and DKIM could each pass without having anything to do with the address a person sees in the From line. DMARC requires that at least one of them passes and aligns with the visible From domain, and it lets the domain owner say what receivers should do otherwise. It also sends you reports, so you can see who is sending as your domain, including impersonators.
Alignment can be relaxed (adkim=r, aspf=r, the default, which allows subdomains of the same organisational domain) or strict (s, exact match only).
Receivers apply their own processing, so a policy is a request, not a command.
v=DMARC1; p=none; rua=mailto:dmarc@example.com
example.com is a placeholder. Publish only a real mailbox or reporting service that someone actually monitors.
Side by side
| Factor | SPF | DKIM | DMARC |
|---|---|---|---|
| Purpose | Lists who may send | Proves the message is intact and signed | Sets policy and reporting |
| Method | IP check against DNS | Public-key signature | Alignment check plus policy |
| What it checks | Envelope sender domain and sending IP | Signature, d= and selector | SPF or DKIM result against the From domain |
| DNS | TXT at the domain | TXT or CNAME at selector._domainkey | TXT at _dmarc |
| Alignment | Return-Path vs From | d= vs From | Requires at least one aligned pass |
| Main benefit | Blocks unlisted servers | Detects tampering; survives forwarding | Stops spoofing; gives visibility |
| Common failure | Missing sender, forwarding, over ten lookups | Wrong selector, signing off, altered body | No aligned pass, no reports reviewed |
| Relationship | Feeds DMARC | Feeds DMARC | Depends on SPF or DKIM |
Use all three. SPF and DKIM give DMARC two chances to pass, and DMARC gives you the policy and the reports that the other two lack.
In practice
Take an invoice sent from billing@example.com. Here is what happens, and why setting up SPF, DKIM and DMARC together improves inbox placement.
DMARC passes if either SPF or DKIM passes with alignment. You should still configure and monitor both, because forwarding can break SPF and some changes can break DKIM.
Provider rules
Not every sender has the same obligations. Some rules apply to all senders, others to bulk senders. The table reflects the published rules as we understand them. Providers update their guidance, so confirm against each provider's current sender documentation before you rely on a detail.
| Requirement | Gmail | Yahoo | Microsoft (Outlook.com) |
|---|---|---|---|
| All senders | SPF or DKIM, valid forward and reverse DNS, TLS, correct message format, spam complaints kept low | SPF or DKIM, valid DNS, low spam complaints | Sound sending practice; strictest rules target high volume |
| Bulk threshold | About 5,000+ messages a day to personal Gmail accounts | "Significant volume"; no exact figure published | Over 5,000 messages a day to Outlook.com, Hotmail and Live addresses |
| Bulk authentication | SPF, DKIM and DMARC (at least p=none) | SPF, DKIM and DMARC | SPF, DKIM and DMARC, announced in 2025 |
| Alignment | From domain must align with SPF or DKIM | Required for bulk | Required for DMARC |
| One-click unsubscribe | Required for bulk marketing and subscribed mail | Required for bulk marketing mail | Working unsubscribe and accurate sender details expected |
| Spam complaints | Aim below 0.10%, never reach 0.30% | Keep below 0.30% | Keep low; no single figure to rely on |
| Enforcement | Rolled out from 2024; non-compliant mail may be delayed, spam-foldered or rejected | Similar, from 2024 | May be junked or rejected; check Microsoft's current status |
A business sending a few emails a day is not a bulk sender, but it still benefits from SPF, DKIM and DMARC. Anything unverified here is a reason to read the provider's own page, not to guess.
Verify
Start with DNS, then test with real mail. Replace the placeholders with your domain and the selector your provider gave you. The selector must match the actual sending platform, or the lookup will find nothing.
dig TXT example.com dig TXT _dmarc.example.com dig TXT selector1._domainkey.example.com
Then send a message to a mailbox you control, open its original headers and find Authentication-Results. You want to see spf=pass dkim=pass dmarc=pass.
Read the values carefully. A pass for SPF with the wrong domain may still fail DMARC alignment. If something fails, check the record text first, then the selector, then whether the platform is actually signing, then alignment.
For ongoing checks, read your DMARC aggregate reports to find every source sending as your domain. If you send volume to Gmail users, Google Postmaster Tools shows your domain reputation and spam rate.
Troubleshooting
| Problem | Likely cause | How to diagnose | What to do |
|---|---|---|---|
| SPF failure | Sender missing from the record | spf=fail or softfail; check the Return-Path domain | Add the provider's include to the one SPF record |
| DKIM failure | Wrong selector, record not published, signing off | dkim=fail or none; look up the selector | Recopy the record exactly, enable signing, resend |
| DMARC failure | No aligned SPF or DKIM pass | dmarc=fail; compare d= and Return-Path with From | Configure custom-domain authentication |
| SPF lookup limit | Too many includes or nested lookups | permerror in headers; count lookups | Remove unused services and consolidate |
| Multiple SPF records | Two TXT records start with v=spf1 | DNS lookup shows both | Merge into one record |
| Alignment failure | Platform signs or returns mail with its own domain | Domains in d= and Return-Path differ from From | Set up the platform's custom domain option |
| Landing in spam | Reputation, content, engagement, list quality | Compare folders across providers; review engagement | Clean the list, send relevant mail, reduce volume spikes |
| High bounce rate | Invalid or old addresses | Review bounce codes | Remove hard bounces; check how addresses are collected |
| High spam complaints | Unexpected or irrelevant mail, hidden unsubscribe | Postmaster Tools, complaint feedback | Confirm permission, ease unsubscribing, cut frequency |
| Poor sender reputation | History of complaints, bounces, erratic volume | Provider dashboards and trends | Send to engaged recipients, keep volume steady |
| Forwarding issues | SPF breaks when mail is forwarded | Passes at origin, fails after forwarding | Rely on DKIM and aligned signing |
| No unsubscribe support | Bulk mail without a link or header | Check for visible link and List-Unsubscribe header | Enable one-click unsubscribe in your sending platform |
Beyond DNS
Authentication is essential, but it is not a guarantee of inbox placement. These factors decide what happens next.
Checklist
Where Virtual Prachar fits
Our Business Emails service is bulk email to people you are allowed to write to. We help with the letter, the list and the send, and we will not mail a list when its source is unclear. We do not promise inbox placement or sell harvested address lists.
Good campaigns start with a clean, permission-based list, so a CRM is often the right home for contacts. For the DNS records in this guide, your domain administrator or email platform handles the technical setup. You can also see everything we offer on the services page, or learn about Virtual Prachar.
FAQs
It is the ability of your emails to be accepted by receiving servers and reach the inbox rather than spam or rejection.
SPF lists who may send for your domain. DKIM signs messages so changes can be detected. DMARC ties both to the From address, sets a policy and provides reports.
Yes, it is strongly recommended for any domain that sends email. Bulk senders to Gmail, Yahoo and Outlook.com have explicit requirements.
Sometimes, for low-volume senders. But you lose protection against spoofing and visibility through reports, and bulk senders are expected to have it.
The message may be marked suspicious, junked or rejected, depending on your policy, DMARC result and the provider's other signals.
The signature cannot be trusted. If SPF still passes with alignment, DMARC can pass, but the message is more exposed to filtering.
It is a monitoring policy. Receivers do not take DMARC action, and you get reports. It does not guarantee that failing mail reaches the inbox.
Often minutes to a few hours, depending on the record's TTL and caching. Occasionally it takes longer.
No. Publish one SPF record that combines all authorised sources.
No. It proves authentication and alignment. Reputation, content and engagement still decide placement.
Send a test message, open the original headers and read the Authentication-Results line for spf, dkim and dmarc, and run DNS lookups on your records.
Weekly while you set up and tighten your policy, then monthly once stable, and whenever you add a new sending platform.
Conclusion
SPF, DKIM and DMARC work best together: SPF names your senders, DKIM signs your messages and DMARC enforces alignment and gives you visibility. On top of that, permission-based sending, list hygiene and regular monitoring are what keep your reputation healthy. If you plan to send campaigns to your own contacts, talk to us about Business Emails or contact Virtual Prachar to discuss your requirements.
Thanks. We will get in touch soon.