Web Development Company in Pune: Why Your Website's Contact-Form and Order Emails Land in Spam, and the SPF, DKIM and DMARC Setup That Fixes It
Your website's contact-form, order and OTP emails land in spam because the receiving mailbox cannot confirm that your domain authorised the server that sent them. The usual causes are a WordPress site sending through the hosting server's default mail function, a "From" address that does not match the sending service, and missing or broken SPF, DKIM and DMARC records in DNS. The fix has four parts: send through a proper mail service over SMTP or an API, publish SPF and DKIM records for that service, add a DMARC record and move it from monitoring to enforcement in stages, and send from an address on your own domain. A good web development company in Pune should be able to do this and prove it in one working session, with a test email that shows "PASS" for all three checks.
This guide is for owners and managers of Pune and other Indian small businesses whose enquiry emails go missing or land in junk. It covers the transactional mail your site generates, not newsletters or cold email.
Two problems that look the same
When form emails "don't arrive", one of two things is happening. Either the mail is delivered but filed as spam, which is an authentication and reputation problem and the subject of this article, or it is never delivered at all. The second case comes from a blocked server, a failing plugin or a wrong recipient address, and it shows up in logs or bounce messages rather than in a junk folder.
Find out which you have before editing DNS. Submit your own contact form from a phone using a Gmail address and check inbox, junk and All Mail, then ask your developer to find the same minute in the mail or SMTP plugin log. If the message was accepted, work through this guide. If the log shows an error or nothing, fix the plugin or hosting setting first.
How email authentication works in plain language
Email was designed when anyone could claim to be anyone. SPF, DKIM and DMARC are how the modern internet checks those claims. All three live in your domain's DNS, the address book maintained by your registrar or DNS host, such as Cloudflare or your hosting panel.
SPF: who is allowed to send for your domain
SPF stands for Sender Policy Framework. It is a single text record listing the servers and services allowed to send mail for your domain. A receiving server looks it up and checks whether the sending server is on the list. If you use Google Workspace for staff mail and another service for website mail, both belong in one SPF record.
DKIM: a signature that proves the message was not changed
DKIM stands for DomainKeys Identified Mail. Your sending service signs each outgoing message with a private key it keeps secret, and you publish the matching public key in DNS. The receiver fetches the key, checks the signature and learns that the message came through a system holding your key and that the signed parts were not modified. Amazon SES's documentation, for example, describes Easy DKIM as adding a 2048-bit key to every message from a verified domain, completed by adding records at your DNS provider.
DMARC: what to do when checks fail, and who gets told
DMARC ties the other two together. It says that the domain in the visible From address must line up with the domain that passed SPF or DKIM, and it tells receivers what to do with failures: nothing special (p=none), spam folder (p=quarantine) or refuse (p=reject). It also asks receivers to send you reports, so you can see who sends mail in your name, including tools you forgot about.
The DMARC specification, RFC 7489, defines the tags: p for policy, sp for subdomain policy, pct for the share of mail the policy applies to, rua for the aggregate-report address, and adkim and aspf for strict or relaxed alignment (relaxed is the default).
Alignment is the part people miss
A site can show "SPF pass" and still fail DMARC. If the visible From is enquiry@example.com but the service signs and sends using its own domain, SPF and DKIM pass for the service, not you, and DMARC fails. The fix is the service's "domain authentication" setup, so it signs with a DKIM key for example.com.
What Google, Yahoo and Microsoft actually require
Large mailbox providers have tightened their rules. Read the official pages yourself, because details change.
Google. Google's email sender guidelines say all senders to personal Gmail accounts should set up SPF or DKIM, use a TLS connection, have valid forward and reverse DNS for the sending IP, send correctly formatted messages and keep spam rates in Postmaster Tools low. Bulk senders, which Google defines as those sending 5,000 or more messages a day to Gmail addresses, must set up SPF, DKIM and DMARC, align the From domain with the SPF or DKIM domain, and support one-click unsubscribe for marketing and subscribed messages. Google also says a DKIM key of 1024 bits or longer is needed for personal Gmail recipients.
Yahoo. Yahoo's sender best-practices page asks all senders to implement SPF or DKIM, bulk senders to use both plus a DMARC policy of at least p=none, and everyone to keep spam rate below 0.3 percent. It gives no numeric definition of "bulk".
Microsoft. Microsoft announced requirements for domains sending more than 5,000 emails a day to Outlook.com, Hotmail.com and Live.com consumer mailboxes: SPF, DKIM and DMARC with at least p=none, with non-compliant mail first routed to junk and rejection planned later. Microsoft's own announcement did not load during our research, so these details come from secondary coverage (Petri, Security Boulevard); read the Microsoft Tech Community post before relying on them.
Small senders are below that line, but Google still lists SPF or DKIM, TLS and valid DNS as expectations for every sender.
Spam-complaint thresholds, in Google's words
Google's guidance says senders should keep their user-reported spam rate below 0.1 percent, and that bulk senders at or above 0.3 percent become ineligible for mitigation and support escalation. These figures come from Google's sender guidelines FAQ; check the current page in case they change.
Complaints come from people pressing "report spam". Order confirmations rarely draw them; marketing mail sent to old, unconsented lists does. Keep marketing and transactional mail on separate streams or subdomains.
Why WordPress and PHP mail fail so often
By default, WordPress sends mail through its wp_mail function, which hands the message to the web server's own mail facility. It is the cheapest possible path and it breaks in predictable ways.
- Not in SPF, not signed. Mail leaves from the hosting server's IP, which your SPF never mentions, with no DKIM signature or one using the host's domain.
- A generic From address. WordPress defaults to something like wordpress@yourdomain, which may not be a real mailbox.
- Shared IP reputation and host limits. Other customers on the same server may send poor mail, and many hosts cap outbound messages or disable direct sending on some plans.
- Plugins overriding From. A form plugin set to send "from" the visitor's address is the most common mistake, covered below.
WooCommerce order mail, password resets and OTPs on custom PHP, Node or Java builds have the same weakness if the code calls a local mail function. Unless someone has shown you a passing test, assume your site is on the default setup.
The fix: send through a proper mail service
Stop sending from your web server and hand mail to a service built for it, either over SMTP (a login the site uses to connect) or through the service's API. Your site then talks to a system with managed IP addresses, DKIM signing, bounce handling and logs. The table lists categories, not endorsements. Volume, budget and the tools you already pay for decide.
| Option | Good fit when | Things to check |
|---|---|---|
| Business mailbox provider (for example Google Workspace or Zoho Mail) over SMTP | A few form and order mails a day, and you already pay for staff mailboxes | Daily sending limits, whether the plan allows SMTP from apps, domain authentication |
| Transactional email service (for example Amazon SES or Brevo) | Orders, OTPs, resets and receipts at higher or growing volume | Domain authentication steps, approval requirements for new accounts, pricing model, log retention |
| Hosting provider's authenticated SMTP | You are on a managed host that documents it | Whether it signs DKIM for your domain, outbound limits |
| Email marketing platform | Newsletters and campaigns | Not meant for order receipts; keep it separate |
Free allowances, limits and approval processes vary and change often, so read each provider's current documentation. Some services, Amazon SES among them, may start new accounts in a restricted mode until you request production access.
A clinic with a booking form can often run on its business mailbox over SMTP, while an online store with receipts and password resets is better on a transactional service with logs. A site sending OTP codes should use its own sending subdomain, because a late OTP is a failed login. Our e-commerce website service includes this wiring in store builds.
Fix the "From" address first
Most "spam" cases begin here, so fix it before touching DNS.
Wrong: the form sets From to the visitor's email, for example ravi@gmail.com. The message claims to be from Gmail but was sent by your server, and Gmail's own DMARC policy treats that as a spoof, so the message may be discarded or flagged.
Right: From is an address on your own domain, such as website@example.com, and the visitor's address goes in the Reply-To header. When staff press reply, the answer goes to Ravi, while the message is honestly from your domain.
Also avoid using noreply@ when customers need to reply, and keep the From address identical in the form plugin, WooCommerce and WordPress settings so all mail aligns.
The records, with examples
All examples use example.com and placeholder values. Your sending service provides the real ones; copy them exactly from its dashboard.
SPF record example
SPF is a TXT record on the root of your domain, and there must be only one per domain. Two records are treated as an error.
| Type | Host | Value |
|---|---|---|
| TXT | @ | v=spf1 include:_spf.google.com include:spf.mailservice.example ~all |
Each include comes from a service that sends for you; here the first stands for Google Workspace and the second for a hypothetical website-mail service. The ending ~all means "soft fail anything else"; -all is stricter. Many setups use ~all and let DMARC enforce.
The 10-lookup limit
RFC 7208, the SPF standard, says an SPF evaluation may trigger no more than 10 DNS-querying terms. The mechanisms that count are include, a, mx, ptr and exists, plus the redirect modifier. The ip4, ip6 and all terms do not count. Going over produces a permanent error (permerror), and receivers may treat SPF as failed. The standard also advises limiting "void" lookups, those returning nothing, to two.
This bites businesses that add a tool every year; a CRM, marketing platform and helpdesk can each add nested includes until the record crosses the line unnoticed. Remove services you no longer use, use ip4 entries where a provider publishes stable addresses, or give each service its own subdomain with a short SPF record. Online SPF checkers count lookups for you.
DKIM record example
| Type | Host | Value |
|---|---|---|
| CNAME | selector1._domainkey | selector1.dkim.mailservice.example |
| CNAME | selector2._domainkey | selector2.dkim.mailservice.example |
Some services use a TXT record with the public key instead. Copy the exact host name and value; some DNS panels append your domain automatically, giving names like selector1._domainkey.example.com.example.com, so look for that doubling if a check fails.
DMARC record example
| Type | Host | Value |
|---|---|---|
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r |
Start with p=none. It enforces nothing and lets you collect reports. The rua address receives XML aggregate reports from large receivers. Raw reports are XML, so use a report viewer or route them to a mailbox someone checks.
Staging DMARC: none, then quarantine, then reject
If you jump to p=reject while a forgotten system, such as an old invoicing tool or a vendor's CRM, still sends as your domain, that mail starts bouncing. Go in stages.
| Stage | Policy | What you do | Typical duration |
|---|---|---|---|
| 1. Monitor | p=none with rua | Read reports, list every source of mail in your name, fix the legitimate ones | 2 to 4 weeks, longer with many tools |
| 2. Partial enforcement | p=quarantine with pct at 10, then 50, then 100 | Failing mail goes to spam for a growing share; watch for complaints from staff or customers | 2 to 4 weeks |
| 3. Full enforcement | p=reject | Failing mail is refused; fakes cannot reach customers | Ongoing; review reports monthly |
The durations are rules of thumb, not requirements. If you cannot reach reject, quarantine is still far better than nothing. Subdomains inherit your main policy unless you set sp.
Testing: how to know it worked
Run these after every change and after any new tool is connected.
- Gmail "Show original". Send a test from your site to a personal Gmail address, open it, use the three-dot menu and choose Show original. Gmail displays SPF, DKIM and DMARC results. You want PASS for all three, with your domain beside each.
- A mail-tester style service. Send to its temporary address and read the authentication, blacklist and content results; treat the score as a rough guide.
- DNS lookup tools. Confirm one SPF record under the lookup limit, a resolving DKIM selector and a valid DMARC record.
- Every real flow. A contact form, a WooCommerce order, a password reset and an OTP take different code paths. Test each, to Gmail, to an Outlook or Hotmail address and to a business-domain address.
A 30-60-90 minute setup runbook
This assumes you have chosen a sending service and have DNS access. The times suit one domain with a simple setup; complex DNS, several systems or slow propagation take longer.
Minutes 0 to 30: inventory and service
List every system that sends mail for your domain (forms, store, CRM, billing, helpdesk, newsletter tool, staff mailboxes), save a copy of the DNS zone, add your domain to the sending service and note the records it asks for, and create a real, monitored mailbox for the From address, for example website@example.com.
Minutes 30 to 60: DNS and site configuration
Add the DKIM records exactly as given, add or edit the single SPF record, and add the DMARC record with p=none and a reporting address. In WordPress, configure an SMTP or API plugin; in custom code, point the mail client at the service's host, port and credentials. Keep the password or API key in configuration or secrets, never in a page or public repository. Set the same From address everywhere and Reply-To for contact forms.
Minutes 60 to 90: test and record
Wait for the service to show the domain as verified; DNS can take minutes to many hours, so check again later rather than editing repeatedly. Run the Gmail Show original test, fix any FAIL, then test the form, order, reset and OTP flows. Record who owns the credentials and DNS access.
This is the same discipline as our website handover and ownership checklist: the DNS login, mail service account and API keys should belong to your business, not to a developer's personal account.
Mistakes that keep sending mail to spam
| Mistake | What goes wrong | Fix |
|---|---|---|
| Form sets From to the visitor's address | Fails alignment and spoofs a third party's domain | From is your domain; visitor goes in Reply-To |
| Two SPF records on one domain | Receivers treat it as an error | Merge into one record |
| SPF over 10 lookups | Permanent error; SPF treated as failed | Remove unused includes; use subdomains |
| DMARC at reject on day one | Mail from forgotten tools is refused | Start at none, read reports, then tighten |
| Marketing and transactional mail on one stream | A bad campaign hurts receipts and OTPs | Separate subdomains or services |
| SMTP password in a public place | Anyone can send as you | Keep secrets in config; rotate if exposed |
What to ask your web developer
You do not need to understand every record, but you do need clear answers.
- Which service sends our website's emails, and by SMTP or API?
- Show me the Gmail "Show original" result for a form email. Do SPF, DKIM and DMARC all pass for our domain?
- What is our DMARC policy, who receives the reports, and what is the plan to reach enforcement?
- How many DNS lookups does our SPF record use?
- Is From on our domain, with the visitor's address in Reply-To?
- Where is the log showing each email was accepted or rejected, and who owns the mail service account and DNS access?
- If the mail service goes down, are enquiries still saved in the site database or CRM?
The last question matters most. An email is a notification, not a database. Save every enquiry in the site admin or a CRM first and email second, so a delivery problem never loses a customer. We cover that pattern in our guide to website lead capture and CRM integration. The credentials involved belong in a wider review; see our website security audit guide, and treat mail checks as part of a maintenance and support plan.
When choosing a team to build or repair a site, add "email delivery setup with test evidence" to the scope.
Working with Govindani Infotech
Govindani Infotech Pvt. Ltd. is a web design and development company in Pune. If your site's enquiry or order emails are going missing, we can review your mail path, DNS records and plugin settings, tell you which of the two problems above you have, and set up authenticated sending with a test report you can keep. See what we build on our website creation service page, and online store work on the e-commerce page.
To talk it through, message us on WhatsApp or use the contact page. It helps if you tell us your site platform, where your DNS is managed and which emails are going missing.
Frequently Asked Questions
Why do my website contact-form emails go to spam?
Usually because your hosting server sent the message without a matching SPF entry or DKIM signature, or because the form used the visitor's address as the From address. The receiving mailbox cannot confirm that your domain authorised the sender, so it treats the message as suspicious. Sending through an authenticated mail service with your own domain in From fixes most cases.
Do I need SPF, DKIM and DMARC if I only send a few emails a day?
Google's formal bulk-sender rules start at 5,000 messages a day to Gmail, so a small site is below that line. Even so, Google lists SPF or DKIM, TLS and valid DNS as expectations for all senders, and DMARC stops your domain being forged. All three take under two hours for a simple site.
Should I set DMARC to reject straight away?
No. Start with p=none and a reporting address, read the reports for a few weeks to find every legitimate sender, fix any that fail, then move to quarantine in steps and finally to reject. Going straight to reject can block mail from tools you forgot were sending as your domain.
What is the SPF 10-lookup limit?
The SPF standard, RFC 7208, allows an SPF check to cause at most 10 DNS-querying terms: include, a, mx, ptr, exists and redirect. Going over causes a permanent error and SPF may be treated as failed. Remove unused services or split sending across subdomains if you are close to the limit.
How can I check### How can I check whether SPF, DKIM and DMARC are passing?
Send a test email from your website to Gmail, open it, choose Show original from the three-dot menu and look for PASS beside SPF, DKIM and DMARC. Then test each real flow, such as forms, orders and OTPs, because they may take different paths.