Article
Email Deliverability for Web Apps: SPF, DKIM and DMARC Explained
Order confirmations, booking reminders, password resets and invoices are essential emails sent by web apps. When they land in spam or never arrive, customers get confused, support requests pile up and trust drops. Many small business sites send email straight from the web server with no authentication, which is a common cause of these problems.
This guide explains the email authentication records that matter, SPF, DKIM and DMARC, plus practical steps for developers and business owners to improve deliverability.
Why Web App Emails Go to Spam
- Sending directly from a web server without proper authentication
- Using a "from" address on a domain that has not authorised the server to send
- Shared hosting IP addresses with poor reputation from other users
- Missing or incorrect DNS records for email authentication
- Content that looks like spam, such as misleading subject lines or only images
Major mailbox providers have tightened requirements for senders in recent years, particularly for bulk senders, and generally expect authentication to be in place. Check the current sender guidelines published by Google and Yahoo if you send at volume.
Contact forms are a special case. If your form sends an email "from" the visitor's address, receiving servers may reject it because your server is not authorised for their domain. Send from your own domain and put the visitor's address in the reply-to field instead.
SPF, DKIM and DMARC in Plain Language
SPF is a DNS record listing which servers are allowed to send email for your domain. If an email comes from a server not on the list, receivers may treat it with suspicion.
DKIM adds a digital signature to each email, verified using a public key published in your DNS. It proves the message was sent by an authorised system and was not altered in transit.
DMARC tells receivers what to do if SPF or DKIM checks fail, such as monitor, quarantine or reject, and can send you reports about who is sending email using your domain.
Key takeaway: SPF says who may send, DKIM proves the message is genuine, and DMARC sets the policy and gives you visibility.
Only one SPF record should exist per domain. Adding a second SPF record instead of editing the existing one is a very common mistake that causes authentication to fail.
Use a Proper Sending Service
Instead of sending from the web server directly, use a transactional email service or your email provider's SMTP relay. These services manage sending reputation, provide DKIM signing and offer logs showing whether emails were delivered, bounced or marked as spam.
- Choose a reputable transactional email provider.
- Verify your domain and add the SPF and DKIM records they provide.
- Configure your app or CMS to send through their API or SMTP.
- Use a consistent from address, such as orders@yourdomain.com.my.
- Monitor bounces and complaints in the provider dashboard.
Separate transactional emails from marketing newsletters where possible, so a marketing complaint does not affect password reset delivery.
Rolling Out DMARC Safely
Start DMARC in monitoring mode, which collects reports without affecting delivery. Review the reports to find all legitimate services sending on your behalf: your email provider, website, CRM, invoicing system and marketing tools. Add them to SPF and set up DKIM where needed.
Once all legitimate senders pass, move gradually to quarantine and then reject policies. This also protects your domain from being used in phishing emails that impersonate your business. DNS changes should be planned carefully; see our guide to domains and DNS for business owners.
Content and Testing Habits
Good authentication is essential, but content matters too. Use clear subject lines, include a plain text version, avoid link shorteners and keep a reasonable balance of text and images. Make sure transactional emails include your business name and contact details.
Test emails before launch by sending to accounts on major providers such as Gmail and Outlook, and check spam folders. Many tools can show whether SPF, DKIM and DMARC pass for a received message. Add delivery checks to your pre-launch QA checklist.
Keep monitoring after launch. A change of hosting, a new tool or an expired DNS record can quietly break delivery months later.
Watch bounce rates too. Repeatedly sending to invalid addresses harms reputation, so clean lists and validate email addresses at sign-up.
FAQ
Do I need all three records?
For reliable delivery and protection against spoofing, yes. SPF and DKIM authenticate; DMARC enforces and reports.
Can I send from my Gmail address through my app?
It is better to send from your own domain through an authorised service, with proper authentication.
Why do some emails still go to spam?
Reputation, content and recipient behaviour also matter. Monitor reports and improve gradually.
Reliable web app email depends on authentication and good sending practice. Use a proper sending service, publish correct SPF and DKIM records, roll out DMARC from monitoring to enforcement and test delivery regularly.