A sent email is not necessarily a delivered email. Between clicking Send and reaching the inbox, the receiving provider evaluates your domain identity, sending IP, reputation, content and recipient behaviour. If one part is wrong, a legitimate message may land in spam or be rejected with an SMTP error.
Email delivery has three layers
- Technical identity: DNS, SPF, DKIM, DMARC, PTR and a valid server hostname.
- Reputation: historic behaviour of the domain and IP, complaints, bounces and blocklists.
- Message and behaviour: content, links, sending rate, consent and recipient engagement.
A perfect SPF record cannot repair a purchased list. Conversely, a useful newsletter can still fail when authentication is missing.
SPF: which systems may send for you?
SPF is a TXT record listing authorised senders. Include not only your mail server but also accounting software, CRM, newsletter services, web forms and ticketing systems. Publish one SPF record and respect the limit of ten DNS lookups. Leaving obsolete includes in place adds risk and complexity.
DKIM: a verifiable digital signature
DKIM cryptographically signs outgoing messages. The receiving server retrieves the public key from DNS and verifies that relevant headers and content were not altered. Use a 2048-bit key where supported, rotate keys carefully and ensure every active service signs with your domain.
DMARC: alignment, policy and reporting
DMARC checks whether the visible From domain aligns with a domain authenticated by SPF or DKIM. A sensible rollout normally begins with p=none and reporting. Map legitimate senders before moving gradually to quarantine and potentially reject. Enforcing rejection before discovery can break invoices, forms or newsletters.
Reverse DNS and server identity
The sending IP should have a PTR record pointing to a valid hostname. That hostname needs an A or AAAA record resolving back to the same IP. The SMTP banner or EHLO name should also make sense. Forward-confirmed reverse DNS is not an inbox guarantee, but a missing or generic PTR is a strong warning signal.
Reputation is built through behaviour
- Send only to recipients who expect the message.
- Remove hard bounces and persistently inactive addresses.
- Warm up new domains and IPs gradually.
- Use a recognisable sender and working reply address.
- Provide an obvious, simple unsubscribe route for bulk mail.
- Avoid sudden volume spikes and contain compromised accounts quickly.
- Monitor complaints and Gmail Postmaster Tools when volume warrants it.
Web forms: an often-forgotten source
Do not make a contact form send as if the visitor were the sender on your domain. Use an address on your own domain in From and put the visitor’s address in Reply-To. Prefer authenticated SMTP and protect forms with rate limiting, CAPTCHA or honeypots.
A practical diagnostic plan
- Read the entire bounce or SMTP response; its status often explains the rejection.
- Inspect received headers and check SPF, DKIM and DMARC results.
- Validate A, MX, TXT and PTR records independently.
- Test one normal plain message without an attachment or tracking link.
- Compare delivery across several mailbox providers.
- Check logs for authentication failures, unusual volume and compromised accounts.
- Make targeted changes; repeatedly resending the same message can hurt reputation further.
Frequently asked questions
Do SPF, DKIM and DMARC guarantee the inbox?
No. They prove identity and help prevent spoofing, but reputation, consent, content and recipient behaviour still matter.
Can I publish several SPF records?
No. Combine authorised sources into one record. Multiple SPF records can produce a permanent error.
Why does mail from my website disappear?
WordPress may be using local mail without suitable authentication, the From address may be wrong or the form may be abused. Authenticated SMTP and correct alignment solve many of these failures.
Would you like your domain and mail flow reviewed? Contact Gigatech for a technical check of DNS, authentication and server configuration.
Source: Google email sender guidelines.
