DEV Community: GlitchGuard

SPF, DKIM and DMARC: A Practical Email Authentication Guide

GlitchGuard — Sun, 09 Aug 2026 16:48:19 +0000

SPF, DKIM and DMARC: A Practical Email Authentication Guide

Modern businesses rarely send email from only one system.

A typical domain may send mail through:

Google Workspace or Microsoft 365
a CRM
an ecommerce platform
a marketing automation tool
a support desk
a booking system
a transactional email provider
password reset infrastructure
billing software
website contact forms

All of those systems may send messages that appear to come from the same business domain.

So how does a receiving mail server determine whether those messages are legitimate?

That is where SPF, DKIM, and DMARC come in.

They are related technologies, but they solve different problems.

A useful mental model is:

SPF   = Is this sending infrastructure authorized?

DKIM  = Does this message contain a valid cryptographic signature?

DMARC = Does successful authentication align with the domain
        visible to the recipient?

DMARC then adds policy and reporting on top of those authentication results.

Let's break down how the three systems work.

1. SPF: Sender Authorization

SPF stands for Sender Policy Framework.

It is published as a DNS TXT record and describes which mail infrastructure is authorized to send on behalf of a domain.

A simplified SPF record might look like this:

v=spf1 include:_spf.examplemail.com -all

A receiving mail server can evaluate the SPF policy when it receives a message.

At a high level, it asks:

Is the system delivering this message included in the sending policy for the relevant domain?

If yes, SPF can pass.

If not, SPF may fail.

Common SPF mechanisms

An SPF record may contain mechanisms such as:

ip4:
ip6:
a
mx
include:
exists:

It also ends with a qualifier such as:

-all
~all
?all

The correct policy depends on the organization's mail architecture.

Do not copy an SPF record from another domain without understanding what it authorizes.

2. Common SPF Problems

SPF configurations often become messy as businesses add more email providers.

Common problems include:

no SPF record at all
multiple SPF records
old providers that were never removed
missing current sending services
malformed syntax
excessive DNS lookups
unnecessary nested include mechanisms
misunderstanding what SPF actually authenticates

Multiple SPF records

One common mistake is creating a second SPF record whenever a new provider is added.

For example:

v=spf1 include:_spf.google.com -all

and separately:

v=spf1 include:mail.exampleprovider.com -all

Publishing multiple independent SPF policies for the same hostname can cause SPF evaluation problems.

The legitimate services should normally be represented within one valid policy.

3. SPF Does Not Authenticate the Visible From Address by Itself

This is an important distinction.

Consider an email displaying:

From: sales@example.com

The recipient sees:

example.com

But SPF does not simply inspect that visible From header.

SPF evaluates the domain associated with the SMTP envelope.

That means SPF can technically pass while the domain authenticated through SPF differs from the domain visible to the recipient.

This is one reason DMARC exists.

4. SPF and Forwarding

SPF can also be affected by forwarding.

Imagine:

Sender
  ↓
Original Mail Server
  ↓
Forwarding Server
  ↓
Recipient

The recipient may see the forwarding server as the infrastructure delivering the message.

That server may not be authorized by the original sender's SPF record.

The result can be an SPF failure even though the original sender was legitimate.

DKIM often survives forwarding more effectively when the message is not modified in a way that breaks its signature.

5. DKIM: Cryptographic Message Authentication

DKIM stands for DomainKeys Identified Mail.

Instead of primarily checking the sending infrastructure, DKIM adds a cryptographic signature to the email.

The sending system has a private key.

The corresponding public key is published in DNS.

A receiving server can use the public key to verify the message signature.

The architecture looks roughly like this:

Sending System
     |
     | Private Key
     v
Create DKIM Signature
     |
     v
Email Message
     |
     v
Receiving Server
     |
     | DNS lookup
     v
Public DKIM Key
     |
     v
Verify Signature

If the verification succeeds, DKIM passes.

6. DKIM Selectors

DKIM uses something called a selector.

A DNS lookup may look like:

selector1._domainkey.example.com

The selector allows a domain to maintain multiple DKIM keys.

This is useful for:

key rotation
multiple sending providers
different applications
migration between email systems

An email's DKIM-Signature header tells the receiving server which signing domain and selector to query.

A simplified header may contain fields such as:

d=example.com;
s=selector1;

Where:

d = signing domain
s = selector

7. Common DKIM Problems

Typical DKIM failures include:

DKIM was never enabled
the public key is missing from DNS
the selector is incorrect
the public/private keys no longer match
a provider rotated its key but DNS was not updated
the message was modified after signing
the DKIM signature is malformed
the signing domain does not align for DMARC

DKIM configuration should therefore be verified publicly rather than assuming that clicking "Enable DKIM" inside an email provider completed the DNS configuration correctly.

8. DKIM Can Pass While DMARC Still Fails

This surprises many people.

Suppose the recipient sees:

From: support@example.com

But the message carries a valid DKIM signature from:

d=emailprovider.net

The DKIM signature itself may be completely valid.

DKIM therefore passes.

But the signing domain:

emailprovider.net

does not necessarily align with:

example.com

That particular DKIM authentication result may therefore fail to satisfy DMARC.

Again, this is where domain alignment becomes important.

9. DMARC: Alignment, Policy and Reporting

DMARC stands for:

Domain-based Message Authentication, Reporting and Conformance

DMARC builds on SPF and DKIM.

Its major contribution is connecting technical authentication with the domain that the recipient actually sees.

Suppose a message displays:

From: billing@example.com

The visible From domain is:

example.com

DMARC asks whether successful SPF or DKIM authentication aligns with that domain.

The simplified logic is:

                 Email arrives
                       |
                       v
              Check SPF authentication
                       |
                       v
              Does SPF domain align?
                    /      \
                  Yes       No
                   |         |
                   |         v
                   |    Check DKIM
                   |         |
                   |         v
                   |   Does DKIM align?
                   |       /     \
                   |     Yes      No
                   |      |        |
                   v      v        v
                 DMARC PASS      DMARC FAIL

A message does not necessarily require both SPF and DKIM alignment.

One valid aligned authentication path can be enough for DMARC to pass.

10. SPF Alignment

For SPF to satisfy DMARC:

SPF must pass.
The SPF-authenticated domain must align with the visible From domain.

Example:

Visible From:
example.com

SPF-authenticated domain:
example.com

That is aligned.

A subdomain relationship may also align depending on the DMARC alignment mode.

11. DKIM Alignment

For DKIM to satisfy DMARC:

The DKIM signature must pass.
The DKIM signing domain must align with the visible From domain.

Example:

Visible From:
example.com

DKIM d=:
example.com

Aligned.

Another example:

Visible From:
example.com

DKIM d=:
emailvendor.net

DKIM may still pass technically.

But that signature may not satisfy DMARC alignment.

12. DMARC Alignment Modes

DMARC supports relaxed and strict alignment.

Relaxed alignment

A subdomain can align with the organizational domain.

For example:

mail.example.com

may align with:

example.com

Strict alignment

The domains must match exactly.

DMARC records can control this with settings such as:

aspf=s
adkim=s

Where:

aspf = SPF alignment mode
adkim = DKIM alignment mode

Most organizations should understand the consequences before changing alignment modes.

13. A Basic DMARC Record

A simple DMARC record could look like:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

The record is normally published at:

_dmarc.example.com

Important fields include:

v=

Protocol version.

p=

Policy.

rua=

Aggregate report destination.

Other options may control subdomain policy, alignment behavior, percentages, and additional reporting behavior.

14. DMARC Policies

There are three main policy levels.

`p=none`

Example:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

This is primarily a monitoring policy.

DMARC authentication is evaluated, but the domain is not requesting quarantine or rejection of failing messages.

This is often useful when deploying DMARC initially.

`p=quarantine`

Example:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

The domain asks receiving systems to treat DMARC-failing mail with greater suspicion.

Depending on the receiver, that may mean spam-folder placement or other restricted handling.

`p=reject`

Example:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

The domain requests rejection of messages that fail DMARC.

This provides stronger protection against certain forms of domain spoofing.

However, moving immediately to p=reject without understanding every legitimate sender can disrupt real email.

15. Why DMARC Reporting Matters

DMARC reporting can help reveal who is sending mail associated with your domain.

Reports may show infrastructure belonging to:

Google Workspace
Microsoft 365
CRM systems
ecommerce platforms
marketing tools
support platforms
transactional providers
old forgotten vendors
unauthorized senders

That visibility is extremely useful.

A business may discover that an application installed three years ago is still sending mail.

Or that a legitimate provider was never configured correctly.

Or that unknown infrastructure is attempting to use the domain.

16. Inventory Every Email Sender

Before making major authentication changes, build an inventory.

For example:

Corporate email
Google Workspace

Marketing
Klaviyo

CRM
HubSpot

Transactional email
Amazon SES

Support
Zendesk

Website forms
Application backend

Billing
Stripe-related notifications

Ecommerce
Shopify

Then determine how each service uses:

SPF
DKIM
custom return paths
custom DKIM domains
DMARC alignment

This is much safer than editing DNS reactively.

17. Authentication Flow Example

Consider this message:

From: orders@example.com

The business sends through an ecommerce email provider.

SPF

The provider's infrastructure is authorized.

Result:

SPF: PASS

DKIM

The provider signs with:

d=example.com

Result:

DKIM: PASS

DMARC

Visible From:

example.com

DKIM signing domain:

example.com

Aligned.

Result:

DMARC: PASS

Now consider another message:

From: orders@example.com

DKIM signs using:

d=vendor-mail.net

Result:

DKIM: PASS

But that domain may not align with:

example.com

If SPF also fails alignment:

DMARC: FAIL

This illustrates why checking only "DKIM passed" is not enough.

18. Common Authentication Mistakes

Multiple SPF records

Combine legitimate sending sources into one valid SPF policy instead of publishing multiple independent SPF records.

Missing DKIM selectors

Verify that every configured selector actually resolves in public DNS.

Passing SPF but failing DMARC

Inspect the SPF-authenticated domain and compare it with the visible From domain.

Passing DKIM but failing DMARC

Inspect the DKIM d= domain and check alignment.

Publishing DMARC and ignoring reports

DMARC provides visibility only when the organization actually monitors its sending environment.

Enforcing too early

Do not jump directly from no DMARC to aggressive rejection without identifying legitimate senders.

Forgetting application email

Authentication audits often focus only on employee mailboxes.

Do not forget:

password resets
invoices
order receipts
shipping notifications
support replies
booking confirmations
website forms
CRM automation

19. SPF, DKIM and DMARC Do Not Guarantee Inbox Placement

Passing all three is important.

But email authentication is not equivalent to deliverability.

Mailbox providers may also consider:

sender reputation
IP reputation
domain reputation
complaint rates
spam reports
recipient engagement
list quality
bounce rates
sending volume
sending consistency
message content
unsubscribe behavior

Think of authentication as identity verification.

It gives receiving systems stronger evidence that the message legitimately relates to the claimed domain.

It does not force the receiving system to place the message in the inbox.

20. Practical Email Authentication Checklist

Use this when reviewing a business domain:

[ ] Inventory every email sending service
[ ] Confirm an SPF record exists
[ ] Confirm only one valid SPF policy exists
[ ] Remove obsolete SPF senders
[ ] Check SPF DNS lookup complexity
[ ] Enable DKIM for each supported provider
[ ] Verify DKIM selectors publicly
[ ] Check DKIM signing domains
[ ] Publish a valid DMARC record
[ ] Configure aggregate reporting
[ ] Verify SPF alignment
[ ] Verify DKIM alignment
[ ] Monitor before increasing enforcement
[ ] Review transactional email systems
[ ] Review marketing platforms
[ ] Review support systems
[ ] Remove providers that are no longer used
[ ] Retest after DNS or provider changes

21. Useful GlitchGuard Checks

You can inspect individual authentication components using:

SPF Checker:

https://getglitchguard.com/tools/spf-checker

DKIM Checker:

https://getglitchguard.com/tools/dkim-checker

DMARC Checker:

https://getglitchguard.com/tools/dmarc-checker

MX Lookup:

https://getglitchguard.com/tools/mx-lookup

The tools are useful for inspecting what DNS currently publishes before changing records.

Final Takeaway

SPF, DKIM, and DMARC become much easier to understand when each technology has a separate job.

SPF
→ Which infrastructure is authorized?

DKIM
→ Is there a valid cryptographic signature?

DMARC
→ Does valid authentication align with the visible From domain?

DMARC Policy
→ What should receivers do when authentication fails?

DMARC Reporting
→ What sending activity should the domain owner know about?

The biggest mistake is treating email authentication as a checkbox.

A modern business may have many legitimate sending systems.

You need to understand the entire sending environment.

Then authenticate it deliberately.

Original GlitchGuard guide:

https://getglitchguard.com/blog/spf-dkim-dmarc-explained?utm_source=devto&utm_medium=syndication&utm_campaign=email_authentication

Check your SPF record:

https://getglitchguard.com/tools/spf-checker

Check your DKIM record:

https://getglitchguard.com/tools/dkim-checker

Check your DMARC policy:

https://getglitchguard.com/tools/dmarc-checker

Robots.txt vs Noindex: A Practical Guide for Developers

GlitchGuard — Wed, 22 Jul 2026 16:58:46 +0000

robots.txt and noindex operate at different stages of the search-engine processing pipeline.

Treating them as interchangeable can create URLs that remain visible without useful snippets, directives that crawlers cannot read, and important pages that disappear from crawling.

Simplified crawl-to-index process

A search engine generally needs to:

Discover the URL.
Check robots.txt.
Fetch the page if crawling is allowed.
Read the response status, headers, and HTML.
Process robots directives.
Evaluate canonical signals.
Decide whether the URL is eligible for indexing.
Consider the URL for search results.

robots.txt operates before the page is fetched.

noindex is processed after the page is fetched.

That distinction explains why blocking a page can prevent its noindex instruction from being processed.

1. Robots.txt controls crawler access

Example:

User-agent: *
Disallow: /admin/
Disallow: /internal-search/

Sitemap: https://example.com/sitemap.xml

Typical uses include:

administrative routes
internal search pages
crawl traps
faceted navigation
duplicate parameter combinations
generated URL patterns
low-value crawler paths

Robots.txt is not an access-control mechanism.

A disallowed route may still be publicly accessible.

The URL may also remain discoverable through links, sitemaps, previous crawling, or browser activity.

2. Noindex controls search inclusion

HTML implementation:

<meta name="robots" content="noindex, follow">

HTTP-header implementation:

X-Robots-Tag: noindex

The HTTP-header method can be useful for non-HTML resources such as certain PDFs or generated files.

Common use cases include:

checkout pages
shopping carts
account pages
login routes
thank-you pages
internal search pages
preview routes
low-value utility pages

The crawler must be able to fetch the resource before it can process the directive.

3. The blocked-noindex conflict

Consider this robots.txt configuration:

User-agent: *
Disallow: /campaign-preview/

The HTML page contains:

<meta name="robots" content="noindex, follow">

The crawler checks robots.txt before requesting the page.

Because the URL is disallowed, the crawler may never fetch the HTML and may never discover the noindex instruction.

For an accessible page that should not appear in search, a cleaner configuration is:

allow crawling
return noindex
remove the URL from the sitemap
reduce unnecessary internal discovery
verify the live response through Search Console

4. Do not put unsupported noindex rules inside robots.txt

Do not rely on this:

User-agent: *
Noindex: /example/

Use a supported page-level robots meta tag or an X-Robots-Tag response header.

5. Canonical tags solve duplicate selection

Example:

<link rel="canonical" href="https://example.com/preferred-url">

A canonical tag helps consolidate duplicate or substantially similar URLs.

It does not mean that the current page can never appear in search.

Canonical signals may be evaluated alongside:

redirects
internal links
sitemap entries
content similarity
URL consistency
external links

Use a permanent redirect when the old URL no longer needs to remain independently accessible.

6. Redirects should be direct

Avoid redirect chains:

/old-a → /old-b → /old-c → /new

Prefer direct redirects:

/old-a → /new
/old-b → /new
/old-c → /new

Use 301 or 308 responses for permanent URL replacement.

7. Missing pages require real status codes

A missing route should not return:

HTTP 200
homepage content
homepage metadata
canonical /

That can create a soft 404.

Return a genuine 404 or 410, or redirect to a genuinely relevant replacement when one exists.

8. Private content requires authentication

Neither robots.txt nor noindex protects sensitive information.

Private routes should use:

authentication
authorization
server-side permission checks
appropriate 401 or 403 responses
secure session validation
protection against unauthenticated HTML exposure

Do not expose confidential route names in robots.txt and assume they are secure.

9. Keep noindex URLs out of the sitemap

Sitemaps should normally contain URLs that are:

canonical
public
indexable
returning successful responses
intended to appear in search

Avoid including:

noindex pages
redirects
deleted pages
soft 404s
preview routes
draft routes
duplicate parameters
non-canonical variants

Decision table

Goal	Recommended method
Reduce crawling of URL patterns	robots.txt
Exclude an accessible page from search	noindex
Consolidate duplicate URLs	canonical
Permanently replace an old URL	301 or 308 redirect
Protect confidential content	authentication and authorization
Remove a missing resource	404 or 410

Audit checklist

[ ] Fetch the live production robots.txt file
[ ] Review every Allow and Disallow rule
[ ] Confirm the production sitemap URL
[ ] Search shared layouts for inherited noindex tags
[ ] Inspect page-level robots metadata
[ ] Inspect X-Robots-Tag response headers
[ ] Confirm noindex pages remain crawlable
[ ] Remove noindex pages from sitemaps
[ ] Verify canonical consistency
[ ] Test HTTP, HTTPS, www, and trailing-slash variants
[ ] Test old URLs for direct redirects
[ ] Test invalid routes for genuine 404 responses
[ ] Confirm private pages require authentication
[ ] Compare raw HTML with rendered HTML

The objective is not to add every possible directive.

The objective is to choose the directive that matches the actual requirement.

Read the complete GlitchGuard guide

The full guide includes detailed examples, comparison tables, common implementation mistakes, and a structured technical SEO audit.

https://getglitchguard.com/blog/robots-txt-vs-noindex?utm_source=devto&utm_medium=syndication&utm_campaign=robots_noindex

Test your robots.txt file

https://getglitchguard.com/tools/robots-txt-tester?utm_source=devto&utm_medium=syndication&utm_campaign=robots_noindex

Check your XML sitemap

https://getglitchguard.com/tools/sitemap-checker?utm_source=devto&utm_medium=syndication&utm_campaign=robots_noindex

Why Mobile Pages Load Slowly: A Practical Performance

GlitchGuard — Sat, 11 Jul 2026 19:07:19 +0000

Why Mobile Pages Load Slowly: A Practical Performance Checklist

A page that performs well on a developer’s desktop can still be slow for real mobile users.

Local testing may involve:

a fast processor
strong Wi-Fi
cached static assets
short network distance
an already-warmed application

A first-time mobile visitor may have none of those advantages.

The following checklist focuses on the most common areas worth inspecting before attempting isolated micro-optimizations.

1. Test representative URLs

Do not evaluate only the homepage.

Test:

paid landing pages
product pages
collection pages
service pages
content pages
forms and checkout
routes with maps, video, reviews, or third-party widgets

Use PageSpeed Insights for URL-level analysis and review field data when it is available.

Separate laboratory diagnostics from real-user measurements. Laboratory data helps reproduce issues. Field data shows what actual users have experienced.

2. Identify the LCP element

Largest Contentful Paint is commonly affected by the primary hero image, banner, heading block, or large content container.

Review:

whether the resource is discovered early
whether the image is oversized
whether it is lazy-loaded incorrectly
whether CSS or JavaScript delays rendering
whether server response delays discovery
whether a client-rendered component inserts it late

Potential improvements:

resize the source image
use a modern image format
preload only genuinely critical resources
avoid lazy-loading the primary LCP image
reduce render-blocking dependencies
return useful HTML early

3. Audit responsive images

A mobile viewport should not automatically download the same oversized image used by a large desktop display.

Review:

srcset
sizes
intrinsic image dimensions
compression level
format
hidden background images
below-the-fold lazy loading

Also set explicit width and height values to reduce layout instability.

4. Reduce JavaScript execution

A page can be visually present but unresponsive because the main thread is busy.

Inspect:

bundle size
unused JavaScript
long tasks
hydration cost
duplicate dependencies
page-builder output
global scripts that are only required on specific routes

Potential improvements:

code split large bundles
remove unused packages
defer non-critical modules
yield during long tasks
simplify expensive event handlers
reduce unnecessary client rendering

5. Audit applications and plugins

CMS plugins and ecommerce applications often inject their own scripts and styles.

Typical examples include:

reviews
chat
popups
heatmaps
social proof
page builders
product recommendations
analytics integrations
A/B testing

Remove unused integrations and verify that uninstalling them actually removes their storefront code.

Measure before and after introducing new applications.

6. Review third-party scripts

Third-party scripts can affect loading, responsiveness, network contention, and privacy controls.

Audit:

advertising pixels
analytics
tag managers
maps
video embeds
chat widgets
session recording
consent platforms
social embeds

Questions to ask:

Must this run on every page?
Can it load after the primary content?
Is an old tag still active?
Is the same event being collected by multiple tools?
Can a heavy embed be replaced by a lightweight placeholder?

7. Investigate server response

A slow initial response delays the discovery of every page resource.

Review:

hosting capacity
cache hit rate
database performance
middleware
authentication checks
redirect chains
uncached dynamic rendering
geographic distance

A CDN can help with static assets, but it does not automatically solve slow application code or database work.

8. Optimize fonts and CSS

Review:

the number of font families
the number of weights
font file size
render-blocking stylesheets
unused theme or page-builder CSS
icon libraries
late font swaps

Keep the critical visual system small.

Do not preload every font file. Preload only what is genuinely required during the initial render.

9. Check caching strategy

Verify:

browser caching for versioned assets
page caching where safe
CDN caching
cache invalidation
personalized route exclusions
checkout and account behavior

Avoid applying aggressive caching blindly to private, dynamic, or transactional pages.

10. Reduce layout instability

Common CLS causes include:

images without dimensions
ads or banners inserted late
cookie notices changing page height
fonts changing text size
dynamic widgets added above existing content
sticky elements appearing after load

Reserve space for dynamic elements and avoid inserting content above what the user is already viewing.

Final checklist

Test real landing pages, not only the homepage
Inspect field and laboratory data separately
Identify the LCP element
Serve responsive, compressed images
Remove unused JavaScript
Break up long tasks
Audit apps and plugins
Reduce unnecessary third-party scripts
Investigate server response
Optimize fonts and CSS
Configure caching carefully
Reserve space for dynamic content
Retest after every major change

The goal is not a perfect score.

The goal is a page that becomes useful quickly and remains responsive for real visitors.

Original GlitchGuard guide:

https://getglitchguard.com/blog/why-website-loads-slowly-on-mobile?utm_source=devto&utm_medium=syndication&utm_campaign=mobile_speed

Run a free website scan:

https://getglitchguard.com/?utm_source=devto&utm_medium=syndication&utm_campaign=mobile_speed

Technical Checks When Business Emails Go to Spam

GlitchGuard — Sat, 11 Jul 2026 17:20:26 +0000

Business emails can land in spam for reasons that have nothing to do with the message body.

Sometimes the problem is technical.

A business may send normal replies, quotes, invoices, booking confirmations, support messages, or order notifications, but inbox providers may still treat the message as suspicious if the domain setup is weak.

Here are practical technical checks to run when business emails are going to spam.

1. Check SPF

SPF helps define which servers are allowed to send email for a domain.

Check:

Whether an SPF record exists
Whether the correct provider is included
Whether there are duplicate SPF records
Whether the record has syntax errors
Whether old sending providers are still listed
Whether the SPF lookup limit is exceeded

A broken SPF setup can make legitimate messages look suspicious.

2. Check DKIM

DKIM helps prove that a message was not changed after being sent.

Check:

Whether DKIM is enabled in the email provider
Whether the DKIM DNS record exists
Whether the selector matches the provider setup
Whether DKIM is passing
Whether multiple sending services need separate DKIM records

DKIM is especially important for transactional emails, marketing emails, and business communication from custom domains.

3. Check DMARC

DMARC tells inbox providers how to treat emails that fail authentication checks.

Check:

Whether a DMARC record exists
Whether the policy is set correctly
Whether reporting is enabled
Whether SPF and DKIM alignment works
Whether the policy is too strict before setup is ready
Whether unauthorized senders are using the domain

A missing DMARC record can reduce trust and make domain abuse harder to detect.

4. Check MX records

MX records show which servers handle email for the domain.

Check:

Whether MX records exist
Whether they point to the correct provider
Whether old providers are still present
Whether priority values are correct
Whether the email provider confirms the setup

Incorrect MX records can cause receiving problems or inconsistent email behavior.

5. Check website form emails

Many websites send form notifications from the server or from a poorly configured sender address.

Check:

Contact form sender address
Reply-to behavior
SMTP setup
Notification email delivery
Customer confirmation email delivery
Whether emails are sent from an authenticated domain
Whether the website host is sending mail directly

Form emails are often a hidden deliverability problem.

6. Check transactional email setup

For ecommerce stores, SaaS platforms, and service businesses, transactional emails are critical.

Check:

Order confirmations
Booking confirmations
Password resets
Account emails
Invoices
Support replies
Payment receipts
Delivery notifications

These emails should be sent through a trusted and authenticated provider.

7. Check domain reputation

A domain can develop reputation issues over time.

Review:

Blacklist status
Spam complaint history
Sending volume changes
Bounce rates
Old email campaigns
Shared sending infrastructure
Suspicious domain activity

Reputation problems can affect both marketing and normal business emails.

8. Check alignment between tools

A business may use multiple tools to send emails:

Google Workspace
Microsoft 365
Website forms
Email marketing software
Ecommerce platform
CRM
Helpdesk
Transactional email provider

Each tool may need proper authentication.

A common problem is setting up email for one provider while another tool sends unauthenticated messages.

Final checklist

If business emails are going to spam, check:

SPF
DKIM
DMARC
MX records
SMTP setup
Form notifications
Transactional emails
Sending provider authentication
Reply-to settings
Blacklist status
Domain reputation

Email deliverability is not only a copywriting issue.

It is also a technical trust issue.

Original GlitchGuard guide:
https://getglitchguard.com/blog/why-your-business-emails-go-to-spam

Run a free website scan:
https://getglitchguard.com/

Technical Checks for Ecommerce Stores Getting Traffic But No Sales

GlitchGuard — Thu, 09 Jul 2026 09:59:44 +0000

Getting traffic to an ecommerce store is only the first step.

The store still has to convert visitors into buyers.

When an ecommerce store gets traffic but no sales, the issue may not only be the ads, product, or audience. The problem may be hidden inside the website journey.

Here are technical and conversion checks to run before spending more on traffic.

1. Check store speed

Slow ecommerce pages can lose buyers before they see the product.

Review:

Product page load time
Mobile speed
Image size
Theme performance
Third-party apps
Tracking scripts
Checkout page speed
Core Web Vitals

Ecommerce stores often become slow because of heavy images, too many plugins/apps, tracking scripts, and unoptimized themes.

2. Check mobile usability

Many ecommerce visitors arrive on mobile.

Check:

Add-to-cart button visibility
Product image scaling
Variant selection
Tap targets
Menu behavior
Checkout flow
Payment steps
Delivery information
Return policy visibility

A store can look good on desktop and still lose buyers on mobile.

3. Check product page trust

Product pages need to answer buyer doubts quickly.

Review:

Product descriptions
Product images
Reviews
Size/material/usage details
Delivery information
Return/refund policy
Secure payment signals
Contact/support options

A product page should help the buyer feel safe enough to continue.

4. Check checkout friction

Checkout issues are expensive because they happen close to the sale.

Check:

Number of checkout steps
Unexpected fees
Required account creation
Coupon field behavior
Payment method clarity
Shipping timeline
Error messages
Mobile checkout
Order confirmation

If checkout feels risky, confusing, or too long, buyers may abandon the purchase.

5. Check tracking setup

If ecommerce tracking is broken, the store owner may not know where buyers are dropping.

Check:

Product view events
Add-to-cart events
Begin checkout events
Purchase events
Payment errors
Abandoned checkout tracking
Traffic source tracking
Mobile vs desktop behavior

Bad tracking can make optimization difficult because the real leak is hidden.

6. Check message match

If traffic comes from ads, the landing page should match the promise.

Review whether the page matches:

The ad headline
The product shown in the ad
The offer
The price expectation
The customer intent
The call-to-action

A mismatch between traffic source and landing page can reduce conversions.

7. Check trust and security basics

Ecommerce buyers need safety signals.

Review:

HTTPS
Valid SSL certificate
Privacy policy
Terms
Return/refund policy
Contact details
Payment security
Real business information
Support options

Missing trust signals can create hesitation.

Final checklist

If an ecommerce store gets traffic but no sales, check:

Store speed
Mobile usability
Product page quality
Reviews and proof
Trust signals
Checkout flow
Payment confidence
Delivery clarity
Tracking setup
Technical SEO basics
Email/domain trust

More traffic does not fix a leaking store.

It only sends more visitors into the same broken buying journey.

Original GlitchGuard guide:
https://getglitchguard.com/blog/ecommerce-store-gets-traffic-but-no-sales

Run a free website scan:
https://getglitchguard.com/

Technical Checks for Google Ads Clicks With No Sales

GlitchGuard — Thu, 09 Jul 2026 09:38:43 +0000

Google Ads can bring visitors to a website, but the website still has to convert them.

When a campaign gets clicks but no sales, the first reaction is often to blame the ads. Sometimes the campaign is the problem. But many times, the issue happens after the click.

The landing page may be slow, unclear, untrusted, poorly tracked, or difficult to use on mobile.

Here are technical and website checks to run before increasing the ad budget.

1. Check landing page speed

A slow landing page can lose visitors before they see the offer.

Review:

Page load time
Core Web Vitals
Image size
Third-party scripts
Render-blocking resources
Server response time
Mobile speed
Checkout or form page speed

Paid traffic is expensive. Slow pages make it more expensive.

2. Check tracking setup

If tracking is broken, campaign performance data may be misleading.

Check:

GA4 events
Google Tag Manager setup
Google Ads conversion actions
Meta Pixel events
Form submission tracking
Checkout events
Phone call tracking
Thank-you page tracking
Duplicate conversion events

Bad tracking can make good campaigns look bad and bad campaigns look better than they are.

3. Check message match

The landing page should match the ad.

Review whether the page matches:

The keyword
The ad headline
The offer
The user intent
The call-to-action
The product or service promise

If the ad promises one thing and the page delivers another, visitors may leave quickly.

4. Check mobile usability

Many ad clicks happen on mobile.

Check:

CTA visibility
Tap targets
Menu behavior
Form usability
Checkout flow
Font size
Image scaling
Sticky buttons
Page layout
Trust signals on mobile

A landing page can look good on desktop and still lose customers on mobile.

5. Check trust signals

Paid visitors often arrive cold. They need proof quickly.

Review whether the page includes:

Clear contact details
Real business identity
Reviews or testimonials
HTTPS
Privacy policy
Refund or service policy
Payment trust signals
Visible support options
Real product or service photos

Weak trust signals can create hesitation.

6. Check forms and checkout paths

The visitor may want to take action but still fail because the conversion path is broken.

Check:

Form submission
Required fields
Error messages
Confirmation messages
Checkout friction
Payment steps
Coupon fields
Delivery/service information
Booking flow
Mobile checkout

These issues usually happen close to the conversion, which makes them especially costly.

7. Check analytics quality

Do not only ask whether traffic is coming in.

Ask:

Which pages are visitors landing on?
Where do they leave?
Are events firing correctly?
Are conversions being counted?
Are users dropping at forms or checkout?
Are mobile users behaving differently?
Are paid visitors seeing the right page?

Without analytics quality, optimization becomes guesswork.

Final checklist

If Google Ads gets clicks but no sales, check:

Landing page speed
Mobile usability
Message match
CTA clarity
Tracking setup
Analytics events
Trust signals
Forms
Checkout flow
Security signals

The campaign may be doing its job.

The website may be where the conversion is being lost.

Original GlitchGuard guide:
https://getglitchguard.com/blog/google-ads-clicks-but-no-sales

Why Google Is Not Indexing Your Pages: Technical Checks to Run First

GlitchGuard — Wed, 08 Jul 2026 22:16:56 +0000

A page cannot bring organic traffic if Google cannot discover, crawl, understand, or index it.

Many website owners think indexing problems are always caused by poor content or weak backlinks. Sometimes that is true. But many indexing issues start with simple technical problems that quietly block important pages from appearing in Google Search.

Before rewriting pages or publishing more content, it is useful to check the technical foundation first.

1. Check whether the page is discoverable

Google needs a path to find the page.

Check whether the page is:

Included in the sitemap
Linked from other pages
Accessible from the main navigation or internal links
Not hidden behind forms, scripts, or login walls
Not orphaned from the rest of the website

If a page has no internal links pointing to it, Google may struggle to discover or prioritize it.

2. Review robots.txt

The robots.txt file can tell search engines which parts of a website they are allowed or not allowed to crawl.

Common problems include:

Blocking important directories
Blocking CSS or JavaScript resources
Blocking blog or product pages by mistake
Using broad disallow rules
Forgetting old staging rules after launch

A single wrong robots.txt rule can prevent important pages from being crawled.

3. Check for noindex tags

A noindex tag tells search engines not to include a page in search results.

This is useful for some pages, but dangerous when applied by mistake.

Check for noindex tags on:

Blog posts
Service pages
Product pages
Category pages
Landing pages
Homepage sections
Important business pages

Noindex tags are common after redesigns, migrations, or staging-to-live deployments.

4. Review canonical tags

Canonical tags help search engines understand the preferred version of a page.

Canonical issues can happen when:

A page points to the wrong URL
Multiple pages canonicalize to one unrelated page
HTTP and HTTPS versions conflict
A page canonicalizes to a deleted or redirected URL
Ecommerce filters generate duplicate canonical confusion

If the canonical tag points Google away from the page, the page may not be indexed as expected.

5. Check sitemap quality

A sitemap should help search engines find important URLs.

Review whether the sitemap includes:

Important live pages
Correct canonical URLs
Updated lastmod dates
No broken URLs
No redirected URLs
No noindex URLs
No staging or test pages

A sitemap with low-quality, redirected, blocked, or noindex URLs can create confusion.

6. Look for crawl errors

Technical errors can stop Google from accessing a page.

Check for:

404 errors
500 server errors
Redirect loops
Timeout errors
DNS issues
Blocked resources
Soft 404 pages

If Google repeatedly sees errors, it may delay or avoid indexing the page.

7. Review internal linking

Internal links help search engines understand page importance.

Pages that matter should not be buried.

Check whether the page is linked from:

Homepage
Category pages
Related blog posts
Main service pages
Footer or resource sections
Relevant internal content

A page that has no strong internal links may be treated as less important.

8. Check content quality and uniqueness

Technical access is not the only indexing factor.

A page may be crawled but still not indexed if it looks thin, duplicated, low-value, or too similar to other pages.

Review:

Is the page useful?
Does it answer a clear search intent?
Is it too short?
Is it copied from another page?
Is it mostly boilerplate?
Does it provide something different from similar pages?

Technical fixes help, but the page still needs to deserve indexing.

9. Use Google Search Console

Google Search Console can help identify indexing issues.

Useful places to check include:

Page indexing report
URL Inspection Tool
Crawl stats
Sitemap submission
Manual actions
Core Web Vitals
Enhancements and structured data reports

The URL Inspection Tool is especially useful because it can show whether Google can crawl the page and whether the page is indexed.

Final checklist

If Google is not indexing your page, check:

Sitemap inclusion
Internal links
Robots.txt
Noindex tags
Canonical tags
Redirects
Server errors
Crawlability
Page quality
Duplicate content
Google Search Console status

Indexing problems are not always solved by publishing more content.

Sometimes the first step is finding the technical issue that stops Google from trusting, crawling, or selecting the page.

Original GlitchGuard guide:
https://getglitchguard.com/blog/why-google-is-not-indexing-your-pages

Before You Spend More on Ads, Check the Website First

GlitchGuard — Wed, 08 Jul 2026 21:44:19 +0000

Many businesses blame the campaign when leads and sales do not come in.

The ads are not working.
The audience is wrong.
The offer is weak.
The budget is too small.
The campaign needs more testing.

Sometimes that is true.

But many times, the ads are not the main problem. The website is.

A business can pay for traffic, get visitors, and still lose customers because the website is not ready to convert them.

That is one of the most expensive problems in digital marketing.

Clicks are not customers.

A click only means someone was interested enough to visit. It does not mean the page loaded fast enough. It does not mean the visitor trusted the business. It does not mean the call-to-action was clear. It does not mean the form worked. It does not mean the checkout was smooth. It does not mean conversion tracking was set up properly.

This is why increasing ad spend too early can make the problem worse.

If a website is leaking visitors, more traffic only sends more people into the same broken journey.

Before spending more on ads, businesses should check:

Page speed
Mobile experience
CTA clarity
Forms and checkout paths
Trust signals
Security signals
Tracking and analytics
Technical SEO basics
Email/domain trust
Landing page relevance

For ecommerce stores, this may show up as traffic but no sales.

For local businesses, it may show up as visits but no calls, bookings, or enquiries.

For service businesses, it may show up as clicks but no qualified leads.

For marketers, it may show up as poor campaign performance even when the campaign itself is not the root issue.

The website is not just a digital brochure. It is part of the sales process.

If the website is slow, confusing, untrusted, poorly tracked, or hard to use on mobile, customers can leave before the business even knows what happened.

The smarter question is not only:

“Are we getting traffic?”

The better question is:

“Is our website ready to convert the traffic we are paying for?”

GlitchGuard helps businesses find hidden website issues affecting traffic, leads, sales, trust, ad performance, email deliverability, and conversions.

Before spending more on ads, run a free website scan:

https://getglitchguard.com/

For a deeper checklist, read the full GlitchGuard guide:
https://getglitchguard.com/blog/website-audit-checklist-before-spending-more-on-ads