This article explains why Cloudflare DNS does not provide a 14400-second (4-hour) TTL option while Hostinger recommends TTL 14400 for MX records, and whether this mismatch causes email delivery, DNS, or compliance issues.
It covers:
DNS TTL behavior in Cloudflare
Hostinger MX record expectations
Real-world impact of TTL differences
Correct configuration and best practices
Common misconceptions and support escalations
This document is intended for production environments, not beginner setups.
Cloudflare – Authoritative DNS provider with fixed TTL tiers
Hostinger – Hosting and email provider recommending specific MX TTL values
Email transport using SMTP (RFC 5321) and DNS (RFC 1034/1035)
MX (Mail Exchange) records
TTL (Time To Live) defines how long DNS resolvers cache a record before re-querying authoritative name servers.
TTL is expressed in seconds
Lower TTL = faster propagation, higher query volume
Higher TTL = slower changes, better cache efficiency
Cloudflare does NOT allow arbitrary TTL values on most plans.
| UI Value | Seconds |
|---|---|
| Auto | Cloudflare managed |
| 2 hours | 7200 |
| 5 hours | 18000 |
| 1 day | 86400 |
➡️ 14400 seconds (4 hours) is NOT available
This is a platform design choice, not a misconfiguration.
Hostinger documentation typically shows:
TTL: 14400
14400 is a recommendation, not a requirement
Hostinger mail servers do not enforce TTL validation
SMTP delivery does not depend on TTL exactness
? RFC standards do not mandate a specific TTL for MX records
No.
| Component | Impact |
|---|---|
| SMTP delivery | ❌ None |
| Inbound mail | ❌ None |
| Outbound mail | ❌ None |
| Spam filtering | ❌ None |
| Mail reputation | ❌ None |
| RFC compliance | ❌ None |
TTL only affects DNS cache refresh frequency
Mail servers resolve MX records independently
Priority and hostname matter — TTL precision does not
Closest available value to 14400
Balanced cache efficiency
Fully supported by Cloudflare
✅ 2 hours (7200) is also acceptable
❌ Avoid Auto TTL unless explicitly required
Root Cause: Misreading UI warnings
Fix: Ignore — informational only
Root Cause: Confusing TTL with SMTP retry timers
Fix: TTL affects DNS cache, not SMTP queues
Root Cause: Proxy misunderstanding
Fix: MX records are always DNS-only in Cloudflare
Expected:
Check:
TTL ≠ 14400 → Not an issue
TTL does not affect:
SPF
DKIM
DMARC
TLS (STARTTLS)
Short TTLs slightly increase DNS query exposure
Long TTLs delay emergency MX failover
? TTL choice is operational, not security-critical
✔ Use 5 hours TTL in Cloudflare
✔ Keep MX priorities exactly as Hostinger specifies
✔ Do not proxy MX records
✔ Separate DNS, mail, and FTP troubleshooting
✔ Document TTL limitations for support teams
❌ Do not migrate DNS just to match TTL
❌ Do not add duplicate MX records
❌ Do not remove working MX records due to TTL warnings
❌ Do not open mail tickets solely for TTL mismatch
A TTL mismatch between Hostinger’s recommended 14400 seconds and Cloudflare’s fixed TTL options is normal, expected, and harmless.
Cloudflare’s 2-hour or 5-hour TTL values are fully compatible with Hostinger mail services and comply with DNS and SMTP standards.
This scenario does not require remediation unless email delivery issues exist for unrelated reasons.
#Cloudflare #Hostinger #DNS #MXRecords #EmailDNS #TTL #ITSupport #SysAdmin #MailServer #SMTP #DNSConfig #CloudflareDNS #HostingerEmail #TechKB #EmailInfrastructure #NetworkEngineering #DomainManagement #DNSIssues #EmailTroubleshooting #RFC #ITOperations #ServerAdmin #EmailSetup #DNSManagement #MailFlow #EmailSystems #CloudHosting #WebHosting #EnterpriseIT #ITKnowledgeBase #CloudDNS #EmailDelivery #DNSArchitecture #MailSecurity #ITBestPractices #TechSupport #DNSResolution #EmailAdmin #HostingSupport #Infrastructure #EmailOps #CloudInfra #DNSRecords #MailRouting #EmailEngineering #HostingTech
