Introduction
A customer fills in the contact form on your website, but the notification never arrives.
An order confirmation from your online store lands in spam.
A password reset email disappears altogether.
These problems are frustrating because the website may appear to be working perfectly.
The form submits successfully, WordPress says the message was sent, and there are no obvious errors.
But sending an email and having that email successfully delivered are not the same thing.
Modern email providers look at a wide range of signals before deciding whether a message should reach the inbox, go to spam or be rejected completely.
One of the most important parts of that process is email authentication.
For businesses investing in website design Currambine, this matters because websites frequently send important transactional email, including enquiries, order notifications, account messages and booking confirmations.
Three of the most important technologies involved are SPF, DKIM and DMARC.
The names sound technical, but the basic idea is straightforward: they help receiving mail systems work out whether an email claiming to come from your domain is legitimate.
Why Can a Genuine Business Email Go to Spam?
Email providers need to process enormous volumes of legitimate messages, spam, phishing and fraudulent mail.
They therefore evaluate many different signals when deciding what to do with an incoming message.
These can include:
- whether the sender is authenticated
- the reputation of the sending domain
- the reputation of the sending IP address
- whether the message resembles spam
- recipient engagement
- previous spam complaints
- sending volume and patterns
- technical DNS configuration
This means a legitimate message can still have delivery problems if its technical authentication is weak or incorrectly configured.
SPF, DKIM and DMARC are designed to help strengthen that authentication.
What Is Email Authentication?
Email authentication is a collection of technical methods that help receiving mail systems determine whether a message has genuinely been sent by an authorised source for a domain.
The three main technologies are:
- SPF – identifies which mail systems are authorised to send mail for a domain
- DKIM – adds a digital signature to the message
- DMARC – checks how SPF and DKIM relate to the visible From address and tells receiving servers how failures should be handled
These technologies are complementary.
Microsoft describes SPF, DKIM and DMARC as interdependent building blocks that work together to provide stronger protection against spoofing and phishing.
You can read Microsoft’s current explanation here: Email authentication in Microsoft 365.
What Is SPF?
SPF stands for Sender Policy Framework.
An SPF record is published in DNS as a TXT record.
It identifies the mail servers or services that are authorised to send email for a particular domain.
For example, a business may use:
- Microsoft 365 for normal staff email
- Mailgun for website notifications
- a CRM platform for automated messages
- a newsletter platform for marketing email
If those services send mail using the business domain, they may need to be accounted for in the domain’s email authentication configuration.
How Does SPF Work?
When a receiving mail server gets a message, it can check the sending server against the SPF policy published for the relevant domain.
If the sending source is authorised, SPF can pass.
If the sending source is not authorised, SPF can fail.
This helps prevent someone from simply using an unauthorised server and claiming to send mail on behalf of your domain.
SPF Does Not Authenticate the Visible From Address by Itself
This is an important limitation.
Email contains several different sender addresses behind the scenes.
The address that users see in their email application is usually the From address.
SPF primarily checks the envelope sender, also known as the MAIL FROM address.
Those two domains do not necessarily have to be the same for SPF alone to pass.
This is one of the reasons DMARC is important.
DMARC adds alignment requirements between the domain being authenticated and the domain visible to the recipient.
You Should Have Only One SPF Record
A common configuration mistake is adding a completely new SPF record every time another email service is introduced.
That is not how SPF is designed to work.
A domain should have one SPF TXT record that includes all authorised sending sources.
For example, if Microsoft 365 is already present and a website email provider needs to be added, the existing SPF policy normally needs to be updated rather than creating a second independent SPF record.
Multiple SPF records can result in a permanent SPF error.
Microsoft’s current documentation specifically warns that only one SPF record should exist for each domain or subdomain.
SPF Has a DNS Lookup Limit
SPF also has an important technical limit.
Evaluation must not require more than 10 DNS lookups.
Mechanisms such as:
- include
- a
- mx
- exists
- redirect
can contribute to that limit.
Nested includes can also add additional lookups.
This means an SPF record can become too complicated when a business keeps adding new sending platforms over time.
If the lookup limit is exceeded, SPF can fail with a permanent error.
Microsoft’s current SPF guidance explains this in more detail here: Set up SPF for Microsoft 365.
What Is DKIM?
DKIM stands for DomainKeys Identified Mail.
DKIM adds a cryptographic signature to outgoing email.
The sending service signs selected parts of the message using a private key.
A corresponding public key is published in DNS.
The receiving mail server can then use that public key to verify the signature.
This helps confirm that:
- the message was signed by a system associated with the domain
- important signed parts of the message were not altered after signing
DKIM Uses a Selector
DKIM records usually contain something called a selector.
This allows a domain to publish more than one DKIM key.
For example, a domain may have separate DKIM selectors for:
- Microsoft 365
- Google Workspace
- a marketing platform
- a transactional email provider
This is normal.
Unlike SPF, where there should generally be one SPF policy for the domain, multiple DKIM records can legitimately exist because each selector has its own DNS name.
DKIM Can Survive Some Types of Email Forwarding
SPF can sometimes fail when a message is forwarded because the forwarding server becomes the apparent sending server.
DKIM can be more resilient because the cryptographic signature can remain valid as long as the signed parts of the message are not changed.
This is one reason SPF and DKIM work better together than either technology alone.
DKIM Alone Is Not Enough
A DKIM signature does not automatically prove that the signing domain matches the address shown to the recipient.
A message could technically have a valid DKIM signature for one domain while displaying a different From domain.
DMARC addresses this problem through domain alignment.
What Is DMARC?
DMARC stands for Domain-based Message Authentication, Reporting and Conformance.
DMARC builds on SPF and DKIM.
It asks an important additional question:
Does the domain that passed authentication align with the domain the recipient sees in the From address?
DMARC also allows the domain owner to publish instructions explaining how messages that fail authentication should be treated.
Microsoft’s current DMARC documentation explains the relationship here: Set up DMARC in Microsoft 365.
What Does DMARC Alignment Mean?
Alignment is one of the most important concepts in modern email authentication.
Imagine a message that visibly says:
From: [email protected]
For DMARC to pass, at least one authentication method normally needs to authenticate a domain aligned with example.com.
That may happen through:
- SPF alignment
- DKIM alignment
Only one of those needs to pass with appropriate alignment for the message to pass DMARC.
Why Does Alignment Matter?
Without alignment, an attacker could potentially authenticate email using a domain they control while placing somebody else’s domain in the visible From field.
The technical authentication might pass for the attacker’s domain while the recipient sees the impersonated business.
DMARC was designed to connect authentication more closely with the domain visible to the person receiving the message.
DMARC Policies Can Be None, Quarantine or Reject
A DMARC record can specify a policy for messages that fail DMARC.
The three commonly used policies are:
- p=none – monitor failures without requesting enforcement
- p=quarantine – ask receiving systems to treat failed mail suspiciously, often by placing it in spam
- p=reject – ask receiving systems to reject failed messages
These policies allow businesses to move gradually from monitoring to enforcement.
Do Not Jump Straight to DMARC Reject Without Checking Your Senders
A strict DMARC policy can provide strong protection against domain spoofing.
But it needs to be implemented carefully.
A business may have legitimate mail being sent by systems nobody immediately remembers.
Examples include:
- website forms
- accounting software
- CRM systems
- booking platforms
- support software
- newsletter services
- ecommerce platforms
- old automated systems
If DMARC is moved directly to a strict reject policy before these systems are identified and correctly authenticated, legitimate mail may fail.
A sensible rollout often begins with monitoring and reviewing DMARC reports before moving toward stronger enforcement.
What Are DMARC Reports?
DMARC can tell receiving mail systems where to send reports about messages claiming to originate from the domain.
These reports can help identify:
- legitimate sending services
- misconfigured systems
- unexpected senders
- spoofing attempts
- SPF failures
- DKIM failures
The raw reports are usually XML files and can be difficult to read manually.
Businesses often use a DMARC reporting service to convert them into more understandable information.
DMARC Reports Can Reveal Forgotten Systems
One of the useful side effects of DMARC monitoring is discovering systems that are still sending email on behalf of the business.
For example, a company may find mail coming from:
- an old website server
- a former newsletter platform
- a booking application
- a customer management system
This can be valuable when cleaning up old infrastructure.
SPF, DKIM and DMARC Need to Work Together
It is tempting to think of these as three independent boxes that need to be ticked.
In reality, they are related.
A good email authentication setup typically aims for:
- a correct SPF record containing legitimate senders
- DKIM signing for major sending systems
- DMARC alignment and reporting
- a DMARC policy appropriate to the maturity of the setup
Microsoft explicitly recommends all three for effective protection against spoofing and phishing.
Google Also Expects Modern Email Authentication
Google has increasingly strengthened its requirements for mail delivered to Gmail accounts.
Google currently requires all senders to Gmail to use SPF or DKIM authentication.
For senders delivering more than 5,000 messages per day to Gmail accounts, Google requires SPF, DKIM and DMARC, along with additional sending requirements.
You can read Google’s current guidance here: Email sender guidelines.
Even businesses sending far less mail should still regard SPF, DKIM and DMARC as good practice.
Email Authentication Helps Protect Your Domain From Spoofing
Deliverability is only part of the reason these records matter.
Email authentication also helps protect the reputation of the business domain.
Without appropriate controls, attackers may attempt to send messages that appear to come from:
This can be used for:
- phishing
- fake invoices
- password theft
- business email compromise
DMARC enforcement can make direct domain spoofing more difficult.
Email Authentication Does Not Stop Every Type of Impersonation
SPF, DKIM and DMARC cannot stop someone registering a lookalike domain.
For example, an attacker may register a domain that visually resembles the genuine business name.
They can then configure SPF, DKIM and DMARC correctly for their own fraudulent domain.
Email authentication verifies domain relationships.
It does not determine whether the person behind a completely different domain is trustworthy.
Why Do WordPress Emails Often Have Problems?
WordPress itself can generate many types of email.
These may include:
- contact form notifications
- new user messages
- password resets
- WooCommerce order emails
- security alerts
- plugin notifications
Problems often arise when the website sends email directly from the web server without proper authentication or when the From address does not match the actual sending configuration.
This can make the email look less trustworthy to receiving systems.
The From Address Matters
A common mistake is configuring a contact form to use the visitor’s email address as the From address.
For example, a customer enters:
and the website then tries to send a message that appears to come directly from that Gmail address.
The website is not authorised to send email on behalf of gmail.com.
This can create authentication problems.
A better approach is generally to send the message from an address on the website’s own authenticated domain and place the customer’s address in the Reply-To field.
Use a Proper Transactional Email Service Where Appropriate
For important website email, it is often preferable to use a dedicated mail service rather than relying solely on the web server’s basic mail function.
Transactional email services are designed to handle application-generated mail and can provide:
- authenticated sending
- DKIM signing
- delivery logs
- bounce information
- suppression management
- reputation controls
Examples of use cases include:
- contact forms
- online orders
- account notifications
- booking confirmations
- password resets
The provider still needs to be correctly authorised for the business domain.
Website Hosting and Email Hosting Are Different Things
A business website may be hosted by one provider while staff email is hosted somewhere completely different.
For example:
- website hosted on a managed WordPress server
- staff email hosted by Microsoft 365
- website notifications sent through Mailgun
This is perfectly normal.
The DNS simply needs to describe the correct relationship between the different services.
Moving a website does not automatically mean changing business email.
DNS Changes Need to Be Made Carefully
SPF, DKIM and DMARC are configured through DNS.
DNS may also contain critical records for:
- the website
- Microsoft 365
- Google Workspace
- mail delivery
- Cloudflare
- verification services
Deleting or replacing records without understanding what they do can interrupt email or other services.
It is important to inspect the existing DNS configuration before making changes.
Do Not Replace an Existing SPF Record With a New One Blindly
This is one of the most common email DNS mistakes.
Imagine a domain already has SPF configured for Microsoft 365.
A new website service then provides another SPF value and instructs the business to add it.
If somebody creates a second SPF record instead of merging the required sender into the existing policy, SPF can become invalid.
The existing SPF record should be reviewed and updated carefully.
Do Not Assume Every Service Needs to Be Added to SPF
Some services authenticate primarily using DKIM or use a different envelope sender domain.
Always follow the specific provider’s current instructions.
Blindly adding every vendor to SPF can make the record unnecessarily complex and contribute to the 10-lookup limit.
Marketing Email and Transactional Email Are Different
A website enquiry confirmation and a monthly newsletter are both email, but they serve different purposes.
Transactional messages may include:
- order confirmations
- password resets
- account notifications
- booking confirmations
Marketing messages may include:
- newsletters
- promotions
- campaigns
- special offers
Businesses may choose different sending services or subdomains for these different types of mail.
Using Subdomains Can Help Separate Email Streams
Larger or more complex sending environments sometimes use subdomains such as:
- mail.example.com
- news.example.com
- notifications.example.com
This can help separate different sending systems and simplify authentication and reputation management.
It is not necessary for every small business, but it can be useful when several independent platforms send significant volumes of mail.
Authentication Does Not Guarantee Inbox Placement
Even a perfectly authenticated email can still go to spam.
Receiving systems also consider factors such as:
- domain reputation
- IP reputation
- spam complaint rates
- message content
- sending patterns
- recipient engagement
SPF, DKIM and DMARC improve trust and help establish legitimate sending, but they are not a guarantee that every message will reach the inbox.
Google specifically states that authentication improves delivery but does not guarantee it.
Spam Complaints Can Damage Deliverability
If recipients repeatedly mark messages as spam, email providers may become less willing to place future mail in the inbox.
This is particularly important for marketing email.
Businesses should avoid:
- buying mailing lists
- sending to people who did not expect the message
- making it difficult to unsubscribe
- continuing to mail disengaged or invalid addresses indefinitely
Good technical authentication cannot compensate for poor sending practices.
Email List Hygiene Matters
Repeatedly sending to invalid email addresses can also harm reputation.
Mailing systems should monitor:
- hard bounces
- repeated soft bounces
- complaints
- unsubscribes
Many professional email platforms automatically suppress addresses that repeatedly fail.
Reverse DNS Matters for Mail Servers
Businesses running their own outbound mail infrastructure need to consider additional technical requirements.
Google’s current sender guidelines require sending server IP addresses to have valid forward and reverse DNS records.
A reverse DNS record is often called a PTR record.
Most small businesses using Microsoft 365, Google Workspace or a professional transactional email provider do not manage this directly because the provider handles the sending infrastructure.
TLS Also Matters for Email Transport
Email authentication and email encryption are related but different concepts.
SPF, DKIM and DMARC help authenticate who is sending the message.
TLS helps encrypt email while it is transmitted between compatible mail servers.
Google includes TLS among its current sender requirements.
This is separate from the HTTPS encryption used when visiting a website.
Forwarding Can Complicate Authentication
Email forwarding can cause SPF problems because the message may arrive from the forwarding server rather than the original sending server.
DKIM can sometimes remain valid through forwarding, provided the message is not altered in a way that breaks the signature.
Modern mail systems may also use technologies such as ARC to preserve authentication information through intermediaries.
This is one reason diagnosing deliverability sometimes requires examining the full message headers rather than looking only at the visible From address.
Email Headers Can Show What Passed or Failed
Most email systems store authentication results in the message headers.
These can show information such as:
- SPF result
- DKIM result
- DMARC result
- sending IP address
- mail routing
- authentication domains
When troubleshooting a message that went to spam, the headers can provide valuable evidence about what actually happened.
Do Not Diagnose Email Deliverability From One Test Alone
Sending one message to your own inbox does not always provide the full picture.
A message may behave differently when sent to:
- Gmail
- Microsoft 365
- Yahoo
- a corporate mail gateway
- a custom domain
Delivery can also vary based on the recipient, sender reputation and previous interactions.
Technical testing should therefore look at several factors rather than simply asking whether one test email reached one inbox.
Website Emails Should Be Logged Where Possible
For important transactional messages, delivery logging can be extremely useful.
A mail provider may be able to show whether a message was:
- accepted
- delivered
- deferred
- bounced
- rejected
- suppressed
This helps distinguish between:
- WordPress failing to generate the message
- the sending provider rejecting it
- the recipient server refusing it
- the message being delivered but classified as spam
A Successful WordPress Form Submission Does Not Prove Email Was Delivered
This is an important distinction.
A contact form can display:
“Thank you. Your message has been sent.”
while the notification email still fails later in the delivery chain.
The form has successfully passed the data to WordPress or the sending system.
That does not necessarily mean the recipient mail server accepted the message.
Our article Why Contact Forms Fail and How to Create a Better Website Enquiry Experience looks at the wider reliability of website enquiries.
Important Website Enquiries Should Not Depend on One Email Alone
Where enquiries are commercially important, it can be sensible to retain form submissions securely within the website or another system as well as sending the notification email.
This provides a second source of information if an email is missed.
The business must still consider privacy, access control and retention of the stored information.
Monitor Before Tightening DMARC
A strong DMARC policy is a worthwhile goal for many business domains.
But the safest path is generally:
- identify legitimate senders
- configure SPF
- configure DKIM
- publish DMARC
- review reporting
- correct authentication failures
- increase enforcement appropriately
This reduces the risk of blocking legitimate business email while improving protection over time.
Parked and Unused Domains Need Protection Too
A domain that does not send email can still potentially be impersonated.
For unused domains, email authentication policies can often be configured specifically to indicate that no legitimate mail should originate from them.
This is particularly relevant for:
- old brand domains
- defensive registrations
- unused variations
The correct setup depends on whether any genuine service still uses the domain.
Email Authentication Should Be Reviewed When You Change Providers
Changing any major mail-related service can require DNS changes.
This may happen when moving:
- from Google Workspace to Microsoft 365
- between newsletter platforms
- to a new website email provider
- between CRM systems
- to a new transactional mail platform
Old sending services should be removed once they are no longer required.
Leaving obsolete providers authorised indefinitely makes the configuration harder to understand and maintain.
Changing Website Hosting Does Not Mean You Should Replace Email DNS
Website migrations deserve particular care.
If a website is moved to a new server, the business email may still need to remain completely unchanged.
MX, SPF, DKIM and DMARC records should not be altered merely because the website’s A record or nameservers are changing unless the migration plan specifically requires it.
This is one reason complete DNS records should be documented before major changes.
Cloudflare Can Host Email DNS Without Hosting the Email
Cloudflare is often used to manage DNS for a website.
That does not mean Cloudflare necessarily provides the business’s email service.
The DNS zone can contain records pointing mail to:
- Microsoft 365
- Google Workspace
- Zoho
- Mailgun
- other providers
The DNS provider and the email provider are separate roles.
Do Not Proxy Normal Mail DNS Records Through Cloudflare
Cloudflare’s proxy is designed primarily for supported web traffic.
Normal mail-related hostnames and MX targets generally need to remain DNS-only unless a specific Cloudflare product says otherwise.
Incorrect proxy settings can interfere with services that expect to connect directly to the mail server.
DNS Changes Can Take Time to Propagate
DNS records have a time-to-live, often abbreviated to TTL.
Resolvers may cache existing records until that period expires.
This means an email authentication change may not appear everywhere immediately.
When troubleshooting immediately after a DNS change, check whether the new records are actually visible publicly before assuming the mail service itself is broken.
Use Real DNS Checks Rather Than Looking Only at the Control Panel
A DNS provider may show that a record has been entered successfully.
That does not necessarily prove the public internet is seeing the intended value.
Useful checks can include:
- DNS lookup tools
- email message headers
- provider verification tools
- DMARC reports
Testing the live DNS result is more reliable than assuming the control panel entry is correct.
What Should a Small Business Have in Place?
A practical modern email authentication setup will usually include:
- one valid SPF policy containing appropriate sending sources
- DKIM enabled for major outbound mail systems
- a DMARC record
- DMARC reporting
- appropriate alignment
- a plan for increasing DMARC enforcement where suitable
The exact records depend on which services the business actually uses.
Do not copy records from another business or from an old tutorial.
What Should You Check If Website Emails Are Going to Spam?
Start by checking:
- which system actually sends the email
- the visible From address
- the Reply-To address
- SPF authentication
- DKIM authentication
- DMARC authentication
- the message headers
- sending reputation
- delivery logs
- whether recipients are marking messages as spam
A deliverability problem is easier to solve once you know which stage is actually failing.
Do Not Keep Changing DNS Randomly Until Email Works
Random DNS changes can make an already complicated problem worse.
Before modifying anything, identify:
- the current email provider
- all legitimate senders
- the existing SPF record
- existing DKIM selectors
- the current DMARC policy
Then make deliberate changes based on the provider’s current documentation.
Good Email Authentication Supports Business Credibility
Customers may never know what SPF, DKIM or DMARC mean.
But they notice when:
- order confirmations do not arrive
- website replies go to spam
- fake emails appear to come from the business
- password reset emails disappear
Email reliability is therefore part of the broader customer experience.
For businesses using web design Currambine, website design Currambine or web development Currambine services, website email should be treated as an important technical system rather than an afterthought.
SPF, DKIM and DMARC cannot guarantee perfect inbox placement, but together they provide a much stronger foundation for legitimate email and help protect the domain from direct spoofing.
PrimeSites Digital helps businesses with WordPress website email, DNS configuration, transactional email, Cloudflare, SPF, DKIM, DMARC and ongoing technical support.
If important website emails are disappearing or landing in spam, get in touch with PrimeSites Digital or book a free chat.
